gsap.defaults force3d conflicts with ScrollSmoother

evomedia.lt · November 26, 2023

In my previous thread Jack suggested using gsap.defaults instead of gsap.config to set force3d for all upcoming gsap animations on the fly...

The solution works but it all falls apart if I try setting

gsap.defaults({force3d:true})

before creating ScrollSmoother instance.

It throws console warning: Invalid property force3D set to true Missing plugin? gsap.registerPlugin()
And the scrollTriggers inside stop working as intended.

Is this a bug or intended behavior?

I was only able to track down the error connection to ScrollSmoother so far, however in my app I'm working in, I have to make the initial force3D defaults call on a 1 second timer because it still sometimes throws the error, and I can't properly debug it because stack trace always points to the

gsap.registerPlugin(ScrollToPlugin,ScrollTrigger,DrawSVGPlugin,ScrollSmoother);

image.png.eea437eabf11a78dc75bf8206b956582.png

line in my code.

In codepen example, you can see how the behavior differs when you set things up in different order.

If you toggle force3d first and then setup scrollSmoother it all falls apart, however it has no effect on ScrollTrigger...

(The random ball flying around is to check if switching of force3d has effect on created tweens since the ball generates new gsap animation for each move)

See the Pen oNmyKVX by driezis (@driezis) on CodePen

GreenSock · November 26, 2023

First, let me explain what's happening...

When you set gsap.defaults({...}), that's literally adding those values to EVERY SINGLE TWEEN thereafter. So be careful.
Since you're adding it to every single tween (and a gsap.set() is just a zero-duration tween), that's also affecting anything internally that runs a gsap.set() and in this case there's stuff in ScrollSmoother that sets some protective values on the <body>. So when you set force3D:true on the <body> that of course causes it to have a transform applied.
Whenever you put a position: fixed element inside an element with a transform, it creates a new stacking context and the position: fixed element is not positioned relative to that [parent] element rather than the viewport. This has nothing to do with GSAP - it's just a CSS spec thing (how browsers are supposed to work). So in this case, it's making your buttons at the bottom position themselves differently (relative to the parent instead of the viewport).

But let's take a step back here for a moment - do you mind me asking WHY you're using force3D at all? I think you might be over-engineering this and there might be a much simpler way to accomplish what you're trying to do.

Honestly, force3D is a bit of a relic from a long time ago when there was no will-change: transform (or support was very spotty) which largely accomplishes the same thing now.

evomedia.lt · November 26, 2023

I'm tasked to fix issues on a website that has a scrollSmoother and a bunch of scrollTrigger (parallax and text) animations. It works great everywhere except for iOS Safari, which only seems to become smooth once gsap is set to force3d on everything.

But you're right on the overengineering part. Now that I look at it, I'm looking at it from a dev environment where the screen/device can change on the fly - on a real device there's no need to do any switching so I suppose setting force3d once in gsap.config should suffice.

Notifications

Messages

gsap.defaults force3d conflicts with ScrollSmoother

Recommended Posts

evomedia.lt

Link to comment

Share on other sites

GreenSock

Link to comment

Share on other sites

evomedia.lt

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members