Hi, On Thu, Jan 3, 2013 at 9:47 AM, Gustavo Sverzut Barbieri <[email protected]> wrote: > On Thu, Jan 3, 2013 at 4:25 AM, Cedric BAIL <[email protected]> wrote: > >> Hello, >> >> On Tue, Jan 1, 2013 at 1:00 AM, Ulisses Furquim <[email protected]> >> wrote: >> > On Sun, Dec 30, 2012 at 9:50 PM, Cedric BAIL <[email protected]> >> 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. >> >> Indeed. I have done some more investigation on why it impact all this >> test case. Basically the Evas_Thread_Command_* are to big for data >> that don't change that often. It could be good to divide them more. >> Like having a Evas_Thread_Command_Image_Context that will update >> mul_col, render_op and smooth or in font something that will keep gl_* >> and all the almost never changing value. I think you get the idea. We >> need to allocate less often, but also allocate less. >> > > the thread doesn't keep state, so it won't be able to remember these > not-changed. Or do you mean having different commands? One for unscaled > blit, another for scaled, another for colored, ... I don't think they will > differentiate much as these data are small. > > One of the things Ulisses mentioned is that we ref(RGBA_Image) before > sending to thread, and during the way back we async_put a command to > unref(RGBA_Image). We could remove those and enqueue the list of RGBA_Image > to unref at the end, before we issue RENDER_DONE. This will remove couple > of allocations for regular usage.
Cedric's change to async events should have minimized the main loop wake up issues. We could even do this like you said too, though. It should be pretty easy, actually. > I did have some 4MB spike of just Evas_Thread_Command_Font in >> terminology for example. Terminology is pathological here as it has >> one text_prop per character, but I guess we do have the same kind of >> problem with all text rendering as all test with text are slower. >> > > Text grid is quite poorly done, maybe we'll need to create a new engine > call that renders an array, then we add that to the common engine and issue > a specific thread command to do that. Will have less overhead as instead of > issuing 80x24 = 1920 commands to the thread, we do a single one. > > It would be nice if someone that uses textgrid take the time to implement > it properly (evas_object_textgrid.c and common/), then we move this to the > thread engine. That'd be good indeed. Regards, -- 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. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
