these were static rect cutouts, so they stayed around on exit and thus
we "lost" them. this nukes them on context free and each new frame.
fixes the "leak"
Note that we can't access gl_common directly as it is not possible to link it
2 times. I also didn't want to force evas to be linked with GL/EGL. So I rely
now on dlsym on about 20 symbols to get that backend going.
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.
Eeeeh. Not only we don't support atlasses with this RGB+A thing
yet, but ETC1 does not even support SubImage2D (according to the
current spec).
Also, fix a few typos in that same function.
Some colorspaces (ETC, S3TC, GRY, ...) don't care about the value
of BGRA support or the alpha flag. So, let's introduce the
new boolean^Wenum value MATCH_ANY ;)
Note: the compressed texture formats with alpha support have been
marked as matching both TRUE and FALSE for alpha. The images
should always have the alpha flag set to TRUE, though.
The BGRA flag really doesn't matter.
These shaders take two textures as input and sample RGB from
texture 1 and alpha from texture 2. This is the non-premultiplied
version, so RGB' = RGB*A.
This includes only the GLSL code.
I saw some GL error messages (with the GLERR() macro activated),
that were caused by GL_INVALID_VALUE.
For some (many) textures, tex->y was 0 but since we now use a 2D
atlas (rectangle allocator), the first row of pixels should be
repeated. This caused uploads to Y = tex->y - 1 = -1, which is
invalid.
Now, the evas loader is supposed to advertise the actual border
size in case of compressed texture formats.
The only case where the border was non zero was ETC formats,
from the TGV loader, so I think we don't need to keep the
previous behaviour (auto-calculate borders for ETC).
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
In case of png, grayscale with transparency format (transparency doesn't mean the png has alpha channel)
gl doesn't prepare that format render.
In this case, set it argb8888 to convert the data in the png loader.
@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>
ETC2 textures were allocated using the same empty slots pool
as RGBA textures.
ETC1 texture atlasses should still be tested.
An extension string is required to avoid using the bad
fallback in place right now. But there is no such thing yet.
this fixes @draisch's report of blankness, but doesn't fix the
garbage. it's something to do with the always render move in elm gl -
it just doesn't seem to be rendering before evas renders, or if it is,
it's failing to work/produce content.
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
Summary:
For drivers that support IMG_multisampled_render_to_texture,
GL_MAX_SAMPLES_IMG should be used to query max supported samples
Likewise, for drivers that support EXT_multisampled_render_to_texture,
GL_MAX_SAMPLES_EXT should be used to query max supported samples
@fix
Reviewers: seoz, Hermet, raster, cedric
Reviewed By: cedric
CC: cedric
Differential Revision: https://phab.enlightenment.org/D948
Summary: The comparison gc->dc with NULL is not necessary. So the unnecessary conditional expression is removed.
Reviewers: Hermet
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D909
CID 1210818
It would be a better and more working fix to use Evas_GL_Image, sadly
no time to do it right now and may be to intrusive for an alpha release.
ETC1/2 textures are (for now) allocated one by one for each image,
because we use only glCompressedTexImage (not SubImage). So,
the texture height must fit that of its content.
This commit bypasses the usual pool allocation logic where textures
are rounded up to the next multiple of 16 pixels in height, in
case of ETC1/2.
Enable 3D features using --enable-evas-3d=yes when configuring.
APIs are exposed through Evas_3D.h.
Currently, evas-3d is being supported only on gl_x11 engine.
Conflicts:
src/lib/evas/Evas_Eo.h
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.
Since the introduction of color spaces other than RGBA8888 in
the GL engines, there was an issue with border images scaled in
GL. The left and right edges were simply not properly copied.
This would then show artifacts when scaling very thin images
(typically 2px wide).
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
In evas_gl_common_image_draw, if an image is drawn with a fresh context,
containing no clip and no cutouts, then it will be wrongly clipped to
the source image size instead of the destination surface size.
This case seems to never happen, ever, since the contexts are always
fully set by the render functions.
@fix
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.
Quick and dirty solution to support the OpenGL engine:
[1] Allocate CPU buffers
[2] Render text and process all effects to these buffers
[3] Push final image as an OpenGL texture.
This patch implements [1].
this changes the internal encoding of font glyphs in evas to use 4bit
uncompressed if small, or 4bit rle (run length encoded) if larger.
this caves at least 50% of memory on fonts - and more if bigger. with
large fonts (40-80pixel size) we can save in the region of 80% of
memory used for glyphs. this also happesn to allow speedups in
rendering too.
if alpha4 is possible (desktopgl) then use it for fonts as this should
cut memory in half for them and possibly speed things up due to less
memory bandwidth needed
this makes efl ignore certain env vars for thnigs and entirely removes
user modules (that no one ever used) etc. etc. to ensure that *IF* an
app is setuid, there isn't a priv escalation path that is easy.
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
parsing problem with opengl_strtok() which would free the previous
token "p", but in some cases it would be a const string. this should
fix CID 1039653
In my config, running terminology with the GL engine and under
cserve2, some image could not be loaded. The tex argument
in evas_gl_preload_target_[un]register was NULL, leading to
an immediate crash.
In evas_gl_api_ext_def.h there're calls such as:
_EVASGL_EXT_DRVNAME(EGL_KHR_image_base)
The macro is defined in evas_gl_api_ext.c as:
(strstr(glexts, #name) != NULL || strstr(glueexts, #name) != NULL)
if (_EVASGL_EXT_CHECK_SUPPORT(name)) *ext_support = 1;
But EGL_KHR_image_base is itself a macro, which is defined
in EGL/eglext.h like this:
Thus, the _EVASGL_EXT_CHECK_SUPPORT macro will unwrap into:
(strstr(glexts, "1") != NULL || strstr(glueexts, "1") != NULL)
instead of intended:
(strstr(glexts, "EGL_KHR_image_base") != NULL ||
strstr(glueexts, "EGL_KHR_image_base") != NULL)
This patch fixes this by applying stringification earlier in
_EVASGL_EXT_DRVNAME
Bugfix reported by jinhyung.jo@samsung.com
Simply call the appropriate cache2 functions when possible
and check for usage of cache2 whenever an evas_cache_ function
is called.
This effectively adds cserve2 image (data) load support for the
GL engines. Fonts were already working out-of-the-box.
Evas GL direct rendering mode didn't properly take into account
the image object's clipping information and clip the region that
it was directly rendering to. Hence there were issues with the
direct rendering region drawing over the objects that are sitting
on top of it.
Also, cleaned up the direct rendering coordinate computation code
and a nasty dependency with image object that should have been
removed a long time ago. Basically the evas-gl engine was directly
accessing the image object data structure for its data when it
really should have just passed along necessary information.
For EvasGL direct rendering, EvasGL does a make_current to the
surface that evas is holding on to. When EvasGL was shutting down
it was wrongly deleting evas' surface. This issue was temporarily
fixed by Raphael before but the proper fix was added.
There was already a surface created by _evgl_tls_resource_create(). If
we assign a new one here, the wrong one will be destroyed at
_evgl_tls_resource_destroy(), and later the GL window will be destroyed
before the surface, causing invalid access errors.
This fixes https://phab.enlightenment.org/T326
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.
Since we take the lock at the start of the function, we should release
the mutex lock if we are going to return.
NB: Fixes Coverity CID1039381
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we get an error trying to "make current" an allocated surface, then
we should free that allocated surface.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
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.
Evas_Common.h should be used for the public header, and rather rename
evas_common.h internal header to another name.
Sa:
Evas_Common_Header.h -> Evas_Common.h
evas_common.h -> evas_common_private.h
Shouldn't have both Evas_Common.h and evas_common.h because of case
insensitive filesystems.
Evas_GL Direct rendering is an optimization path that renders
directly to the window if conditions are met. Because evas gl
backend used to re-render the entire screen, evas_gl direct
rendering didin't have to concern with partial region rendering.
Now that partial rendering/swapping has been applied to evas gl-
backend, evas_gl direct rendering also had to take into account
clip regions. in order to properly apply it, some adjustments
were made to the engine functions and etc.
Basically, EGL does not define a GL_DRAW_FRAMEBUFFER_BINDING so we
test for that and if not found then define it to be
GL_FRAMEBUFFER_BINDING
Signed-off-by: Chris Michael <devilhorns@comcast.net>
(Bad antognolli, No cookie !!)
NB: Fixes build break !!! If we are going to use defines from glext.h,
let's be sure to have the necessary header included Yes ?? ;)
Signed-off-by: Chris Michael <devilhorns@comcast.net>
If we don't do this, the framebuffer object used on shader_array_flush()
will be wrong.
NOTE: shader_array_flush() should take care of setting the fbo
correctly.
Evas engine is created per window but evas_gl engine was not properly
updating the engine info for new windows that are created. So, addressed
the design issue by passing engine_data to evas_gl engine apis..
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.
Resource contexts/surfaces are used for creating resources within Evas_GL.
In oder to handle Evas_GL runnig from different thread than the main one,
a resource context/surface pool was used. This turned out to be unnecssary
as they are not used very frequently. So, I got rid of the pool and
made the resources create as needed.
downscaling. This makes quality much better and "at best"
equates to a 16 point sample (2x2 linear interpolation samples,
where a linear interpolation sample equates to a 2x2 sample).
This will have perfomance impact, but the quality is worth it and
makes it closer to software downscaling in quality. It supports
2x2, 2x1 and 1x2 oversampling. YUV not done, nor image mask
(font shaders not needed).
for direct rendering optimization. For direct rendering in EvasGL,
it falls back to FBO rendering if the conditions are not met. Before,
the fallback resources were created in the beginning but now they are
created and destroyed on need base.
SVN revision: 83057
evas_gl_shader.c file and made an internal generic caching api in
evas_gl_common.h for use in other places ie. evas_gl.
Then implemented evas_gl surface cap. caching code in gl backend to
accelerate the engine creation.
SVN revision: 82321
it is "const char * const *", not "const char **", and it was triggering a warning in our code.
it's just constness and will not trigger an error in our user's code, just an warning that he should fix.
SVN revision: 82278
Stefan Schmidt
Carsten Haitzler
Cedric BAIL
ChunEon Park
Jean-Philippe Andre
Dmytro Dadyka
Rajeev Ranjan
Raoul Hecky
Nicolas Aguirre
Dongyeon Kim
Jaehyun Cho
Cedric Bail
Daniel Zaoui
subhransu
Taekyun Kim
Cedric BAIL
Anand
Jihoon Kim
Sung W. Park
Daniel Juyung Seo
Rafael Antognolli
Sung W. Park
Chris Michael
Daniel Willmann
Tom Hacohen
Sebastian Dransfeld
Eduardo Lima (Etrunko)
Chris Michael
ChunEon Park
Henrique Dante de Almeida
Stefan Schmidt
Gustavo Sverzut Barbieri