Hi Cedric, On Sun, Dec 30, 2012 at 9:50 PM, Cedric BAIL <cedric.b...@free.fr> wrote: > > 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.
Cedric, really, we were focused on making it actually working first. Thanks for taking a look at it and for fixing the problems. I did tell Gustavo we were allocating/deallocating too much memory and we'd have to fix that. As for waking up the main loop too often, that's because we are notifying the main thread _unref() the objects, clearly. > 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 ? After the holidays I'll ask the team to take a look at both of these. Thanks, -- Ulisses >>> 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 -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs ------------------------------------------------------------------------------ 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_122412 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
