GreenSock

A few things: Why are you calculating the offsets on every single update of the ScrollTrigger? That seems very wasteful. onUpdate: calculateOffsets, // <-- remove this? Maybe you intended that to run onRefreshInit or onRefresh? You can't have scrub and toggleActions - those are mutually exclusive. You can remove the toggleActions if you have a scrub. There's no point in having rotation, perspective, or skewX in your tween because you're not animating those at all. Filters are TERRIBLE for performance, just so you know. It's totally unrelated to GSAP. It's just that browsers have a tough time rendering them. You might want to try adding will-change: transform on anything you're animating (I saw you only had it set to filter on that image). One trick is to create a blurred version of the image (like in Photoshop), and then just crossfade that blurred version with the non-blurred version. That'll be WAY cheaper for the browser to render.

I'm not sure if I understand you correctly, but maybe you wanted this?: https://codepen.io/GreenSock/pen/qBwRgXZ (just add some conditional logic to make the first one active initially)

Yep, because if we combine them all into a single tween, there's only one transform render that must occur on each tick (that's the part where the transforms get combined into a string and applied to the style). Just a small performance optimization that you'd likely never even notice in real-world scenarios but I obsess about performance. You had to create a new tween anyway on each update, so might as well just combine the x/y into that rotation one.

Yeah, it's super hard to troubleshoot a live site - a minimal demo like in CodePen or Stackblitz is best. My guess is that even if you completely remove ScrollTrigger from the equation, crack open Dev Tools and you'll see that the computed height of that <main> element is indeed 0. The visible content may just be due to the fact that overflow is visible on that element. In short, I bet the issue has nothing to do with ScrollTrigger, but it's in your CSS/layout. Once you post a minimal demo for us to investigate, we'll be able to advise further.

@bellaz do you have a minimal demo that illustrates the issue? That'd go a long way toward getting you a good answer. My guess is that maybe you want something like this?: https://codepen.io/GreenSock/pen/VwNPqjO?editors=1010 Notice I'm just checking to see if the pointer moved more than 3 pixels in either direction, in which case I call preventDefault() on the event to make sure the click doesn't happen.

I read that a few times but I still don't understand what you mean. Can you provide a minimal demo that illustrates the problem? Hm, that also sounds odd to me. Why would appendChild() fail? Again, a demo that illustrates the problem would be super duper amazingly helpful. 🙂

And here's another way to do it - a custom plugin: gsap.registerPlugin({ name: "autoWillChange", init(target, vars, tween) { this.target = target; this.active = false; this.tween = tween; return !!vars; }, render(ratio, data) { let progress = data.tween.progress(), active = (progress > 0 && progress < 1); if (active !== data.active) { data.active = active; data.target.style.willChange = active ? "transform" : "auto"; } } }); Usage: gsap.to(".container", { x: 100, duration: 2, autoWillChange: true, // <-- magic! onComplete() { console.log("complete"); } }); 🥳

Yeah, it's a little frustrating that the browsers moved the goal post and switched up how things work (they've gone back and forth actually). will-changed is really a mixed bag. Sometimes it helps, sometimes it hurts. And sometimes it depends on which browser. Here's the real question: have you ever seen any real-world benefit to switching back and forth between will-change values? Why not just set will-change: transform in the CSS and leave it alone? I know you mentioned memory savings and in theory that's true, but you also need to factor in the cost of switching that value back and forth because that takes CPU cycles and involves funneling data to the GPU. In other words, you actually may see a DECREASE in overall performance by toggling like that. So if I were you, I'd do some tests in your particular scenario to see if there's really any benefit one way or the other. I'll keep this in mind as a possible enhancement for a future release (autoWillChange), but it'd also be pretty easy to write a helper function that does it for you: function autoWillChange(vars) { let setTo = (callback, value) => { let orig = vars[callback]; vars[callback] = function() {gsap.set(this.targets(), {willChange: value}) && orig && orig.call(this); } }; setTo("onStart", "transform"); setTo("onComplete", "auto"); return vars; } Usage: gsap.to(".container", autoWillChange({ x: 100, duration: 2, onComplete() { console.log("complete"); } })); Just wrap it around your vars object and you're good-to-go. You don't need to use those extra .set() calls at the beginning and ending of those timelines. But again, I personally would probably just set will-change: transform in the CSS and leave it alone because in most cases the memory won't be an issue and it'll deliver better performance not to shift the value around. I hope that helps!

By the way, there's a very easy workaround if you don't want to wait for the patch to be released - just create a simple ScrollTrigger that doesn't do anything first: https://codepen.io/GreenSock/pen/eYogRgB?editors=0010 (uncomment line 4 to see it work) Thanks for putting together such a great minimal demo. That makes troubleshooting much easier. 🙌

I'm curious if you tried putting your code into a DOMContentLoaded event handler. In other words, wait for the DOMContentLoaded event to fire before you execute the SplitText/GSAP code. document.addEventListener("DOMContentLoaded", () => { // your code here... }); Worst case is maybe listen for the "load" event (which waits for images/assets to finish too).

Great catch, @Cuberto! Sorry about any confusion there. This would only happen if the very first ScrollTrigger (in terms of refreshPriority/order) has once: true. It should be resolved in the next release which you can preview at: https://assets.codepen.io/16327/ScrollTrigger.min.js (you may need to clear your cache) Better?

No problem! Happy to help. By the way, another option is to just create CSS variables for your various colors that you plug into your radial gradients, and then just animate those individual CSS variables in the tween(s). Have fun!

One of the reasons gsap.quickTo() is so fast is because it skips a bunch of conveniences like unit conversions, special features like "_short", relative values, etc. - it's purely for funneling a raw number directly into an existing tween. So I would probably do it like this: https://codepen.io/GreenSock/pen/MWRJJay?editors=0010 One simple tween that gets killed/replaced on each move.

Because "background" is a combination of a bunch of different sub-properties. It's much cleaner to focus on exactly the one you need which is backgroundImage. I have no idea - I didn't create that. Looks to me like it's useless.

I just meant that if you create a ScrollTrigger...and then re-create that same one again without reverting/killing the old one, that could cause an issue. Or if you did multiple .from() calls, like: gsap.from(".target", {x: 100}); gsap.from(".target", {x: 100}); // ran again without reverting the previous one, thus the end value will be incorrect. When you can't seem to reproduce the issue in a minimal demo, it becomes a game of "spot the difference" - try making it more and more like your "real" project until it breaks. 🤷‍♂️

LocomotiveScroll is not a GreenSock product, so we can't really support that. Sorry. But you'll significantly increase your chances of someone being willing to help if you provide a minimal demo that clearly illustrates the issue.

Yeah, unfortunately we really can't help without a minimal demo to look at. Obviously something else is interfering in your project. Are you using React or something? Are you absolutely positive that your setup code only executes ONCE? Are you maybe not doing proper cleanup or something? Are you using the latest version of the tools?

If that gives you the result you want, that's totally fine. I don't think it'd be good to make that the default behavior in Draggable because of the other potential side effects, but if your solution works for your project, fantastic, do that. 👍

Welcome to GSAP, @BattN There are many ways you could do that. Here's just one: https://codepen.io/GreenSock/pen/KKYNYgy?editors=0010

@Reela we don't have templates for whole sites like that, no, but there are a ton of CodePen and Stackblitz demos that are linked to in the docs and resources section of the site. https://codepen.io/GreenSock/collections/ Have fun!

Sounds good. And you don't have to use the beta if you don't want to - you could just apply that workaround from my CodePen (save/restore the _scrollTop function on the scroller element). Let us know how it goes. And thanks for being a Club GSAP member! 💚

This sounds like the issue discussed here: https://github.com/darkroomengineering/lenis/issues/311#issuecomment-1986531084 It's not a GSAP/Observer problem - it's a very weird Firefox behavior that Lenis doesn't handle properly but I think they're working on a fix.

I would also recommend making sure you're using the latest version of GSAP/ScrollTrigger. Your demo uses a VERY old version.

That's a very inefficient way of running that logic. Are you trying to do this?: https://codepen.io/GreenSock/pen/yLraRBd?editors=0010 That'll play/reverse the animations when that particular spot on the scroll is hit. But if you want it to be scrubbed instead, you could do that too very easily: https://codepen.io/GreenSock/pen/YzMGJzx?editors=0010 Lots of options!

Yeah, you totally don't need to use React. Quite the contrary. The "solution" they offered there has absolutely nothing to do with useLayoutEffect() - it's the sentence after that in the article: So it's the data-speed attribute that was doing it.