PDA

View Full Version : Order of Operations in ActionScript - SWF execution cycle



particles
March 5th, 2010, 01:16 AM
I have read Order of Operations in ActionScript tutorial by senocular at http://www.senocular.com/flash/tutorials/orderofoperations/. It is very nice to understand how code executes inside swf. But some thing I want to understand clearly but cannot able to post comments there to get cleared.

Object Creation

The initialization of a SWF starts with (mostly) the document class constructor. This is the class associated with the main SWF instance, or the main timeline. Though this is the perceived entry point for a SWF application, the first code run within a SWF actually starts with any child objects that may be defined in the main timeline's first frame (as created in Flash Pro, or (1)otherwise defined in SWF tags).


Object Destruction

Objects generally cease to exist, or are removed from memory, when they (2)a) are no longer able to be referenced through ActionScript and b) are cleaned up by garbage collector (GC) process in Flash Player. The GC is a hidden, background process that automatically manages memory for you, deleting objects in memory when they're no longer being used. References to timeline objects are automatically managed by the timeline, created and removed as the frames with the timeline objects are entered and exited.

When a timeline object no longer exists in the next frame, it will be destroyed at the end of the current frame. There are no destructors in ActionScript, so display object destruction is often identified by removal from the timeline which can be captured through events. This process will usually mean removal from memory as well unless any (3)custom ActionScript references persist after this process.

Help me to clear those points.
Thanks in Advance,
-particles

wvxvw
March 5th, 2010, 07:22 AM
1. SWF tag should probably refer to [SWF(widht="", height="", backgroundColor="", frameRate="")] tag recognized by MXMLC and COMPC compilers (those come with Flex), which in it's turn refers to compiler options -default-size <width> <height> and other to define the SWF file header.

2. Once you set some reference to an object to reference something else, and then you reset all other references to the said object so that no "live" reference remains, this object becomes a subject for garbage collection. (GC counts references, and when it sees that the reference count is 0, then it removes the object and reallocates the memory occupied by it to a free memory pool). To be honest, I don't know how exactly this happens and how exactly Flash Player manages it's memory, there were claims it is not very efficient, but, it would be difficult to verify that).

3. is rather a particular case of removing a reference. I think at the early days of AS3 this was a confusing subject for many developers as they didn't know that display objects are not removed from memory at the same instance they are removed from the display list, however, removing an object from display list is in no way different then removing it from some Array or Vector or just any other sort of collection - which means, this will not signal to GC to remove this object.

particles
March 5th, 2010, 10:10 PM
Thanks for ur detailed replay.

Regarding point 2 and 3. Is there any function for a displayObject which returns Array of external reference (Variables, Event Listeners etc.). So that I will write a standard function to clear all the references.

-particles



1. SWF tag should probably refer to [SWF(widht="", height="", backgroundColor="", frameRate="")] tag recognized by MXMLC and COMPC compilers (those come with Flex), which in it's turn refers to compiler options -default-size <width> <height> and other to define the SWF file header.

2. Once you set some reference to an object to reference something else, and then you reset all other references to the said object so that no "live" reference remains, this object becomes a subject for garbage collection. (GC counts references, and when it sees that the reference count is 0, then it removes the object and reallocates the memory occupied by it to a free memory pool). To be honest, I don't know how exactly this happens and how exactly Flash Player manages it's memory, there were claims it is not very efficient, but, it would be difficult to verify that).

3. is rather a particular case of removing a reference. I think at the early days of AS3 this was a confusing subject for many developers as they didn't know that display objects are not removed from memory at the same instance they are removed from the display list, however, removing an object from display list is in no way different then removing it from some Array or Vector or just any other sort of collection - which means, this will not signal to GC to remove this object.

wvxvw
March 5th, 2010, 10:43 PM
I *think* you can gather such info by using http://livedocs.adobe.com/livecycle/8.2/programLC/common/langref/flash/sampler/package-detail.html however, this info isn't available to the ActionScript running in release player (and my guess is that it is difficult to almost impossible to get that info in debugger either... :( ). AFAIK this information persist in the player, but there's no way that I know of to get from there to ActionScript. So, a general advice would be to keep those references into private namespace, and if you cannot trust the environment using your SWF, then probably, override getChildByName(), getChildAt(), dispatchEvent(), getObjectsUnderPoint()?, don't allow "foreign" display objects to be parented by your display objects etc...
Well, but it's not as horrible as it sounds :) My guess is that the chance someone purposely would want to prevent some display objects from being GC-ed is almost nil...