Summary:
Without EGL_PLATFORM environment variable, eglInitialize() can be
failed because egl tried to load DRM platform instead of X11 platform and it
tried to handle XDisplay pointer as a gbm_device pointer as well.
The failure seems to be occured especially if the egl was built
with DRM platform as native platform.
This revision can prevent the failure by indicating proper egl platform using
EGL_PLATFORM environment variable.
@fix
Reviewers: gwanglim, jaehwan, seoz
Reviewed By: seoz
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1828
If MSAA was requested, it is very likely that no config was
found (depending on the driver), so we'll try again without
MSAA. Yeah, this might not look very smooth but it should be
better that failing at eglMakeCurrent.
Carefully select the requested EGL config and match it with
the available visual from X, including the following options:
- Stencil
- Depth
- MSAA
TODO: The same thing for GLX. And fix direct rendering as well.
this cleans oyt a few bits o9f old glx context handling code that are
no longer used as well as avoids causing server-side to crash on
tryng to set a "none" glxwindow as current. this is what cases the
nvidia server-side crashes.
Summary: glsym_evas_gl_common_error_set used here leads to an implicit
declaration in compiler warnings. Remove the call to that function and
just print out an error message. This is a cleanup function anyway.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: In fixing a Coverity issue, I copy/pasted a call to
evas_gl_common_error_set without compiling :( Bad me !! This commit
fixes the issue (data was undefined). Since evas_gl_common_error_set can
take NULL as the data parameter, lets use that.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
evas gl window was freed before new one was created getting shared ctx
to 0 refcount thus freeing everything there - BAD. fix. new issue in
git, not from release
so this is a re-try at the evas gl destination alpha fix. this is what
cedric tried, but done RIGHT. it required adding an ecore_x call to
create a window with correct visual/colormap. it requires doing
visuals totally correctly all the way from ecore_evas to the evas
gl_x11 core. nvidia drivers are very picky about visuals. i also had
to vid the egl/gles code too to do the same thing. nvidia gles/egl
drivers are also picky, mesa is not. this all requires a lot of code
changes. it's far from trivial
this isn't backported for a few reasons:
1. verify this fix doesn't break for anyone.
i tested:
nvidia glx + egl/gles
intel glx + egl/gles
radeon glx
it needs wider testing. nouveau, fglrx for starters and maybe
some other gles/egl drivers.
2. have some review time
3. time to settle before blasting to stable branches
@fix
Not sure if this is very relevant, since GLX does not support
GL-ES as such, anyways... We should be using the extension
GLX_EXT_create_context_es_profile to create proper contexts.
Note: GLX + OpenGL-ES 1.1 crashes at any function call on my
machine (binary bloc driver), while EGL + GLES1.1 is fine.
Forgot to set the TLS value after creating a new context.
No problem would show up in most cases, even in my test app.
But elementary_test GLView would just not work at all, spitting
incomplete FBO errors at me. Damn this one line was hard to find.
But introduced in df66916cd22ec6c4.
This introduces XPixmap usage for indirect rendering.
Of course this works only for the gl_x11 engine... and for
now only when using EGL... and only on some drivers...
damn limitations.
Direct rendering should work on more platforms (eg. some desktop
nvidia cards with the EGL drivers).
Add version param to context_create.
Add support for 1.1 contexts in the GL_X11 engine, and checks
for version in all other engines (return NULL).
Add API wrappers for all OpenGL-ES 1.1 APIs (normal and debug
modes).
Welp, glGetString() crashes if called before eglInit... And this
piece of code is now useless because "safe native" mode is not
used anymore (safe_native is never read).
Remove all safe native-related code.
This will be used to increase the chances of having direct
rendering (no fallback to FBO) even if the window is rotated.
The client is then responsible for handling the view rotation.
@feature
This was affecting use of GL backend when having a transparent window. It
is actually a fix for a bug reported by Thanatermesis. It has been inspired
by D1229.
To reproduce the issue just do ELM_ACCEL=gl elementary_test -to "Icon transparent".
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.
Summary: re->win pointer was not compared with NULL pointer before re->win was referenced.
Reviewers: Hermet
Reviewed By: Hermet
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D910
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 the introduction of new colorspaces for GL_X11
(GRY8, AGRY88 and ETC1), stride_get() would return
an invalid value and data_get() would just abort().
Add proper support for these functions.
ETC1 data will NOT be returned from data_get() and
stride_get() will return 0. This is to avoid people from
messing up badly with encoded color spaces.
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.
GL_READ_FRAMEBUFFER isn't defined when compiling for Wayland
Thanks Stefan for the report.
Also, import GL_FRAMEBUFFER overrides from other GL files, so
that it points to the proper extension (_OES or _EXT if applicable).
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.
even though we don't support rectangle bits in texture targets for
texture-from-pixmap the code checked and complained - problem is it
checked the wrong thing. fixes CID 1135267
Summary: Ensure Evas's eglContext when several eglContexts are used.
Test Plan:
1. Native GLES application works with evas_object_image_native_surface_set
2. One Evas object works with evas map.
Reviewers: seoz, tasn, cedric
Reviewed By: cedric
CC: cedric, raster
Differential Revision: https://phab.enlightenment.org/D534
Signed-off-by: Cedric BAIL <cedric.bail@samsung.com>
Summary: This patch is for QUADRUPLE window buffers.
Test Plan:
When enlightenment uses quadruple buffers or window system can support quadruple buffers,
application can use quadruple buffers with partial rendering
Reviewers: tasn, seoz, raster
Reviewed By: raster
CC: cedric
Differential Revision: https://phab.enlightenment.org/D527
Summary: Ensure eng_window_use in image_content_hint_set
Test Plan:
1. make native OpenGLES application.
2. set evas object image with evas_object_image_native_surface_set.
3. GLES Application try to call eglMakeCurrent with own eglContext, then resize evas object resize
Reviewers: Hermet, raster, cedric
Reviewed By: cedric
CC: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D523
Signed-off-by: Cedric BAIL <cedric.bail@samsung.com>
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.
[Problem] When glTextureDelete is called in image_cache_flush(), it sometimes doesn't work.
[Cause] glTextureDelete is called with the wrong eglContext.
[Solution] Call eng_window_use() in image_cache_flush() and image_cache_set() to use the correct eglContext.
Change-Id: Id7ab1aaeb456be6dbc5f09cb2731ace5399a5dce
Signed-off-by: Cedric Bail <cedric.bail@samsung.com>
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.
If the egl_surface is different from the current one, it may be that the
it has been destroyed already. Removing the below check (and just
checking for different contexts) will avoid calling makecurrent when
destroying a window. That was always failing anyway.
Should fix https://phab.enlightenment.org/T311 for gl_x11 too.
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.
In case of render_mode == EVAS_RENDER_MODE_ASYNC_INIT we're jumping
directly to end which then calls
evas_gl_preload_render_unlock(eng_preload_make_current, re);
Make sure re is initialized with the render engine data so we don't
dereference junk.
Signed-off-by: Daniel Willmann <d.willmann@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.
For native surface rendering (glX, egl) in gl-backend, if pixel get callback
function is called for native rendering, there is a case where evas will
try to call evas_gl_common_context_flush() to flush its remaining commands
in its command queue while the context is set current to the native surface/
context that is called within the pixel get callback. So, I've added an
engine function that forces a flush before it enters the pixel get callback
function.
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..
MinJeong Kim
Jean-Philippe Andre
Carsten Haitzler
Chris Michael
Stefan Schmidt
Cedric BAIL
Jérémy Zurcher
Gwanglim Lee
Cedric BAIL
Tom Hacohen
Jaehyun Cho
ChunEon Park
Taekyun Kim
Cedric BAIL
Sung W. Park
Wonsik Jung
Vostokov Sergey
Daniel Juyung Seo
Stanislav Vorobiov
Sebastian Dransfeld
Sung W. Park
Rafael Antognolli
Daniel Willmann
Sebastian Dransfeld
Chris Michael
Daniel Zaoui