This reverts commit 5e18223f67.
Conflicts:
src/modules/evas/engines/gl_common/evas_gl_context.c
we've got a side effect(another quality issue) of the patch. so revert it.
Masking is not used (there even was a recent commit by Hermet to
remove most of the occurences of mask shaders in GL), and I've
introduced a new ETC1+Alpha feature. Replace the old texm and
associated variables by texa for alpha texures.
To avoid texture bleeding in the texture atlas,
we adjust texture uv point as much as a half uv point.
Especially, this improves the rendering quality when the image has the border
area.
Unless apply this patch,
You might find the rendering result is different with software backened,
if the image has the borders.
In the software backened,
the border line was clear but the gl wasn't.
because the border line was interpolated so the rendering result was not the one we expected.
@fix
Summary:
This patch introduce various new logic for packing/unpacking of Eina Rectangle in a pool.
It is then used by Evas GL backend texture allocation to improve how efficiently we pack
image in texture atlas. This lead to improved memory usage and reduced power consumption
with usually a more stable higher FPS (as it use less texture to do the same task, their
is less texture switch, so saving memory and speed at the same time).
This patch was developped on Cedric's suggestions to optimize the packing logic using Skyline
algorithm. This patch is based on master and is a new submission for earlier phab link
https://phab.enlightenment.org/D774.
Signed-off-by: Sanjay Nirankari <sanjay.n1@samsung.com>
Signed-off-by: Rajeev Ranjan <rajeev.r@samsung.com>
Signed-off-by: Sreedeep Moulik <sreedeep.m@samsung.com>
Reviewers: cedric, raster
CC: wonsik, jpeg, sreedeep.m, sanjay, govi
Differential Revision: https://phab.enlightenment.org/D1063
Signed-off-by: Cedric BAIL <c.bail@partner.samsung.com>
ecore_evas_convert: Add -e/--encoding option
This uses directly the encoding parameter.
For now, used only by the TGV saver, but there is no other way
to specify between ETC1 and ETC2. And we don't have a mixed ETC1+2
mode (yet).
@feature
We prefer ETC2 textures when ETC2 support has been detected.
According to the spec, glCompressedTexSubImage2D should work
for ETC2.
Try even with ETC1. This may fail at runtime. The fallback path
is very dubious right now but without a proper test case I'm
not sure which approach to take.
We can also imagine cases where the GPU supports TexSubImage for
ETC1 but ETC2 is not supported at all. This will need testing, as
this case is not handled.
@feature
Since rg_etc1 now outputs proper BGRA data, the shaders should not
swizzle the colors around. Stick to the normal fragment shaders.
Note: This is not tested.
This symbol should be part of the loaded libraries, can be found
using dlsym, even if eglGetProcAddress() returns NULL.
Add etc1 flag in the debug output.
Summary:
Warning fixed of evas
modules/evas/engines/gl_common/evas_gl_context.c: In function 'evas_gl_common_context_new':
modules/evas/engines/gl_common/evas_gl_context.c:392:32: warning: 'minor' may be used uninitialized in this function [-Wuninitialized]
modules/evas/engines/gl_common/evas_gl_context.c:314:8: note: 'minor' was declared here
modules/evas/engines/gl_common/evas_gl_context.c:392:16: warning: 'major' may be used uninitialized in this function [-Wuninitialized]
modules/evas/engines/gl_common/evas_gl_context.c:313:8: note: 'major' was declared here
@fix
Compilation Warning Fixed
Test Plan: Compile efl
Reviewers: singh.amitesh
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D656
evas_gl_common_buffer_dump can be used to dump all frames into
a series of PNG files. But the filename contained some garbage
characters (and potential segv, too).
(cherry picked from commit a0f886138ed5a28d0d1596df3b805fca06d1ae31)
It is not necessary to dynamically link to glReadPixels since
this is not an extension. This code wouldn't even work on some
devices.
Also, the pixels returned are not premultiplied (yeah >_<)
And some devices (EGL) don't support GL_BGRA... so glReadPixels
would just fail and not fill in the pixels. Conversion is required.
This will be needed by the filters for proxy rendering,
for textures and maps (displacement).
Add new engine functions to unleash the (sluggish) power of glReadPixels.
The idea is to be able to bypass glReadPixels later, so 3 new APIs are
added:
- surface_lock
- surface_read_pixels
- surface_unlock
They must be called in that order.
Note (for history):
glReadPixels was always getting the wrong data during first draw,
but the right data during a redraw...
Why? Well simply because for OpenGL itself, the image had never
been drawn in teh first place! Only the Evas GL context knew
about the image drawing, as it was queued somewhere in the pipe.
One line solution: Call evas_gl_common_context_flush before
doing anything else.
When running in direct rendering mode, properly support partial
rendering if the extension is properly supported.
Also, fixed the SwapBufferwWithDamage rectangle coordinate bug.
It wasn't properly y-inverted before.
At least on recent mesa (since commit 9f07ca11c17), it will find the
mentioned symbols but they won't really work, leading to error messages,
and possibly some other errors. So far, I just ifdef'ed the
glGenFramebuffer and glBindFramebuffer functions, but it may require
others to be ifdef'ed too.
This is just a workaround, to fix https://phab.enlightenment.org/T246.
Added a feature to dump out a png image before calling SwapBuffers.
To turn on the feature, use the following env vars.
EVAS_GL_SWAP_BUFFER_DEBUG_DIR="dir_name" sets the name of the directory
that the files will be output to and enables the debug mode.
EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS=1 will enable the writing of the
files every frame. This in effect turns on the swap_buffer_debug
variable, which can be set on or off in gdb for debugging. This will
allow dumping of certain frames without having to dump out a ton of
files to track down one frame.
NOTE: when using Evas_Object image preload infrastructure the GL texture
upload was uploaded from the main loop during the rendering stage. This
could lead to some frame drop during fast animation due to the time needed
to upload that texture.
This patch fix this problem by uploading a small texture quickly (16x16)
and waiting for going back to the main loop to be able to use the same GL
context from another thread to do the texture upload asynchronously without
blocking the main loop.
it seems glmapbuffer can be nasty overhead on some drivers, so go back
to gldrawarrays by default until such a time as we know a lot more...
i'm looking at YOU nvidia! YOU!
num size.. and alloc size is much bigger as it makes room for 1024
quads per alloc increase (6*1024 vertexes etc.). literally this drops
e17's cpu usage while compositing stuff by 40%...at least in my test
case.