Nested timelines and immediateRender of set()

Go to solution Solved by Carl,

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

Hey everyone ,

I post this not so much as a problem, since the solution is easy, but more as a curiosity and a bit of help to anyone else that may see this nested timeline behavior.

I’ve created a master timeline via four nested timelines in functions. The first timeline tween of each nested timeline is a set() call. On the first pass through the master timeline, each nested set() at time zero fires at time zero of the master timeline – not time zero of the local timeline. This is easily corrected by applying immediateRender:false to the set() calls.

My guess is that when the master timeline is created, all the set()s at position zero of the nested timelines are fired as they become relative to the master timeline of zero?

@ Jack – I won’t even pretend to understand many of the things under the hood, but I was reading this post in which you said:

'That's one of the reasons we have the "set()" convenience method in TimelineLite and TimelineMax - it creates a zero-duration tween but it automatically sets immediateRender:false unless you're inserting it at the current time.'

I totally understand that and the first set() of the first nested timeline is essentially at time zero of the master timeline so it should and does fire immediately, but I’m mostly curious about why the repeats of the master timeline all play as one might expect – each nested set() at local time zero wait their turn without having to apply an immediateRender of false.

At any rate, this is not too big of a deal and easily solved by explicitly setting the immediate render .  As I said, it’s more curiosity and for any future forum searchers with questions about it.

See the Pen xZxvgz?editors=001 by PointC (@PointC) on CodePen

Share on other sites

• Solution

Hi PointC.

What a great demo. Thanks so much for creating that.

It sounds like your understanding of why / what is happening is pretty solid. To offer just a touch of clarity, its important to note that when your child timelines are created inside those functions they have no idea that they are going to be placed inside a parent timeline and scheduled to run in the future.

When each timeline is created it says "ARGHHH! I have a set() at time 0! I better render that now!"

Another thing you could do in this case is pause the timelines on creation and add() them in an un-paused state like

```var masterTimeline = new TimelineMax( { repeat:-1, repeatDelay:1,  paused:true } );
masterTimeline

http://codepen.io/GreenSock/pen/MKYJqK?editors=001

Hopefully this helps. Thanks again for the wonderful demo.

• 5
Share on other sites

When i saw PointC's helpful demo, i was thinking about pausing but was stumped on when to add the play().

Thanks Carl, now i know i can use play() inside the add() method for the returned child timeline.

Great explanation and solution Carl

• 2
Share on other sites

Hey Carl ,

Thanks very much. Yes that makes sense - the timelines in the functions have no idea what they'll be used for so they have a mind of their own upon creation.

So... in my demo, the repeats work because the nested timelines now "know" they're part of a master timeline.

Would you say adding the nested timelines in an un-paused state would be a better solution than adding an explicit immediateRender:false to set()s at time zero?

• 2
Share on other sites

Would you say adding the nested timelines in an un-paused state would be a better solution than adding an explicit immediateRender:false to set()s at time zero?

The end result is the same, and I'm doubtful there would ever be a performance difference. I would probably go with the immediateRender:false as it seems more natural to me.

• 1
Share on other sites

Sounds good.

I'll stay with immediateRender:false, but it was nice to learn that I can add that play() inside the add() method. That could come in handy.