Different Animation Based on Scroll Direction

[Olly Grunt]

I'm a GSAP noob.  I was looking into how to create an animation that behaved slightly differently when you scroll back up rather than just reversing. I came across this forum post 

which has this example: 

See the Pen eYJjxVb by GreenSock (@GreenSock) on CodePen

 Although this showed me how to achieve what I was after, my version AND the example animation both exhibit the same unexpected behaviour as explained below . I've forked the example where I've simply increased the duration and the distance of movement, set all opacity occurrences to 1 and added markers. As expected, when you scroll down, the squares move up. When you scroll back up, the squares move back down. 

 

 

To see the problem, rerun the animation and scroll down until the start marker just passes scroller-start. As soon as the left square starts to move, scroll back up a little bit until the start marker is just below scroller-start. What you should see is the square on the right moving up while the other two squares move down. Any help explaining why this happens would be appreciated.  

 

See the Pen OJjEwZN by Gsapper (@Gsapper) on CodePen

[GreenSock]

Welcome to the forums, @Olly Grunt.

 

Yeah, that's not a bug - that's just a logic issue on your code. You've got overwrite set to "auto", so each tween will wait to execute any overwriting until the very first time it renders at which point it will look for any other CURRENTLY ACTIVE tweens of the same properties of the same targets and kill just those parts. But you've set up your staggers and delays in a way that makes it pretty easy to create a scenario where the old/stale tweens haven't even started yet when the new tweens render for the first time, so overwriting doesn't occur. 

 

Simple solution: set overwrite: true instead of overwrite: "auto". When you set overwrite to true, that IMMEDIATELY kills all animations of the same targets regardless of which properties are getting animated or if those other animations have started yet. 

 

There are other solutions too, like you could create a variable to store the current animation (onEnter or onLeave, whichever was last to fire) and simply .kill() that before you create your new tween. That's basically like a manual overwrite system

 

Good luck!

[Olly Grunt]

Thanks for the explanation. Setting overwrite: true I can still get the animation to go awry on very rare occasions. I've not been able to isolate the exact circumstances and will report back when I do. The manual overwrite approach works perfectly and I've settled on that.  Thanks again.