On Fri, 22 Feb 2008 19:52:06 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:
> Hi, > > I am tracking a slow down since a few days now and I think I finally > understand where it come from. The symptom were some frame glitch > during edje animation, when I called a edje_object_part_text_set. > > By putting more presure on edje_object_part_text_set from a timer, I > was able to loose a lot of time in _edje_part_recalc with around 300 > 000 call to it according to valgrind (when _edje_recalc is called > around 9200). And from what valgrind tell me, most of the cost come > only when called from edje_object_part_text_set (With only 800 calls). > The edje calc make sense, but as only one part change, only part > related to it, will need to be updated and their is no need to > calculate all the other part (as their are not affected by this > change). It's getting worse when you don't have a FPU. In my test, it > cost around 35% of the CPU time in soft float and 15% in edje_*calc. > > If understood the code correctly, when I change a property that > could affect the layout of the edje, _edje_calc is called directly > instead of being defered until render like all native evas_object > behaviour. That's because smart object don't have a render_pre > function. It also need to recalculate all edje part, because their is > actually no way to know what are the part that would be affected by > the change of another part. correct. render_pre's don't exist for smart objects as the smart obj itself is never rendered. what we should have is a render_prepare call and a dirty flag - any objects set to dirty have their render_prepare calls before any other render stuff is done at all, this then will calculate and prepare everything for display (move/resize all sub-objects etc.). this would be the right hook spot for this. this'd eliminate excess calcs by a lot. also dave - remember we still can have a call to force the calc to happen for edje_editor. > So before coding, I would like to know your opinion on : > > - adding a per part list of dependent part. complex - i'd not do this for now. > - adding a list of modified part. maybe - but depends on the previous one to be useful. > - modifying _edje_calc to use this list. again - depends on the previous 2 > - adding a render_pre to evas_smart object. definitely - but see above. i'd add another stage prior to render_pre which would be render_prepare and a list of all items that need a render_prepare. remember that in the case of a swallowed environment, a render_prepare may be issues for a top-level object that then moves/resizes sub edjes - these then end up also going onto this list, so using this list would need to handle deleted objects, and new additions while walking the list. > - call _edje_calc only from a render_pre. yup. this i think will get you most of what you want performance-wise. > -- > Cedric BAIL > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
