On Fri, Dec 28, 2012 at 1:33 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > 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
Well, there is no problem in not adding it as current behavior (receiving NULL) is valid. > 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. Well, I kind of see it full of bad consequence. We are now passing a callback that may change from one frame to another. So if for example instead of the current logic, we want to let the next frame go and block after the list of command has been build, then we are entering a complex stage. The more level of asynchronous you add, the more problematic it become. You don't have this issue with evas callback as we can just define that changing the callback list when a frame is rendered is prohibited. As a matter of fact, we will need to move to that kind of asynchronous rendering as the current code add a huge complexity in building the command queue and we should be doing that in parallel of the rendering stage. The current code is 4 times slower than the synchronous one in some widget list simulation in expedite, we really need to have a better score there. > Looking from the other way: aside from reducing minimally the code by > abusing the callback. What do you gain? More future proof code, basically. I have noticed that there is no GL async implementation. Is it planned ? Do you have any idea how to fix all those GL direct rendering call ? -- Cedric BAIL ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 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_122912 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
