Now, more than ever, is the time to cease adding components to itemrenderers on the whim and start really thinking about what should be included; what  the minimalist components are that will do the job right.

If you are interested in performance and memory issues in AS3 I would highly recommend reading the following:

Fast Integer math:
http://lab.polygonal.de/2007/05/10/bitwise-gems-fast-integer-math/

If you constantly have to measure items for display (positions etc…) it can have a lot of benefit using ‘Bitwise Operators’ (x << 1) as they are incredibly faster than your typical native operators (x * 2)

Optimizing Mobile Content:
http://www.bytearray.org/?p=1363

This is by far the greatest white paper I have found so far about generally optimizing AS3.  Do not let the mobile part detour you -  a very good read for flash overall

Using Vectors in Actionscript:
Mike Chambers Article ->

The new Vector class is simply a typed ‘Array’ with huge performance benefits (Kick ass and chew bubblegum)

On to some more Item Renderer specific guidelines

____________________________________________________________________________________

Extract the common visual elements

It is a good starting point to extract all the common visual items from the itemrenderers. Particularly useful if you use ‘on mouseOver show’ controls as illustrated below:

As you can see the controls are only required when a user rolls over an Item and therefore these controls (play && download buttons) only need to be instantiated once == Yippie much better performance + lower memory usage.

How to create the above TileList example:

Each Item Renderer will only have the Image and associated text (in this case album/artist name) and the controls will be created and added to the parent item (List – Gumbo, TileList-Flex3 etc…), we can then listen to the ITEM_ROLL_OUT && ITEM_ROLL_OVER events and position/show our controls accordingly using the X & Y coordinates of the event.target which will be each Item in the list.

View Source

As you scroll through the above list you can see the RED square following the items in the list (I am using tweener to follow the list but this can be popped up in the correct position instantly), it is not so apparently beneficial with so little items though start to increase the numbers and watch the render time lower and physical memory usage drop off.

Using images inside an itemrenderer

The approach to take is dependant on if the images are static or dynamic/remote, I’ll cover remote images in detail though by doing this it should answer any query’s you may have about static ones.

Remote/Dynamic Images

The easiest and heavy approach is to simply use the “Image” component (mx.controls.Image), the Image is great to use outside of an itemrender though you when you look into the image class you realize it extends SWFLoader (hence why all the loading is done for you), this can be extremely expensive in memory.

Solution: Use the new BitmapImage (spark.primitives.BitmapImage) component in junction with a static loader class (Simple static class external where all loading is handled for you).

You could also make use of current ‘Bulk Loaders‘ such as http://code.google.com/p/bulk-loader/, It is almost always better to build these types of things yourself though (in terms of performance), if anybody needs some more details please just Twitter/Hola/Email/Touch-Me

Text

When building Flex 4 Applications you should use the Spark controls where possible, the spark controls are lighter and have better font embedding, if you are NOT using “Right to Left” text you should NOT be using RichText (made the mistake early on).

The spark label (spark.components.Label) field is light enough to use with large data providers

nothing more to say here….

Events

As much as we would like ‘Events’ not to be used inside item renderers we simply can not survive without them, one of the key things to remember is that if we do not REMOVE/DISPOSE the EventListeners when the itemrenderer is destroyed (removed from stage, data changed in list) the flash Garbage Collector may not be able to completely destroy it.

/**
* Dispose Item
* @public
* */
public function dispose( ):void
{
	removeEventListeners( );
	//Destroy Children && Elements
}
 
/**
* Activate Deactivate Component
* @private
* */
private function activateDeactivate( evt:Event ):void
{
	switch( evt.type )
	{
		case Event.ADDED_TO_STAGE:
			addEventListeners( );
			break;
		case Event.REMOVED_FROM_STAGE:
			dispose( );
			break;
	}
}
/**
* Add Event Listeners
* @private
* */
private function addEventListeners( ):void
{
	addEventListener( Event.REMOVED_FROM_STAGE, activateDeactivate, false, 0, true );
}
/**
* Remove Event Listeners
* @private
* */
private function removeEventListeners( ):void
{
	removeEventListener( Event.REMOVED_FROM_STAGE, activateDeactiveHandler, false );
 
       //Remove all other event listeners here
}

This example shows how you could handle adding and removing events from the renderer, when the renderer is destroyed it is removed from the stage causing the Event.REMOVED_FROM_STAGE to dispatch, we can not remove all events and make sure all children/elements are destroyed correctly (Garbage Collector == Happy).

Typical I create an interface (IDisposable) and implement this with function destroy( ):void.

It would be worth noting this applies to any custom component, it is good to clean up after yourself (remember wifey giving you a hard time about the dishes!)

Timers VS EnterFrame

I have no idea why somebody would need either of these in Itemrenderer’s, perhaps some Photoshop ninja requires an animated swirl every couple of seconds to tempt users to interact.  I would personally  fight this off as much as possible, though if  unavoidable it is good to understand the differences between these two approaches.

The facts:

1. Timers are more expensive than the EnterFrame event (more CPU intensive).
2. Timers are more accurate than the EnterFrame as the EnterFrame event relies heavily on a users CPU (a slower CPU == less times EnterFrame fired) though it is not true that the Timer is 100% accurate itself, more information can be found here http://www.bit-101.com/blog/?p=910

This is getting long and bloated which is exactly what I wanted to avoid, maybe this should be done in parts (see you in part II)