Just a simple log domain issue (EvasGL was not initialized, so
ERR() would trigger a fatal error). EvasGL is now initialized
on demand when a new GL surface is requested.
The previous commit modifies the concept of direct rendering
vs. indirect rendering, so some runtime checks (in debug mode
only) will fail.
This commit introduces two new engine functions:
- gl_get_pixels_pre
- gl_get_pixels_post
The latter will be used in a later patch for optimization.
not changed.
Automatically fallback to indirect rendering on FBO or X11 Pixmap
if the Evas Object Image is not marked as dirty. This should
improve the performance and/or power consumption in those
rare cases where this area of the canvas needs to be redrawn
but the GL content has not changed.
@feature
When destroying a GLES 1.1 surface, it is necessary to also
destroy and remove the main surface from the list.
This issue probably never really showed up because people
don't:
- use GLES 1.1
- constantly create & destroy new Evas GL surfaces
- but mostly no one cares about 1.1 anymore :)
@fix
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).
Those 2 new values are here to avoid using environment variables
that have side effects on the whole application.
I'm actually wondering if we shouldn't just kill off the env
vars altogether. Also, direct override is a terrible option that
should never be used.
Memory optimization can make sense (needs more testing tho).
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:
Extension function pointer initialisation requires glGetString(GL_EXTENSIONS).
To get GLESv1 extension string, GLESv1 context has to be bound.
Change involves updating extensions after GLESv1 context has been bound.
Reviewers: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1946
Signed-off-by: Jean-Philippe Andre <jp.andre@samsung.com>
We should use GLESv1 functions in a GLESv1 context to scan for
GLESv1 extensions. Makes sense yeah?
This should expose the proper list... especially enabling FBO
extension when it's supported by the driver.
There was a problem when checking whether the current surface
is compatible with direct rendering. In case of client-side
rotation (it's a flag set on the surface by the app), a surface
can be directly rendered even if the rotation is not 0.
But, before this patch, it was assumed that the surface was
current. Which doesn't make sense because make_current is
called by the pixel callback, from the application, and this
happens *after* we check for direct rendering.
As a consequence, it was not possible to mix directly rendered
surfaces with FBO-based ones, and use client-side rotation.
This patch should solve that issue.
Example scenario:
- Create a direct rendered Evas GL 'sfc' 'ctx'
- Create a PBuffer dummy surface, make it current
- Do some stuff
- Make current (NULL, NULL) to go back to no target
- Make current (sfc, ctx)
--> glClear() will not render anything on screen
Reason:
The current FBO binding is still set to the implicit FBO
bound to the PBuffer surface (it could be any surface, really).
Since this struct is likely to grow in size over time, client apps
built against future versions of EFL might start indexing fields
that are not present in the current form.
Also, don't reset the struct memory as this would break
multithreaded GL applications.
While this is not exactly a fix, I'll backport this.
@fix
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.
- glGetString(GL_VERSION) should not return "OpenGL ES 3.0" because
GLESv3 is not supported yet.
- GL_EXTENSIONS should return only the list of supported extensions
--> disabled for now as the whitelist of safe extensions is way
too small.
Apps would crash if they call make current without creating
a surface in the same thread. I don't see a good reason why
we should have this a limitation.
It will be triggered when EVAS_GL_API_DEBUG is set.
Yeah, that's abusing the variable a bit, as it was intended for
GL calls only, but this is pretty harmless.
Also add string "GL_DEPTH_STENCIL".
This will mark some extension functions as "safe", which means
we don't need to wrap them in order to expose them.
All the known extensions from Evas_GL_API have been marked as safe
for now.
In the future, we may encounter extensions that are not safe
out of the box, but can be wrapped. At that time, we will have
to mark them as safe but return the pointer to the wrapper instead.
Until then, only whitelisted extensions will be supported.
@feature
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).
This is a new feature allowing direct rendering even when
the view is rotated. In that case, the application is responsible
for rotating its view and rendering it properly given the object
geometry.
This implements support for the flag
EVAS_GL_OPTIONS_CLIENT_SIDE_ROTATION
@feature
When using direct rendering, glClear() should not do anything
if the ClearColor was (0,0,0,0). The application would indeed
expect a transparent output (so, see the widgets below the view),
but glClear would erase the pixels instead. So add a quick check
to skip glClear entirely in that specific case.
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.
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
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.
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
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.
Jean-Philippe Andre
Minkyoung Kim
mythri.venugopal
Carsten Haitzler
Cedric BAIL
Dongyeon Kim
Sung W. Park
Sung W. Park
Rafael Antognolli
Chris Michael
Daniel Willmann
Tom Hacohen
Cedric Bail