t.marty

Wrong reset on 2x autoAlpha with label timing

Recommended Posts

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!

Share this post


Link to post
Share on other sites

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.

  • Like 4

Share this post


Link to post
Share on other sites

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.

 

 

 

  • Like 3

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

Sure, you can set this:

 

GSDevTools.logOverwrites = true;

 

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

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.