ScrollTrigger - Wobbly Pinning

[Slowchange]

Hi all. I've been using and loving GSAP/ScrollTrigger for a little while but am new to the forums (well, I've spent plenty of time reading but first time posting). So I'll echo many other first time posters by saying a big thanks to the GreenSock team for all the GSAP magic and support you guys provide to the community here. Much appreciated.

 

Anyway - my question is to do with pinning elements in ScrollTrigger. I've made a quick codepen recreating the issue I'm having, and really hoping someone can help me out. The site I'm working on is using Ajax for page/content transitions, and so my ScrollTrigger is set up where the inner container is the 'default' scroller, rather than the document body.

 

The problem I'm having now, which you should be able to see in my codepen, is the pinned section of the page jumping/wobbling rather than being tightly pinned as it hits the trigger's 'start' position. 

 

On this particular page where I'm having the issue, I've got a canvas element being created by PIXI.js as the page loads. I thought at first that maybe this was causing the problem, as I seem to remember reading in the docs somewhere that changes to the DOM after ScrollTriggers have been created can throw them off. (Although the canvas element being created shouldn't be changing the layout at all, as it's contained within its larger section?)

 

What I did realise, is that when I change the 'scroller' element back to the default, rather than my '.scroll-wrapper' - the problem is fixed, and the pinning works smoothly as expected. So I'm at a bit of a loss. Is this a problem with my '.scroll-wrapper'? I'm using that scroll-wrapper on other pages of the site and things are pinning smoothly.

 

Here's a fork of my codepen that's NOT using my custom scroller/scroll-wrapper, to save you having to mess around with it, and the pinning working perfectly. 

See the Pen yLXBLJb by stuartmack (@stuartmack) on CodePen

 

I've read that using 'anticipatePin' when pinning these large sections can help, but this doesn't seem to make any discernible difference for me here.

 

Would massively appreciate any help on this one! Thanks!

 

EDIT: If you're not seeing the wobbly behaviour on this bottom codepen, please try viewing it full-screen or refreshing it!

See the Pen jOmgZKW by stuartmack (@stuartmack) on CodePen

[OSUblake]

Welcome to forums @Slowchange

 

I'm not seeing any issues. Can anyone else reproduce this?

 

And what browser and OS are you seeing this on?

[Slowchange]

Thanks @OSUblake.

 

I'm using Chrome on macOs Catalina. The embedded demos work fine here for me, but the issue occurs on the full-screen version (of the second codepen in my post).

[Slowchange]

Here's a quick screen recording of the behaviour:

 

 

[GreenSock]

That looks to me like the effect you get when the browser does scrolling on a totally different thread (most do these days) and the pinning is done using transforms (which is the default when you're pinning inside a scroller that's not the root because often those have transforms applied which ruins position: fixed). The browser repaints from the other thread and then when it executes JavaScript on the main thread, you see it suddenly corrects things. Super annoying. As far as I know, it's completely impossible to force them to stay in sync. Thanks browsers!

 

I'm curious why you're using a wrapper element like that instead of just using the window. 

 

You can set pinType: "fixed" to force it to use fixed positioning which in your case will fix the jittering but you'll see a new problem - your fixed element will basically sit on top of everything and absorb mouse wheel and pointer events, thus it inhibits scrolling. 😐 To solve that, you can set pointer-events: none on your .content (pinned) element but sometimes you can't do that because you need things to be clickable. In that case, you'd need to do a more complex setup to listen for various events like "wheel" and then manually cause those to scroll the scroller that's sitting underneath your position: fixed (pinned) element. Here's a demo where I just slapped a wheel listener in there to show what I mean, but you'd probably need to add pointer and touch events and maybe tweak the delta handling for certain browsers that do non-standard things with the delta:

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

[Slowchange]

@GreenSock - amazing, thanks so much for the quick and well-explained answer!

 

I'll have to go and have a look over my project again to remind myself why I went with the scroll wrapper instead of the window - I do know that at some point in the project, I decided maybe I didn't need it, refactored, and had other troubles - sorry, pretty vague, I know. 

 

I'll check out the viability of losing the scroll wrapper, and if that's a no go, your answer around pinType: 'fixed' and the related considerations seems very promising. Will report back if I get it sorted, in case anyone else has this problem at some point.

 

Thanks again!

[GreenSock]

Actually, @Slowchange, I think I figured out a workaround that I've implemented in the next version of ScrollTrigger that significantly improves things - does this work better for you? 

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

 

Here's a preview link to the compressed version of the upcoming ScrollTrigger: https://assets.codepen.io/16327/ScrollTrigger.min.js (you may need to clear your cache). 

[Slowchange]

Thanks for the followup, @GreenSock - unfortunately still getting that dragging/wobbling behaviour on that last pen.

 

Had a busy day yesterday but I'll have a chance to try implementing the fix from your previous answer today. Let you know!

[GreenSock]

I see what you mean now - it's a different issue altogether, related to PIXI somehow. I poked around and discovered that if you .stop() the PIXI.Application immediately, the problem goes away. And then if you need to update the PIXI.Application's ticker, you could do: 

window.addEventListener("scroll", () => {
		pixiApp.ticker.update(performance.now());
		pixiApp.render();
});

I'm not a PIXI guy, so I'm sure what the ramifications are of that, but it was curious how it resolved things.

 

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

 

Better? 

[OSUblake]

On 8/22/2021 at 2:38 AM, GreenSock said:

Actually, @Slowchange, I think I figured out a workaround that I've implemented in the next version of ScrollTrigger that significantly improves things - does this work better for you? 

 

This doesn't seem to work for me. Before I couldn't see any problems. Now they are clear as day. Everything is jumping around, even without PIXI.

[GreenSock]

@OSUblake you cleared your cache, right? Just making sure you're using the latest version. What browser/OS? Can you record a video please? Does it behave the same in other browsers too? 

[OSUblake]

It's hard to record because it happens so quickly, but you can kind of see in the video. Happening in Edge and Chrome on Windows.

 

[GreenSock]

Yeah, I think once in a while the browser hiccups in terms of its repainting since it handles that on a different thread. I don't think there's anything we can do about that. But your recording looks WAY better than it was performing before the fix was applied. It was jumping all over like crazy when the PIXI stuff was there and activated. Very odd.

 

A few more questions:

1. Does the OLDER version (well, current right now, 3.7.1) behave any worse or better? 
2. You said that "Everything is jumping around, even without PIXI" which sound drastic but your video wasn't drastic at all. Did you have a different experience before you recorded that video or does it accurately reflect what you were referring to? 

[OSUblake]

1.) The older version looked better. The text had a little jitter to it, but nothing too noticeable.

 

2.) The video wasn't able to capture everything, so it's a lot worse. Glitching is the best way to describe to it, kind of like seeing a bunch of FOUC happen all at once.

[Slowchange]

@GreenSock For what it's worth, that latest fix with the PIXI adjustments appears to have completely solved the problem for me on Chrome/macOS Catalina! Thanks so much for that (especially given that it was sort of a PIXI issue, thanks for digging into that aspect - above and beyond as usual).

 

I guess I'll have to do some QA for other devices/OS to see if I can replicate (or avoid) the problem @OSUblake is seeing now. 

 

Thanks guys

[GreenSock]

1 hour ago, Slowchange said:

@GreenSock For what it's worth, that latest fix with the PIXI adjustments appears to have completely solved the problem for me on Chrome/macOS Catalina! Thanks so much for that (especially given that it was sort of a PIXI issue, thanks for digging into that aspect - above and beyond as usual).

Yay! Glad to hear that. 

 

1 hour ago, Slowchange said:

I guess I'll have to do some QA for other devices/OS to see if I can replicate (or avoid) the problem @OSUblake is seeing now. 

I applied an additional patch this afternoon that @OSUblake seemed to indicate fixes things on his end as well, so hopefully we're all set. He can confirm whether or not the last demo looks good on his system now. 

[OSUblake]

I also didn't see a need for those PIXI adjustments with the latest fix either.

 

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

 

[GreenSock]

28 minutes ago, OSUblake said:

I also didn't see a need for those PIXI adjustments with the latest fix either.

Your demo definitely looks terrible on my Mac in Chrome (without my PIXI fix), but looks great in Safari. Slightly jittery in Firefox. Chrome is acting super weird with PIXI in there. Maybe a WebGL painting thing, I dunno. 🤷‍♂️

[OSUblake]

Sounds like maybe the painting order might be different between mac and windows. I'm not sure how to test for that sort of thing 🤷‍♂️

[Slowchange]

Possibly a weird tangent, but from some more playing around with things, I've noticed that all my unstable pins/triggers correct to desired, clean pinning behaviour when I change browser tab (or window) and then come back to the project's tab/window. This is without doing any workarounds with PIXI, and also is on the latest ScrollTrigger version (3.7.1)

 

It might be ill-advised, but I was wondering if there's a way to fire this event on page load to simulate whatever this correction is coming from. Do you guys know what it is that ScrollTrigger might be doing here to 'refresh' things? I feel like whatever is happening that's fixing things is not the same as a regular ScrollTrigger.refresh(), as I've tried calling this (with and without 'true' argument) after the page loads and it doesn't seem to help in the way that leaving the tab/window does.

 

Sorry if this is getting in the weeds too much 😅

[GreenSock]

Ha, that's pretty weird. The only thing ScrollTrigger does when you un-hide a tab is call ScrollTrigger.refresh(). That's it. Nothing special. So whatever you're experiencing there sounds more like a browser thing, like it's synchronizing paints differently. I dunno. 🤷‍♂️