On Thu, Jan 3, 2013 at 4:25 AM, Cedric BAIL <cedric.b...@free.fr> wrote:
> Hello, > > On Tue, Jan 1, 2013 at 1:00 AM, Ulisses Furquim <ulis...@profusion.mobi> > wrote: > > 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. > > 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. 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. -- 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. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
