On Tue, 15 Dec 2015 22:32:18 +0000 Mike Blumenkrantz <[email protected]> said:
> This got derailed into buffer management somehow when the topic is > unrelated. > > I've pushed another change which fixes the semantics of the FLUSH_PRE > callback to occur in a more accurate place. Even though this is not > completely identical to the synchronous rendering callback positioning, > it's close enough that it works for my purposes. your assumption that buffer and surface sizes match is not right. the surface (object representing it anyway in evas) could be resized by this time. > On Mon, Dec 14, 2015 at 9:14 PM Carsten Haitzler <[email protected]> > wrote: > > > 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 > -- ------------- 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
