Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
dude

Readable timelines vs performance

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

Hi,

 

I'm curious about the performance penalties (if any) of how I'm abstracting out some of my animations into discreet timelines. Consider the following:

 

Fig 1

//timeline setup plus some animations before this part

tl.to(['.group1', '.group2', '.group3'], 1, {autoAlpha: 0})

// some animations after this part

The above would be a part of a larger timelined animation. I have many animations, triggered under different events, that operate on common constituent elements (ex: group1 elements, group2 elements, group3 elements). Across these animations, many of the things I need to do with these elements and/or groups of elements are repetitive, so I was thinking to abstract out an API of sorts (basically a bunch of organized discreet timeline functions). So for example, my code structure for a given element / group of elements that would need to commonly be operated on might look like this:

 

fig2

Example Folder Structure:

-animations

---parts

-----group1 //animations group1 has to do alot

-------enter //animations for bringing group1 in

---------fadeIn.tsx

---------fadeAndFlyInStaggered.tsx

---------aMoreComplexTimleinedAnimation.tsx

-------update

---------wiggle.tsx

---------jiggle.tsx

-------exit

---------fadeOut.tsx

-----group2

-----group3

 

 

The same pattern (enter/update/exit) would be there for each group, and each tsx file exports a function that returns a timeline. The benefit of this being that then I can have a higher level animation timeline that isn't so long, and easier to read. Perhaps something like:


fig3

tl.add(parts.group1.enter.fadeIn(...params));

tl.add(parts.group2.enter.fadeInStaggered(...params));

tl.add(parts.group1.update.reflectNewData(...params));

// maybe more stuff depending on complexity

 

This makes my life way easier, prevents repetitive code, makes code more maintainable / readable, and allows me to isolate implementation details from the larger high-level orchestration of the animation. If I was doing purely GSAP stuff it may not have been so bad, but often times I need to set classes, change classes, get positions of things, add remove elements, etc. All that takes up space and makes things harder to read / maintain. So I really like the idea of timeline abstraction. I am however new to it. As I go about working on the abstraction defined above, I started thinking there could be some trade-offs. Consider Fig4 below, against Fig1 above.

 

fig4

tl.add(parts.group1.exit.fadeOut(), 'timeToLeave') //fadeOut transitions to autoAlpha = 0 and removes the element(s) if a flag is set to true

tl.add(parts.group2.exit.fadeOut(), 'timeToLeave')

tl.add(parts.group3.exit.fadeOut(), 'timeToLeave') 

 

Where as before this was a single tl.to ..., now I have three seperate timeline.add(anotherTimeline) lines, that I have to coordinate start times with ('timeToLeave' marker in fig4). My question is:

 

Question: Is there a performance penalty for doing things the fig4 way vs fig1? Or is this something that GSAP optimizes for?

 

Link to comment
Share on other sites

You should read "Writing Smarter Animation Code" by our very own Carl if you haven't already. It shows how to modularize your timelines for easier manipulation. 

 

2 hours ago, dude said:

Question: Is there a performance penalty for doing things the fig4 way vs fig1? Or is this something that GSAP optimizes for?

There is always some penalty for abstraction (think of extra parsing/function calls, etc.). But I think it is so small that is can safely be ignored in this case. Especially in the modern day web where function calls are not very expensive (they used to be). This sort of abstraction shouldn't be noticed unless you're doing it thousands upon thousands of times in a small duration.

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

Yeah I saw that one, great article! I'm glad you pointed it out again, because I was looking for it actually. Definitely want to spend some more time analyzing it.

 

And thanks for the answer. More or less what I figured, but wanted to double check with the experts :)

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.
×