Possible intermittent bug in Timeline updating

[Dave Stewart]

With regards to the multiple-child timeline / pause test I posted, I may have uncovered a minor bug.

 

I updated the amount of children added to 500 timelines, and it's almost perfect!

 

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

 

Really, really impressive.

 

However, sometimes if you scrub the controller very quickly from, let's say 400 to 100, box 250 (always 250!) doesn't get reset:

 

 

I wondered if there was something significant about the number 250?

 

I changed the total to 400, and then box 200 would sometimes get left behind. So obviously, this is mid-way through the timeline.

 

It's certainly not something major, but thought it would be worth bringing it to your attention.

 

Cheers,

Dave

[GreenSock]

Very interesting. Your test exposed an EXTREMELY uncommon condition that would cause this problem, so that's actually very good news. It helped me identify it and fix it. I'll be pushing an update within the next few days that has the fix. I have attached a preview in case you want to test.

 

The explanation:

Zero-duration tweens strike again In your case, you put a zero-duration tween (which is what a set() is) at the very beginning of a nested timeline. When the parent's playhead goes PAST the child's startTime and then you go backwards and the playhead lands EXACTLY on top of that child's startTime, it must decide - is it supposed to render the set() tweens starting values or ending values? See the conundrum? Since those should be set() at the very beginning of the timeline, then rendering that timeline at a time of 0 should put those at their end values. So that's precisely what happens.

 

However, when the parent's playhead now goes backwards, thus it's before the start time, technically it's not changing the local time of that nested timeline (a time can never be negative or greater than the total duration). I know, this is a little mind-bending.

 

Anyway, the glitches you saw in your demo would only happen when the playhead happened to land EXACTLY on top of the startTime of one of those nested timelines that had a set() at its very beginning, and then you had to go backwards past it to get the odd effect. So again, this is exceedingly rare but it happens on occasion. 

 

I edited the code so that it'll sense that condition and adjust accordingly. After I applied the update, I could never get your demo to glitch. Let me know if it resolves things for you too. 

 

Sorry about the hassle, but I'm really glad you stumbled across this and that it's fixed now. It's almost impossible to anticipate every scenario and test case in a complex animation platform like this which is why it's great to have a larger community that's aggressively pressing it into action in all sorts of ways. I did write a test now that'll sense this condition in future revisions to make sure there isn't a regression. 

GSAP_1.13.0_preview.zip

[Dave Stewart]

Hey Jack,

 

You know I set my alarm for 6am each morning, go for a 5 mile run, 50 press-ups, a few squat-thrusts, then settle down in front of the computer to find GreenSock bugs don't you?

 

This comes back to our reset() / preset() / setup() conversation, right?

 

I was thinking about that, and after looking through the API understood your reluctance to change things. My only other thought was to add an extra explicit parameter to set:

public function set(target:Object, vars:Object, position:* = +=0, immediateRender:false):*

But again, it felt like sticky-tape. And who knows when someone would want to add more sticky tape. Gah.

 

In the end, I added tiny waits to the start of each of my timelines, as you suggested, within my own framework code. The only downside to that being that all subsequent keyframes are off slightly from integers, if set there, which can make adding-up a bit tricky.

 

Glad it helped you make the lib even more robust, though.

 

And don't worry, it didn't affect me in the slightest. It just came up when testing a wrapped addPause()

 

Cheers,

Dave