Question

I’ve been using BitmapData.copyPixels() to draw graphics onto a canvas (Bitmap).

I need to rotate the resulting graphics without the use of draw() because it’s vastly slower.

How can I rotate the target graphic? I’m assuming that there might be a formula or library that I can use which will first reorganize the pixels that make up a graphic based on an origin (point) and radians.

I’m pretty certain that I’m not capable of creating such logic, so if there are any known libraries that do this, that would be awesome.

I’d like to achieve something similar to XNA’s SpriteBatch.Draw() method, which accepts rotation as its 5th argument.

Answer 1

copyPixels basically just copies memory blocks from one BitmapData object to another. Transforming the pixels (eg. scaling, rotating, shearing etc.) is way more CPU intensive. That’s just how things are and there’s no magic method to change this. Even if you would find another library that does these things, I doubt it will be any faster than the native implementation as it would have to be implemented in pure ActionScript and cannot be optimized as the native commands are.

If you’re blitting your scene (eg. copy sprites to a larger BitmapData canvas) and you have to perform a lot of rotations with lots of sprites, then the best way would be to render a discrete amount of render steps to a BitmapData and then use copyPixels to copy the rotation that is closest to your desired rotation. That way you would use the slow draw only once at initialization and then use the fast copyPixels from there on.

There’s another way for drawing rotated bitmaps, by using the new 3D API, you could simply render textured quads which you can rotate, scale and move to any extent without performance drops. This would be the closest to XNAs draw implementation, but it would require you to dump the blitting (draw to a Bitmap) entirely.

Overall I would go with the simplest way and just use BitmapData.draw. Create a test-case that draws your estimated maximum of concurrent sprites and profile it to see if the performance-impact is so large that it’s worth implementing any of the mentioned workarounds.