Please explain the initial animation delay that exists with ScrollTrigger

[Oooh Boi]

Hi everyone! 

This shouldn't be a tough one but it's bugging me for some time now... so I have created a simple demo on Codepen.

It's quite obvious that there's a slight delay in animation start when the box hits the trigger point. However, there's no delay when animation is played in reverse. 

If you cancel out the first animation and uncomment the second one, there's no initial delay but the reverse animation is screwed up. 

I'm not new to GSAP and ScrollTrigger. Is there anyone willing to explain what's happening here and why? 

Thank you!

See the Pen KKEVpOM by oooh-boi (@oooh-boi) on CodePen

[Carl]

Thanks for posting the nice demo.

 

For case 1 the perceived delay is just because the first tween where you animate from x:0, y:0 does nothing for 0.5 seconds.

 

For case 2 you don't need that first tween at all. When I removed it looked like things were working fine.

Although I don't think it's 100% necessary here it is recommended that you don't animate the element that you use for the trigger.

I added a wrapper div to act as the trigger.

 

Please see if this gives the desired result

 

See the Pen bGZEVaw?editors=0110 by snorkltv (@snorkltv) on CodePen

[Oooh Boi]

Thank you Carl, appreciated!

 

Maybe I should have provided more info to make things as clear as possible... anyhow...

 

I wish the case #2 is that simple... remove the "from" and everything is OK. 
In reality, the "from" is being generated dynamically. Both "from" and "to" are, to be more precise. 

 

So I can't just remove it even if the element's starting position is zero. That's the reason I tried to figure how to get rid of 0.5s delay. 
It turned out that if zero is being used for the "position" parameter, the initial delay gets shaved off, but then there's a strange jump going on when the animation is played in reverse. 

 

Is there any explanation to what's causing that sudden jump? Any workaround?

 

Cheers!

[Carl]

thanks for the additional info.

I believe this has to do with overwriting.

You are creating conflicting tweens and my guess is that when played in reverse the animation that animates from x:0, y:0 to x:0, y:0 is winning the battle and thus you see the box jump back to the initial start state.

 

If you set overwrite:"auto" on tweens 2 and 3 then:

 

tween 2 will kill the y portion of tween 1

tween 3 will kill the x portion of tween 1

 

I think this works for this exact scenario you have

 

See the Pen PoLZZaE?editors=0010 by snorkltv (@snorkltv) on CodePen

 

If you set overwrite:true then tween 3 will kill BOTH tween 1 and tween 2.

You can give it a try to see how that looks (bad)

 

from the docs

Quote

overwrite:true all tweens of the same targets will be killed immediately regardless of what properties they affect

 

https://gsap.com/docs/v3/GSAP/Tween

 

I also think this video will help with overwrite modes

 

 

I know you are saying that the tweens are automatically generated, but my advice would be to add whatever logic necessary to avoid creating conflicting tweens in the first place.

 

Hopefully overwrite:auto solves the problem

 

Carl

 

 

 

 

 

 

 

[Oooh Boi]

Thanks a lot, it looks like I'll have to take completely different approach!