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. So before coding, I would like to know your opinion on : - adding a per part list of dependent part. - adding a list of modified part. - modifying _edje_calc to use this list. - adding a render_pre to evas_smart object. - call _edje_calc only from a render_pre. -- 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
