Wrong reset on 2x autoAlpha with label timing

[t.marty 2 Likes (Newbie)]

I have an element that is by default set to opacity:0 and then first set to 0.5 and then to 1 via GSAP.

When I use a label for the timing the element is not reset to 0 but to a random (?) number somewhere between 0.3 and 0.5.

 

Does restart() not reset all parameters?

 

Thanks!

See the Pen XOVORN by Dollique (@Dollique) on CodePen

[Dipscom 2,815 Likes (Superhero)]

At first I thought that was indeed a wonky bug but having spent some time looking at it, it kind of makes sense...

 

The catch here is the subtle detail that you setup a label and then immediately added two .to() calls to tween the autoAlpha of the same element overlapping each other. If we write out how long those tweens are and where they overlap, we can see that GSAP has to merge them together (as it's its default behaviour when overwriting competing tweens) KILLS ONE OF DEM DEADED. Done for. Snuffed. Gone to a better place. (see @Carl official state-sponsored GSAP behaviour report in the post bellow). I stand corrected.

Think of each dash 10 seconds.

[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ] Total time

[ - - - - - | - ] Label ('start', 1)

[ - - - - - - - - - - - - - - - > | | | | | | | | | | | < ] Tween ('start+=1.4')

[ - - - - - - - - - - - - - - - - - - - - - - > | | | | | | | | | | | < ] Tween ('start+=2.9')

 

If you stop the overlapping of the competing tweens, the issue goes away.

 

I am guessing here when I say, what could be causing this strange behaviour is how GSAP creates the easing curve of the merged competing tweens and because of the lenght of the whole timeline, it causes the very first frame to have an opacity of 0.375 as it would be the very first frame of the resulting merge.

 

Maybe @GreenSock himself will have a chance to look at it and explains what could be going on under the hood.

[Carl 9,066 Likes (Superhero)]

Dipscom is on the right path. The issue in fact is related to both tweens trying to change opacity at the same time. The second tween starts changing the alpha before the first tween ends.

 

GSAP does not yet merge competing tweens (referred to as additive animation), it kills one of them. If you think about it, it isn't very efficient for the engine to try to set 2 values on the same property at the same time, so the engine intelligently kills the pre-existing tween. In your case the first tween gets killed by the second tween which means it will not run or render when your timeline repeats. It's dead.

 

You can change this behavior by setting an overwrite mode.

In your case the easiest solution would be to set overwrite:"none" on your second tween (as shown below) or schedule it to run at a time that does not conflict with the first tween.

 

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

 

 

[t.marty 2 Likes (Newbie)]

Thank you both for the detailed explanation.

This makes indeed a lot of sense and I will change accordingly.

 

In my case this is indeed a mistake (and I really can't think of a scenario where this would be intended).

 

One question:

Would the gsdevtools give some sort of feedback on overlapping animations (I don't use the tool atm)?

 

Thanks!

[GreenSock 8,117 Likes (Superhero)]

Sure, you can set this:

 

GSDevTools.logOverwrites = true;

 

And it'll do a console.log() when overwrites are encountered.