The bAS3 Class » performance

FITC San Francisco

Brandon — Sat, 21 Aug 2010 22:40:40 +0000

FITC held it’s first ever event in San Francisco last week where they brought together some of the most creative and innovative minds from Flash’s design and development communities. I had heard about previous FITC events and their increasing reputation for great speakers, educational sessions, and never-before-seen demos experiments, so when I heard they were coming to my new home, San Francisco, I have to admit I got a little giddy.

They sent out an early call for volunteers which I jumped on in a heartbeat. Being a volunteer was a no-brainer for me, it saved a ton of money and for just a little bit of my time I got access to most of the sessions as well as an inside look into how FITC works and what it takes to put it together. I met several of the FITC staff and chatted with them about their jobs of putting on these events all across the world. It’s an impressive feat for them to orchestrate so many moving parts remotely, fly to a new city and have them all fall into place, then turn and do it all over again just a couple months later in another new city! I also thought it was really funny how all these Canadians were caught totally by surprise by San Francisco’s chilly Summer weather, it was warmer in most parts of Canada than it was in SF!

I went to several sessions including the Adobe Keynote with Kevin Lynch, Flex 4 Lifecycle Best Practices with Aaron Pedersen & James Polanco, and High Performance Mobile Content with Flash with Mike Chambers

The Adobe Keynote was great and renewed my confidence that Flash is and will be an integral part of the Internet for a long time to come. For example, cell handset makers are starting to advertise that their devices support Flash, even putting the Flash Player logo on their packaging. I also asked Kevin Lynch a question that has been burning in my mind for a while about the capabilities of CS5’s Device Central. His answer was really, really impressive. Normally you would expect the first iteration of a major feature like Device Central to be somewhat underwhelming, but not so in this case, just a few of the features are:

Simulation of all input types and layouts – In Device Central you can see a little picture of the actual device your testing and play with each and every one of the buttons and input controls it suppors
Memory and CPU Simulation – What’s more important on a mobile device than performance? (See below!) Device Central actually simulates the capabilities of the device you’re testing to let you know how your content will do.
Radio interference – Kevin told a story about how some developers were actually taking test devices into elevators to test how their application performs with degraded reception, so they built this into Device Central!
Screen glare – Whaaaat? Does your application have enough contrast to be seen when the device is being used outdoors? Device Central can help you find out.

Device Central is powerful, but no tool can guarantee that your app will work as designed in real world scenarios, so don’t forget to test yourself, on a real device, because as we all know: ain’t nothing like the real thing, baby.

And finally, I attended Mike Chambers’ session on mobile application performance. I was going in hopes of picking up tips to apply to my day job as a game developer, and I wasn’t disappointed, as most of Mike’s tips could be applied to virtually any application, but is especially important when running in under-powered mobile environments. Here are my Cliff’s notes:

Air 2.5 beta open – Open to anyone who registers. Repurposes most of the work done for iPhone development and applies it to Android.
Bit.ly/as3performance – Grant Skinner’s performance testing framework
Github.com/MikeChambers – Mike Chambers’ Simple Game Framework, a set of utility classes to perform various game related functions like a Centralized Game Loop, Object Pooling, Caching, etc.
Mobile support coming to next version of Flash Builder (don’t know any details of what this means)
ALL vector rendering in AIR 2.5 is done via the GPU, which improves performance on all devices and improves battery life on mobile devices
All vectors on stage are rendered, regardless of screen position. i.e. If you move an object off-screen, it is still iterated over in the rendering phase, wasting resources. To improve this, set visible = false.
A new property called “cacheAsBitmapMatrix” is now available in AIR 2.5, and will be available in the Flash Player in a near release. Right now when you set cacheAsBitmap=true, and then scale or rotate the bitmap, it has to be redrawn. By setting the cacheAsBitmapMatrix to a matrix (usually just the identity matrix), you enable bitmap caching and greatly increase the performance of any redraws that occur.
Performance tip: Do anything you can to prevent redraws (check the redraw regions to figure out what’s being redrawn). Things that force redraws are: Using the drawing API, changing/moving an object or it’s children, removing an object/child, or occluding non-cached objects.
Setting Array/vector.length = 0 is faster than setting array/vector = new Array/Vector
Object instantiation is very expensive, so instead of disposing objects, you can put them back in the pool and reuse them later.
Mouse events are cheaper than touch events on mobile devices, and single finger touch events are automatically translated to mouse events. You should use these mouse events instead of the touch events to improve performance.
Avoid using mouse move which is fired really, REALLY fast, and can cause lots of extra calculations that are made but go unused between frames. Instead, do your updates at the framerate by using ENTER_FRAME
In certain areas where performance is super-important, consider using callbacks rather than events. Event objects have to be created and propagated, which is expensive.
If you’re listening to an object that is deeply-nested in the display list, stop its propagation
Bytearray.org/?p=1363 – A whitepaper called “Optimizing Performance for the ADOBE® FLASH® PLATFORM” (attached), this is the single greatest resource for performance tweaks I’ve ever come across. It validates a lot of the techniques I’m already applying for game development, and points out a few others to consider.

All in all, the 1st annual FITC SF was a resounding success, and you can bet I’ll be back next year!

Creating an Image Cache with ActionScript 3

Brandon — Wed, 19 Aug 2009 03:04:49 +0000

A Flash application that loads images at runtime and uses them over and over won’t attempt to reuse any previously downloaded assets. Instead, the Flash Player will download a new image from the server over and over, wasting time and bandwidth. The additive effect of this can create a real noticeable difference in performance on a large scale.

For example, we ran into this problem on the leaderboard of the PGA Tour Shot Tracker. The leaderboard displays the player’s name and the flag of the country they’re from. There can be hundreds of players in the tournament, but they all come from about 2 dozen countries or so. This setup is a perfect use case for caching images internally.

I started looking around for a solution, and came across this question on StackOverflow.com as well as an excellent pseudo-code example: this blog post.

With about an hour’s worth of free time I created a fully functioning ActionScript image cache of my own. There are only 2 parts:

CachedImage.as – A subclass of the Image control. A CachedImage adds itself to the cache when its COMPLETE event is fired.
ImageCache.as – Stores the BitMapData of the CachedImages in a dictionary and provides a small set of static methods for querying, adding, and retrieving from the cache.

CachedImage.as

package com.bdement.imagecache
{
import flash.events.Event;
 
import mx.controls.Image;
 
public class CachedImage extends Image
{
	private function onComplete(event:Event) : void
	{		
		ImageCache.add(this);
	} 
 
	public override function set source(source:Object) : void
	{
		if(!ImageCache.contains(source)) {
			addEventListener(Event.COMPLETE, onComplete); 
		}			
		super.source = ImageCache.get(source);
	}		
}
}

ImageCache.as

package com.bdement.imagecache
{
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.utils.Dictionary;
 
/**
 * 
 * @author bdement
 * 
 * This class reduces the amount of HTTP requests your application has to make
 * by storing the BitMapData of CachedImage objects in memory for reuse
 * by images created after the first one completes.
 */
public class ImageCache
{
	/**
	 * The internal representation of the cache
	 */		
	private static var cache:Dictionary = new Dictionary(false);				
	/**
	 * All the methods of ImageCache are static, so the constructor shouldn't be called.
	 * 
	 */				
	public function ImageCache()
	{
		throw new Error("You don't need to instantiate the ImageCache!");
	}	
	/**
	 * 
	 * @param imageSource The source of an image
	 * @return Whether the cache already contains the image indicated by imageSource 
	 * 
	 */				
	public static function contains(imageSource:Object) : Boolean
	{
		return cache[imageSource] != null;
	}		
	/**
	 * Retrieves the image 
	 * 
	 * @param imageSource The source of an image
	 * @return Either: The image if it exists in the cache, OR the default
	 * source that was passed in via imageSource.
	 * 
	 */		
	public static function get(imageSource:Object) : Object
	{
		if(contains(imageSource)) {
			trace("using '" + imageSource + "' from cache!");
			return new Bitmap(cache[imageSource] as BitmapData);	
		}
		return imageSource; // String or Object
	}
	/**
	 * Adds an image to the cache
	 * @param image The image to be cached 
	 * 
	 */		
	public static function add(image:CachedImage) : void
	{			
	    if (!contains(image.source))
	    {
	    	trace("adding '" + image.source + "' to cache!");
	        var bitmapData:BitmapData = 
	        	        new BitmapData(	image.content.width, 
	        	                                        image.content.height,
                                                                true,
	        		                                0x00000000);
 
	        bitmapData.draw (image.content);
 
	        cache[image.source] = bitmapData;
	    }
	}
 
}
}

Finally, you leverage the ImageCache and CachedImage in your application. You can set the source of your CachedImages in all the ways you normally would, and the ImageCache will be used automatically. Note that our ImageCache doesn’t cache embedded images. This is because embedded images don’t fire the COMPLETE event, which is OK because they’re already cached in memory and they can be reused without using our ImageCache.

Application.mxml

 version="1.0" encoding="utf-8"?>
 
	xmlns:mx="http://www.adobe.com/2006/mxml" 
	xmlns="*"
	width="500" height="200"
	layout="horizontal"	
 >  
	 id="image1" source="http://www.brandondement.com/blog/wp-content/uploads/2009/08/rooster.gif" />			
 
	>
		 text="Set image2.source to..." />
		 click="{image2.source = image1.source}" label="image1.source" toolTip="image1.source" />
		 click="{image2.source = 'http://www.brandondement.com/blog/wp-content/uploads/2009/08/rooster.gif'}"	label="HTTP URL" toolTip="http://www.brandondement.com/blog/wp-content/uploads/2009/08/rooster.gif" />
		 click="{image2.source = null}"	label="null" />
	>
 
	 id="image2" />
 
>

And finally, here’s the working example. To doublecheck that it’s actually using the cache, reload this page with a web debugging proxy on, like Charles. You’ll notice a request for “rooster.gif,” which is the flash movie downloading the image on the left. (There will probably be two, since there are two example files) But notice that when you click the buttons below, no more requests are made. Success!

And here, just for comparison’s sake, is the example using normal mx:Images without caching built in. With Charles on you’ll notice that every time the image source is changed from null, a new request is made!