On Fri, Dec 28, 2012 at 11:32 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> 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. > There is no magic, some data must be copied or locked. To be accurate regarding frames, we must duplicate data. Locking specific elements would led to inconsistent frames (as we need to calculate cutout rectangles, etc) > 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 disagree with that statement. It's less future proof. 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 ? > the direct rendering is easy, we just need to give those functions do_async. what is hard and not in our plans to touch is how to mix main thread with render thread. If evas was the only GL player out there, all the calls could be sent to the render thread, but the main thread may be doing GL as well. Also the map/proxy case right now is in the main thread, which would make the former case void. The proxy/map could be moved to the thread in theory, because it's ordered, then the surface would be ready when its usage is done, but we're on the safe side. For GL the biggest problem is how to lock it and avoid other threads (main) to don't do the make-current. The infrastructure allows that, but the implementation will be dependent on drivers && application. :-( -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
