Further the code isn't running on a solid server where the environment is controlled, and where you can simply throw more processors and memory at a problem to make it go away, the code is being run on differently specified machines almost every run, in a different client and in different versions of player.

To compound this unique situation the virtual machines (relatively) poor performance comes in to play.

Why is this good?

It has spurred a good percentage of ActionScript developers on to look at more advanced levels of code optimisation, to consider factors which are simply ignored and overlooked in other languages, to work with (and create) other technologies in order to push performance to the max; indeed even to hack the virtual machine to bits then create custom compilers and optimisers.

Libs and frameworks from PV3D through to Flex, projects such as haXe, Apparat and Alchemy; not to mention the wide array of technologies from AMF to RTMFP - this list goes on (and on).

There are 3 types of coders: bad coders, normal coders and ultra coders who's skillsets and level of understanding are far and beyond that of the normal coder; what I'm trying to get at here, is that the ActionScript challenges outlined above create an environment where a higher percentage of coders can grow in to ultra coders, than in any other language I know.

The Flash / ActionScript pair gives both designers and developers the notion that anything is possible - and this spurs them on to the push boundaries of what can be done; that kind of thinking sticks with people, they carry it on to other languages, platforms and communities; bringing inspiration and forward thinking to the web of humans.

Context: Really enjoyed reading this post: The Advantage Of ActionScript from Joa, in particular I'm glad that he mentioned "Poor Performance" as an advantage. The above post leads on from Joa's to give some of my own thoughts on why we all owe ActionScript and Flash a little something.

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 Point - Events are useful everywhere even when you don't have a UI, the main reason for building this was to create a kind of "hook" system for php. Often we create multi site systems where each implementation of that system has different client specific considerations; consider a system where one client wants all of there images to go to amazon s3 instead of being saved on the host like your other clients. With this system you can simply:

1. throw an "storeUpload" event which is cancelable
2. register a default event listener which listens for "storeUpload" events and provides default functionality, saving the upload and setting the location (ur) on the event.target
3. on one site register a custom event listener which listens for the "storeUpload" event, uploads to amazon s3, then cancels the event and set the event.target to the s3 url instead

as you can see, with this you can keep the codebase of your multisite application the same and simply hook in to events whereever you want.

the system consists of 2 public classes:

Event

The base class for all events, provides event type and cancelable; with typical usage you create a new event, then dispatch it when ready.

• __construct( $type , $cancelable=FALSE )
  create a new event listener - if you extend the Event class you must call this with parent::__construct( $type , $cancelable );

  $type - string, event type eg "debugEvent"
  $cancelable - boolean, provides cancelation functionality, so you can prevent further event listeners from firing thus in effect overriding them.

  throws InvalidArgumentException if $type is not a string

• cancel() : void
  cancels an event, only if it is cancelable
• isCancelable() : Boolean
• isCanceled() : Boolean
• getType() : string
• getTarget() : obj
  target always contains the instance which dispatched the event.

EventDispatcher

All classes which wish to dispatch events must inherit from EventDispatcher (like in most languages), this class provides:

• addEventListener( $type , $callable , $owner ) : void
  adds an event listener, this may be a function, a class method or a static class method.
  note: a current limitation is that event listener methods must be public

  $type - string, event type eg "debugEvent"
  $callable - string, the function or method which is to be called when event $type is dispatched
  $owner - mixed, used when $callable is a method, can be either an object instance, or the string name of a class for static methods.

  throws:
  InvalidArgumentException when type or callable isn't a string
  Exception('unknown method / function')

• removeEventListener( $type , $callable , $owner ) : void
  removes an event listener that has been added with addEventListener, this only removes a single event listener each call, so if you have 3 identical event listeners you will need to call this method 3 times to remove them all.

  arguments are the same as addEventListener - throws no exceptions, always returns void

• hasEventListener( $type ) : Boolean
  checks if any event listeners are registered for event $type; always returns boolean true or false.
• dispatchEvent( Event $event ) : void
  the obvious one, dispatches an event and notifies all listeners.

Notes:

The event dispatcher implements a function which hides all instance properties starting with __ from the serialize process, thus hiding the events and meaning your current serialization process will still work, additionally you can utilize it to hide any properties you don't want to be serialized.

I've tried to make the classes as simple, small and practical as possible, they execute rather quickly and shouldn't make any speed difference to your application - do however be aware that loosely coupling and entire system could allow coding errors to creep in, so maybe don't use it everywhere - but then PHP isn't strict anyways so..!

Download

You can download the PHP Event system here (3 classes + example, 4.2k) - hope somebody finds it useful!

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.

Here's one from my library, made it a few months ago to auto get the best version of a video from youtube.

Not too much to write on this one, you pass in the url of a youtube video (the normal web url) - it'll first try and load the HD version, then the HQ version and finally falls back to the "normal" quality version; the class extends mx.controls.VideoDisplay so you have all the normal methods.

Further, it only does all the detection stuff if the url is a youtube video, if it isn't then it loads the video as per usual, so it can be used as a replacement class for VideoDisplay without any negative effects or strange functionality.

no demo, just the source. Uses Flex 3 and ActionScript 3

hope it's of use to somebody!

Source: CleverVideo.as

Usage:

video : CleverVideo = new CleverVideo( 'http://www.youtube.com/watch?v=_OBlgSz8sSM' );
addChild( video );

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.

Ralph Hauwert somehow managed to push 300k+ 3D particles around in realtime using alchemy, pixelbender and flash 10; I played around with the code a bit and made similar in pure as3, nothing magnificent.. a month later in a totally unrelated event (namely me getting thoroughly p'd off with PHP) I discovered haXe and set to work playing around with it.

Finally in another totally unrelated event I came across Joa Eberts AS3 only version of Ralphs earlier work; upon closer inspection I found it wasn't as fast as Ralph's alchemy version but completely awesome code non-the-less, to do this in pure AS3 is simply amazing.

As if you can't guess where this is going.. I thought I'd give it a go in "pure haXe" to see if one could replicate the speed of Ralphs version or maybe even top it. Sparing any further detail..

Here's haXe pushing 300k+ 3d particles around in realtime (source included)

and...

here's haXe pushing 600k particles (twice as many), and erm 1 Million (a bit stuttery but hell why not)

and.. (just for fun)

here's haXe pushing 300k particles in color, and 500k in color for good measure! - before downplaying the color versions, it's worth noting that each r,g,b value is independantly calculated and weighted as a float then combined to a render color right before updating the bitmap, so in effect it's not just x,y,z stored for each pixel, it's r,g,b as well - so 2x more number crunching + a bit more.

think I can safely say I love haXe and since doign this I've been going nuts doing lots of experiments using similar code :p

so, any doublts about haXe's perfomance with flash can be considered resolved imho.

regards, nathan