Aside from the current runtime being incorrect, since the FLUSH_PRE callback is now called after flush, this creates issues with Wayland rendering due to how the engines are written.
All Wayland buffer management occurs during flush, meaning that immediately prior to this is the only time when window/surface geometries are guaranteed to match the buffer. Unless there is a mechanism to have this callback work as intended/documented, there will always exist a race condition during rendering which will cause a mismatch between window geometry and buffer/surface size. On Fri, Dec 11, 2015 at 7:19 PM Carsten Haitzler <[email protected]> wrote: > On Fri, 11 Dec 2015 13:42:04 +0000 Mike Blumenkrantz > <[email protected]> said: > > > This is going to need a different fix then. At present, RENDER_FLUSH_PRE > > triggers after the outbuf flush, and this breaks Wayland rendering. > > how does it break anything? are you trying to tell me that wayland will be > broken if we do ANY FORM of async rendering that has the buffer display > (be it > eglswapbuffers, or putimage or equivalent) done from a thread? that isn't > going > to be acceptable. if you send back an event to mainloop before you flush > then > send another, they will both be called after the flush anyway as mainloop > will > be delayed in handling them most likely. > > the only option is to send to mainloop and block in render thread UNTIL > mainloop has called the callback, then it unblocks render thread, then > calls > the post afterwards. > > but this will lead to rendering being blocked if mainloop is busy here. > that's > not good at all. > > so what is broken in wayland. explain it to me? > > > On Fri, Dec 11, 2015 at 1:16 AM Carsten Haitzler <[email protected]> > > wrote: > > > > > raster pushed a commit to branch master. > > > > > > > > > > http://git.enlightenment.org/core/efl.git/commit/?id=000beb2f17ff17c3ca600586457c0877af39579b > > > > > > commit 000beb2f17ff17c3ca600586457c0877af39579b > > > Author: Carsten Haitzler (Rasterman) <[email protected]> > > > Date: Fri Dec 11 15:10:53 2015 +0900 > > > > > > Revert "evas: trigger RENDER_FLUSH callbacks during async render" > > > > > > This reverts commit cbb447c878ef779230ebf4470b615b8276c50fa2. > > > > > > 1. this is wrong because evas_render_pipe_wakeup() is being called > IN > > > THE RENDER THREAD. it... SENDS a wakeup back to the mainloop with > > > > > > evas_async_events_put(data, 0, NULL, evas_render_async_wakeup); > > > > > > and you can see that evas_render_async_wakeup() calls > > > evas_render_wakeup() and in evas_render_wakeup() flush pre/post are > > > called, but since the trhead does the flush we cant realyl call > > > before/after, but it retains order... IF there are updates > (haveup). > > > > > > so calling these callbacks FROM a thread is now leading to apps > > > mysteriously exiting. this is mucho bad. just at random i now have > my > > > terminals exiting. > > > --- > > > src/lib/evas/canvas/evas_render.c | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/src/lib/evas/canvas/evas_render.c > > > b/src/lib/evas/canvas/evas_render.c > > > index 249da38..1645ebc 100644 > > > --- a/src/lib/evas/canvas/evas_render.c > > > +++ b/src/lib/evas/canvas/evas_render.c > > > @@ -3071,10 +3071,8 @@ evas_render_pipe_wakeup(void *data) > > > } > > > eina_evlog("+render_output_flush", e->evas, 0.0, NULL); > > > eina_spinlock_release(&(e->render.lock)); > > > - _cb_always_call(e->evas, EVAS_CALLBACK_RENDER_FLUSH_PRE, NULL); > > > e->engine.func->output_flush(e->engine.data.output, > > > EVAS_RENDER_MODE_ASYNC_END); > > > - _cb_always_call(e->evas, EVAS_CALLBACK_RENDER_FLUSH_POST, NULL); > > > eina_evlog("-render_output_flush", e->evas, 0.0, NULL); > > > evas_async_events_put(data, 0, NULL, evas_render_async_wakeup); > > > } > > > > > > -- > > > > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > enlightenment-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
