You are currently browsing the monthly archive for July, 2008.

Caching images in your Flex application can greatly improve performance and reduce the overhead of loading external resources.

And I’m not simply talking about using the cacheAsBitmap property to improve rendering performance or the cachePolicy property to speed up animations. I’m talking about caching the actual bitmap data of an image.

To get started, you’ll need a hash map to store the image data. A Dictionary or an associative array will also work just fine.

Loading an image for the first time is the same as usual. You create a new Image object and add a listener for the COMPLETE event:

var image : Image = new Image ();
image.addEventListener (Event.COMPLETE, onImageComplete);


Once the image has finished loading, you add a copy of the bitmap data to the hash map using the image URL as the hash key:

private function onImageComplete (event : Event) : void
{
    var image : Image = event.target as Image;

    if (! imageCache.containsKey (image.source))
    {
        var bitmapData : BitmapData = new BitmapData
            (image.content.width, image.content.height, true);

        bitmapData.draw (image.content);

        imageCache.put (image.source, bitmapData);
    }
}


Now we can use the image as many times as we want without ever having to load it again!

To take advantage of this, you’ll need to check the hash map every time you create a new image (or change the source property) to see if you’ve already cached it:

var image : Image = new Image ();
image.addEventListener (Event.COMPLETE, onImageComplete);

if (imageCache.containsKey (imageURL))
{
    image.source = new Bitmap (imageCache.getValue (imageURL));
}
else
{
    image.source = imageURL;
}


And that’s it!

If you have an application that loads a large number of images you may want to limit the number of cached images to prevent the Flash player memory usage from getting out of hand, but in general caching even several dozen large images only results in a slightly increased footprint.

A simple way to track memory usage in your Flex application is to create a Label that displays the System.totalMemory property and updates it on render events.

This isn’t anything fancy, but it’s useful when checking for memory leaks and helps you avoid making mistakes when dealing with memory intensive applications.

Also, its just kind of cool. 8-)

You can even go a step further and create a button that allows you to manually perform garbage collection. This, coupled with the memory monitor, gives you the basic workings of a Flash Player memory management tool.

Just remember that System.totalMemory reports the total memory in use across ALL instances of Flash Player and not just the current one – so if you have other Flash or Flex applications open your usage patterns will be skewed!

Here’s some sample code for the label and button:

<mx:Label id=”totalMemory”
    text=”{(System.totalMemory / 1024) + ‘ KB’}”
    render=”totalMemory.text = (System.totalMemory / 1024) + ‘ KB’” />

<mx:Button id=”gcButton”
    label=”force garbage collection”
    click=”System.gc ()” />

It seems that Flex Builder 3 has an issue when it comes to reseting warnings about non-bindable properties.

Consider the following example:

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application
    xmlns:mx=”http://www.adobe.com/2006/mxml”>

    <mx:Script>
        <![CDATA[

            [Bindable] public var model : Model;

        ]]>
    </mx:Script>

    <mx:Canvas height=”{model.newHeight}” />

</mx:Application>


package
{
    public class Model
    {
        public var newHeight : Number;
    }
}


As you can see, the MXML file is data-binding the height property in the Canvas container to the newHeight property in the model.

If you compile this application, you should expect to receive the following warning:

Data binding will not be able to detect assignments to “newHeight”

To resolve this, you just need to make the newHeight property bindable. No big deal.

However if you make this change and recompile the application, the warning about the property will not disappear.

It seems that the compiler is not so smart when it comes to bindable property changes. If you go back and edit the MXML file, or clean the project and recompile, the warning will disappear.

While this is nothing more than an annoyance, it’s always good to know that’s it’s not a problem with your code. :-)

Categories