One of the feature I would really love to see in a future release of the Flash Player is a native rasterizer for display objects. Imagine something like :
myMovieClip.rasterize = true;
This code would rasterize your DisplayObject as an animated PNG. It would bring crazy improvements for designers and coders who want to improve the rendering performance of any animation. This would be in fact the same behavior as the Banana Slice component I talked about.
When talking about this, some people could think "Well, you have cacheAsBitmap for that". The reason why such a feature would rock is mainly due to the fact that cacheAsBitmap is very dangerous. Well, it won't hurt you 
, but it can definitely hurt your application performance.
As I said before, when cacheAsBitmap is set, the DisplayObject is cached as a bitmap on memory and the Flash Player is using this copy to render it on screen. The main problem that we have here is that if you do more than moving this DisplayObject on x and y, for each frame the Flash Player is updating the cached copy on memory before updating the screen. So if you apply any rotation, scale, alpha, or even if you have any key frames in your DisplayObject you will get performance decrease.
Hopefully, you can bypass this limitation by creating a BitmapData by yourself, draw the MovieClip on it, and pass it to multipe Bitmap instances. So let's take a simple example, in the folllowing movie, when you click on the "cacheAsBitmap" button, I create multiple instances of an Apple MovieClip, set cacheAsBitmap, and move them on screen :
var apple:Apple;
for (var i:int = 0; i< 100; i++)
{
apple = new Apple();
apple.cacheAsBitmap = true;
addChild ( apple );
}
When you click on the "draw" button, I first create an instance of the apple MovieClip, draw it on a BitmapData and then create Bitmap instances linked to the one and unique BitmapData instance :
var source:AppleSource = new AppleSource();
var buffer:BitmapData = new BitmapData ( source.width, source.height, true );
buffer.draw ( source );
var bitmapApple:BitmapApple;
for (var i:int = 0; i< 100; i++ )
{
bitmapApple = new BitmapApple( buffer );
addChild ( bitmapApple );
}
Online demo :
As you can see, manual rasterizing is king
You can download the sources here
Comments (15)
Indeed. I’ve come to the same conclusion when I was asked to create a really animation-heavy tile-based game.
I wrote my own “slicing” class to easily rasterize movieclips and have them play back at different framerates.
The only downside to this is memory. BitmapData is stored in RAM uncompressed, so a simple animation can quickly eat up dozens of MB’s of RAM if you’re not careful.
You can read my original post here: http://blog.vandenoostende.com/?p=47 and download the scripts there.
But yeah, a native animation rasterizer would be neat
We could create something like this as a subclass of Sprite or movieclip. Is this the same thing as frame-ripping?
I don’t know why but it remember me some really recent debate with the worst flash activist ever.
Really enjoying the post and the example. I hope that Adobe will do something special for your “rasterize” idea.
In your code, I think you did 2 errors, in the first sample, I think it should be
var apple:Apple;
instead of
var apple:Pomme;
And in the second sample:
var bitmapApple:BitmapApple; intsead of
var bitmap:AppleBitmap;
Nice work on the demo.
Hi Gilles,
I saw your AnimationSlicer which is very nice. I agree with you, the only drawback here is memory usage. In common cases it is reasonable, and having a native rasterizer could solve such behavior. I will definitely push such a feature for a future release.
TK,
Yes, there are many ways to do it. In this example I extended Bitmap and passed the BitmapData to it, but you could extend MovieClip and do all the rasterizing inside it and add a final bitmap showing each frame as a child.
Tek,
hehe yes, I was sure you would remember it
Hi Zedia,
Thanks
Copy & paste doh !
impressive difference, thanks for the tip
Take a look at this class, it does just that:
http://code.google.com/p/mrdoob/source/browse/trunk/libs/net/hires/utils/display/BitmapDataSequence.as
A sliced game may well use 100 mb of RAM.. so what about it? I don’t have a problem with that. Your average downloadable game will do that too. It’s actually very smart: usethe vectors/gradients/etc for data storage (=download time), and unpack (rasterize) for hyper run speed.
Hi Mr.doob,
Nice class
You could also use the getBounds method to detect if the DisplayObject is not aligned at 0,0. Use a matrix and translate the matrix passed to the draw method, to always have your bitmap entirely drawn.
You’re right!! Will put that on the next version, thanks!
yeah, nice.
tek: can´t be the worst flash activist ever if everyone remembers him and even if people kid about him he inspires others
WOW this really add some speed! i´m getting %600 speed improve on a site i was having using cacheAsBitmap on some sprites.
Would this benefit a case where only one DisplayObject is on screen?
Hi Doooooo,
Yes, this would benefit if the DisplayObject is moving and contains complex content like gradients, alpha transparency.
In terms of rendering performance, bitmap will always win
best,
Thibault
Trackbacks/Pingbacks (8)
[...] http://www.bytearray.org/?p=290 [...]
[...] Why cacheAsBitmap is bad [ by Thibault Imbert ] [...]
[...] http://www.bytearray.org/?p=290 [...]
[...] Why cacheAsBitmap is bad [ by Thibault Imbert ] (from ByteArray.org) Share and Enjoy: [...]
[...] ne pas utiliser le fameux cacheAsBitmap de Flash? En fait pas mal de raisons explique ce choix, mais surtout, je n’ai jamais trouvé moyen d’obtenir d’aussi [...]
[...] Why cacheAsBitmap is bad Flex Move Effect Messes Up Mask Alignment [...]
[...] – Consider bitmaps versus vectors. I’ve shown to the audience a benchmark application that demonstrates the good usage of the cacheAsBitmap property. My advice is the following. If you manipulate graphical elements using the X and Y axis only, please set the cacheAsBitmap property to true. It will dramatically improve the performances of your applications. Transparency is very expensive, avoid the alpha channel, avoid filters and blend modes. If you use the rotation property, don’t use cacheAsBitmap, but the Draw sample detailed here: http://www.bytearray.org/?p=290 [...]
[...] Great tip: ByteArray.org – Why cacheAsBitmap is bad [...]