Jump to content
Search Community

Wrong reset on 2x autoAlpha with label timing

t.marty test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

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
Link to comment
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.

 

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

 

 

  • Like 3
Link to comment
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
Link to comment
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.
×
×
  • Create New...