4

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?

Benny
  • 2,250
  • 4
  • 26
  • 39
zechdc
  • 3,374
  • 9
  • 40
  • 52

4 Answers4

7

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

Benny
  • 2,250
  • 4
  • 26
  • 39
Michael Antipin
  • 3,522
  • 17
  • 32
  • What do you mean, " it's generally a good idea to use a Timer instance with TimerEvent.TIMER" Not sure I follow? – – zechdc Jul 06 '11 at 20:24
  • 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? – zechdc Jul 06 '11 at 20:28
  • 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. – shanethehat Jul 06 '11 at 21:54
  • 3
    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 Jul 06 '11 at 23:28
  • ... 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. – scriptocalypse Jul 06 '11 at 23:29
  • 4
    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 Jul 07 '11 at 07:32
  • 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 Jul 07 '11 at 07:42
  • `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). – Michael Antipin Jul 07 '11 at 08:15
  • 1
    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 Jul 12 '11 at 02:55
  • 1
    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. – fenomas Jul 12 '11 at 03:31
  • 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? – Michael Antipin Jul 12 '12 at 21:12
1

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.

Daniel
  • 34,125
  • 17
  • 102
  • 150
  • 1
    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.) – fenomas Jul 07 '11 at 07:35
1

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.

Fionnuala
  • 90,370
  • 7
  • 114
  • 152
Rajneesh Gaikwad
  • 1,193
  • 2
  • 14
  • 30
0

Check this out for anyone looking for a framerate independent solution... this guy's really smart and has a technique for both animating consistently across multiple framerates (slower devices, desktops, etc) and keeping your object's framerate independent of your timeline's framerate. Check it out here. Tips 4 & 5. Hope that helps!

I found that the timer class is actually very inconsistent when mashing buttons, sometimes the timer just fails to complete a cycle and the TIMER.COMPLETE event never gets reached, if I had 5 cycles of 100ms, it would just stop after 3 cycles... Also, framerate will fire every frame but IT IS NOT CONSISTENT!!! If you have lag on the CPU, your framerate will drop and hence you will not have anything updating at regular intervals, but rather whatever the current framerate is. Check out that link, there's even some framerate code you can use on your projects to check it.

Bacon Neck Games
  • 1
  • 2