Working on a large Papervision3D project, I had begun to notice a constant increase in RAM usage as the Scene was running. This particular scene does a lot of updating of BitmapMaterials and Planes, responding to user input by transforming a thumbnail plane into a larger full view plane. The animations run about 1 second, with roughly (on faster machines) 30 frames per second. On most machines out in the ether I’m hoping to maintain 20 FPS.

So, what I noticed was that there was a pretty large spike in memory usage when the scene first loads–no problem, I’m loading a couple hundred images in, I should expect that. However, I noticed also that as I transitioned from one image to the next (the smaller to the larger), RAM use would jump up about 10 megabytes. Where is garbage collection when I need it?

The trouble turned out to be that I was re-instantiating a BitmapMaterial object during each from of the animation. For whatever reason (I haven’t had time to walk through the BitmapMaterial and MaterialObject3D classes carefully yet), BitmapMaterial objects seem never to leave memory. The issue may be more complex than this though, as I’m also reinstantiating a plane each frame as well to accommodate the changing siz. Perhaps the Plane is not leaving memory either?

Combing the web, I found an article on the Papervisio3D 2.0 Alpha “Great White” (http://thebackbutton.com/blog/47/materialmanager-memory-leak-in-papervision3d-great-white/) in which he mentions the whoas of a certain Singleton object that goes by the name of MaterialManager.

I scrubbed my Papervision3D 1.5 hierarchy for the same and found nothing. Looking a little further though, I found in the SceneObject3D class a reference to a class called MovieMaterial, which has in it a Singletonish static method called updateAnimatedBitmaps. This function references the animatedMaterials dictionary, containing (presumably) references to every material in the Scene including the one’s that I want, expressly, to die.

My apologies to anyone expecting a clearer outline of what’s going on with the animatedMaterials dictionary. You won’t find it here. You will however find a couple of fixes for this particular flavor of memory leak.

The first fix I found was to create a private class property of a BitmapMaterial object for each item that gets displayed. The class arrangement I am using has an composed DisplayObject3D inside of a class that handles event assignment, etc. So, by instantiating this BitmapMaterial once and simply changing it’s texture property each frame of animation instead of reinstantiating it, the animatedMaterials dictionary doesn’t get bloated with invisible BitmaMaterials, and the RAM uses stays where it should. Each frame I would then reapply the material to the newly resized plane.

A second fix, taking a note from Alex Bustin (see link above), is to simply comment out the lines of code in the SceneObject3D class that run the updateAnimatedBitmaps function. Both of these fixes seem to do the trick, I’ll leave it up to you decide which feels better.

I hope someone else might find this useful. Maybe you can spare yourself the three hours of trouble shooting. =P.

For those out there who will stumble around as I did for a solution to apparently missing items in the code hinting context menus inside the Flash ActionScript editor, the answer is as you probably suspected–something simple.

If, for instance, you try to import a sub-package of the flash package and find yourself with only display, external, filters, geom, net, and text much like this:

The problem is that your ActionScript file is loading code hints for Actionscript 1.0 and 2.0. This problem would be very apparent to anyone who, unlike me, leaves the ActionScript editor’s built-in class and package browser open. For those who have closed this frame in order to save horizontal space might be at a loss for why their code hinting is incomplete.

The Fix

To fix this issue, just open the ActionScript class and package preview pane and select the proper version of ActionScript for the AS file.

Like a lot of Flash developers who don’t always get to work on the big-budget projects, I’ve been pretty slow to get my feet wet in ActionScript 3.0–Flash’s newest supported scripting language. Over the last few weeks, I’ve been knee deep in Packages, new native types, display lists, and to my greatest enjoyment, the ActionScript implementation of E4X.

For those who don’t know, E4X stands for EcmaScript for XML. EcmaScript as I’m sure everyone reading this already knows, is a root language that both JavaScript and ActionScript are based on. Unlike C++ or Java, Ecmascript lets you do a lot of magic with data-typing, passing functions as data, and much, much more. XML is a set of rules that governs how to mark up data in a way that describes it.

Within the scope of this post though, XML is just a way to get data into a Flash movie (and often get it back out of the Movie as well). So, let’s look at a little snippet in AS2.0.

Let’s say this is our XML:

<book>
     <chapter>Cotton Ball Joint Compound</chapter>
     <chapter>Rust Protector of Liberty</chapter>
     <chapter>Key Board of Trustees</chapter>
</book>

In ActionScript 2.0, if we wanted to access the name of the first chapter, we’d have to write some ActionScript like this:

//Assuming we already successfully loaded the XML
var chapterName = xmlObj.firstChild.childNodes[0].firstChild.nodeValue;

While it get’s the job done, it’s certainly not the most efficient or the most intuitive bit of code.

Compare that with the AS3.0 E4X version though:

var chapterName =  xmlObj.chapter[0];

Ahhh, now that is a beautiful thing, isn’t it? Not only do we get to use the XML node name as a variable-style accessor, we don’t have to fumble with all the firstChildren issues of yesteryore. E4X assumes for us that we’re after the nodeValue rather than the node itself.

Whoever concepted E4X is my personal hero of the day. Whoever decided to implement it as part of AS3.0 is my personal hero of tomorrow.

Now, back to O’Reilly and the world of Essential ActionScript 3.0. Stay tuned for more code snippety goodness!