So I’ve finally had some time to play with Flash 10, with the Pixel Blender Toolkit mainly + some of the new vector drawing, but also with some of the other features as well. Flash Player 9 was huge for everybody, and opened so many doors, and Flash 10 is supposed to do the same as well. It was by far one of the largest FP releases to date, but I would have to say I am a fairly disappointed with some of the tests I was trying out.

Pixel Blender Toolkit

First and foremost is that the Pixel Blender Toolkit, while faster in some regards, is extremely slow in other regards. I was trying to mimic some of the photoshop blend modes, and could not get a ShaderFilter to run any faster than 5ms per BitmapData.applyFilter() on a 320×240 image — which amounts to 20 frames per second. It would vary greatly anywhere from 5ms to 10ms, which isn’t something we normally expect from bitmap operations in FP. Even very simple operations in shaders, where it would take the input and just return it back, would sometimes take 2 ms. These shaders need to be much more robust if we are to be expected to use them regularly. Granted, this is much better than trying to use set/getPixel (which runs normally 320×240 at 60ms), but for many purposes, it falls short. We need it to run 2x faster and more consistenly.

Secondly, parts of the API don’t match up, or are only partially implemented. Why isn’t there a method to use BitmapData.draw and BlendMode.SHADER?

Graphics rendering performance still isn’t that great

Yes, you gave us vectors, and you let us pass in entire path commands. That’s great. But really, performance is not that much more improved. I can still only draw about 100 lines at 60fps. Also, if one wants to change a line stroke, one has to create an entire new vector. Why not create another GraphicsPathCommand that can change stroke thickness, color, or any other option? I’ve ended having to run many graphics.drawPath() commands and seperate vectors — I thought the whole API was created to reduce method calls and interpreted code execution.

Old performance issues still need to be ironed out:

Why is it that BitmapData.copyPixels() is still 10x faster than BitmapData.setPixels (from byte array)?