Summary:
When direct rendering is enabled, FBO configuration should match
window surface configuration as FBO will be used in fallback cases.
So create FBO with configuration from window surface.
@fix
Summary:
When either FBO or EGL image from texture extension is not supported,
we can use pixmap surface as indirect surface fallback.
Since native pixmaps have (0,0) in the upper left while
FBOs have (0,0) in the lower left, we should invert the y coordinates
when native pixmaps are used as the render target.
To accomodate run-time y-invert check we add a new callback for
EVAS_NATIVE_SURFACE_EVASGL type.
Reviewers: cedric, jpeg
Subscribers: wonsik, mer.kim, cedric
Summary:
Now we can support EVAS_GL_GLES_1_X version for GLX backend
with both direct and indirect rendering.
Refactored api get functions to have similar code path for each version.
@feature
Test Plan: Evas GL test case
Reviewers: cedric, jpeg
Subscribers: cedric, mer.kim, mythri, wonsik
Differential Revision: https://phab.enlightenment.org/D2342
Summary: This fixes Coverity CID1293519 where einfo was being used
Before it was being null checked (which Could have caused a crash if
in fact einfo Was NULL).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Test case:
- Elementary Test
-- GLView
--- Direct rendering
Direct rendering would never happen in reality, because Evas GL
had to fallback. The reason being that DR requires the window
to have a depth buffer, but this depth buffer was no present
in the default config.
From elm, the solution is to set a special accel_preference,
for instance "gl:depth". But setting this value right before
calling elm_win_add() for the GLView test was already too late.
Indeed, evas_x would keep the default configurations and reuse
them no matter what was requested (ie. only RGB and RGBA would
work).
Solution:
Implement a slightly more complex cache based on a hash map instead
of just two static variables. Always request a new config if it's
not found in the current hash. Store that config, and reuse it for
the same config requests.
Tons of line changes because of the name changes and the whitespace
adjustments. Also some variables disappeared into the magic hash table.
Summary:
There is a restriction for some gpu drivers that
eglGetProcAddress must be called after eglMakeCurrent.
So separate egl/glx extensions check from gl_symbols
to be called inside eng_window_new.
Test Plan: egl and glx backend tests
Reviewers: cedric, jpeg
Subscribers: cedric, mer.kim, wonsik
Differential Revision: https://phab.enlightenment.org/D2193
This reverts commit 0585540bb3.
This broke Evas 3d examples. I also suspected some weird things and
wasn't 100% confident with this patch.
Closes T2215.
Thanks for the report.
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, and additionally it will unset
EGL_PLATFORM environment value when the engine free its info.
@fix
Reviewers: gwanglim, seoz, jaehwan, cedric, raster
Subscribers: raster, cedric
Differential Revision: https://phab.enlightenment.org/D1844
Depth32, Stencil16 and MSAA are known to be unsupported on many platforms.
While applications should try not to request them, we can try to fallback
nicely and still render using depth24+stencil8 (which is often supported),
or reducing the number of MSAA samples (until 0 if not supported at all).
Summary:
EVAS_NATIVE_SURFACE_EVASGL uses egl image, but egl image is
not supported in glx backend, so use texture instead.
Test Plan: Local tests on pc
Reviewers: jpeg
Subscribers: cedric, mer.kim, mythri, wonsik
Differential Revision: https://phab.enlightenment.org/D2174
jpeg: fixed casts
Summary:
When the context version between Evas GL and GL backend differs,
we cannot share texture between them.
So, when the driver has support for KHR_gl_texture_2D_image extension,
use EGL image to share between Evas GL and GL backend
Test Plan: Local Evas GL tests for 1.1, 2.0 and 3.0
Reviewers: jpeg
Subscribers: mythri, mer.kim, wonsik, cedric
Differential Revision: https://phab.enlightenment.org/D2115
Summary:
Remove gles1 prefixes for functions that are also used by gles3.
Refactor evgl_make_current a little bit.
Destroy indirect context properly.
Some log message changes and typo fixes.
Test Plan: Local tests on desktop PC
Reviewers: jpeg
Subscribers: mythri, mer.kim, wonsik, cedric
Differential Revision: https://phab.enlightenment.org/D2104
Summary:
This should enable applications to use GLES 3.0 through evas gl.
Todo: Fix indirect rendering issue occuring because texture objects
cannot be shared between different version of GLES contexts.
Todo: extension pointers need to be updated for GLES 3.0
Reviewers: wonsik, spacegrapher, jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2017
@feature
Summary:
When Evas GL runs with direct rendering, it can not set depth, stencil and msaa to Window surface.
This patch is possible to use "option" input paramater of ecore_evas_gl_x11_options_new.
So, new API is not needed.
The other patch is in elementary. The elementary patch will be used this patch.
Test Plan: Test elm gl veiw in elementary_test and JP's test app.
Reviewers: spacegrapher, cedric, raster, jpeg
Reviewed By: jpeg
Subscribers: cedric, mer.kim
Differential Revision: https://phab.enlightenment.org/D2144
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
Note: jpeg changed the original patch a bit (fix style and depth value)
Automatically fallback to OpenGL ES 2.0 if OpenGL ES 3 is not supported.
This is a first step in trying to support GLES 3 for Evas GL.
This commit is also a wild test to see whether using GLES 3 contexts
by default will break anything. The theory says that GLES 3 is
backwards compatible with GLESv2.
So, if anything GL breaks for you... scream loudly!
But before reporting any bugs, please set the env variable:
- export EVAS_GL_DISABLE_GLES3=1
This does not add any requirement for GLESv3 support.
This requires a special context that matches the configuration
required for GLES 1.1. Otherwise eglMakeCurrent() would fail
miserably with EGL_BAD_MATCH in case of indirect rendering
(at least on some drivers).
Summary: If eglGetError sequencially called, second eglGetError() doesn't give the information of real Error.
@fix
Reviewers: raster, jpeg, cedric, Hermet
Subscribers: cedric, spacegrapher, wonsik
Differential Revision: https://phab.enlightenment.org/D1982
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
The exact same ugly macro would appear hundreds of times in the GL
code:
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
Instead, override the common GL functions iif GL_ERRORS is defined.
This greatly simplifies code and removes tons of useless lines.
Also, this will give better debugging output as the exact code line
is printed, and the function name is also printed.
Also, fix linking to the glerr function.
This is a code cleanup. Hopefully I didn't break anything with this
big operation of find & replace.
Summary:
This native surface type is based on the tbm surface used for the tizen platform.
EGL_TIZEN_image_native_surface EGL extension is used to map
tbm surface to an egl image
@feature
Reviewers: raster, cedric, jpeg
Subscribers: cedric, wonsik
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
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.