On Fri, Oct 18, 2013 at 3:19 PM, Ulisses Furquim <[email protected]> wrote: > Raster, > > On Wed, Oct 16, 2013 at 8:58 PM, Carsten Haitzler <[email protected]> > wrote: >> On Wed, 16 Oct 2013 12:26:26 -0300 Ulisses Furquim <[email protected]> said: >> >>> Raster, >>> >>> On Wed, Oct 16, 2013 at 12:01 PM, Carsten Haitzler <[email protected]> >>> wrote: >>> > raster pushed a commit to branch master. >>> > >>> > http://git.enlightenment.org/core/efl.git/commit/?id=06c3c0cd0c0e2af7279470ab5b3fd3100e1499db >>> > >>> > commit 06c3c0cd0c0e2af7279470ab5b3fd3100e1499db >>> > Author: Carsten Haitzler (Rasterman) <[email protected]> >>> > Date: Thu Oct 17 00:00:05 2013 +0900 >>> > >>> > async render -> alpha set. if not visible dont WAIT. do it now. >>> > --- >>> > src/modules/ecore_evas/engines/x/ecore_evas_x.c | 11 ++++++++--- >>> > 1 file changed, 8 insertions(+), 3 deletions(-) >>> > >>> > diff --git a/src/modules/ecore_evas/engines/x/ecore_evas_x.c >>> > b/src/modules/ecore_evas/engines/x/ecore_evas_x.c index 627dd15..69e0709 >>> > 100644 >>> > --- a/src/modules/ecore_evas/engines/x/ecore_evas_x.c >>> > +++ b/src/modules/ecore_evas/engines/x/ecore_evas_x.c >>> > @@ -2284,10 +2284,15 @@ _ecore_evas_x_alpha_set(Ecore_Evas *ee, int alpha) >>> > { >>> > if (ee->in_async_render) >>> > { >>> > - ee->delayed.alpha = alpha; >>> > - ee->delayed.alpha_changed = EINA_TRUE; >>> > - return; >>> > + if (ee->visible) >>> > + { >>> > + ee->delayed.alpha = alpha; >>> > + ee->delayed.alpha_changed = EINA_TRUE; >>> > + return; >>> > + } >>> > } >>> > + if (ee->in_async_render) >>> > + evas_sync(ee->evas); >>> >>> Why? We're syncing just to apply the alpha for those not visible? Your >>> commit message is wrong because we are WAITING on this sync call >>> before the _alpha_do(). Thus it's almost the same as letting the alpha >>> be set the delayed way. Unless I'm missing anything we're not gaining >>> anything with this patch. >> >> no sync -> segv. sync -> no segv. (inside evas async rendering where an xob >> is >> null). since changing to alpha destroys and recreates the window id... not >> surprising. > > Do you have a backtrace? I did some quick testing but no segv for me. > >> if we delay UNCONDITIONALLY (which is what it did before the change - >> regardless of visibility) we WAIT until the window has already rendered >> something (which likely is after a show that came AFTER the set to alpha), >> and >> then now that we rendered and showed... we destroy and re-create again... >> when >> we could have happily just done it without delay/wait and avoided artifacts >> on >> invisible windows. :) > > I understood what you and Mike meant, thanks. But the way it works is > that if we are not async rendering it'll be done with no delay and if > we are async rendering then it'll be delayed until the "old" frame is > completely rendered and no new frames will be sent to render because > we actively drop frames! Thus I don't think that setting alpha would > destroy any new content rendered and showed but only old ones. Does > that make sense?
Yes, Ulisses did explain it to me here in more details and he seems to be right. And yes, you guys do have a problem that was fixed. However Ulisses want to know if we're fixing the problem in the right place or we're just reducing the chances of it happening, thus we need a way to replicate it here so he can check that as he seems the "sync" shouldn't be required there. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (19) 9225-2202 Contact: http://www.gustavobarbieri.com.br/contact ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
