On Sat, Dec 29, 2012 at 12:12 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > 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)
I am disappointed by your answer. Terminology now use 4 times more CPU and your answer is just live with it ! You didn't even look at it. So I took the time to see what was going on, basically we are allocating memory like crazy and waking up the main loop to often. I fixed the main loop wake up issue and I also partially fixed the memory allocation issue. But there is still a problem there, it seems that we do rebuild the glyph array every time we render a text. That should definitively only happen when the text change. I also noticed that we do malloc and copy Evas_Map without using refcounting or anything like that. Could you look at both issue ? >> 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. Ok. First that callback never change once you setup your canvas, so why do we need to pass it every time we draw a frame ? Second as it is related to the frame we are rendering, when we do double or triple buffer rendering, it start to make sense to have more than one queue waiting to be rendered. With your API, we will need to remember one more useless information that callback that never change. So I don't see any benefit with adding that mechanism over using the existing one. In fact, it introduce drawback that the current one doesn't have. > 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. :-( Couldn't we use the fact that we have EvasGL to do the lock at that level properly ? -- 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. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
