containerAnimation delay on horizontal scroll, why is it happening?

[artyor]

Hi all,

I created codepen where you can see a .h-scroll__inner section that pins and do horizontal scrolling. 
I also animate inner element (red boxes) with new containerAnimation. But as you can see, red boxes have this delay when I use scroll wheel. they are not instant. 

Why is this happening?

See the Pen jOLKKOR?editors=0010 by artyor (@artyor) on CodePen

[GreenSock]

If I understand your question correctly, it's because you're compounding your scrub values - you've got a delayed scrub on the main scrollTween animation, and then on TOP of that, you've got your containerAnimation with a delayed scrub. I'd strongly recommend NOT doing a delayed scrub on your containerAnimation - just set it to true: 

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

 

Is that what you want? 

[artyor]

@GreenSock
Yes, that's what I wanted.

I never thought of scrub as delay, but rather the "smoothness" of scurb animation

Thanks for clearing that up!

A quick follow up, these red boxes are actually images in my local project, but once the main parent pins, the images (and also text behind) have this werid kick? Like they go down  for brief moment, maybe like 1 frame per second, almost impossible to see it. I tried to solve it with "    anticipatePin: 1," but does not work. It's literally same code as in codepen

I can upload video if that could give you any better idea. 

[artyor]

Its very hard to see on video, but it happes first two times I scroll up and down:
https://vimeo.com/manage/videos/644140012

[GreenSock]

It sounds like what you're describing is the inescapable consequence of browsers handing scrolling on a separate (non-synchronized) thread. So imagine scrolling down very quickly and let's say the spot where pinning should happen is at exactly 500px (scroll position) and as you scroll quickly it goes from 490 to 520 on the next screen repaint. Well since the scrolling is handled on a separate thread, it'll show all the content as if it has been scrolled to 520 (20 pixels past where it was supposed to pin) and a few milliseconds later it executes the main (JavaScript) thread at which point ScrollTrigger says "HEY! Pin that element as if it were pinned at precisely 500", so you see it jump up 20px. 

 

anticipatePin is the only defense I know of, but it definitely isn't perfect. All that does is look at the velocity and try to predict ahead of time when pinning is supposed to happen so that it kinda jumps the gun a bit. Again, this isn't a bug in ScrollTrigger and as far as I know it's absolutely impossible to solve perfectly due to the way browsers handle scrolling and repaints. 

 

The only other thing I can think of is you could try applying smooth scrolling (NOT the CSS, I mean a JavaScript smooth scrolling effect - see .scrollerProxy() docs for some demos) because that essentially offloads the scrolling to the main thread. 

 

Does that clear things up? 

[artyor]

5 hours ago, GreenSock said:

It sounds like what you're describing is the inescapable consequence of browsers handing scrolling on a separate (non-synchronized) thread. So imagine scrolling down very quickly and let's say the spot where pinning should happen is at exactly 500px (scroll position) and as you scroll quickly it goes from 490 to 520 on the next screen repaint. Well since the scrolling is handled on a separate thread, it'll show all the content as if it has been scrolled to 520 (20 pixels past where it was supposed to pin) and a few milliseconds later it executes the main (JavaScript) thread at which point ScrollTrigger says "HEY! Pin that element as if it were pinned at precisely 500", so you see it jump up 20px. 

 

anticipatePin is the only defense I know of, but it definitely isn't perfect. All that does is look at the velocity and try to predict ahead of time when pinning is supposed to happen so that it kinda jumps the gun a bit. Again, this isn't a bug in ScrollTrigger and as far as I know it's absolutely impossible to solve perfectly due to the way browsers handle scrolling and repaints. 

 

The only other thing I can think of is you could try applying smooth scrolling (NOT the CSS, I mean a JavaScript smooth scrolling effect - see .scrollerProxy() docs for some demos) because that essentially offloads the scrolling to the main thread. 

 

Does that clear things up? 

Yes, thank you. I always learn something new here.

I will give a smooth scroll, I guess locomotive should work ok with it

[GreenSock]

10 hours ago, artyor said:

I will give a smooth scroll, I guess locomotive should work ok with it

Or just use the native ScrollTrigger-based helper function from the docs (first demo). No need to use a 3rd party library in most cases.