Timelines and nested Timelines ... how do they work?

[Dave Stewart]

I'm curious as to the mechanics of how timelines and also nested timelines work.

 

I suspect that the individual animated properties from each element end up with their own individual animation track, is that right?

 

I'm guessing that code used to create the key frames and values is first first set, then these tracks are controlled (or the values therin are retrieved on a global level) according to the global progress value?

 

Do these tracks remain nested, or are they all passed up to some kind of top-level array?

 

Also, when scrubbing some of my animations quickly, you can see that the results seem to get more accurate the more of the timeline that has been scrubbed. In the example of a simple box animating left to right on the stage, the integrity of such properties as width and height appear compromised, until those frames have been fully gone-over:

 

See the Pen ACHmx by davestewart (@davestewart) on CodePen

 

Is there some kind of rendering / caching going on here, so that the original code which creates the movement eventually becomes redundant?

 

Anyway, just very interested / curious. I think it would be really useful to know a bit about, and have an appreciation of, what is going on under the hood in order to get the most out of the library.

Am really getting into Timelines now. They're pretty amazing.

Cheers,

Dave

[Carl]

Hi Dave,

 

Its great to have you so interested in GSAP.

 

As for the mechanics of nested timelines did you catch this section of the TimelineLite docs?

 

How do timelines work? What are the mechanics like?

 

Every animation (tween and timeline) is placed on a parent timeline (except the 2 root timelines - there's one for normal tweens and another for "useFrames" ones). In a sense, they all have their own playheads (that's what its "time" refers to, or "totalTime" which is identical except that it includes repeats and repeatDelays) but generally they're not independent because they're sitting on a timeline whose playhead moves. When the parent's playhead moves to a new position, it updates the childrens' too.

 

When a timeline renders at a particular time, it loops through its children and says "okay, you should render as if your playhead is at ____" and if that child is a timeline with children, it does the same to its children, right on down the line.

 

The only exception is when the tween/timeline is paused in which case its internal playhead acts like it's "locked". So in that case, it's possible (likely in fact) that the child's playhead would not be synced with the parent's. When you unpause it (resume()), it essentially picks it up and moves it so that its internal playhead is synchronized with wherever the parent's playhead is at that moment, thus things play perfectly smoothly. That is, unless the timeline's smoothChildTiming is to false in which case it won't move - its startTime will remain locked to where it was.

 

So basically, when smoothChildTiming is true, the engine will rearrange things on the fly to ensure the playheads line up so that playback is seamless and smooth. The same thing happens when you reverse() or alter the timeScale, etc. But sometimes you might not want that behavior - you prefer to have tight control over exactly where your tweens line up in the timeline - that's when smoothChildTiming:false is handy.

 

One more example: let's say you've got a 10-second tween that's just sitting on the root timeline and you're 2-seconds into the tween. Let's assume it started at exactly 0 on the root to make this easy, and then when it's at 2-seconds, you do tween.seek(5). The playhead of the root isn't affected - it keeps going exactly as it always did, but in order to make that tween jump to 5 seconds and play appropriately, the tween's startTime gets changed to -3. That way, the tween's playhead and the root playhead are perfectly aligned.

 

---

 

Thanks for providing the CodePen demo. I think I got a little lost though trying to understand what you meant by "the integrity of such properties as width and height appear compromised, until those frames have been fully gone-over"

 

---

 

Is there some kind of rendering / caching going on here, so that the original code which creates the movement eventually becomes redundant?

 

 

I can tell you that once a tween renders for the first time its start and end values get recorded internally. So if a tween is restarted or reversed it saves the overhead of doing that each time. 

[Dave Stewart]

Hi Carl,

 

Regarding the integrity issue - I think upon further examination that this is Chrome-specific, something to do with rendering, and perhaps some kind of visual caching.

 

Take this animation:

 

See the Pen wlFDf by davestewart (@davestewart) on CodePen

 

On Chrome, if you scrub the timeline by moving your mouse over the bottom grey bar, you see the red box travel across the screen. If you get the velocity just right, the red box appears to get significantly narrower (even down to about 20px) until after 4 or 5 scrubs it begins to start maintaining its shape again.

 

However, I've just tested in the other browsers and I can't get it to happen. And in some animations in Chrome it doesn't happen either. It seems to be a intermittent.

 

And when I take a screenshot, the box is rendered at the correct size (I guess there's some internal routine that must finish on that cycle).

 

It's certainly not my eyes, there's something going on which Chrome - though not GSAP, as I can tell now!

Do you not get the same results?

 

Cheers for the explanation too. Very interesting.

[GreenSock]

I wasn't able to see anything odd in Chrome, but I'm on a Mac which may be different. It almost sounds like a video card issue (well, the way Chrome interacts with your video card somehow), but that's just a guess. I think you're right when you say it doesn't appear to have anything to do with GSAP specifically. 

[Jonathan]

Hello..

 

I just tested your link Dave Stewart .. but was unable to replicate what you were seeing in regards to the box losing its shape. I did not see anything odd in Chrome either like Jack.

 

I tested on PC Windows 7 (64-bit) -  Chrome 35.0.1916.153 m