On Friday, December 28, 2012, Cedric BAIL wrote: > On Fri, Dec 28, 2012 at 12:32 PM, Gustavo Sverzut Barbieri > <barbi...@profusion.mobi <javascript:;>> wrote: > > On Thu, Dec 27, 2012 at 11:08 PM, Cedric BAIL > > <cedric.b...@free.fr<javascript:;>> > wrote: > >> On Wed, Dec 19, 2012 at 1:27 AM, Enlightenment SVN > >> <no-re...@enlightenment.org <javascript:;>> wrote: > >> > Log: > >> > ecore-evas: Async render > >> > > >> > > >> > Author: acidx > >> > Date: 2012-12-18 08:27:26 -0800 (Tue, 18 Dec 2012) > >> > New Revision: 81283 > >> > Trac: http://trac.enlightenment.org/e/changeset/81283 > >> > >> I am just starting to look at this evas async rendering and I am not a > >> big fan of the prototype of evas_render_async. Why do we need to > >> duplicate the evas event infra and specify the Evas_Event_Cb per call > >> to evas_render_async ? It seems to me EVAS_CALLBACK_RENDER_POST should > >> do the job just fine. > > > > you can use that, but we did not want to abuse the already existing evas > > canvas event (with multiple listeners) with that. Also we must return the > > updates list and it must be emitted only when called in async mode (so > > others can differentiate). > > I don't see any abuse here. That infra is here to do just that, notify > when a frame has been rendered. In fact, it looks to me like exactly > the opposite, yet another callback infrastructure and without any > technical reason for it. We do call the RENDER_POST just before > calling the async func callback. There is no point in duplicating > them. > > >> At the same time I don't like the idea of directly giving an Eina_List > >> for update. It should be put in a proper public structure like all > >> others events structure and the list will just be a member of it. Of > >> course that structure should also be send with > >> evas_event_callback_call instead of the current NULL. > > > > That's what I specifically want to avoid. > > > > The list behavior is the same as the evas_render_updates(), you get it > when > > you called it, you must free it... same as before, single listener/owner > as > > the caller. Propagating it to multiple interested may be non-interesting > :-) > > Propagating it is a zero cost. Every one will see the same pointer to > the same data. If they don't want that data, they just need to not > look at it. Zero cost, zero impact.
Its not the performance impact. It's the possible impact of letting multiple peers know about the information you should not. Why didn't you change evas_render_updates() to emit that list? Isn't it strange that the list returned there is dependent on how it was called (render updates x regular?) should we change to always emit render update list? Etc The code itself is pretty minimal. That wasn't the reason. Is to avoid bad consequences in the future by not changing an existing behavior. Looking from the other way: aside from reducing minimally the code by abusing the callback. What do you gain? > -- > Cedric BAIL > > > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net <javascript:;> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
