Jump to content
GreenSock

Battlecruiser

Is duration guaranteed?

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hello everyone. I'm working on some animation that very much depends on the accuracy of delay and duration. And I really would like to know if GSAP guarantees accurate delay and duration time for animation? Is it possible that animation duration can have delays itself, meaning that it will take, for instance, 1.01 seconds to complete instead of 1s:

var _duration = 1, _delay = 3;
TweenMax.to(item, _duration, {css: { opacity: 1}, delay: _delay});

Thank you so much!

Link to comment
Share on other sites

Hi;

 

I've done some very accurate animations ( 60 fps, 1/100th of second chaining ) with delay and duration and gave perfect timing on all the machines I've tested. My advice is don't worry about that. 

  • Like 2
Link to comment
Share on other sites

It's actually impossible to guarantee perfect durations/delays, but that has nothing to do with GSAP - it's how the browser works too (and virtually any software). In normal situations, it should be almost perfect, but if the CPU gets loaded down (like with graphics rendering or a gc cycle or the person is encoding video in the background or whatever), the browser may not trigger the requestAnimationFrame or setTimout() call exactly on time. 

 

Let's just say that in a perfect world, updates would pulse through the system 60 times per second which is roughly every 16.7 milliseconds. Maybe on one of those updates, you set up a tween to run with a delay of 18 milliseconds. The next update happens at 16.7 milliseconds and it will see that the delay (18ms) hasn't elapsed yet. Then, the next update happens at 16.7 milliseconds later at which time we're technically 15.4 milliseconds tardy. That'll of course trigger it to begin, but again, it's slightly late. However, we've built GSAP so that it doesn't "slide" like many other systems. It factors in that 15.4 millisecond tardiness so that it still ends when it originally should have rather than sliding everything back 15.4 milliseconds. But again, that last update when the tween ends might run very slightly late depending on system load. This is absolutely impossible to mitigate, but GSAP handles timing as good or better than any other animation system I've seen out there. This is especially true with repeats (most other systems "slide", so after several repeats the gap gets wider and wider, but GSAP keeps things super tight). 

 

I would strongly recommend against writing your code so that it breaks when things are even a few milliseconds tardy because you're sure to run into trouble that way. 

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Thank you for your replies! Does it make any difference whether the animation is run in IFrame or not? Seems like my animation starts acting weird only if I run it from IFrame.

Link to comment
Share on other sites

Nope, it shouldn't make any difference. If you need more help, please create a simple example in codepen or jsfiddle so we can see what's happening. 

 

Also, please make sure you're not double-loading the JS files. I wonder if maybe you're loading TweenMax AND TimelineLite or TimelineMax - remember, TweenMax has TimelineLite and TimelineMax inside of it, as well as CSSPlugin, TweenLite, and several plugins (to make things easier for folks to get robust functionality with a single load). 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×