Flex Rendering Performance

Question

Recently I found out that there are several things that one can do to massivly slowing down a Flex application. One of those things is the use of many nested layout containers. Another thing which is very problematic is the usage of lot's of relative positioning and sizes.

I do understand that there is a very big amount of calculations that must be done before the layout elements can be displayed. What I do not understand is why the rendering is done all the time. With a certain amount of complexity in your layout your CPU usage is 100% all the time even if there are no changes in the layout.

Why is that? And what can I do about that (without redoing the whole layout)?

Thanks a lot!

Answer 1

It is true that nested containers do slow things down, but I haven't yet been able to get the CPU usage up to 100% yet. The framework should only recalculate the layout of a component after its invalidateDisplayList() has been called. Calling this schedules a call to updateDisplayList, in which the layout of a container is calculated. Consequently, the display lists of the component's children are invalidated as well.

Besides doing it yourself, the displayList can be invalidated by the framework for a variety of reasons. For instance, it is always invalidated after invalidateProperties(). It could be that you have something that accidentally invalidates the display list of some high-level container all the time, thus propagating it down to its children.

Do you have any code to share? And what kind of a system are you running?

Answer 2

Any other solution other then refactoring your layout and not use many nested elements means change the way adobe framework works, and you do not want to do it ! My suggestion although might be painfull , change your view components , use absolute size and location where possible , do not nest too many elements . The reason for the bottle neck with nested components is that the invalidate functions go 2 way , first up the tree from the changed component to the root , then from the root to all its nested elements , that whats taking your cpu .

Answer 3

Finally I found out what exactly the problem with our application was!

The problem was not that we used lot's of nested layout containers. I found out that there was a third party component that we use which attaches an event listener to the ENTER_FRAME-Event. Unfortunately this component does not shutdown properly so the event listener never gets removed. One thing this event triggers is a call to invalidateDisplayList(). I found out that the ENTER_FRAME-Event occurs very often (I still don't know why exactly this happens) and because of that the whole layout is recalculated over and over again. Because of the nested structure of our layouts this is a very time consuming thing to do and therefore the CPU gets very busy!

I could solve this problem by adding some extra code to the component that properly removes the event-listeners if they are no longer needed. The result of that has been that the application now does not need any CPU-power when in idle-mode. Hooray!!