Not providing a call to the first method segfaults in elm_glview
right away. Instead of crashing, we now just issue a runtime error
about the method not being implemented.
If there's a "next" buffer set, we're better off freeing it before we
start to render. This lets us keep gbm from allocating an extra buffer
which it currently never frees.
Previously we'd call this only when we absolutely needed to, so it made
sense to always attempt to free a buffer, including ones on scanout or
pending flip.
However, it's useful to have a way to release the "next" only, so we can
do that before starting a render to free up the buffer that's never going
to be scanned out.
for gl noscale buffers are texture atlases that are fbo's. the point
is never to scale or transofmr them but to render them pixel for pixel
and just store pre-rendered data where its cheaper to do this than
rebuild every time. this is the enigne infra for sw and gl with the gl
code... it SHOULD work... in theory...
preparing an object is a good idea. especially with gl. you want to do
texture uploads BEFORE using textures all in one batch. otherwise this
may mean the gl implementation has to make a copy of your data in a
tmp location then copy it in later when texture becomes "unused" as it
may be in use at the moment, or it may have to stall and wait.
i have seen somewhere around 7-10% speedups on nvidia and intel
drivers with this on given a very special test case i brewed up (1000
32x32 images where i change 1 pixel every frame). this should have
impact really when we are modifying textures a lot. this is all i've
implemented for now, but this should/would/could do much more like
re-order map, proxy renders to render FIRST in a pre-render list
instead of inline and to pre-render fbo/buffer content for complex
objects like text or textblock etc.
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...
so i was just about to add buffer age debugging evlogs to everywhere
doing buffer age and i found... drm gl and wayland gl engines DONT
HANDLE age change like gl_x11! they dont reset to a "full render" for
that frame. well well. this explains bugs i am seeing for sure. very
very bag! i thought this was handled properly. this does lend some
credence to my thoughts about somehow having a single universal buffer
swapping/update calculating and "applying" api inside efl somewhere...
anyway - this fixes this issue for these 2 engines which is a real
necessary fix to be correct.
@fix
The first patch did not work for maps. This explains why the
original code was so weird. But it actually made sense.
After struggling a bit I realized that we really just need
to shuffle around the pixel position on the window to map that
of the position in the canvas (unrotate it).
Note that compatibility with GLSL-ES (for OpenGL ES) implies
we can not use an array initializer like:
vec2 pos[4] = vec2[4](a,b,c,d);
So the code could probably be optimized. But at least this works.
This patch also avoids calling glGetUniformLocation again and
again.
as per mailing list discussion about dropping xcb support now. it
hasn't been complete for a long time, thus not recommented for being
turned on. as we are moving to a wayland world xcbmakes even less
sense. as agreed, time to clean up a bit and remove a distraction as
well as not well tested code. this also updates po's too.
@feature
The original solution was really complex and relied on
transforming the current gl_Position into the screen
coordinate in pixels, and map that to the pixel position
in the mask.
This new solution simply pushes the required vertices for
the mask, based on its geometry. This fixes masks when used
in a rotated window.
Why was it so hard to get right? :(
@fix
These engines are incredibly similar - by sharing the same engine info
structure we'll be able to simplify the wayland ecore_evas bits and
make them much more maintainable.
In the event that an ecore_evas (using wayland_shm) gets hidden then
the corresponding wl_surface gets destroyed. If evas_norender is
called after that, the outbuf_redraws_clear function follows.
Outbuf_redraw_clear function ends up trying to post updates to the
wl_surface however if that wl_surface is gone, then we end up crashing.
This patch addresses that issue by checking for a valid wl_surface
inside the engine before trying to post updates to that wl_surface.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Now that we have redraws_clear exposed through software generic, we can
use that to do the final buffer swap from the main thread instead of doing
it in outbuf_flush which runs from the render thread.
This becomes more important later when other call sites in the main thread
will perform buffer flips.
Based on 95a00b8e49 by Derek Foreman
Signed-off-by: Chris Michael <cp.michael@samsung.com>
When triple buffering it's possible that we'll only need two buffers at
a time for long durations. When we finally call upon a third buffer it
hasn't been used recently enough to do a partial redraw.
By picking the oldest available buffer when multiple buffers are free we
can increase the likelihood of doing partial redraws.
Based on 79409757c6 by Derek Foreman.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
One deadlock and one segfault.
Patch 1:
Software X11 Evas Engine: Fix deadlock
Summary:
The patch bc6e8d2692 introduced a callback responsible to notify the pixels
that were sent to the X server. Since all EFL rendering is done by another
thread, the callback should be called from the main thread context.
To achieve this behaviour evas_software_x11_region_push_hook_call()
was using ecore_thread_main_loop_begin(), which may cause deadlocks, since
evas mainloop waits for the render thread and the render thread waits
the mainloop.
In order to fix this problem, the function
ecore_main_loop_thread_safe_call_async() will be used to
schedule the callback to run in the main loop context.
Since a callback is schedule to run in async manner, the pixels that
were sent to the X server must not be deleted until the user is informed.
In order to avoid more mallocs(), this patch adds the support for refcounts to the
X_Output_Buffer and Xcb_Output_Buffer.
Patch 2:
Ecore_Evas VNC: Use the image size to create the buffer.
In same cases they may differ and may lead to a segfault, since
memcpy() causes a buffer overrun.
Reviewers: bdilly, raster
Reviewed By: raster
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4323
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.
There's no reason why we'd need a full redraw if the buffer age for
this buffer isn't the same as the buffer age for the last buffer, so
let's cut out this thing.
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.
This reverts commit 62ca4486ea.
Honestly, I think the gl_x11 code doesn't make sense either. :)
There's no logical reason that we have to do that, though it may be
hiding some other bug? If that's the case, the bug should be fixed
properly.
This copies the behaviour in opengl_x11 engine, where the buffer
age needs to be continuously the same to be taken into account.
If the age varies, then we fallback to a full redraw.
Apparently this fixes issues on actual devices. I tested this
patch in weston (I didn't have issues before and buffer age is 1).
Carsten Haitzler
Jean Guyomarc'h
Derek Foreman
Chris Michael
Subhransu Mohanty
Stefan Schmidt
Guilherme Iscaro
Jean-Philippe Andre