Best Practices: Is it better to have one timer to handle all animations on a sprite?

arjunr24724 · January 2013

Hi

Is there any performance issue if I use 4-5 timers on a sprite to handle different kinds of animation (like fade, move, shake) or is it better to use one timer and run the animation code conditionally?

ar2rsawseen · January 2013

@arjunr24724 actually I'm trying to handle all animations inside onEnterFrame event instead of timers, I find the enter frames be more efficient than timers.

Thus I'd say the least timers you have the better

But that's just something I do, want to hear other experiences

thanhquan1512 · January 2013

I use onEnterFrame event to handle all my animation too and I think this is a lot better and easier to work since you do not rely on system time.

Just convert your frame per second in case you need to calculate time (for examples 60fps mean 60 frames = 1 seconds)

hgvyas123 · January 2013

also i think so Timer is also doing the same thing internally

OZApps · January 2013

I would use a enterFrame event rather than a timer for animation, etc. The only thing that you might need to manage is the speed / FPS.

Rickyngk · January 2013

I use only one enterFrame for everything, better fps, not sure why, but it seem to be

MauMau · September 2013

Wouldn't it be more efficient to use a timer instead of enterFrame? Since a timer can be set to any update interval it's frame rate independent. So you are free to choose an appropriate update interval (using delta time), no matter what frame rate your app is actually running. If you want smooth animations, you can set it to a higher update rate -or set it to a lower update interval to save valuable CPU performance, for example.

Delta time should be used anyway, even with enterFrame, because the frame rate can drop easily on a slow device and therefore all your enterFrame animations would slow down. So shouldn't we prefer timers instead?

ar2rsawseen · September 2013

@MauMau that is not always true that animations will remain smooth with constant update time, because if FPS drops and you would tween the element, then it won't be a smooth tweening, but rather jumping from one position to another. But that would be in sync with expected time. So yes it depends on what you need and each approach has its advantages.

MauMau · September 2013

Sorry for being unclear -of course an animation may get choppy with timers, too if the app's frame rate drops too low. What I was trying to say is: by using timers you can choose ANY update rate, so you are not bound to the app's FPS. This means that you can also choose a slower update rate for stuff that does not need to be updated with every single frame (some calculations, slow animations etc.) and therefore save CPU performance -or not?

Just as an example: if your app is running at 60 FPS but you want to save some performance and therefore want to update some objects not 60 times per seconds but, let's say, 25 times per second only, you could use a timer to update them -independently from the actual FPS. This is quite handy in my opinion.

ar2rsawseen · September 2013

Yes, I completely understand that and we also discussed internally of providing an option for enter frame like event with fixed and updatable time interval.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Best Practices: Is it better to have one timer to handle all animations on a sprite?

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Best Practices: Is it better to have one timer to handle all animations on a sprite?

Comments