Flash main loop

Flash is platform like another one, but specific is that we have a quarantined loop cycle.

 

That means if we set 30 FPS in our app/game that in the best way we achieve exactly 30FPS (or less in some cases), and each next ENTER_FRAME broadcast event will be dispatched in next 33,(3)ms. Rest of this time will be spend in idle mode. 

Let’s have a look closer on the each element of main loop.

1.ENTER_FRAME

This is most interesting phase and most heavy for CPU.

This event do not ensure that we have access to children by getChildByName or getChildAt. Sound weird but it is. This happens only in the specific scenario. First of all this happens when we compose scene by Flash Professional IDE and we will attach ENTER_FRAME handler to MovieClip with more than one frame and we will try to get under-construct child (yet).

In this phase each under-construct children placed on stage will be constructed . Mostly by standard constructor of MovieClip/Sprite or linked class in Flash Professional.

If we link following class to the object and we will place it onto the stage we will see output:
– Hello
– MC: onAdded

 

package eu.trzeci.test{
	import flash.display.MovieClip;
	public class MC {
		public function MC() {
			trace("Hello");			stage.addEventListener(Event.ADDED_TO_STAGE, onAdded);
		}

		public function onAdded(event:Event):void {
			stage.removeEventListener(Event.ADDED_TO_STAGE, onAdded);
			trace("MC: onAdded");
		}
	}
}

This provides some facts like:

• Constructor is launched at first visit main frame
• Constructor has access to stage
• ADDED_TO_STAGE launches right after class constructor

This is valid for object created by stage (composed in Flash Professional)

If in some place of our code we can use:

new some_animation();

Then we receive Exception about null reference to stage.  That’s why we should protect access to stage and ensure that stage != null.

2. FRAME_CONSTRUCTED

This phase ensures we have access to main graph of stage including children and parents. getChildByName() and getChildAt() work as we expect.

In MovieClip this phase handles frame scripts (ActionScript placed in Flash IDE within frame).

3. EXIT_FRAME

Most safe and (unfortunately) most unused phase. We have quarantined that display tree is ready and every frame scripts has been finished.

4. RENDER

One of asynchronous events in Flash platform. It could be dispatched at least once. We can force dispatch this event by:

stage.invalidate();

This could be useful to simulate more FPS that we already have, or just invoke some logic.

5. GRAPHIC GENERATION and IDLE

Unfortunately there is no way to separate graphic generation from idle. This is also phase when every asynchronous event are handled. Events like: MouseEvent, KeyboardEvent, ProgressEvent.

Interesting fact is that we can call stage.invalidate() in this phase event will be dispatched.

If there is some time left until target FPS will be reached the application will run into idle and wait until next cycle.

There is a lot of problems with composition using Flash IDE. I prefer to avoid linking Classes to clips in Flash IDE. Maintenance long term project what has been built could be hard.