The Standard Way
This way essentially exports all SSL data, certs, client and server side if you read the notes has performance penalty.

SSLVerifyClient optional_no_ca
SSLVerifyDepth 1
SSLOptions +StdEnvVars
SSLOptions +ExportCertData


The Lighter Way
This way simply passes in the SSL_CLIENT_CERT in to the env REMOTE_USER and skips the rest which you don't use (for FOAF+SSL).

SSLVerifyClient optional_no_ca
SSLVerifyDepth 1
SSLUserName SSL_CLIENT_CERT


Tested and works very nicely (again, imho).

note: Enabling SSLOptions +FakeBasicAuth will overwrite this with the Subject from the client side certificate.

A lot of work is always done on the code optimization side of things, and recently this has hit the ActionScript world; most notably (imho) with haxe and TAAS - both of these things have a lot of optimizations improving the compile process, which means our code ultimately runs faster :) inlining, code reduction, dead code elimination, flow optimization etc.

Ultimately, the fastest compiled script will always be a flat set of vm operations with none of that expensive method calling and instantiation, and lets remember that OO is pretty much a syntax we use to develop, haxe makes it clear with its common syntax which compiles to multiple vm targets.

So, here's the background question - why do our actionscript classes compile to compiled classes?, all the code from those nested called methods could be factored right the way back in to one big method, and a single class, then heavily optimized - imagine the speed gains.

Thinking further, implementing doesn't appear too hard - i mean all your going to need to do is essentially copy the code from one method and place it in the calling method at the correct position(s); any duplicate code introduced would be offset easily by the amount of code cut out by removing all those un-needed classes and methods - further the unused classes and methods would be lost; and the final chunks of code could be optimized to hell and back.

The only problem i can see is that we need compiled classes to distribute or pull in remotely sometimes, which is why I'd propose a simple "Service" interface (or suchlike) the point of which is that any class marked as a service class (or gateway?) would keep its class structure and public methods.. after all everything behind the public methods is of no concern to any other part of the system.

If you consider a flex application for example, or that class which uses circa 5% of all the large libs included in the final compiled script.. not to mention the additional optimizations that could be made on the big blocks of code in each method!

So that's it, Flat Packing - the ultimate optimization?

ps: quite sure this applies to most OO languages not just actionscript ( haxe guys will agree I'm sure (I hope) ).

Regards!

The change isn't a massive one, but does speed things up - simply it replaces the old:

important: turns it this runs slower if the z-val is outside of the range 0-1; a LOT slower, so don't use!

sortArray.sortOn("screenZ", Array.NUMERIC | Array.DESCENDING);

with the new:

sortVector.sort( function compare( x : SimpleZSortVO , y : SimpleZSortVO ) : int {    return x.screenZ - y.screenZ; } );

and here's the source all nicely zipped up, you should be able to simply drop this in your fp10 swfs as a replacement for the older version,

Thanks to Ralph for one opensourcing it and two giving me a heads up that its okay to "upgrade", sure it can still be made faster still with a bit of thought.

PixelBender is one of these technologies, as advertised "You can use the Pixel Bender kernel language to implement image processing algorithms (filters or effects) in a hardware-independent manner"; however this isn't the whole truth of the matter.

PixelBender is a highly under-rated and under-used technology imho. Simply put PixelBender is actually a very fast way of converting or manipulating large sets of numerical data, whether it's image based or not. In this post I'm only going to skim the surface and give some pointers.

The standard input types cover Vector, ByteArray and BitmapData, likewise with output data, additionally many types are supported for parameters, everything from ints up to 4x4 Matrix' of floats.

Some obvious and simple uses include:

• 3D Data Manipulation (Float3 input and output - rgb or xyz)
• Raw Sound Data Manipulation (from Sound.extract, you could even build an FFT implementation in PixelBender)
• Visual Effects Calculations
• Batch Processing and Data Transformation.

Starting with Batch Processing and Data Transformation, here is the simplest PixelBender usage and example you could ever get.

Problem

Turn a BitmapData in to a Vector of RGB float values where each value is float < 1 and each set of 3 values comprises a pixel.

Doing this with pure AS3 or haXe or anything else is quite intensive, then you add PixelBender in to the equation

Solution
PixelBender Code:

<languageVersion : 1.0;>
kernel Identity
<   namespace : "org.webr3.pb";
 vendor : "WebR3";
 version : 1;
 description : "Converts BitmapData to Vector Number (rgb)";
>
{
 input image3 src;
 output pixel3 dst;

 void evaluatePixel()
 {
 dst = sampleNearest( src, outCoord() );
 }
}

And to use this we can create a simple wrapper class in AS3:

package test
{
 import __AS3__.vec.Vector;

 import flash.display.BitmapData;
 import flash.display.Shader;
 import flash.display.ShaderJob;
 import flash.utils.ByteArray;

 public class ShaderVector
 {
 [Embed("/rgb.pbj", mimeType="application/octet-stream")]
 private var shaderClass : Class;

 private var shader : Shader;

 public function ShaderVector()
 {        
 shader = new Shader(new shaderClass() as ByteArray);
 }

 public function convert( img : BitmapData ) : Vector.<Number>
 {
 var output : Vector.<Number> = new Vector.<Number>( (img.width*img.height) * 3 , false );
 shader.data.src.input = img;
 var job : ShaderJob = new ShaderJob( shader , output , img.width , img.height );
 job.start( true );
 output.fixed = true;
 return output;
 }

 }
}

Now we've got a kind of worker / utility class which we can farm all the hard work on to; usage is simple:

var worker : ShaderVector = new ShaderVector();
var rgb : Vector.<Number> = worker.convert( someBitmapData );

that's it, in one line we've solved the problem.

PixelBender is a lot easier than you may think, the above code is a small model you can easily manipulate just embed different pixel bender files.

Here's another simple kernel file; this one will take a BitmapData of perlin noise and convert it in to Vector of 3D positions for us to use.

It takes the bitmap data, converts every pixels r,g,b values in to float -0.5 to +0.5 values, then scales them up and finally returns back a vector of what are essentially 3D Perlin Noise Particles (like the ones in my earlier experiments)

<languageVersion : 1.0;>
kernel Scaler
<   namespace : "org.webr3.pb";
 vendor : "WebR3";
 version : 1;
 description : "For Perlin Noise, Converts BitmapData to 3D x,y,z positions";
>
{
 input image3 src;
 output pixel3 dst;

 parameter float scaleX
 <
 defaultValue : float(1.0);
 minValue     : float(0.1);
 maxValue     : float(100000.0);
 >;

 parameter float scaleY
 <
 defaultValue : float(1.0);
 minValue     : float(0.1);
 maxValue     : float(100000.0);
 >;

 parameter float scaleZ
 <
 defaultValue : float(1.0);
 minValue     : float(0.000001);
 maxValue     : float(100000.0);
 >;

 void evaluatePixel()
 {
 dst = sampleNearest( src, outCoord() );
 dst -= 0.5;
 dst.r *= scaleX;
 dst.g *= scaleY;
 dst.b *= scaleZ;
 }
}

and the modified shader vector, only 3 new lines to set up the scale values:

package test
{
 import __AS3__.vec.Vector;

 import flash.display.BitmapData;
 import flash.display.Shader;
 import flash.display.ShaderJob;
 import flash.utils.ByteArray;

 public class ShaderVector
 {
 [Embed("/rgb.pbj", mimeType="application/octet-stream")]
 private var shaderClass : Class;

 private var shader : Shader;

 public function ShaderVector()
 {        
 shader = new Shader(new shaderClass() as ByteArray);
 shader.data.scaleX.value = [200];
 shader.data.scaleY.value = [200];
 shader.data.scaleZ.value = [200];
 }

 public function convert( img : BitmapData ) : Vector.<Number>
 {
 var output : Vector.<Number> = new Vector.<Number>( (img.width*img.height) * 3 , false );
 shader.data.src.input = img;
 var job : ShaderJob = new ShaderJob( shader , output , img.width , img.height );
 job.start( true );
 output.fixed = true;
 return output;
 }

 }
}

If you're thinking this is complex, it's honestly not - try coding this in pure AS3 and it'll be a lot of complex slow lines, been there and done that!

I'm going to leave the examples there for now, if your looking for a 3D example then check the PixelBender files in Ralphs 3D Particle example.

Conclusion.

AS3 together with PixelBender, haXe and Alchemy is fast becoming an immense tech for us developers, have a play around you may be suprised by the results you can achieve by utilizing these techs.

Coming very soon I'll be posting some examples which show what can be done when you use PixelBender, Fast Memory, Vectors and haXe / AS3 together, but in unconventional ways. Until then I hope this is enough to get some more dev's playing with PixelBender.

peace ::

image is a still from I am Legend : Awakening a very well made 5 minute short animation.

Skippable Details

All this traffic is round robin'd to 2 apache2 servers (each is 2x 2.86 quad xeons w/ 4GB ram) and one backend db server of similar spec.

Over the years familiar problems rear there heads, the mysql "Too Many Connections" error, Apache running like a dog under stress etc.

This weekend I got the chance to rebuild the servers from scratch, and a chance to optimize everything - works very very well now!

Easy Optimization - Apache2

KeepAliveTimeout: Number of seconds to wait for the next request from the same client on the same connection.

Translate this to "Number of seconds to lock up a worker thread just incase another request comes in from the same client on the same connection" - in short a lot of browsers will request the page, keep the connection alive and use it to request images, css etc.

The default is 15 seconds; in my experience about 40-50% of connections will use KeepAlive, so if you have enough ram to support 500 requests before going in to swap memory, and you get 500 requests a second, by the time 3 seconds are past you've got a load of workers with RAM assigned doing nothing and all the hard work is getting done using swap memory instead, from this poitn on basically all the hard work is getting done using swap rather than ram, ya?

Thus, the simple fix is to knock KeepAliveTimeout right down - some people recommend 2 seconds, my personal preference is 4 seconds - works a charm for me :)

To analyse this yourself just check the server-status provided by apache (normally only viewable from localhost, easy way around this is to <?php echo file_get_contents('http://localhost/server-status'); ?>

Easy Optimization - MySQL Server

Other than the normal cnf values you should be optimizing [ key_buffer, sort_buffer_size, max_allowed_packet, thread_stack, thread_cache_size, max_connections, table_cache, query_cache_limit, query_cache_size ] - there is one more that is very important; namely wait_timeout.

wait_timeout - The number of seconds the server waits for activity on a noninteractive connection before closing it.

By default this value is very high, but often you get connections that just aren't closed properly, especially in the PHP apache world - if you ever hit that "Too many connections" error or see a lot of connections open for prolonged periods of time then this could / should be addressed.

Often you will see connections sitting idle for 10-15 seconds, for no good reason. Best to address it I'd say; and thus we lower wait_timeout to 5 seconds.

Connections are cleared faster, more resources free for other connections and all round its good. Remember one of mysql's strongest features is it's ability to open and close connections ultra-fast.

Summary

Honestly just check the your apache server status, see how many connections are open, how many of them are flagged K for keep alive then drop the keep alive time, take a note of processor usage / memory usage, drop the KeepAliveTimeout to 2, 4, 6, 8 and check it all again, you may be very suprised, it sure beats weeks of manual code optimizatios to make those scripts run faster.

Regards

Other than the really obvious bit that its direct access to a block of ram/fast memory which works extremely quickly, there is one other small but vital detail that's haXe specific and makes a vast difference between alchemy and haxe.

The Big Difference

You can think of flash.Memory as a static ByteArray, thus it is accessible from both static class and instance methods.

Now, another feature which offers huge speed increases in haXe is inlining.

Spelling it out - You can only inline static private methods, flash.Memory is all static access. So stick all your data (or big chunks of it) in flash.Memory and then inline  most of your heavy number crunching class.

All inlined, all using fast memory = very very quick swfs!

Ideas and Tricks

First of all, get the thought of only being able to have one chunk or type of data in fast memory at a time, you can partition it up and load everything in there.

A common setup I use is to have the first 1024 bytes as fast storage for float, int, byte, uint variables, the next xxx-thousand bytes as raw bitmap data, then all the other data I may want - like a block of 500k x,y,z floats for 3d data, followed by a few lookup charts.

the first 1024 bytes as fast storage for float, int, byte, uint variables - because you can then access the most commonly used vars using small int offsets (0-255) - and since its a small int your using it avoids all stacks completely, the bytecode will only contain the opcode to get the value from fast memory followed by the offset actually in the bytecode - for anything 256 and over its going to hit the int stack to get the offset first (which is barely noticable, but you know every fraction counts)

the next xxx-thousand bytes as raw bitmap data - because you can then work on your bitmap data ultra fast and write it back to the BitmapData instance using setPixels; very fast indeed, faster than a fixed sized vector even.

then all the other data - this is partially obvious, what may not be is the use of lookup charts, but I'll cover that in a moment.

Accessing..

Remember flash.Memory differs from a byte array in that you have to add in the offset for each value you want to grab

• Byte = 1 Byte
• Int = 4 Bytes
• Float = 4 Bytes
• Double = 8 Bytes

To use flash.Memory with functions which require a ByteArray.. [ like BitmapData.getPixels() -  Sound.extract() ] .. you can access it directly from flash.system.ApplicationDomain.currentDomain.domainMemory for example:

// set position to start of the data we need
flash.system.ApplicationDomain.currentDomain.domainMemory.position = SOME_OFFSET;
// use the fast memory
bitmapData.setPixels( bitmapData.rect , flash.system.ApplicationDomain.currentDomain.domainMemory );

note: don't be fooled though, you can't simply call the functions on the bytearray in currentDomain, although it is the data that is in fast memory, it does not use the opcodes, which are what speed it up!

Lookup Charts

Often you'll find yourself calling the same code over and over and over; perhaps without realising just how much; consider we make an animation which uses perlin noise to generate 2d or 3d data - like this example - the example reads about 40k uint values from perlin noise, then converts each pixel to individual r,g,b values, then turns it in to a float -1 to 1 using a simple calculation. Thing is.. that means the same calculation runs 3x40000 times per frame at 50 frames a second.. 6 million times a second!

In this scenario, there are only 256 possible inputs to the calculation and 256 results - so rather than working it out 6 million times we can load it all in to a lookup chart, stick the lookup chart in fast memory and then lookup values rather than calculating - often you can really speed things up by doing this. Practical example with comments here.

Hope this is of use to somebody and clears things up a bit; I use the methods often so you'll see them in the source of my experiments.

Elliot Rock asked me 3 fantastic questions about my previous post, it's good information so best to share for all I think!

So the inline methods and variables is the main optimisation in the final version?

it's the only optimisation made, I simply added the "inline" keyword to 2 methods and all static vars.

Can you explain where and why the HaXe methods greatly improve performance please :)

haxe offers 3 main forms of performance optimisation (we're being swf specific here);

1. haXe produces bytecode/opcodes which are optimized better than the adobe compilers / mxmlc. This provides a small but significant increases in speed which all mount up. See the links at the foot of the page for more information.
2. haXe provides the ability to inline, which I'll explain further in a moment, this often gives a fantastic increase in speed.
3. haXe provides access to the new opcodes for fast memory access; the only other place to get them is through Alchemy.

I must stress that these are 3 minor benefits of haxe compared to the hundreds of others, but they are very good ones none the less!

I know inlines are so great but haven't found an explanation on why :)

The simple answer is it produces less and better optimized opcodes + reduces calls to the stack(s).

I'm going to jump straight in to full on detail here! from the examples in question, here is snippet of code from the non-optimised version:

Non-Optimized

private static var WIDTH : Int = 550;
// ...
po = pointToOffset( Std.int(realVector[a*3]) , Std.int(realVector[(a*3)+1]) , WIDTH );
// ...
private static function pointToOffset( vx : Int , vy : Int , vw : Int ) : UInt {

taking the single functional line only (the middle one) here is are the opcodes produced for it:

OLabel
OGetLex(Idx(62))
OFindProp(Idx(83))
OGetProp(Idx(83))
OReg(6)
OSmallInt(3)
OOp(OpIMul)
OGetProp(Idx(17))
OToNumber
OToInt
OFindProp(Idx(83))
OGetProp(Idx(83))
OReg(6)
OSmallInt(3)
OOp(OpIMul)
OSmallInt(1)
OOp(OpIAdd)
OGetProp(Idx(17))
OToNumber
OToInt
OGetLex(Idx(62))         // get name Identical
OGetProp(Idx(47))        // get property WIDTH
OCallProperty(Idx(67),3) // call pointToOffset with arg count: 3 (from previous uncommented opcodes)
OToUInt                  // set result as UInt
OToInt                   // set above as Int
OSetReg(5)               // store it in variable po

and here's the pointToOffset opcodes

OReg(1)
OReg(2)
OReg(3)
OOp(OpIMul)  // multiply argument 1 and 2
OOp(OpIAdd)  // add argument 3 to result of previous op
ORet         // return result

so.. it's going to get the static var WIDTH from the class, then pass it and the other 2 arguments from our vector through to pointToOffset, run all the pointToOffset code, get the result, convert it and store in variable po. *phew* quite a lot really.

Optimised

now let's look at the optimised version, remember the only thing to change here is the addition of the keyword "inline":

private static inline var WIDTH : Int = 550;
// ...
po = pointToOffset( Std.int(realVector[a*3]) , Std.int(realVector[(a*3)+1]) , WIDTH );
// ...
static inline function pointToOffset( vx : Int , vy : Int , vw : Int ) : UInt {

and the corresponding op codes (snipped as the rest if the same)

OToNumber
OToInt
OIntRef(Idx(4)) // value 550 on the int stack
OOp(OpIMul)     // multiply first two arguments (vector values)
OOp(OpIAdd)     // add the third (width)
OToInt          // set to int
OSetReg(5)      // store in po

the static var width and the function point to offset are removed and never called.

back to an english explanation, we've removed some normal but heavy operations and replaced them with 3 simple and light operations, giving us a big speed increase.

All credit to Nicolas the creator of haxe for this, it's amazing what he's done.

Reading

• http://ncannasse.fr/blog/flash_9_optimizations
• http://ncannasse.fr/blog/haxe_swc (specifically "More Optimizations")
• http://haxe.org/ref/inline

Hope that answers the questions, and thanks Elliot.

Ralph Hauwert created a great demo of the power of Flash 10 / PixelBender / Alchemy that you're probably familiar with, then Joa Ebert made a fantastic Flash 9 pure AS3 version that's very impressive, then I gave it a go with haXe and flash.Memory which turned out rather well too.

It's been bugging me for some time that the code just wasn't real world enough though - so I thought I'd give it a go using AS3 and flash 10, using only native methods and no fancy 3D calculations that us commoners don't quite get. In short I've stripped it down and turned it into a simple class which uses flash 10 Vectors and Matrix3D.

I've taken a different approach with these demo's, rather than all in realtime, you simply click and it runs the enterFrame code once and displays the time in ms that it took. There is however a final realtime version using this code at the end.

Four examples are provided, Pure AS3, then the same code converted to haxe, then the haxe "inline" keyword added and finally the whole thing working in realtime.

AS3 Flash 10 Version with Vector / Matrix3D

Here's the main source used:

private function enterFrameHandler( event : Event ): void {
 var d : Date = new Date();
 var t : Number = d.getTime();

 updateMatrix( mouseX , mouseY );
 _matrix.transformVectors( particleVector , realVector );

 var pxs : Vector.<uint> = new Vector.<uint>( PIXELS , true );
 var po : int = 0;
 var a : int = 0;

 while( a < PARTICLES ) {
   po = pointToOffset( int(realVector[a*3]) , int(realVector[(a*3)+1]) , WIDTH );
   if( 0 < po && po < PIXELS) {
     pxs[po] = increaseColor( pxs[po] );
   }
   a++;
 }
 // update display
 this.bitmapData.lock();
 this.bitmapData.setVector( this.bitmapData.rect , pxs );
 this.bitmapData.unlock( this.bitmapData.rect );

 d = new Date();
 textField.text = "single frame time: " + ( d.getTime() - t );
}

private function updateMatrix( mx : Number , my : Number ) : void {
 tx = tx + ((mx - tx)/10);
 ty = ty + ((my - ty)/10);
 _matrix.identity();
 _matrix.appendRotation( tx , Vector3D.Y_AXIS );
 _matrix.appendRotation( ty , Vector3D.X_AXIS );
 _matrix.appendTranslation( CX, CY, 10 );
}

private static function increaseColor( c : uint ) : uint {
 return c < MAXCOLOR ? c + SHADE : 0xFFFFFF;
}

private static function pointToOffset( vx : int , vy : int , vw : int ) : uint {
 return vx + ( vy * vw );
}

And here's the AS3 result (with full source)

The same code in haXe

next up I spent literally 2 minutes converting this to haXe syntax, changed no functionality - just slight syntax changes between the languages.

private function enterFrameHandler( event : Event ) : Void {
 var d : Date = Date.now();
 var t : Float = d.getTime();

 updateMatrix( mouseX , mouseY );
 _matrix.transformVectors( particleVector , realVector );

 var pxs : Vector<UInt> = new Vector<UInt>( PIXELS , true );
 var po : Int = 0;
 var a : Int = 0;

 while( a < PARTICLES ) {
   po = pointToOffset( Std.int(realVector[a*3]) , Std.int(realVector[(a*3)+1]) , WIDTH );
   if( 0 < po && po < PIXELS) {
     pxs[po] = increaseColor( pxs[po] );
   }
   a++;
 }
 // update display
 this.bitmapData.lock();
 this.bitmapData.setVector( this.bitmapData.rect , pxs );
 this.bitmapData.unlock( this.bitmapData.rect );

 d = Date.now();
 textField.text = "single frame time: " + ( d.getTime() - t );
}

private function updateMatrix( mx : Float , my : Float ) : Void {
 tx = tx + ((mx - tx)/10);
 ty = ty + ((my - ty)/10);
 _matrix.identity();
 _matrix.appendRotation( tx , Vector3D.Y_AXIS );
 _matrix.appendRotation( ty , Vector3D.X_AXIS );
 _matrix.appendTranslation( CX, CY, 10 );
}

private static function increaseColor( c : UInt ) : UInt {
 return c < MAXCOLOR ? c + SHADE : 0xFFFFFF;
}

private static function pointToOffset( vx : Int , vy : Int , vw : Int ) : UInt {
 return vx + ( vy * vw );
}

And here's the identical haXe result (with full source)

Optimized haXe Version

Next up I spent another minute optimizing (literally, one minute) - haXe supports inlining of variables and methods, so I added the inline keyword to the static vars and two of the static methods (increaseColor and pointToOffset)

private function enterFrameHandler( event : Event ) : Void {
 var d : Date = Date.now();
 var t : Float = d.getTime();

 updateMatrix( mouseX , mouseY );
 _matrix.transformVectors( particleVector , realVector );

 var pxs : Vector<UInt> = new Vector<UInt>( PIXELS , true );
 var po : Int = 0;
 var a : Int = 0;

 while( a < PARTICLES ) {
   po = pointToOffset( Std.int(realVector[a*3]) , Std.int(realVector[(a*3)+1]) , WIDTH );
   if( 0 < po && po < PIXELS) {
     pxs[po] = increaseColor( pxs[po] );
   }
   a++;
 }
 // update display
 this.bitmapData.lock();
 this.bitmapData.setVector( this.bitmapData.rect , pxs );
 this.bitmapData.unlock( this.bitmapData.rect );

 d = Date.now();
 textField.text = "single frame time: " + ( d.getTime() - t );
}

private function updateMatrix( mx : Float , my : Float ) : Void {
  tx = tx + ((mx - tx)/10);
  ty = ty + ((my - ty)/10);
  _matrix.identity();
  _matrix.appendRotation( tx , Vector3D.Y_AXIS );
  _matrix.appendRotation( ty , Vector3D.X_AXIS );
  _matrix.appendTranslation( CX, CY, 10 );
}

static inline function increaseColor( c : UInt ) : UInt {
  return c < MAXCOLOR ? c + SHADE : 0xFFFFFF;
}

static inline function pointToOffset( vx : Int , vy : Int , vw : Int ) : UInt {
 return vx + ( vy * vw );
}

And here's the inlined haXe result (with full source)

Summary

In under five minutes and with tiny code changes we've gained well over 100% speed increase; using nothing fancy and the speed rivals all the heavily optimized versions using every trick in the book.

The final result (simply with the event listener changed to Event.ENTER_FRAME and fps added) is available here.

In this post I'm looking at the layout of BitmapData and the fastest way to access / manipulate the raw data. The syntax used is haXe, however the information is good for as3/flash10 right up until the last section which deals with using fast memory and is haXe/Alchemy specific.

The Simple Stuff

A BitmapData 5px by 5px will comprise of 25 pixels; the flash API is a bit misleading as to the point coordinate system used,
as such here's the layout of the data contained:

       X
   0,-,-,-,-
   -,1,-,-,-
 Y -,-,2,-,-
   -,-,-,3,-
   -,-,-,-,4

the upper left corner is point(0,0) - the lower right is point(4,4); [not 1,1 to 5,5 as the manual suggests]

to access the data I'm going to be using three specific methods:

• BitmapData.getPixel( x, y );
• BitmapData.getPixels( rect );
• BitmapData.getVector( rect );

the data returned by getPixels and getVector is in array format (ByteArray and Vector<UInt> respectively), both are 0 indexed with 25 entries.

Pixel values run from left to right, so the 5px example above converts to

index[0] = point(0,0)
index[1] = -
index[2] = -
index[3] = -
index[4] = -
index[5] = -
index[6] = point(1,1)
index[7] = -
index[8] = -
index[9] = -
index[10] = -
index[11] = -
index[12] = point(2,2)
index[13] = -
index[14] = -
index[15] = -
index[16] = -
index[17] = -
index[18] = point(3,3)
index[19] = -
index[20] = -
index[21] = -
index[22] = -
index[23] = -
index[24] = point(4,4)

Converting between X,Y and Offsets

to work with the data in its raw format we're going to need some helper functions/code to convert between point(x,y) and offset.

X,Y to Offset

function pointToOffset( x : Int , y : Int , width : Int ) : Int {
    return (y * width) + x;
}

thus for point(3,3):

    (3 x 5) + 3 = 18

Offset to X,Y

function offsetToPoint( offset : Int , width : Int ) : Point {
    return new Point( offset%width , Std.int(offset/width) );
}
// or
bitmapData.getPixel( offset%width , Std.int(offset/width) );

thus for offset 18 :

    x: 18%5 = 3
    y: 18/5 = 3

Speed Tests

For each of the three methods [ getPixel(x,y); getPixels(rect); getVector(rect); ] I've done a lot of testing to see which is fastest. All tests use a non transparent bitmapData of 1,920,000 pixels (1600x1200) the task of the test itself is to get all pixels from the bitmapData, load them in to an array/bytearray/vector, add 1 to the color for each pixel and then write the new data back to the BitmapData.

Starting with the Flash 9 methods available:

Test One, getPixel -> array -> setPixel
This method incurs two full loops because there is no setPixels(array) method, the time of a bare loop of 1920000 is 8ms.

var o : Array<UInt> = new Array<UInt>();
for( i in 0...1920000 ) {
    o[i] = bitmapData.getPixel( i%WIDTH , Std.int(i/WIDTH) ) + 1;
}
for( i in 0...1920000 ) {
    bitmapData.setPixel( i%WIDTH , Std.int(i/WIDTH) , o[i] );
}

results [all times in ms]

555, 569, 574, 573, 575, 570, 570, 570, 568, 576, 575, 573, 569, 563, 570

Test Two - getPixels -> ByteArray -> setPixels

This method needs two ByteArrays to avoid using temporary var's and setting positions multiple times, the time of simply calling getPixels() alone is 90ms!

var b : ByteArray = bitmapData.getPixels( bitmapData.rect );
var n : ByteArray = new ByteArray();
n.endian = b.endian; // getPixels often returns big endian values and byte arrays are little endian by default
b.position = 0; // other wise we get an error
for( i in 0...1920000 ) {
    n.writeUnsignedInt( b.readUnsignedInt() + 1 );
}
n.position = 0; // otherwise we get an error
bitmapData.setPixels( bitmapData.rect , n );

results [all times in ms]

597, 590, 591, 598, 591, 591, 595, 593, 595, 591, 591, 594, 591, 594, 588

Rather disapointing results really, we'd get a lovely 2fps at that rate (all tests ran on a quad core btw).

On to the methods available in flash 10, which let's us use Vectors

Test Three, getPixel -> Vector -> setVector

This test is included purely to show the speed difference between Vectors and Arrays (test one)

var o : Vector<UInt> = new Vector<UInt>( 1920000 , true );
for( i in 0...1920000 ) {
    o[i] = bitmapData.getPixel( i%WIDTH , Std.int(i/WIDTH) ) + 1;
}
for( i in 0...1920000 ) {
    bitmapData.setPixel( i%WIDTH , Std.int(i/WIDTH) , o[i] );
}

results [all times in ms]

439, 443, 447, 444, 447, 445, 448, 447, 446, 447, 447, 445, 447, 449, 448

Test Four, getVector -> Vector -> setVector (unfixed vector)

unfixed vector initialization is virtually instant, way too quick for me to measure anyways (or to make a difference)

var v : Vector<UInt> = bitmapData.getVector( bitmapData.rect );
var o : Vector<UInt> = new Vector<UInt>();
for( i in 0...1920000 ) {
    o[i] = v[i] + 1;
}
bitmapData.setVector( bitmapData.rect , o );

results [all times in ms]

96, 66, 80, 71, 75, 65, 74, 72, 76, 68, 77, 73, 72, 77, 68, 70, 72, 72, 81, 68

Test Five, getVector -> Vector -> setVector (fixed size vector)

fixed size vectors take time, in this instance Vector<UInt>(1920000,true) takes circa 5ms

var v : Vector<UInt> = bitmapData.getVector( bitmapData.rect );
var o : Vector<UInt> = new Vector<UInt>( 1920000 , true );
for( i in 0...1920000 ) {
    o[i] = v[i] + 1;
}
bitmapData.setVector( bitmapData.rect , o );

results [all times in ms]

53, 41, 41, 46, 45, 47, 41, 40, 45, 45, 46, 41, 40, 46, 45, 47, 41, 50, 42, 46

Test Six, getVector -> setVector

this time we cut out the second vector, as essentially it's not needed

var v : Vector<UInt> = bitmapData.getVector( bitmapData.rect );
for( i in 0...1920000 ) {
    v[i] = v[i] + 1;
}
bitmapData.setVector( bitmapData.rect , v );

results [all times in ms]

44, 36, 38, 36, 38, 36, 36, 38, 36, 36, 37, 39, 35, 38, 38, 36, 39, 36, 38, 38

Some fantastic speed gains, and since we're getting to smaller figures we need to start counting the cost of each line:

bitmapData.getVector( bitmapData.rect );

10, 8, 9, 9, 8, 10, 8, 9, 8, 11, 8, 10, 8, 10, 8, 9, 8, 9, 8 [ms]

for( i in 0...1920000 ) {
    v[i] = v[i] + 1;
}

25, 25, 25, 27, 27, 26, 25, 26, 25, 25, 26, 25, 27, 25, 25, 26, 25, 26, 25, 25

however the loop alone takes 8ms so we're looking at av 19ms for this part

bitmapData.setVector( bitmapData.rect , v );

11, 5, 6, 4, 4, 6, 4, 6, 4, 4, 5, 5, 6, 4, 6, 4, 5, 5, 4, 5

and finally to be really count the cost we need to see what the uint+1 would take by itself

for( i in 0...1920000 ) {
    0xFFFFF9 + 1;
}

9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 8, 9, 9

so the true cost of using this single vector method in test six is 37-9 = 28ms for getVector, update vector, setVector

the true cost of using a vector inside the loop is 26-9 = 17ms (we need this later)

Adding haXe in to the equation.

Finally, as you probably know haXe provides access to fast memory; fast memory is essentially a ByteArray set in flash.system.ApplicationDomain.currentDomain.domainMemory and accessed through the new opcodes.

A little trick we can use with haxe is to write info from this fast memory to BitmapData via setPixels() since it is a ByteArray.

First off we need to set up the fast memory storage somewhere in our app:

var storage : ByteArray = new ByteArray();
storage.endian = Endian.LITTLE_ENDIAN;
storage.length = BYTES;
flash.Memory.select( storage );

to calulate the value of BYTES we simply do WIDTH*HEIGHT*4 (because a UInt takes up 4 Bytes of memory)

we know from earlier that getVector only takes circa 9ms, whereas getPixels takes a shocking 90ms; so what I'm going to do is:

Test Seven : getVector -> flash.Memory -> setPixels

var v : Vector<UInt> = bitmapData.getVector( bitmapData.rect );
for( i in 0...1920000 ) {
    flash.Memory.setI32( i*4 , v[i] + 1 );
}
// ensure position of fast memory is 0
flash.system.ApplicationDomain.currentDomain.domainMemory.position = 0;
bitmapData.lock();
bitmapData.setPixels( bitmapData.rect , flash.system.ApplicationDomain.currentDomain.domainMemory );
bitmapData.unlock( bitmapData.rect );

results [all times in ms]
34, 31, 32, 34, 32, 32, 32, 33, 32, 33, 31, 33, 32, 31, 33, 32, 33, 32, 33, 31,

We've shaved off 5ms! but hold on.. there's more - we need to analyse this

bitmapData.getVector( bitmapData.rect ); as we know from earlier takes 9ms

the loop takes 9ms

flash.system.ApplicationDomain.currentDomain.domainMemory.position = 0;
bitmapData.lock();
bitmapData.setPixels( bitmapData.rect , flash.system.ApplicationDomain.currentDomain.domainMemory );
bitmapData.unlock( bitmapData.rect );

together all takes 5ms

which means that the true cost of using flash.Memory is 32-9-9-5 = 9ms

if you remember from test six, the vector cost was 17ms so we've gained some and lost some, but overall came out on top, and certainly a tonne better than flash 9!

now, these tests where all with a big chunk of 1600x1200 pixels, in a real world app we'd have less.. so lets see with 800x450px (360,000 pixels)

Vector Only:

var v : Vector<UInt> = bitmapData.getVector( bitmapData.rect );
for( i in 0...360000 ) {
    v[i] = v[i] + 1;
}
bitmapData.setVector( bitmapData.rect , v );

results [all times in ms]
13, 6, 6, 6, 6, 7, 6, 7, 6, 6, 7, 6, 6, 7, 7, 7, 7, 7, 7, 7  = 137 / 20 : av 6.85ms = 146fps

Vector + Memory

var v : Vector<UInt> = bitmapData.getVector( bitmapData.rect );
for( i in 0...360000 ) {
flash.Memory.setI32( i*4 , v[i] + 1 );
}

// ensure position of fast memory is 0
flash.system.ApplicationDomain.currentDomain.domainMemory.position = 0;
bitmapData.lock();
bitmapData.setPixels( bitmapData.rect , flash.system.ApplicationDomain.currentDomain.domainMemory );
bitmapData.unlock( bitmapData.rect );

results [all times in ms]
7, 6, 6, 6, 5, 6, 6, 5, 5, 5, 6, 5, 5, 5, 6, 5, 5, 5, 5, 5 = 109 / 20 : av 5.45ms = 183fps

Summary

so, there's your choices 800x450px swf using methods to update raw bitmap data at 3fps for flash 9 vs 146fps for pure as3 vs 183 fps for haXe (and probably alchemy).

imho: vectors are a fantastic choice, my personal preference goes to using fastmemory, but thats because i can avoid the stack using it and know that whilst its a little more coding, you can't get faster.

overall: I'm just grateful we've got options to be able to deliver this kind of performance, really opens the doors for some stunning work and libraries not least the upcoming version of papervision and no doublt some libs for haXe.