Choosing Between Timer and Event.ENTER_FRAME

Choosing Between Timer and Event.ENTER_FRAME

As we’ve just seen, the Timer class and the Event.ENTER_FRAME event can both be used
to produce animation. So which one is right for your family? Here are the major factors
to consider:

1. Frame rate is subject to change

When a .swf file is loaded by another application, the frame rate of that application
might be vastly different than the .swf file’s designated frame rate, potentially
causing the .swf ’s animations to play too quickly or too slowly. The loaded
.swf file can, of course, set the frame rate, but that change in frame rate might
cause undesirable playback behavior in the parent application. The Timer class
offers some frame-rate independence (subject to the limitations discussed in the
earlier section “Frame Rate’s Effect on Timer”).

2. Using many Timer objects requires more memory

In decentralized animation management architectures, using a separate Timer to
control the animation of each object requires more memory than would be
required by the analogous Event.ENTER_FRAME implementation.

3. Using many Timer objects can cause excessive screen update requests

In decentralized animation management architectures, using a separate Timer in
conjunction with updateAfterEvent( ) to control the animation of each object
leads to multiple independent requests for screen updates, possibly leading to
performance problems.