On Mon, 28 Oct 2013 17:13:08 -0200 Ulisses Furquim <uliss...@gmail.com> said:
> Hi Raster, > > On Mon, Oct 28, 2013 at 12:47 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Fri, 18 Oct 2013 15:19:00 -0300 Ulisses Furquim <uliss...@gmail.com> > > said: > > > >> Raster, > >> > >> On Wed, Oct 16, 2013 at 8:58 PM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >> > On Wed, 16 Oct 2013 12:26:26 -0300 Ulisses Furquim <uliss...@gmail.com> > >> > said: > >> > > >> >> Raster, > >> >> > >> >> On Wed, Oct 16, 2013 at 12:01 PM, Carsten Haitzler > >> >> <ras...@rasterman.com> wrote: > >> >> > raster pushed a commit to branch master. > >> >> > > >> >> > http://git.enlightenment.org/core/efl.git/commit/?id=06c3c0cd0c0e2af7279470ab5b3fd3100e1499db > >> >> > > >> >> > commit 06c3c0cd0c0e2af7279470ab5b3fd3100e1499db > >> >> > Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com> > >> >> > 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. > > > > i did have one... it was in the async "flush" code - the one where the > > mainloop inline does its putimage to the window... but the xob was NULL (i > > didn't even check more than that because i instantly had the twinge that > > "aaaah i bet the xob creation failed due to invalid window id or something > > and thus why its null.. when the code is ASSUMING window id doesnt change > > during rendering"... thus simple - ensure rendering is done before we > > change window id. :) > > Window ID shouldn't change during rendering, that's the point of > having delayed operations. :-) Like Gustavo said I'm interested to > know what really was the problem because I don't think we should be > solving everything by adding evas_sync() calls everywhere. the window id does change. that's the core issue here. it is destroyed and re-created as that is the only way we can switch the visual of the window :) (given ecore-x). thus why i forced the "wait for async to finish"... :) also remember any properties set on the window before are then lost and we rely on ecore-evas to restore the ones it knows about (and has remembered to restore). > >> > 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? > > > > the problem is we are messing with a window and its properties... and the > > code expects to mess with it there and then.. but it gets deferred until > > later .. and this leads to inconsistency issues. as best i saw a primary > > one is that UNTIL we render yet again the window stays hidden. (invisible). > > and our render was over already... > > Hmm.. Raster, please, we need to have this information better on > commits messages or elsewhere. I'm trying to make sure we fix things > the proper way but without information is really difficult to help. > :-/ i didnt think putting in a sync for a rare operation (like switching to an argb target window) would warrant a full essay on it... it's rather simple and minor -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
