Jumpy Text and ScrollTrigger Markers with Pin in Scroller

[rpsstudios]

Check out the CodePen example. I'm using ScrollTrigger with the scroller property set to a div. As you scroll down you'll notice that the text and scroll end/start makers are VERY jumpy. This only seems to be an issue when using the scroller property. If I remove that property so the scroller is tied to the window then everything works as expected. Has anyone else experienced this? This issue is much worse in Safari on a Mac, but it's still there on Chrome.

See the Pen gOdwVYY by rpsstudios (@rpsstudios) on CodePen

[GreenSock]

Hi @rpsstudios. Welcome to the forums!

 

I'm not seeing lots of jumpy behavior on my Mac in Safari, but iOS Safari was indeed jumpy. Let me explain some factors involved...

1. Almost all browsers now handle scrolling on a separate thread that is NOT synchronized with the main (JS) thread, so think of it as if the browser took a screen shot of your whole page as-is and then as soon as there's a scroll behavior (wheel, touch-scroll, etc.), it just moves that screenshot in the direction of scroll and repaints the screen...and then a few milliseconds later, it runs the main thread where JS executes, and that's where ScrollTrigger works its magic. So imagine you scroll and on the next refresh cycle, it sees that your finger/mouse moved the page 10 pixels. You'll briefly see that page repainted 10px lower/higher...and then when ScrollTrigger runs, it corrects the display of various things (like for pinning), so maybe the pinned element jumps back 10px (corrected). 
2. Pinning is complicated. Ideally, we use position: fixed to lock the element into position in the viewport and just leave it there until it needs to be unpinned. That's easier for the browser too because it knows that element is position: fixed and kinda unhooks it from that "screen shot" I talked about above. However, if your pinned element is INSIDE another scroller (not the root/body), that cannot be safely pinned using position: fixed because it's in an entirely different stacking context (it'd move with the scroller), so we must switch strategies to using transforms to MOVE the element in the opposite direction. For example, if you scroll that scroller 10px down, we must move that pinned element 10px up to make it appear pinned. Combine this info with what you learned in #1 above...can you now see why the jittering happens in this case whereas it doesn't if your pinned content is in the root/body? 

The lack of synchronization in the browser repaints is most noticeable on mobile devices. Different strategies are used by the browsers for repainting/timing, and obviously mobile devices are far less powerful. As far as I know, it's literally impossible to force the threads to be synchronized. The only way to correct this is to disable the normal scroll behavior and handle it with JavaScript. That's exactly what ScrollTrigger.normalizeScroll() is intended to do: 

 

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

 

It's not a silver bullet that solves everything, but it can make a big difference especially on mobile when you're doing pinning. 

 

Another strategy is to use something like ScrollSmoother because the entire point of that is to handle scrolling on the JS level and smooth it out. Since it's handled on the JS thread, it's automatically synchronized. ScrollSmoother is a membership benefit of Club GreenSock but if you don't want to join, you could try a different 3rd party smooth scrolling library, just make sure that you enable the smoothing on mobile because a lot of them disable it by default on mobile/touch devices. You could just use a much smaller smoothing amount on mobile because typically it feels odd when the scroll lags behind too much on touch devices. 

 

Does that clear things up at all? 

[rpsstudios]

Thank you so much for the detailed explanation! That all makes sense. Your Codepen is still showing the same jittery ghosting effect I was seeing previously. Here's a quick video to show what I am seeing. Can you confirm that ScrollSmoother will definitely help with this? This is the first time I had a need to use the scroller option for a ScrollTrigger. Maybe I just need to find a solution that sticks with the browser scrollbar.

[GreenSock]

No, my CodePen doesn't jitter like that at all. Not even on iOS. Are you sure you're looking at my fork and not your original? Maybe clear your cache? 

 

And yes, if there's a way you can re-engineer your markup/project so that you don't have to use a scroller, I would certainly recommend that. 

 

I do think ScrollSmoother would help, but it's probably not essential. You can try it out on CodePen as much as you want for free.

 

 

Enjoy!

[rpsstudios]

I was definitely using your Codepen. I'm on an M1 MacBook Pro with the latest version of MacOS and Safari at the time. In any case, I ended up finding a workaround so I don't need to use the scroller property. Thanks again for your input.

[GreenSock]

Hm, that's super weird - I'm on exactly the same Mac with exactly the same OS/Safari. Not even a tiny hint of jitter. Perfection. Did you clear your cache? I'm so confused right now. I'm glad you figured out a different workaround, but I'm concerned about what you were seeing and I want to make sure there's not some kind of bug we need to look at. The more info you can give me about reproducing the problem, the better. Do you have access to any other machines/devices? Can you replicate it anywhere else? 

[rpsstudios]

I can't replicate this on other devices, so it's just something with my browser.

[GreenSock]

Well I suppose that's good news overall, but it still leaves me a bit concerned. Did you clear your cache? And you're definitely looking at my CodePen, not an adjusted version of yours, right? 

[rpsstudios]

I was 100% looking at your Codepen. It's not adjusted in any way. I have clicked on "Develop > Clear Caches" a few times. One time while on the page. Another with no tabs open and then I visit the Codepen. Then I tried a private window. I disabled any extensions I had enabled and then cleared the cache one more time and tried it again. I did have a MacOS update, so I upgraded to Ventura 13.2.1 and Safari 16.3 and that didn't help. I would be happy to jump on a screen share to show you.