Does AS3 Event.ENTER_FRAME run on every frame, always? Even on slow computers?

Question

I have a script that relies on ENTER_FRAME event to run every time. I have noticed on some slower computers there can be some lag when a flash movie is playing.

Does ENTER_FRAME run on every frame, even if its on a slow computer? If the flash movie lags, does the ENTER_FRAME event still run and the rendering just try to catch up?

Is running code on ENTER_FRAME a reliable way to execute code every time a frame is entered?

Solution 1

Yep. Every frame, no exceptions. If something is slowing a movie down (either heavy scripts or heavy graphics), it Event.ENTER_FRAME handlers are still being executed before a frame is rendered.

Hence, it's generally a good idea to use a Timer instance with TimerEvent.TIMER, even if it's delay is set to be equal to 'ideal' frame duration for your movie's fps. Because timer handler is not bound to be triggered at exactly uniform rate.

See the following link for more in-depth explanation: The Elastic Racetrack

Solution 2

if you have a framerate set to 30fps, then the event will fire 30 times per second, as long as you don't put a load on the processor, making the frame rate drop. Therefor, if the framerate is fluctuating, you might get more consistent results with a timer Event.

on a side note, be aware that... Using many Event handlers can create performance issues too (if you have too many) Every time it is called, flash has to create an event object at the very least. That means you have memory that needs to be allocated every time the event fires. That memory then needs to be garbage collected at a later time, and the garbage collection will also use resources to execute.

If you have have many movie clips or sprites it could be worthwhile to have one controller that manages all of them, rather than each one having it's own EnterFrame handler.

Solution 3

The general answer to general question.

If you want to improve performance of Flash Player then consider following points,

1. Do not use strokes unless if it is required. (Strokes are more cpu
   intensive)

2. Use less gradient colors if possible.

3. Use optimized bitmaps if any.

4. Make effective use of addChild(yourObject), addChildAt(yourObject, index), removeChild(yourObject), removeChildAt(index).

5. Listen to Event.ADDED_TO_STAGE and Event.REMOVED_FROM_STAGE respectively.

6. Listen to addEventListener(somelistener, somefunction);
   removeEventListener(somelistener, somefunction);

7. Listen to Event.ACTIVATE and Event.DEACTIVATE.

8. If objects are loaded externally then make sure to use
   unloadAndStop() to completely remove unnecessary objects from the stage.

Comments

[zechdc]

What do you mean, " it's generally a good idea to use a Timer instance with TimerEvent.TIMER" Not sure I follow? –

[zechdc]

Also, that article was kind of confusing. Is it saying Timer is more accurate than Enter Frame? Or Enter Frame gets executed only once per frame while timer gets executed an unknown number of times per frame?

[shanethehat]

It's saying that Timer is more accurate because it is executed an unknown number of times instead of one; the assumption being the timer checks many more times than once in a frame unless the program execution delays it, in which case the enterframe event would also not fire until whatever was executing completes.

[scriptocalypse]

I maintain that neither is more accurate. The truly important part is to keep track of delta time between updates and use delta time to update your positions instead of a fixed value "per frame." The delta time is simply "guaranteed" to be roughly the same every time the function runs if it's a timer, whereas in the enter frame loop it's going to be however long it takes for the entire rendering process, which means your delta time can vary wildly.

[scriptocalypse]

... continued : this might be important if you care about what positions the objects might be in during the space between actual screen refreshes, but if you don't then neither one is particularly better or more accurate.

[fenomas]

It is not generally a good idea to use a Timer with your ideal framerate, because when the real framerate slows down, your Timer handler will be doing iterations whose results will never get drawn to the screen. Do your logic in an EnterFrame handler, and in that handler use getTimer() to check how long it's been since the last frame update, and act accordingly.

[fenomas]

It's true that during heavy loads Timer events may be timed more consistently, but that's not useful - whatever you do in response to those events will not be drawn to the screen until the next frame. For any logic that updates what the user sees, do it in a frame event. (Timers are really more useful for things you want to do less often than the framerate, like every few seconds or minutes.)

[Michael Antipin]

Sorry, but I don't agree. It depends on what you are trying to accomplish. In my experience controlling the exact amount of time is almost always useless when doing some visualization stuff (like animation). Because when you do control time gaps, you intentionally create clearly visible irregularities in your animation, event when general slowdown is negligible. When you do not, a user who experiences a movie slowdown sees slow but still smooth visualisation.

[Michael Antipin]

when the real framerate slows down, your Timer handler will be doing iterations whose results will never get drawn to the screen -- this is partially true. Flash Player tries to maintain the amount of calls to TIMER event handler. However, TIMER event may even skip a frame if a movie is slowed down (meaning that you can get two consecutive ENTER_FRAME events with no TIMER events in between).

[fenomas]

Nox, no matter what you do with timer events or getTimer, you are guaranteed to get a frame event before each redraw, hence that's the correct place to update visuals. Whether to measure the time delta each frame, and what to do with that delta, depends on the content and what your goals are. But there is no value whatsoever to running the logic that updates the screen more or less frequently than the screen gets redrawn.

[fenomas]

Also: Flash Player tries to maintain the amount of calls to TIMER event handler. - this is not correct. At a regular interval (driven by the container, but typically every 10-50ms or so) Flash will check whether the relevant interval has elapsed since the last timer event, and if so issue one. Then it does the same for frames, then it waits another 10-50ms and repeats. It doesn't make any attempt to maintain any particular order of events or event types.

[Michael Antipin]

I want to mention, that in current versions of player Timer events behave in a rather weird way. If you try to measure the time elapsing between timer ticks, you may notice a frightening and repeating regularity of events fired at wrong intervals. Timer events may even be fired twice per one frame (which does not make any sense to me). The closer your frame rate is to refresh rate of you device's screen, the more uniform intervals between timer ticks you get. Say what?