On Mon, 14 Dec 2015 18:20:46 +0000 Mike Blumenkrantz <[email protected]> said:
> 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. keep buffers locked in place (unchanged) until a flush post. even a flush pre/post is no guarantee. for gl this would be called before eglswapbuffers then after. as such rendering CAN STILL BE GOING after a swapbuffer. you would have to do glfinish to ensure this, which is just broken as you make a huge pipeline stall. i would say then - you're doing your buffer management wrong if you need this flush pre/post literally either side of it as even with gl things are deferred and not guaranteed without the above glfinish stall. let me get into that with more detail. you bind a buffer (drm/tbm/gbm/whatever), you draw, you unbind. gl will not have finished rendering the buffer then. the buffer size should, at this point be correct, and content too. given how wayland works, this buffer should be owned by the compositor (conceptually) and not re-used by the client until the compositor releases it. the release would be the flush POST which is called AFTER the flush. that should be ok. though technically we could have started another frame already before the flush post is called. we have to keep in mind that the rendering code can (and really must) move into an async thread for many reasons - performance, drivers, node.js and efl js bindings etc. etc.etc. and flush pre/post have always been pretty rough as to what they really mean other than "well the engine code says it finished" on a flush post. a flush pre is just a stage before the flush of result to the screen - but that is not really defined as to what that exactly means. > 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] > > > > -- ------------- 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
