Performance implications of the List itemRenderer vs. itemRendererFunction properties

The spark List component in Flex 4 has virtualization enabled by default. Virtualization is an optimization that only renders items that are currently in view which allows the List to support very large data sets. You can learn more about how virtualization works in Flex 4 by reading the Spark Virtualization Spec.

In Flex 4, the spark List provides two methods of defining an item renderer, either by setting it directly using the itemRenderer property, or by defining an itemRendererFunction that returns an item renderer based on a given item. For example this renderer function returns a specific renderer based on the gender property of the item:

public function genderItemRendererFunction(item:*):IFactory
    if (item.gender == "female")
        return new ClassFactory(FemaleItemRenderer);
        return new ClassFactory(MaleItemRenderer);

Virtualization is supported when defining either of these cases, but there is a subtle difference between the two approaches which is whether item renderers get recycled or not.

– If you define an itemRendererFunction then renderers will be created and destroyed roughly as items come into view and out of view.
– If you define an itemRenderer then a set of renderers will be created and then re-used rather than destroying and re-instantiating them.

I created a custom item renderer which when the renderer is created (on creationComplete) the background fades from blue to white. Try scrolling around in both of the two scenarios below and notice the difference in behaviour.

On the left List (itemRenderer): renderers will be created at first and then a few later on as needed to reach a safe buffer amount, but after that no renderers are created or destroyed when scrolling or adding new items.

On the right List (itemRendererFunction): renderers will be created as they come into view so scrolling and adding items will always cause renderers to be created.

View Source

Depending on your item renderer it is typically more efficient to use an itemRenderer over an itemRendererFunction to take advantage of the renderer recycling.

This custom item renderer is for demonstration purposes only, you typically shouldn’t key off of the creationComplete event, but rather override the set data method or key off of the dataChange event.

An enhancement request is filed (SDK-27727) to enable item renderer recycling when using itemRendererFunction. Please vote for it if you would like to see it implemented.

Note: This sample requires Flex SDK or higher. You can get the latest SDK builds from

6 thoughts on “Performance implications of the List itemRenderer vs. itemRendererFunction properties”

  1. The VerticalLayout/HorizontalLayout/TileLayout classes each support virtualization, but it is off by default.

    However the default List skin uses a VerticalLayout and sets useVirtualLayout to true. So if you were to use a List out of the box like this:

    <fx:String>item 0</fx:String>
    <fx:String>item 1</fx:String>


    Then virtualization would be on. You could turn it off by setting the useVirtualLayout property on the List to false. This value then gets pushed down to the List’s layout:

    <s:List useVirtualLayout=”false”>


    But if you were to define a new layout on the List then virtualization will not be on by default unless you specify useVirtualLayout=”true” on the List (or the layout):

    <s:List useVirtualLayout=”true”>
    <s:HorizontalLayout />


  2. Actually, to correct my last comment it looks like if you define a new layout on a List then useVirtualLayout=”true” will be pushed into the layout unless the List has specifically defined useVirtualLayout=”false”.

Comments are closed.