Thank you NVIDIA for breaking your drivers regularly!
eglGetDisplay(x11_display) should work but was consistently
returning 0 instead.
Apparently EGL 1.5 introduced "eglGetPlatformDisplay" that
is more advanced to open a display. So, prefer that over
eglGetDisplay if it's available.
@fix
this will define EGL_WAYLAND_PLANE_WL and EGL_WAYLAND_BUFFER_WL if
missing as SOME older egl public headers dont expose them and yet we
still wans to compile and support the feature should the egl BINARY
etc. actually support this (or be upgraded to support it after efl
compilation).
@fix
this technically isn't needed. it does help in some cases hide driver
or other buffer swap bugs, but in and of itself is not needed, so
remove. at least the drm egl bugs still happen on my pi3 so its
something else...
KHR partial damage must be set once at the beginning of rendering with
buffer damage for the entire scene to be rendered. Doing otherwise can
result in graphical anomalies on some GL implementations.
Some engines should using sending surface damage, until now we'd only ever
provided them with buffer damage.
The difference is that surface damage is the damage to the surface the
compositor is displaying, and the buffer damage is the damage to the
buffer the client has rendered. These are different when the client
is using multiple buffers of different ages to render into.
Anything that calls eglSwapBuffersWithDamage, wl_surface_damage() or
wl_surface_damage_buffer() should be using surface damage, and not
buffer damage.
This patch is intended to make no functional change - any flush cb that
used buffer damage before still should. Actual fixes to follow.
Apologies if I broke any engines - it's a bit of a copy and wasteland
out here.
eglCreateImage and eglCreateImageKHR have different parameters - the
attribute list is EGLint for one and EGLAttrib for the other. Since
EGLAttrib is long, on a 64-bit system it's a different size than EGLint.
This was causing a crash in Enlightenment's wl_x11 on 64-bit machines when
trying to use a gl client.
Add a thin wrapper to use whichever is available and pass the appropriate
sized data.
To properly implement EGL_KHR_partial_update we need to know the buffer
damage before any drawing operations take place. Add a new callback to
software_generic that takes place after combining of surface damage and
swap mode when we actually have this available.
Note: This means the three copy pasta implementations of
EGL_KHR_partial_update scattered around the tree are all wrong. bummer.
Summary:
If native surface is multiple buffer pixmap such as named pixmap, Evas should recreate eglImage everyframe.
Because DDK get the buffer ID once at eglImageCreate time.
So if internal buffer ID is changed, should recreate eglImage.
Test Plan: Wearable Tizen.
Reviewers: wonsik, raster, cedric, jpeg
Reviewed By: jpeg
Subscribers: spacegrapher, dkdk, cedric
Differential Revision: https://phab.enlightenment.org/D4211
This is reverts:
e4c641ed1e
build fix
19eb7b727fbf35620a13fb65b50d3056a484360e:
glx: Fix black windows in E on nvidia
For all extension functions, we need to match with the extension itself
since GetProcAddress() can return a non-NULL value even when the function
does not exist. Drivers can do a runtime mapping depending on the
context. So, we only trust the return value of GetProcAddress() when
we know for sure that the extension exists.
Thus, if a symbol exists we will always prefer it rather than relying
on GetProcAddress().
Also, glGetString(GL_EXTENSIONS) is now deprecated so we're lucky
it still works most of the time. glGetStringi() should be used
instead. This patch changes some of the use cases, but not all.
Fixes T3030 (again)
Fixes T4288
@fix
it serems some changes broke our buffer age querying - we were using
the wrong symbol... the EXT or ARGB onenot the core one which does
work. use that first. then we get buffer age.
@fix
This fixes an issue from 19eb7b727f where the code
would no longer compile due to not finding noext_glXCreatePixmap in
the structure. This was due to the fact that this field was not
compiled into the structure if gl_gles was defined.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This fixes calls to glXCreatePixmap that would consistently
fail on nvidia >= 360.
It seems glXCreatePixmapEXT was used instead of glXCreatePixmap,
and that function always returned 0.
One could assume always using the non-EXT version of the
function should be preferred. Unfortunately, doing so for all
the other functions brings back the black windows.
I'm taking a very careful approach by doing this only for drivers
>= 360.
Fixes T3030
@fix
Summary:
Disables GLES3 support when it cannot be determined that it is
available. Prevents to repeatly request a (missing) gles3 support and
fail.
Fixes T3795.
Reviewers: jpeg
Subscribers: cedric, jpeg
Maniphest Tasks: T3795
Differential Revision: https://phab.enlightenment.org/D4014
some font glyphs are still allocated after tyhe last gl window is
freed which means we can't make current anymore to free textures after
that. this fixes that by flushing gl texture info from the font cache
when the last gl windows are gone.
@fix
Summary:
Evas Image should be independent of render engine.
So remove native.func.data member of RGBA_Image, Evas_GL_Image struct.
And remove data argument,too.
Test Plan: Local test, Tizen3.0 mobile, Desktop englitenment
Reviewers: jpeg, spacegrapher, wonsik
Subscribers: cedric, dkdk
Differential Revision: https://phab.enlightenment.org/D3850
Summary:
If 2 evases refer to same pixmap, use same EvasGL_Image.
But EvasGL_Image can have only one engine data.
When evas related to native is destroyed and another evas use that native, crash occur.
So native callbacks need to be independent to engine data.
Test Plan: mobile, local test
Reviewers: cedric, spacegrapher, wonsik, jpeg
Reviewed By: jpeg
Differential Revision: https://phab.enlightenment.org/D3800
- image_native_init
- image_native_shutdown
init() will be used to test whether the engine supports a
certain type of native image.
Note: Native image support is very much dependent on the engine,
and some stuff like opengl should work everywhere (even in sw
with osmesa) but that's not the case.
Summary:
Add TBM surface in wayland and clean up Native struct on Evas Engine.
Previous TBM surface for evas_object_image's native_surface_set is only in Evas X11 backend.
This patch has the code for wayland backend.
In addition, evas_native_tbm.c is moved to software_generic. Becuase this file is common.
And, Native in Evas_Engine is clean-up.
@feature
Test Plan:
TBM surface is tested with spacegrapher's test app(tbm.c) in Tizen Device.
Pixmap surface is tested in ubuntu with same test app.
EvasGL is tested with elementary_test.
Reviewers: jpeg, spacegrapher, raster, cedric
Subscribers: dkdk, scholb.kim, JoogabYun
Differential Revision: https://phab.enlightenment.org/D3501
When gl window is created, XCreateColormap is called in eng_best_visual_get
but when gl window is freed, Colormap is not freed.
See original patch: D3342.
This is the kind of horrible things you'll encounter when working
with GL. The surface and context need to have matching configuration
otherwise make current will fail, and the only way to get a matching
config is to reuse the config selected to create the context. Gah.
This is the same fix as for EGL. More a hack than a fix, to be honest.
@fix
egl images created using tbm surface for native surface set use
GL_TEXTURE_EXTERNAL_OES as texture target, so we should bind to
this target when rendering.
Dynamic hint set using tbm surface also creates egl images, but
as we only use RGB* colorspace for this we can use GL_TEXTURE_2D.
So, keep track of texture target in shader array, and bind to the
appropriate one.
This also fixes the bug that image_data_get only worked when BOTH
sec_image_map and sec_tbm_surface extensions are supported.
Summary:
Dynamic hint set using tbm surface can only be used when EGL_TIZEN_image_native_surface
extension is supported by the driver. So check for both tbm surface and egl extension.
This is an optimization for EGL only and for the main loop only.
eglGetCurrent{Display,Context,Surface} are expensive calls (they
shouldn't be, but they are). eglMakeCurrent is also very expensive,
so we want as much as possible to avoid calling those functions.
Store the pointers for the main loop as static variables.
Valgrind stats for a quick scrolling session in elm_test:
Before this patch:
- eglGetCurrentContext ~ 0.4%
- eglGetCurrentDisplay ~ 0.4%
After this patch:
- evas_eglGetCurrentContext ~ 0.02%
- evas_eglGetCurrentDisplay ~ 0.02%
There was a terribly complex mechanism to call this function
from the gl_x11 engine to gl_common (evas gl core)... and it
simply didn't work because the function pointer would be NULL.
It is safe to release the compiler at any time since the next
call to glCompileShader will restore it. This may even be a no-op
for all we know (this is driver-dependent).
Summary:
Checking for NULL is redundant here, because if cfgs was NULL, then at
line 760 it would fail.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Differential Revision: https://phab.enlightenment.org/D3238
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
If the current context & surface are already null, avoid
calling eglMakeCurrent again, since it can return an error
(EGL_FALSE but with no error code, thanks Nvidia).