dcsimg
A Flash Developer Resource Site

Results 1 to 14 of 14

Thread: [RESOLVED] EnterFrame pro's/con's

Hybrid View

  1. #1
    Senior Member
    Join Date
    Jan 2007
    Location
    Nottingham, England
    Posts
    263

    resolved [RESOLVED] EnterFrame pro's/con's

    Hi,

    Just curious what people think about the ENTER_FRAME event?

    I've been using some scripting i found online to scroll a background, but it's very jumpy. The mouseMove event is used to trigger the scroling event which then repositions the Bg with event.updateAfterEvent code.

    Problem is if you move the mouse too quick it doesnt move the Bg until you stop or slow down. Doesnt make the whole thing look very smooth.

    I could probably get around this quite easily by changing it to an ENTER_FRAME event to update the background, but isnt the ENTER_FRAME event something to be avoided if possible? something to do with it clogging up memory and slowing the swf down if left running too long?

  2. #2
    Bearded (M|G)od MyFriendIsATaco's Avatar
    Join Date
    Dec 2002
    Location
    Awesomeville.
    Posts
    3,046
    Are you working with an extremely large background image? Using the updateAfterEvent() and an extremely large image is going to cause problems just with CPU. Flash doesn't handle large images very well and moving it that quickly probably isn't working out too well. So in this case, maybe limiting it to ENTER_FRAME would be better. But you can actually eliminate the ENTER_FRAME and just take out the updateAfterEvent() call. It'd pretty much be the same thing without the slight extra overhead of ENTER_FRAME.

  3. #3
    Senior Member
    Join Date
    Jan 2007
    Location
    Nottingham, England
    Posts
    263
    Hi,

    thanks for the advice. The images are large (100Kb +) so will probably try the onEnterFrame instead.

    I had ago without the update event code and it seem to be a bit quicker. Still have the same problem as before though - if i keep the mouse moving at a high enough speed, the Bg doesnt move. The mouseMove event listener only seems to work when it's slowed down or stopped.

    out of curiousity, isnt the onEnterFrame event going to be generally bad news in terms of the cpu?

  4. #4
    Ө_ө sleepy mod
    Join Date
    Mar 2003
    Location
    Oregon, USA
    Posts
    2,441
    Nothing in Flash can ever run faster than the frame-timer anyway so enterFrame is usually a better solution than either Timers or mouseMove.

    EnterFrame does incur a little more overhead, but it's spread consistently over the movie, so if you're getting stutters with it your problem is probably in the code being called, regardless of how you're calling it. The only problems I've ever had with eFrame are with javascript co-computing things and getting weird lags...but my site is running some pretty heavy code in both the javascript and flash sides so it's kind of an outlier. Bottom line - try it and see what happens.

  5. #5
    Senior Member
    Join Date
    Jan 2007
    Location
    Nottingham, England
    Posts
    263
    Quote Originally Posted by neznein9
    Nothing in Flash can ever run faster than the frame-timer anyway so enterFrame is usually a better solution than either Timers or mouseMove.

    EnterFrame does incur a little more overhead, but it's spread consistently over the movie, so if you're getting stutters with it your problem is probably in the code being called, regardless of how you're calling it. The only problems I've ever had with eFrame are with javascript co-computing things and getting weird lags...but my site is running some pretty heavy code in both the javascript and flash sides so it's kind of an outlier. Bottom line - try it and see what happens.
    Thanks nezein9 - you must of posted whilst i was typing

  6. #6
    half as fun, double the price senocular's Avatar
    Join Date
    Feb 2002
    Location
    San Francisco, CA (USA)
    Posts
    4,361
    Quote Originally Posted by neznein9
    Nothing in Flash can ever run faster than the frame-timer anyway so enterFrame is usually a better solution than either Timers or mouseMove.

    Not sure what that means, but to be clear, enterFrame is in sync with the frame refresh of the movie. It gets called once each time the frame is rendered. Other events like timer and mouseMove actually occur outside of the frame refresh of the movie. These events can occur many times in the time frame it takes one enterFrame event to occur. If you want changes within these events to be visible on the screen, you can use event.updateAfterEvent which forces a frame refresh within that event outside the normal frame rate.

    Of course here is where you have the overhead since you're forcing refresh outside the expected refresh making the player do a lot more work than it was originally intended to do with its originally set frame rate. Ideally updates with these events should be for enhancing interactive response time for low frame rate movies. For example, drag and drop for a 12 fps animation movie. using event.updateAfterEvent in mouseMove for your drag and drop, feedback for the user in that interaction would be much more responsive compared to what it would be with the 12 fps set for the animation.

    Additionally, you should know that Timer-based animations are not necessarily time-based animations. There are a number of factors that could cause timer timing to stall or be paused which I've seen break applications because of their dependency on them. If you want to make a time-based animation, you should animate based on getTimer and update based on enterFrame since, afterall, that is when your movie is expected to refresh the screen.

  7. #7
    Ө_ө sleepy mod
    Join Date
    Mar 2003
    Location
    Oregon, USA
    Posts
    2,441
    @Senocular: Referring to the fact that you can 'update' your code many times in a frame with a timer but that it wont actually update anything until a frame tick.

    @anyone else: Here's a link with more than you ever wanted to know about frame updating.

  8. #8
    half as fun, double the price senocular's Avatar
    Join Date
    Feb 2002
    Location
    San Francisco, CA (USA)
    Posts
    4,361
    Quote Originally Posted by neznein9
    @Senocular: Referring to the fact that you can 'update' your code many times in a frame with a timer but that it wont actually update anything until a frame tick.
    You're still confusing me ; )

    Here's an example to show what I mean to clear things up:
    http://www.senocular.com/pub/flash/animUpdate.html

  9. #9
    Ө_ө sleepy mod
    Join Date
    Mar 2003
    Location
    Oregon, USA
    Posts
    2,441
    Hrmm...now I'm confused - are you using updateAfterEvent in there? I was under the impression that timers would run but wouldn't update until the next subsequent frame...

  10. #10
    Ө_ө sleepy mod
    Join Date
    Mar 2003
    Location
    Oregon, USA
    Posts
    2,441
    Alright - here's a demo showing (as I understood it...?) that timers will continue running between refreshes without updating the display...so now I'm curious why your timer is updating and mine isn't...here's my code:

    PHP Code:
    addEventListener(Event.ENTER_FRAME, function(e:Event):void{
        
    dot2.+= 9.5
        if(
    dot2.>= 606dot2.36;
    });

    var 
    t:Timer = new Timer(3360);

    t.addEventListener(TimerEvent.TIMER, function(e:TimerEvent):void{
        
    dot3.+= 9.5;
    });

    t.addEventListener(TimerEvent.TIMER_COMPLETE, function(e:TimerEvent):void{
        
    dot3.36;
        
    t.reset();
        
    t.start();
    });
                                                                
    t.start(); 

    EDIT: One more thing - if you ARE using updateAfterEvent, why wouldn't the entire stage update and re-interpolate the timeline tween for the inbetween frame? The more I think about this the more confused I'm getting.

  11. #11
    half as fun, double the price senocular's Avatar
    Join Date
    Feb 2002
    Location
    San Francisco, CA (USA)
    Posts
    4,361
    It's updateAfterEvent - it redraws the screen for events occuring outside the normal frame refresh.

    It doesn't move the playhead or make a new frame (which I think is what is confusing you), it simply tells the renderer to redraw the screen which, in my example, allows timer and mouseMove to be drawn at faster rates than that indicated by the movie's frame rate.

    Using e.updateAfterEvent() in your example should do the same (assuming you set a low frame rate too -where its most obvious)

  12. #12
    Ө_ө sleepy mod
    Join Date
    Mar 2003
    Location
    Oregon, USA
    Posts
    2,441
    Interesting...thanks for clarifying Senocular. At the risk of hijacking this thread a second time I'm going to throw out one more nagging question:

    I just dropped a millisecond counter into my timer's eventHandler and I'm getting strange results. My timer is set to update at 17ms, so I should get roughly 60 ticks per second. When the framerate is set to 1 (1000ms between frames), my timer is firing every 100ms. When the framerate is at .1, the timer fires once every 1024ms...I would think (especially on the idealogy of the elastic racetrack writeup) that the timer should go nuts when Flash isn't worrying about updating everything else...but it seems like there is still some limit hooked between the Timer and the framerate. Any ideas? I was thinking it could be cool to set the fps down to .01 and use a timer to make a truly fluid framerate but it seems like Adobe doesn't approve of that.

  13. #13
    Senior Member
    Join Date
    Jan 2007
    Location
    Nottingham, England
    Posts
    263
    Quote Originally Posted by neznein9
    Interesting...thanks for clarifying Senocular. At the risk of hijacking this thread a second time I'm going to throw out one more nagging question...
    go for it! far more interesting than my original question!


    although i still dont get why keeping my mouse moving above a certain speed stopped the image from updating...?


    ...carry on!

    P.s. going to mark the thread resolved as i've since sorted my problem.

  14. #14
    half as fun, double the price senocular's Avatar
    Join Date
    Feb 2002
    Location
    San Francisco, CA (USA)
    Posts
    4,361
    Timers are based on the frame rate, and they are an approximation.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  




Click Here to Expand Forum to Full Width

HTML5 Development Center