Freezing and unfreezing objects
Wow.. It’s been a long time since my last post! But don’t worry there is a lot of things I plan to talk about.
So let’s start with: Freezing and unfreezing objects
*Erratum*
When I made all my tests, they were builded into FlashCS3 (which only build Flash 9 SWF)
And when playing the animations, it was really ugly.
But when you build the same animation in Flash CS5 (Flash 10 SWF), the animation is really clean and have absolutly no object waiting for GC. which is GREAT.
And if you start a SWF10 preloader and then load a SWF9 file? working great!
And if you start a SWF9 preloader and then load a SWF10 file? Bad GC!
So this post is still valid only if the first thing you run is a SWF9 animation in FP9/10/10.1
*End erratum*
The problem
A few months ago (before FlashPlayer 10.1) I made some comments on the Adobe “Freeing memory” article about the need of manually stopping MovieClip at the end of a timeline animation in order to optimize CPU and memory.
Thibault pointed me to a very nice article (solution) to this problem.
Now that FP 10.1 is released, I just realized that it’s now even worst.
When a MovieClip playhead hit an empty frame on the timeline or a blank KeyFrame it remove itself (and its child’s) from the screen. But everything continues to play until the GC collect them all.
With FP 10, the ENTER_FRAME event is not dispatched anymore and you cannot instantiate a class after root object has been removed from stage, but the visual is still playing.
In fact, the MC doesn’t just keep playing. It keeps instantiating (allocating memory and processing time) clips and child’s and everything that would be required if the original clip wasn’t removed.
This means that even when you have 1000 DisplayObjects on stage, you might manage and compute 4000 in the background without knowing it.
Performance wise, in FlashPlayer 9 it was bad.
In FlashPlayer 10 it was badder… …and in 10.1 it’s just Badderdest!
One big difference since 10.1 : A timeline that has been removed from stage continue to play and dispatch AddedToStage and RemovedFromStage for object that shouldn’t be accessible, hence giving bad information on the stage current state.
Example
Here is video of how this could impact the DisplayObject hierarchy, CPU, and memory.
In the video, wait for the green squares to appear… they are assets waiting for GC.
Blue square mean MC received a “RemovedFromStage” event, and gold square mean assets received “AddedTOStage” event.
Result in FlashPlayer 9 and 10
Result in FlashPlayer 10.1
As you can see, most the sprite are waiting for collection. You can also look at the stats on the bottom of the screen.
If you want to use my profiling tool: FlashPreloadProfiler
Full documentation is also on that page.
Source
SVN source for the example showed in the videos are available on Google Code
Comments are closed.
jpauclair 
How can you say it’s worst in flash player 10 when the publish settings of your example is set for flash player 9 ? If you compile for flash player 10 you will see a totally different behavior.
Maxime: if what you say is true, it’s even worse news. So far I knew only one feature that depended on assembly version – You cannot set mouse cursor to i-beam, even if the SWF plays in FP10, but the first loaded SWF was compiled for FP9. This is bad, but not critical. However, if the assembly version impacts how objects are GC’ed it is very bad… This actually means that regardless of the version you are building for, you will have to deal with unpredictable behavior, which doesn’t depend on you…
jpauclair: Regarding the “very nice article” link. It’s kind of a very silly way to store pressed keys 🙂 And I have no idea why the dictionary was declared as using weak keys, while keys are built-in constants!
The normal way would be:
var keys:int;
function onPress(event:Event):void {
keys += event.keyCode;
}
function onRelease(event:Event):void {
keys -= event.keyCode;
if (keys > 0) {
// do something here
}
}
Sigh… Adobe code examples make me sad…
@wvxvw : from what i see the way Adobe using weak reference here is completely useless, but the way they use Dictionary to store key pressed is not bad at all, although in this case it’s not any useful, but once you need multiple key pressed combination, it’s the way to go, you can also use an object, it’s just the same, your example can not handle key combination.
@jpauclair : I find difficulties trying to understand what you want to talk about, although your others articles is really excellent. Can you explain more clearly ? Also i find the test not clearly help us get the idea …
I’m digging into the code now, just trying to understand that …
He was at a black tie dinner accepting one of the many awards I am sure he will receive this year, and he made some comments about how American public schools weren t up to snuff.