artyor Posted November 9, 2021 Share Posted November 9, 2021 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 Link to comment Share on other sites More sharing options...
Solution GreenSock Posted November 9, 2021 Solution Share Posted November 9, 2021 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? 1 Link to comment Share on other sites More sharing options...
artyor Posted November 9, 2021 Author Share Posted November 9, 2021 @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. Link to comment Share on other sites More sharing options...
artyor Posted November 9, 2021 Author Share Posted November 9, 2021 Its very hard to see on video, but it happes first two times I scroll up and down:https://vimeo.com/manage/videos/644140012 Link to comment Share on other sites More sharing options...
GreenSock Posted November 10, 2021 Share Posted November 10, 2021 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? 1 Link to comment Share on other sites More sharing options...
artyor Posted November 10, 2021 Author Share Posted November 10, 2021 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 Link to comment Share on other sites More sharing options...
GreenSock Posted November 10, 2021 Share Posted November 10, 2021 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. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now