On Wed, 16 Oct 2013 13:42:23 -0300 Ulisses Furquim <uliss...@gmail.com> wrote:
> Mike, > > On Wed, Oct 16, 2013 at 12:32 PM, Michael Blumenkrantz > <michael.blumenkra...@gmail.com> wrote: > > On Wed, 16 Oct 2013 12:26:26 -0300 > > Ulisses Furquim <uliss...@gmail.com> wrote: > > > >> 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. > >> > >> -- Ulisses > > > > changing alpha requires that we delete and create a new x window if there's > > already one existing. without this patch, changing alpha is totally broken > > and no window > > manager can show our windows. > > Thanks for answering. For those visible we're still delaying so when > returning from alpha_set() that wasn't yet applied. The only change is > that for those not visible after you return from alpha_set() you can > be sure that was already applied. You're telling me that this solves > our windows not being shown by a window manager. > > Do you care to explain in more detail? Sorry, but I still didn't > really understand the details of the problem we're solving. :-) Btw, > it'd be good if our commit messages could include more context on what > is being fixed. > > Regards, > > -- Ulisses okay...to display a canvas, we need to have something to render into, right? in this case, it's an XWindow. normally, we just create a window, show it, and render into it, though not necessarily in that order. the problem is that in the case where we take a visible ecore-evas and change the alpha setting, we need to delete the XWindow and create a new one; you cannot just change the argbness (alpha) on a window. this isn't a complex process: all that needs to be done is delete the old window, create a new window, apply previous attrs, and then redraw into the new XWindow. at some point during the async rewrite, someone deferred the alpha apply. this is fine, but in the case of a non-visible ecore-evas the switch to argb would be made AFTER the draw, and so rendering would be broken for that frame since the window with stuff rendered to it would get deleted. this broke things like elm tooltips with alpha which had static content (text, images). ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
