The result below are tentative until I have confirmed that the code follows the rules (and spirit) of the contest. If you see any issues with any of the top 5 submissions, please post them in the comments. You can view all of the entries in the contest’s GitHub repository.

Here are the results:

You can download the raw results in CSV format from here, or view them on google docs here.

All examples were compiled with MXMLC from the Flex SDK 3.4 (Version 3.4.0 build 9271), with the following command:

mxmlc --target-player=10.0.0 -compiler.source-path ~/src/PerformanceTest/ -- TestRunner.as

Results were obtained by running TestRunner.as. TestRunner.as ran each test 300 times per run. The TestRunner was run a total of 5 times (with the SWF reloaded each time).

Test were run in Safari Version 4.0.4 (6531.21.10) on Mac 10.6.2 in Flash Player 10,0,32,18 (regular). The Mac was a MacPro 2 x 3 GHZ Quad Core Intel Xeon with 8 GB RAM.

I will finalize results and announce the winner either late tonight, on Wednesday (I am traveling on Tuesday). Check back here for updated information, or follow my twitter account at @mesh. I will be awarding prizes to multiple submissions.

UPDATE : (November 17th, 2009) : I am declaring the entries final. Arnaud Gatouillat is the overall winner, and wins Flex Builder, a tshirt, etc…. In addition, given some of the great results that we got from the submissions, I am also going to award a prize (their choice of a tshirt from threadless.org) to the next 3 top entries, which include Grant Skinner, Jim Cheng, and Jean Phillipp Auclair. If you are one of the top four entries, please email me at mesh@adobe.com and we will work out the details.

If you sent me an entry and do not see it in the repository, email me ASAP (without the file). Adobe’s spam system can be a bit overzealous at times, but if I know you sent me something, I can find it.

Also, I have not validated all of the entries yet. I will do that later today or over the weekend. If you see any major issues in a submission, then post them in the comments (do not email me directly about it). My plan is to post the initial test results on Monday, and then finalize Monday night or Tuesday. However, I am traveling early next week, so that might slip a day.

All of the source code is fully commented, so please feel free to ask question, or comment on general techniques in the comments for this post. I think it is a great opportunity to learn from the code, and different approaches. My guess is that we can get something even faster by combining some techniques used by different submissions.

Note that I also submitted my entry, although I am not eligible for the contest. Also, I did not update mine any once I started receiving submissions.

Btw, if someone wants to modify the TestRunner to run all of the entries at once, then I will run it on multiple platforms and devices (including iphone), and report back the results.

Finally, thank you to everyone who submitted. When commenting, please keep in mind that there are various levels of developers who submitted content, so no “j00r (0D3 $U><0r$” comments.

First, a couple items:

1. Make sure to include your name for the copyright in the ProximityManager.as file (replace my name at the top). This is really important, as you have the copyright, and it makez it easier for me to know who the submission is from.
2. Run your submissions again against the latest test files. There have been some minor changes to the test, so make sure they dont affect your results.
3. Test that you are returning valid results. See below for tips about how to do this.
4. Read through the comments in the original contest post, especially the comments that I made. There are some rule clarifications that are important.
5. Make sure you are using testing with the latest contest files. TestRunner.as has had some updates.

Regarding #4, here are some of the rule clarifications:

• For the purposes of the contest, you should use the x, y coordinates of the display objects to determine which cell they are contained within (i.e. you don’t have to worry about a display object straddling two cells).
• Basically, the only information your class has access to is that which is passed to its constructors and methods. Your code cannot make assumptions based on information in the test which is not passed to the ProximityManager class (i.e., how many items there are on the stage, or the fact that the items are not moving, etc…). If I change the parameters of the test that your code does not know about, then your class should still work correctly.
• The bounds argument is now required in ProximityManager constructor. This specifies the bounds of the collision detection / grid area.
• If the positions of the DisplayObjects change, update will be called again. Thus, when update is called, the code should treat it as new data.
• You must return a new Vector from getNeighbors. (You can’t re-use the same Vector instance).

If you have any additional questions about the rules, then please post them on the original post.

Validating Results

Inside of TestRunner.as, there is a checkResults method, which you can use to validate your results.

To run it, uncomment the runTests() method in onStageAdded, and and the add this code:

private function onStageAdded(e:Event):void
{
	...

	//runTests();

	proximityManager.update(items);
	checkResults(checkSprite_3, proximityManager.getNeighbors(checkSprite_3));
}

This will return something that should similar to this:

This test ensures that you are not missing any DisplayObjects which you should return.

To ensure you are not including any DisplayObjects which you should not be, change the for each loop in checkResults to:

private function checkResults(checkSprite:Sprite, items:Vector.<DisplayObject>):Boolean
{
	...

	for each(var disp:Sprite in items)
	{
		disp.graphics.beginFill( 0x0000FF , 1 );
		disp.graphics.drawCircle( 5 , 5 , 5 );
		disp.graphics.endFill();
		disp.alpha = 1;
	}

	...
}

You should not see any dark spots appear.

I have gone through and done an initial validation all of the submissions thus far. There were a couple of entries which were not returning the correct results, and I have emailed those developers. I also did a quick test run on my Mac Book Pro (2.4 Ghz Intel Core 2 Duo), and in general, right now, the bar to reach is an average of 2 – 3 ms per test run. Most submissions use take the same basic approach, but some have some interesting twists. I think there is still a opportunity for someone to take a novel approach and maybe jump ahead.

Remember, contest entries have to be received by me (mesh@adobe.com) by 12 Noon, PST, Friday, November 13.

Goals of contest

1. Get some solid implementations of classes that will be useful to everyone.
2. Get multiple examples of high performance code that everyone can learn from.
3. Drive discussions around implementations, and possible further optimizations (code and architectural).

Keep these goals in mind when writing your code and making your submission.

Contest Task

Implement a class named ProximityManager that divides the stage into a grid with cells sizes of 35px x 35px, and returns all of the display object instances within the same and adjacent cells as a specified display object (that will be passed in).

I have provided a TestRunner.as class that will be used to judge the contest. You cannot change this file. Your entry will consist of a class called ProximityManager.as that implements the constructor and public APIs in the included ProximityManager.as.

Update (November 11, 2009) : For the purposes of the contest, you can use the x, y coordinates of the display objects to determine which cell they are contained within (i.e. you dont have to worry about a display object straddling two cells).

The TestRunner will randomly place 10,000 display objects on the stage. It will then randomly place four target Sprites (checkSprites) instances on the stage.

The test that will be run is:

private function testProximityManager():void
{
	proximityManager.update(items);
	proximityManager.getNeighbors(checkSprite_1);
	proximityManager.getNeighbors(checkSprite_2);
	proximityManager.getNeighbors(checkSprite_3);
	proximityManager.getNeighbors(checkSprite_4);
}

Where items is a Vector of all DisplayObjects to be checked against, and checkSprite is the target Sprite, whose neighbors must be found and returned in a Vector of DisplayObjects.

Tests will be run and results determined using Grant Skinner’s ActionScript 3 Performance Test Harness.

Download Contest Files

All test files and entries will be posted to the ActionScript 3 Development Task Contests GitHub Repository.

Additional Rules

• Code must be release under an MIT license.
• Code must be fully commented.
• Code must be human readable.
• Code must implement the constructor and public APIs defined in the included ProximityManager.as file.
• Code must be implemented in the provided ProximityManager.as class.
• Contest is open to everyone.
• Code must be authored by the submitter.
• Code cannot have any external dependencies (including Flex).
• Code cannot require any additional tools, pre or post processing steps.
• All entry code must include the MIT license at the top, as well as the name of the developer who wrote and is submitting the code.
• Developers may enter more than once, but only entries that take a significantly different approach will be accepted.

Note, that the rules and TestRunner may be tweaked after I post them, but I will try and make any changes or clarifications within 1 day. Please make sure to check back to this post for any changes.

Don’t try to game the contest. If you are not sure if you are, then ping me. This is a community contest for fun and learning. I will make the final call on all disputes and entries. If I think an entry doesn’t abide by the rules, or is trying to game the contest then I may reject the entry. I am very serious about this, so dont mess around.

Update (November 10, 2009) : Basically, the only information your class has access to is that which is passed to its constructors and methods. Your code cannot make assumptions based on information in the test which is not passed to the ProximityManager class (i.e., how many items there are on the stage, or the fact that the items are not moving, etc…). If I change the parameters of the test that your code does not know about, then your class should still work correctly.

The winning entry will be determined by compiling the TestRunner.as (included) and submission class with the latest public release of the mxmlc compiler. The TestRunner SWF will be run 5 times and total times will be combined. The submission with the lowest total time over the test iterations will be the winner. The return values from the getNeighbors API will be validated (an example validation test is included in the TestRunner).

Tests will be run on the latest Flash Player 10 Release (non-debug) version in the Safari browser (latest release version) on an Intel Mac Pro. All submissions will be posted online.

Once the results are announced, ranked, and posted, there will be a short period before the contest is finalized. This will give the community a chance to identify any bugs in the code logic. I will make the final decision about whether any bugs in the logic will disqualify the entry. Basically, if it is a minor bug that will not affect performance, then I will let it pass. If it is a major bug, or has a major impact on performance, then I will probably disqualify the entry. I may give the developer a chance to correct the bug.

Since one of the main goals of the contest is to help generate knowledge on techniques and optimizations, the contest is open to everyone, including Adobe employees. However, if an Adobe employee wins, the prizes will go to the highest ranked non-Adobe employee.

This is the first time I have tried this, so there will be some kinks in the process. Please be patient, and keep the goals and spirit of the contest in mind. If it goes well, then we will do more contests, with different tasks.

If you find any errors / bugs in the TestRunner class, please post them in the comments, and I will get them fixed.

If you have any questions, or want clarification on something, post it in the comments. All clarifications made by me in this post and its comments should be considered part of the rule set.

Watch this blog post, and my twitter account (@mesh) for contest updates and reminders.

File Updates:

Release 0.7 (November 12, 2009)

• TestRunner now waits one second after it has loaded before it runs the performance tests.

Release 0.6 (November 12, 2009)

• checkResults now removes all result items from the stage. This makes it easier to view and validate results

Release 0.5 (November 12, 2009)

• All circles are now drawn so the top left of their bounds is at 0,0.

Release 0.4 (November 11, 2009)

• bounds argument is now required in ProximityManager constructor. This specifies the bounds of the collision detection / grid area.

Release 0.3 (November 11, 2009)

• Fixed Release dates in README.txt
• Added visual validation code to TestRunner.as (thanks to Sean Christmann for the help)
• Made a minor change to how circles are drawn in Display Objects on stage.
  From : disp.graphics.drawCircle( 0 , 0 , 5 );
  To : disp.graphics.drawCircle( 5 , 5 , 5 );

Release 0.2 (November 10, 2009)

• Move SWF meta data from ProximityManager to TestRunner
• Added README.txt file

Release 0.1 (November 10, 2009)

• Initial Release

I am currently working on a Flash based iphone game code-named “pewpew”, which is maintained within my projects repository. As I have begun to work on it more and more, I decided that I wanted to have pewpew in its own git repository. This will make it easier to track issues, as well as give me the option of open sourcing it and allow others to create and submit forks.

Initially it looked like the way to do this was to use git submodules. However that seemed to keep the code linked to the original repository, which I did not want. I could have simply copied the code over and then initialized it as a new repository, but I wanted to maintain the commit history. Finally, I came across an article at GitHub titled Splitting a subpath out into a new repo. This does exactly what I needed (basically, create a new repository from a directory within an existing repository).

After following the steps in the article, I had to do one additional step before I could push the new repository to GitHub. I had to change the origin from the old repository url, to the new one. You can do this by changing the [remote "origin"] url property in the .git/config file to point to the new repository.

Anyways, this worked perfectly, and maintained the history. If anyone has any suggestions for other or better ways to accomplish this, please post it in the comments. Thanks for to everyone who had suggestions about this on twitter.

You can download the slides from here.

Btw, really great conference and vibe, and the speaker list was simply amazing. Congrats to Shawn and the FITC crew for putting on another great event.

Developer FAQ : Official FAQ which answers common questions about creating content for iPhone using Flash.

Why you should NOT care about building apps for the iPhone with Flash : Blog post I made which puts the announcement into the context of the other Flash Player 10.1 announcements.

Flash to iPhone : Excellent article by Veronique Brossier (who was on the private pre-release) going into deep technical detail about creating applications for the iPhone using Flash.

Flash on iPhone : My Experience : Blog post by Ben Garney (of pushbuttonlabs) talking about his experiences building the “Trading Stuff in Outer Space”" game for the iPhone using Flash.

Designing Flash Applications for the iPhone : Max session from Arono Gourdol from the Adobe AIR team, talking about designing content for iPhone applications using Flash.

Optimizing Flash Content for iPhone Applications Max session from Scott Petersen and Chris Brichford (two of the engineers who are working on the Flash to iPhone compiler technology), which goes in depth into how the toolchain works, as well as tips and tricks for optimizing content for the platfrom.

Designing and Developing for the Multiscreen web : Max session from Thibault Imbert (bytearray.org) talking about tip and tricks when developing for mobile devices.

I am also starting to work on a small project which works with pixel data from images, and on which I anticipate performance might be an issue when working with larger images. I figured this would be a good opportunity to use some of the early code as a case study. I wanted to post the process and results here.

The task that I will focus on is grabbing a palette of 16 colors from an image, created by averaging the colors within that image. Upon searching on google, I found a very good solution over at soulwire.co.uk, which I will use as the base for creating the palette. I want to point out that the original code targeted Flash Player 9 (and thus couldn’t take advantage of some things such as Vectors), and already ran pretty blazingly fast.

I am using Grant Skinner’s performance test harness to profile performance. Each test is run 50 times, and is tested in Flash Player MAC 10,0,32,18 (debug) in the browser.

You can download all of the code from here.

First, here is the original test case, based on soulwire’s code:

/*
	Code adapted from:
	http://blog.soulwire.co.uk/flash/actionscript-3/colourutils-bitmapdata-extract-colour-palette/
*/

package
{
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.geom.Rectangle;
	import flash.geom.Point;

	import com.gskinner.utils.PerformanceTest;

	public class PixelSort extends Sprite
	{

		[Embed(source="../graphics/image.jpg")]
		public var TestImage:Class;

		public function PixelSort()
		{
			addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
		}

		private var d:BitmapData;
		private function onAddedToStage(evet:Event):void
		{
			removeEventListener(Event.ADDED_TO_STAGE, onAddedToStage);

			var b:Bitmap = new TestImage();

			d = b.bitmapData;

			var perfTest:PerformanceTest = PerformanceTest.getInstance();
			perfTest.out = trace;
			perfTest.testFunction(run, 50, "averagecolors", "averagecolors");
		}

		private function run():void
		{
			var out:Array = averagecolors(d, 16);
		}

		public function averageColour( source:BitmapData ):uint
		{
			var red:Number = 0;
			var green:Number = 0;
			var blue:Number = 0;

			var count:Number = 0;
			var pixel:Number;

			for (var x:int = 0; x < source.width; x++)
			{
				for (var y:int = 0; y < source.height; y++)
				{
					pixel = source.getPixel(x, y);

					red += pixel >> 16 & 0xFF;
					green += pixel >> 8 & 0xFF;
					blue += pixel & 0xFF;

					count++
				}
			}

			red /= count;
			green /= count;
			blue /= count;

			return red << 16 | green << 8 | blue;
		}		

		public function averagecolors( source:BitmapData, colors:int ):Array
		{
			var averages:Array = new Array();
			var columns:int = Math.round( Math.sqrt( colors ) );

			var row:int = 0;
			var col:int = 0;

			var x:int = 0;
			var y:int = 0;

			var w:int = Math.round( source.width / columns );
			var h:int = Math.round( source.height / columns );

			for (var i:int = 0; i < colors; i++)
			{
				var rect:Rectangle = new Rectangle( x, y, w, h );

				var box:BitmapData = new BitmapData( w, h, false );
				box.copyPixels( source, rect, new Point() );

				averages.push( averageColour( box ) );
				box.dispose();

				col = i % columns;

				x = w * col;
				y = h * row;

				if ( col == columns - 1 ) row++;
			}

			return averages;
		}
	}
}

And here is the initial performance test:

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                              1264    25.28
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

First, considering what the code is doing, it is already pretty fast, taking only 25 ms to split the image into a grid, and loop through all of the pixels and averaging the values. However, there is probably some room for improvement, especially given that the original code targets Flash Player 9 and thus cant take care of Flash Player 10 optimizations such as using Vectors.

Now, the first thing I would normally do is to profile the SWF using the profiler in Flash Builder to find out where the most time is being sent. However, in this case, there are only two methods that do anything, averageColors and averageColor. averageColors is called once, while averageColor is called once for each swatch we want to create (in this case 16), and ends up looping over each pixel in the image (over those 16 calls). So these are the two areas we will focus on, with particular attention directed to averageColor.

The first thing I did was look at updating the content to Flash Player 10 by converting all of the Arrays to Vectors. I expected to get a decent boost from this, but the improvement was minimal.

Within the averageColors method, I looked at reusing the Point, Rectangle and BitmapData instances, instead of creating new ones on each iteration of the loop. Again, on the desktop this didn’t really make any difference. However, one thing to consider is that on a mobile device where memory allocation can be more expensive (and there is less RAM altogether), this change may have had a bigger impact (which I didnt test). This leads to an important point. It is important to test performance on the platforms which you are targeting, as some optimizations can have a different impact depending on where the content is running.

Next, I set the averageColor and averageColors methods as final, which allows them too be looked up at compile time (as opposed to runtime), this led to small improvement in performance, but again, not really anything significant.

At this point, I was getting a very slight performance improvement, but not really anything that mattered (basically, small enough to be insignificant),

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                              1224    24.48
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Next, I moved on to the averageColor method, where I expected (and hoped) to have better results, as this is where the bulk of the work occurs.

First I converter some of the Numbers to ints and uints in places where Numbers were not needed. This led to a small improvement.

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                              1190    23.80
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Next, I changed the bitmapData.getPixel call to use bitmapData.getVector. Doing this then allowed me to loop through the pixels using a single loop, instead of a nested double loop, and also eliminated a getPixel call for each pixel. I used a for each loop to loop through the pixel color values.

This provided another slight improvement (although not quite as much as I expected). We are now making some small gains.

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                              1137    22.74
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Next, I decided to try a for loop, instead of a for each loop.

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                               282     5.64
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Wow! As you can see, that makes a huge difference.

Finally, I explicitly cast i to an int when pulling the value from the Vector. This gave a small improvement, but again, nothing significant:

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                               268     5.36
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

I tried a couple of more optimizations in the method, around converting division operations to multiplication operation, and replacing Math.round calls but in this case it didnt make any difference.

I also looked at caching some constants used in some of the bitwise operations, changing

red += pixel >> 16 & 0xFF;
green += pixel >> 8 & 0xFF;

to

private var s16:Number = 16 & 0xFF;
private var s8:Number = 8 & 0xFF;

red += pixel >> s16;
green += pixel >> s8;

First, that optimization actually produces the wrong result (I had my operator precedence backwards). Second, it was actually slower:

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
averagecolors (50 iterations)
Player version: MAC 10,0,32,18 (debug)
averagecolors
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
method...................................................ttl ms...avg ms
averagecolors                                               349     6.98
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

There are two lessons from this. First, make sure your optimizations produce the same results (ideally by creating and using unit tests). Second, bitwise operations are really, really fast. In this case, they are even faster than doing a variable lookup.

So, after going through the code, and applying a number of different optimizations, I was able to improve performance from an average of 25.28 ms, to 5.36 ms, an improvement of about 470%.

Here is the final code:

/*
	Code adapted from:
	http://blog.soulwire.co.uk/flash/actionscript-3/colourutils-bitmapdata-extract-colour-palette/
*/

package
{
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.geom.Rectangle;
	import flash.geom.Point;

	import com.gskinner.utils.PerformanceTest;

	public class PixelSort extends Sprite
	{

		[Embed(source="../graphics/image.jpg")]
		public var TestImage:Class;

		public function PixelSort()
		{
			addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
		}

		private var d:BitmapData;
		private function onAddedToStage(evet:Event):void
		{
			removeEventListener(Event.ADDED_TO_STAGE, onAddedToStage);

			var b:Bitmap = new TestImage();

			d = b.bitmapData;

			var perfTest:PerformanceTest = PerformanceTest.getInstance();
			perfTest.out = trace;
			perfTest.testFunction(run, 50, "averagecolors", "averagecolors");
		}

		private function run():void
		{
			var out:Vector.<uint> = averagecolors(d, 16);
		}		

		public final function averageColour( source:BitmapData ):uint
		{
			var red:Number = 0;
			var green:Number = 0;
			var blue:Number = 0;

			var count:int = 0;
			var pixel:uint;

			var pixels:Vector.<uint> = source.getVector(new Rectangle(0,0, source.width, source.height));
			var len:int = pixels.length;

			for(var i:int = 0; i < len; i++)
			{
				pixel = pixels[int(i)];

				red += pixel >> 16 & 0xFF;
				green += pixel >> 8 & 0xFF;
				blue += pixel & 0xFF;

				count++;
			}

			red /= count;
			green /= count;
			blue /= count;

			return red << 16 | green << 8 | blue;
		}		

		public final function averagecolors( source:BitmapData, colors:int ):Vector.<uint>
		{

			var averages:Vector.<uint> = new Vector.<uint>(colors, false);
			var columns:int = Math.round( Math.sqrt( colors ) );

			var row:int = 0;
			var col:int = 0;

			var x:int = 0;
			var y:int = 0;

			var w:int = Math.round( source.width / columns );
			var h:int = Math.round( source.height / columns );

			var p:Point = new Point();
			var rect:Rectangle = new Rectangle(0,0,0,0);
			var box:BitmapData = new BitmapData( w, h, false );

			for (var i:int = 0; i < colors; i++)
			{
				rect.x = x;
				rect.y = y;
				rect.width = w;
				rect.height = h;

				box.copyPixels( source, rect, p );

				averages[i] =  averageColour( box );

				col = i % columns;

				x = w * col;
				y = h * row;

				if ( col == columns - 1 )
				{
					row++;
				}
			}
			box.dispose();
			return averages;
		}
	}
}

Lessons learned

Profile content to isolate bottlenecks : I skipped that step in this case since my code consisted of only two methods, but even in that case, the most significant improvement came from a single optimization. Profile so you know where to focus your efforts.

Test and profile all optimizations : Make sure to test performance after each optimization, as optimizations do not always have the desired effect.

Test on target devices and platforms : Optimizations can have a different impact on where they are run. This includes browser, platform and device, as well as player type (debug vs release). For example, when testing directly from Flash Authoring, results where significantly slower than when testing in the browser.

Test the results of the optimizations : Make sure that your optimizations do not break your code or content. The best way to do this is by using unit tests and running them after each optimization.

There is still some potential for optimization. In particular, since the code is essentially looping over all of the pixels of a bitmap and then doing some math operations on their values, this could be a good candidate for porting to PixelBender.

If you have any additional optimizations, questions or suggestions, post them in the comments.

Also, make sure to check out soulwire’s blog, as he is doing some very cool stuff with ActionScript 3 and Flash.

You should NOT care about using Flash to build applications for the iPhone.

Hear me out on this. One of the major advantages of using Flash has always been that you can create your content, and then be confident that it will run consistently across different platforms and browsers. However, in the past, if you wanted to deploy to mobile platforms or devices, you would have to target a different player (most likely based on Flash Lite), which lagged behind the capabilities of the desktop player. However, the fragmentation between desktop and mobile players is about to change.

I think the biggest news out of Max last week was not the Flash applications for iPhone announcements, but rather the unveiling of Flash Player 10.1. Not only will Flash Player 10.1 run across desktop operating systems and browsers, but it will also be available on the newest generation of smart phones. This includes Palm Pre, as well as Android and RIM based devices. Furthermore, the iPhone work, as well as Adobe AIR 2.0 are both also based on Flash Player 10.1.

Thus, not only will you be able to create content and target multiple browsers and operating systems, but you will also be able to target mobile devices, as well as desktops.

Now, it is important to remember that devices, such as the Palm Pre and iPhone have significantly slower processors and less memory, as well as smaller screens than desktop machines. However, if you design and develop with these limitations in mind, then you will be able to leverage you content anywhere that Flash Player 10.1 is available.

Furthermore, if you are leveraging functionality that is only available on a subset of devices, then of course, your content can only leverage that functionality on devices where it is supported. This is the same as on the desktop when using APIs to access the user’s microphone and webcam. If the target platform supports the functionality then you can use the APIs to access that functionality. (The Flash Player includes APIs to check at runtime if specific functionality is supported on any particular target platform).

The important thing is that the Flash Player exposes the APIs across platforms in a consistent manner. So, for example, if you want to use multitouch functionality in Flash Player 10.1, then you will use the same APIs regardless of whether your content is running on the desktop, in a browser, on the iPhone, the Palm Pre, etc…

For the past couple of months, I have been working on a gamed called “Pew Pew”. I originally developed it by targeting the browser, but knowing that I wanted to deploy it to the iPhone, payed attention to performance, and sized the content, and designed the user interactions appropriately. Once the iPhone work was at a point internally that I could deploy content to it, I was able to run my content on the device with no changes at all. Now, I did have to do some additional code optimizations to bring the frame-rate up (something which benefitted the game on the desktop as well), but once I did these, the SWF for my game was able to run on both in the browser on my desktop and as a standalone iPhone application. Indeed, the team working on Flash Player 10.1 for Android asked if I could send them the SWF, and it ran on that device as well with no modifications. This was possible because Flash Player 10.1 allowed me to target the capabilities that my game needed, as opposed to targeting a particular device.

So, to summarize, when developing content targeted at Flash Player 10.1, you should think in terms of the capabilities of the platform, and not get hung up on a particular device or browser.

Creating applications for the iPhone is great. But creating content for the iPhone, and having the option to deploy it on an Android, RIM or Palm Pre device, in a browser on Mac, Windows, Linux and Solaris, and being able to deploy to the Mac, Windows and Linux desktops via Adobe AIR 2.0 is even better.