Jump to content
Search Community

Perfomance difference between timeline and direct gsap methods?

wpsoul test
Moderator Tag

Recommended Posts

As far as actual performance of the library? No there shouldn’t be why are you experiencing something?

 

But in many cases you may experience performance differences from a code writing & maintenance standpoint. It can be much more efficient and effective to use timelines than a million different tween calls and corresponding logic. From that aspect its discussed in this older article which still applies to GSAP 3.

 

https://css-tricks.com/writing-smarter-animation-code/

Link to comment
Share on other sites

Practically-speaking, you'd probably never notice any difference. Technically a Tween instance is the basic building block of GSAP, and Timelines are containers for Tweens, so if you use raw Tweens and skip the containers it's fewer calculations. So 1000 tweens (with no containers) would be faster than 1000 tweens inside 1000 containers. :)

 

However, Timelines can make things more efficient in some cases. If you put 1000 tweens inside a single timeline and pause the timeline (or it's delayed until later...the point is that it's not active on the current tick), then the engine only has to check that one instance to see if it's supposed to render and if not, it moves on to the next one (thus skipping 1000 checks, 1 for each individual tween instance). The nesting architecture of GSAP has a lot of benefits like this. 

 

Also, I noticed that you're pausing your timeline initially, and then calling play() after you add all your tweens. I see that a fair amount and it's completely unnecessary. In fact, if you're looking to optimize things, you're wasting function calls like that. GSAP is built in a way that keeps everything perfectly synchronized and it only updates its timing once per requestAnimationFrame. So ALL of the code that runs during a particular requestAnimationFrame cycle will have EXACTLY the same start time. It doesn't matter if you've got a TON of code that bogs down the CPU for 5 full seconds. 

 

It looks like some people worry that maybe the time it takes to instantiate tweens in one section of code is gonna take a few ms and then when the next chunk of code (right below it, on the same requestAnimationFrame tick) runs, it'll be delayed a little bit, throwing things out of sync. But again, that is NOT true with GSAP. Some other engines may suffer from that time creep, but not GSAP. 

 

So unless you plan to keep the timeline paused until at least the next full tick, there's absolutely no reason to have it start out as paused and then call play() a few lines down (on the same tick). Utterly wasteful (not noticeable...I'm just a performance nut so the little things matter to me). :)

 

Does that make sense? 

  • Like 4
Link to comment
Share on other sites

6 minutes ago, GreenSock said:

So unless you plan to keep the timeline paused until at least the next full tick, there's absolutely no reason to have it start out as paused and then call play() a few lines down (on the same tick). Utterly wasteful (not noticeable...I'm just a performance nut so the little things matter to me). :)

 

Does that make sense? 

 

Ok, i's clear now. 

Reason why I use pause is because I use animations in waypoints. So, it must be triggered once object will be visible in window. Is there any better way than pausing timeline?

 

I have next now

 

  revealwrap.Waypoint(function(direction) {
      tl.play();
  }, { offset: 'bottom-in-view' }); 

 

 

 

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.
×
×
  • Create New...