This isn’t a new article, but it touches on a topic I’ve heard a lot about recently. That is, pixel ‘blitting‘. Blitting is an old school process used in sprite-based games of essentially erasing a spot in a bitmap image based on a sprite’s alpha and using a bitwise operator to draw the sprite into that bitmap image. Most graphics systems do this transparently to the user in some fashion (pardon the pun). 8-Bit Rocket has a good introduction to these concepts with regards to Flash, but read on for the important part of this post.
Read the article on Photon Storm
The article shows that Flash Player is already fairly optimized for graphical composition operations when compared to blitting. Both showed similar framerates. However, the cacheAsBitmap operation caused an exponential increase in memory consumption when the number of sprites on stage increased. Ironically, the comparison was run by the creator of the Pixel Blitz library who, I’m sure, had a difficult time presenting the results.
There are some good details in the article so if you’re interested, read the whole thing before you decide if you agree.
Have you done any work with bit blitting or sprite sheet animation? Have you found it to be beneficial? Tell us your thoguhts.
The most important thing to say here is that there is no technique that will always be beneficial. Every tool has limitations and tradeoffs.
As well, I think there’s two topics here — blitting to a BitmapData buffer, and choosing to work with bitmaps over, say, vector graphics created in Flash.
As for the first topic, I’m sure you can find some case in which blitting to a BitmapData buffer is faster than dealing with individual bitmap DisplayObjects. For my money, I want to keep the benefits that the display list gives me, like the native API, blend modes, depth sorting, and so on (though I kind of hate the gapless depth model, but that’s fodder for another rant entirely). I think in general the Flash Player engineers made display list compositing as fast as possible, including dirty rects and platform-specific optimizations that you can’t beat with client code. Additionally, Flash Player 10.1 is currently rolling out on devices with compositing moved entirely onto the GPU. Preventing this by compositing in client code seems like a bad idea.
Now on the other hand, dealing with bitmap representations of other kinds of art can have really great gains. In every game I’ve developed recently I’ve used sprite atlases, and custom bitmap caching (it’s well-documented that cacheAsBitmap will only cache a DisplayObject through translation). Again, this is not a fix-all speed solution, and it has major tradeoffs in memory consumption. The fact that Flash Player uses 32-bit alpha blending and that current desktop versions composite on the CPU still limit its speed… But if your graphics pipeline is better at scaling up a bitmap than rendering some text in a complex font at large sizes, it might be better to cache your text in a bitmap. There’s lots of different cases to discuss here and lots of strategies for bitmap caching and prerendering, but in lieu of starting a huge post, I’ll come back on-topic and say that in no way should you construe “blitting to a bitmap buffer isn’t that much faster than compositing bitmaps” to mean “bitmaps aren’t as fast as you think.”
(By the way, this is a good time to say: I think setting .opaqueBackground on DisplayObjects will actually skip alpha blending on them, which can give you a noticeable speed boost.)
(Another favorite thing of mine about working in bitmaps: you can control the quality of the scaling with a combination of .smoothing and stage.stageQuality. You don’t get that kind of quality control with normal DisplayObjects!)
Another aside: I recently worked on a multitouch kiosk that drew lots of sprites in 3D. In order to keep the framerate smooth, at application launch I prerendered the vector assets at a very large size, and at a variety of levels of blur. Then I swapped out the blur level bitmaps and scaled them. This operated many orders of magnitude faster than rasterizing the vector art and applying realtime blurs. The memory consumption was not that bad, since multiple Bitmap instances can display the same BitmapData instance (i.e. despite being 500 images on-screen there were only 20 images in memory). Think about what doesn’t change appearance in your application and look at the most complex-to-render objects to direct your bitmap caching strategy.
Pingback: Weekly Shared Items – 23. March, 2010 | TOXIN LABS - weblog of a german design student from wuerzburg