Animation Breaks When GSDevTools is Removed

[David Hudson]

My animation project runs great, while an instance of GSDevTools is created. But it breaks once it's removed.

See the Pen XOYxdo by jooel (@jooel) on CodePen

[Carl]

Hi and welcome to the forums.

 

Thanks for the demo. Great animation! Really love the style. 

 

Very strange. First I'm hearing about something like this.

I verified that you are correct, I have a solution but not sure of the reason.

 

It seems if you instantly advance the playhead to the end before playing that it will work fine (using progress(1).progress(0)

 

var master = new TimelineMax();
master.add( thisIs() );
master.add( noData() );
master.add( noTaxes() );
master.add( noContract() );
master.add( noEquipment() );
master.add( uploadsAs() );
master.add( instantActivation() );
master.add( tvShows() );
master.add( videos() );
master.add( internetOn() ).progress(1).progress(0);

 

What this does is force every tween to record its start and end values. 

 

Please see the demo below.

 

See the Pen mvKaJv?editors=0010 by GreenSock (@GreenSock) on CodePen

 

I'm not sure why exactly this is necessary in this case, but I'm sure @GreenSock will be able to shed more light on it. Hopefully my solution works for you.

[David Hudson]

@Carl Awesome! That worked. Thank you.

 

It would be interesting to know if there is something else fundamental that I'm doing wrong.

[Carl]

Great!

 

On first glance your code looked great, very well-structured. However we are in the process of diving deeper (into the engine, and your code) to find out where the problem is. We will definitely report back here when there are some results.

[GreenSock]

Yeah, pretty much all of this has to do with immediateRender behavior. It can be a blessing or it can trip you up if you don't really understand it. 

 

Currently (and this is changing in 2.1), timeline.set() calls have immediateRender default to false UNLESS they're at the very beginning. There are reasons for this which I'll spare you in the interest of not making this overly complex   The new behavior in 2.1 will make immediateRender:false the default for all set() calls. 

 

Also keep in mind that from() and fromTo() calls always default to immediateRender:true. Again, that's by design because most people WANT that behavior but in your case you've got a bunch of things affecting the same elements, so the immediate renders are affecting other tweens. For example...

var tl = new TimelineLite(),
    obj = {x:0}; // <- obj.x starts at 0

tl.to(obj, 1, {x:100, lazy:false}) //you might expect obj.x to start at 0 and go to 100 but...
  .from(obj, 1, {x:200, lazy:false}); //this renders the starting values IMMEDIATELY (before the preceding line even renders on the next tick), thus the previous line will actually animate obj.x from 200 to 100! And then this line animates from 0 to 200 because when it rendered the first time (immediately), obj.x was indeed 0! To solve this, we can just set immediateRender:false on the from() tween. 

 

So in the demo above, obj.x animates from 200 to 100, then jumps to 0 and animates to 200. 

 

Setting immediateRender:false on the from() tween makes obj.x animate from 0 to 100, then it jumps to 200 and animates to 0, all because the immediateRender doesn't affect the starting values of the to() tween in this case. 

 

So I just always tell people to be very careful when using from(). If you need tight control over starting and ending values, just use fromTo(). 

 

Zero-duration tweens (which are what set() calls are anyway) are inherently tricky logic-wise too, so sometimes it's a good idea to just use very short durations like 0.0001 instead of 0. The problem with zero-duration stuff is discerning what values should be rendered in various scenarios like...if the playhead lands EXACTLY on top of the set(), you'd probably expect it to render its end values. But what if the playhead of the parent timeline was moving in reverse? What if it's at the very start of a timeline and the playhead runs into it backwards? You'd probably expect it to render its starting values in that case. 

 

So again, if you run into any issues, it might help to avoid zero-duration stuff and just go really small. And watch out for multiple from() calls on the same target. Once you really understand how immediateRender works and how/when values get recorded, it can all make sense, but sometimes it's a little tricky to understand.