cacheAsBitmap is a feature in Flash (since Flash 8) that tells the Flash Player to store a movieclip of vectors into one static instance in memory. It’s a great way to boost the performance of your Flash.

But I’m writing about how to use cacheAsBitmap (you can just google that).

Some things you may never knew about cacheAsBitmap.

• With the exception of changing position, if a movieclip animates with cacheAsBitmap set to true, performance will slow down. This is because the Flash Player must recalculate the vectors and reload the Bitmap instance into memory. Moving x or y doesn’t change the vectors of the movieclip and thus will not affect performance.
• cacheAsBitmap is automatically set to true whenever a filter is set on a movieclip.
• A movieclip moving with cacheAsBitmap set to true, the movieclip will probably not animate smoothly. Unless the displacement values are round numbers, the movieclip will seem to move in a zig zag.

Example:

clip.cacheAsBitmap = true;
clip.onEnterFrame = function() {
this._x += 1;
this._y += 1;
};

Will look fine…

clip.cacheAsBitmap = true;
clip.onEnterFrame = function() {
this._x += 1.5; // Decimal displacement makes things shaky
this._y += 1.5;
};

Won’t.
Just take a look at the following example… Is the red dot shaking or is it just me? Maybe it’s scared of the blue dot.

So I was working on the sequel to Boomshine this week, and for some bizarre unexplainable reason, the file SWF perfectly in Flash Player 9 r45; however, if I dropped down to Flash Player 9 r28 (or anything lower), the Flash wouldn’t work at all!

I looked at the change log for r28 to r45 released by Adobe. These are the four I could find:

New ActionScript 3.0 components for Flash CS3 Professional do not function correctly in versions prior to Flash Player 9.0.45.0.

Well, I am using some CS3 components, but Adobe doesn’t say they should crash, only that they do not function correctly.

Runtime Shared Libraries (RSLs) exported for ActionScript 3.0 generate a runtime security error. (195395)

No runtime errors for me…

Display objects instantiated by the playhead entering a frame because of a gotoAndStop command (or similar action) incorrectly process actions on frame one. (189490)

This is something that I don’t quite fully understand. However, just to be safe, I move all my code from frame 1 to frame 2.

flash.text.TextField.getCharBoundaries returns a rectangle that is offset to the left by 2 pixels for fields that are created using the Flash CS3 Professional text tool. (193249)

Not applicable in my situation.

As you can imagine, this was painful to debug. I downloaded Flash Switcher Extension for Firefox by Alessandro Crugnol which allows you to switch Flash versions on the fly inside a browser. The only negative side to this is that Firefox has to restart every time you switch flash versions.

After investigation and frustration, I finally figured out the problem.

In Flash 8 and Actionscript 2.0, to get around the preloading linked movieclips and objects properties, you had to place an instance of the object on one of the frames and uncheck Export to First Frame from the linkage properties menu. This ensured that the assets would load after frame 1 rather than before it. Meaning that you could create a preloader to load the assets.

If it still doesn’t make sense, imagine creating a 5 frame flash. In the first frame you have your preloader code.

onEnterFrame=function()
{
var percLoaded:Number = getBytesLoaded()/getBytesTotal();
trace(Math.floor(100*percLoaded));
if (percLoaded >= 1)
gotoAndStop(5);
}

Now import your favorite picture (larger the better) into the library. Put it in a movieclip, and export the movieclip with the linkage identifier MyPic. Make sure you keep the Export in First Frame checked.

Put the following code on frame 5.

attachMovie("MyPic","MyPic",1);

Run the flash and you should see 100 in the trace action and your picture on the screen. Now try simulating the download, you’ll still see that the preloader will only show 100. This is because the preloader frame is actually loaded after the picture is loaded.

To reverse this, go back to the library panel and uncheck Export to first frame. Run the flash, and you’ll notice the picture doesn’t show up anymore! That’s because the picture wasn’t loaded into Flash memory before the frame that wanted to display it.

Now place the movie clip on the stage on frame 3. Run the flash, in simulated download mode, and you’ll notice your preloader is now working fine and tracing from 0-100 a few times before going to frame 5 and showing the picture. Now that you put the image on frame 3, frame 3 has grown in memory size and loaded the movieclip, meaning that after the preloader finishes, you can attach the movieclip on runtime. Pretty nifty.

Now I told you that story to tell you this story. Flash 9 has changed completely. You can no longer uncheck the Export to First Frame, else the SWF will simply not work – with Flash Player 9 r28.

DisplayObjects aren’t the only things affected, sound won’t load either unless it’s loaded before the first frame.

Check out the attached source for an example. It will work perfectly with Flash Player 9r45, but with anything lower, it won’t.

Maybe I’ll submit this to Adobe so that they can add it to the change log?

Download the FLA that won’t work with Flash Player 9r28 and below…

-Danny