//
// FRAME / INTERVAL
//

fTime = getTimer()
iTime = getTimer();
var frame = 0;

var id = setInterval ( this, ‘onInterval’, 0 );
function onInterval () {
var now = getTimer();
var change = now - iTime;
iTime = now;
trace( ‘onInterval: \tf: ‘ + ( frame ) + ‘\tc: ‘ + change );
}

this.onEnterFrame = onFrame;
function onFrame()
{
var now = getTimer();
var change = now - fTime;
fTime = now
trace( ‘\nonFrame: \tf: ‘ + ( frame++ ) + ‘\tc: ‘ + change + newline);
}

onFrame: f: 93 c: 88

onInterval: f: 94 c: 8
onInterval: f: 94 c: 8
onInterval: f: 94 c: 8
onInterval: f: 94 c: 8
onInterval: f: 94 c: 8
onInterval: f: 94 c: 8
onInterval: f: 94 c: 8
onInterval: f: 94 c: 8
onInterval: f: 94 c: 26

onFrame: f: 94 c: 90

onInterval: f: 95 c: 73
onInterval: f: 95 c: 5
onInterval: f: 95 c: 8

onFrame: f: 95 c: 86

onInterval: f: 96 c: 8
onInterval: f: 96 c: 8
onInterval: f: 96 c: 8
onInterval: f: 96 c: 8
onInterval: f: 96 c: 8
onInterval: f: 96 c: 8
onInterval: f: 96 c: 8
onInterval: f: 96 c: 8
onInterval: f: 96 c: 8
onInterval: f: 96 c: 8
onInterval: f: 96 c: 8

You can prevent the compiler from showing errors by adding the following line:

intrinsic function setTimeout():Number;

to your toplevel.as file, located in
“documents and settings\\Local Settings\Application Data\Macromedia\Flash 8\en\Configuration\Classes” folder.

Conversely, for MTASC, you can add the following line:

static function setTimeout():Number;

to the TopLevel.as, located in MTASC’s “std” folder.

The decision to draw data to the screen is made on an application wide level, careful consideration is taken by the developers to ensure that drawing their data doesn’t intrude on the end user in any way. Therefore events tied to drawing the screen are inherently subject to the same considerations. This means that your frame event reliant code is optimized such that if it were to break, the end users compuer is not affected, and by ‘not affected’ I mean there is usually some kind of graceful degradation.

I unfortunately have limited resources in knowing the exact inner workings of the Flash Player, so all information is based on my understanding of virtual machines in general.

With that said, there is nothing to say that timers are not affected by the VM in the same way that frame events are. However through what I have tested it does not seem so. It seems that timers are executed on a more direct level than frame events. This means that a lack of consideration in this aspect can leave your application in ruins.

The use of timers and updateAfterEvent() can lead to serious issues within your application. If a timer is set to some unreasonably low value the operating system can only go so far as to accomodate the Flash Player. This means that it’s not likely that your actual interval will reflect your desired interval. The reason this happens can be any of an infinite possibilities. Most likely though, it is caused by your computer not being capable of processing all of its running applications. The developer must remember that no matter how crafty they are, they’re still bound by the same physical laws the rest of the universe is. It will always become more difficult, the more data you have to process.

The reason that your flash application begins to run slowly has just as much to do with how it is designed as it does with how the computer it’s running on executes it. In short, use what the developers give you, don’t try to force an application to do something it’s already having a hard time doing. This leaves the issue of timers and frame events up as a design consideration for you the developer.

Both intervals/timers and frame based events are completely acceptable solutions to any problem that has planned their use in an ‘efficieny’ aware manner.

Sorry, don’t know what that was about… Great blog, keep up the good work.
Michael