On Sun, Apr 13, 2008 at 1:33 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > On Fri, Apr 11, 2008 at 8:56 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > > > > Some of you already know, I am working on improving the speed of > > evas_render_phase1_object_process. The idea is that the list of > > active_object, and object to render will change much between to call > > to evas_render. > > > > I started by removing the use of evas_list and use a growing array > > of evas_object that is only freed on idle. This does bring only a > > small speed improvement. Then I started to cache the result > > evas_render_phase1_object_process and keep it alive except on layer > > change, show, hide and some color set case. On move and resize I > > wanted to just check if the state of stack of call to render_pre is > > still valid and call them accordingly. It's almost working. Just the > > resize is not. I don't understand why yet, but I can't make it work > > the same way as the move. Perhaps someone can help me on understanding > > this. > > > > So the code is attached for your fun, but don't commit it or it > > will break for sure :-) > > After some sleep I found where was the problem and here is an updated > patch that finally work. It improve speed when you don't call > evas_object_show/hide and don't use layer. Each time you call them, > the cache will be droped in other case it will work. > > This improvement will complexify the task when we will one day enable > render_pre for smart object as it make the assumption that no > evas_object are modified during call to evas_render_updates_internal. > > Please review this patch and test it with your application.
no time to test it now, but an overview is: - good, seems to break nothing (as you said); - my general remarks to your coding style: try to avoid aligning variable declaration, it's not used in E and it causes patches to be dirtier than they need to (changes that just change this). I also dislike the "return ;" (with the space) ;-) - my general remarks about patches: try to avoid useless changes, like changing tabs<->spaces and removing trailing white spaces, do it in separate patch before (now you have commit access, just commit these before you play!) - evas_array seems very useful, make it available to evas as a whole! Just have it to take "void *" and it will do just fine. Also, I'd make the increase amount (16) configurable after the array is created (or provide an alternative constructor). - I'd remove the calls to really do things (ie: e->engine.func->output_redraws_rect_del()) from _evas_render_phase1_object_process(), just call _evas_render_phase1_direct() after you built the array... I think this separation will be good and will no cause any damage to performance). OTH, if you want to have performance no matter what, then keep it as is by carry the "should not cache" flag (clean_them), in that case you'd not add to the array at all. as you can see, just minor things. It looks very great so far! PS: do you have the improvements in numbers? Would rock to present it as a chart, let's also make it public somewhere. (I regret for not doing that for the optimizations I did) -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
