Leaderboard

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"); } }); 🥳

No worries. I would keep the question to the same topic, no need to create a new one. Even if the pen stays the same just post the link again in the most up to date reply that way we know what the most up to date version is. What I would do is update the timeScale() of the current timeline and then after some time set it back to the normal speed. https://gsap.com/docs/v3/GSAP/Timeline/timeScale()/ If it was an element that was not in a background-image and just a normal dom element you could have two tweens on the same element one that moves the xPercent and the other the x doing this would allow the main timeline to never stop playing and the other to just move is some amount, but that will require a rewrite of your current setup. Hope it helps and happy tweening! https://codepen.io/mvaneijgen/pen/gOygjzJ?editors=0011

Hi @Atap Tailor welcome to the forum! GSAP records its starting values and when you set repeat: -1, it will repeat to its original position, so you have to call repeatRefresh: true, to have it recalculate new values on each repeat. When working with timelines I would put all the logic on the timeline and keep the tweens just for animations. Also check out our Seamlessly loop elements along the x-axis might be helpful https://gsap.com/docs/v3/HelperFunctions/helpers/seamlessLoop/ Hope it helps and happy tweening! https://codepen.io/mvaneijgen/pen/oNOByvj?editors=0110

Hey there! So GSAP can animate pretty much anything *animatable* - by that I mean properties of JavaScript objects that are able to change gradually from one value to another, like numbers or percentages. Boolean values true/false or strings aren't animatable (unless GSAP's done some magic internally, which it has for a lot of CSS properties) So in terms of whether you can animate mapbox stuff with GSAP, the question becomes more "Can I draw a line with mapbox" "Can I access the properties of that line" "Does that line have a width/length/or similar property that would allow me to expand the length of it like it's drawing" I took a look in their docs and it seems like you can use a custom animated canvas, so this looks likely https://docs.mapbox.com/mapbox-gl-js/example/animate-point-along-route/ In order to animate canvas with GSAP you'd just need to find the name of the property you want to animate, work our the values and then update the draw function of the canvas on each tick of the animation. Like so https://codepen.io/GreenSock/pen/XWENapb or in your case... (minus the canvas draw as I'm just animating a proxy object) https://codepen.io/GreenSock/pen/ExJZEpo?editors=0011 Hope this helps!

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!

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?

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.

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.

Thank you for your quick response. It was the filter drop shadow, I didn't know it could impact so much on the performances. I'd like to ask you for another suggestion, if you don't mind. In the circular slider of the example above, I have <a> elements instead of the simple <div> cards. The problem is that the click on the element is triggered also when i swipe vertically across the slider. This also happens if I remove the href and try to go to the linked page manually on the onClick callback. That is very frustrating especially on mobile devices: is there a way to disable the vertical drag on a type: "rotation" Draggable? My expected behaviour is this: Swipe horizontalli -> The slider rotates Swipe vertically -> the page scrolls (which now doesn't) Click -> Open the link Thank you very much!

Thanks @GreenSock for the quick response and fix!👍 It works! Fixed demо: https://j4detdwi8u.demo.cubdev.com/fixed.html

Hi, Is just a matter of making the correct calculations. For that is better to use a to() instance and yPercent instead of y: // Animte cards up from off screen one by one. tl.to(".card-wrapper:not(:first-child)", { yPercent: (i) => -100 * (i + 1), duration: time/2, stagger: time }); Here is a fork of your demo: https://codepen.io/GreenSock/pen/wvZgJeg Hopefully this helps. Happy Tweening!

The slice seems to do what's supposed to, so no suggestions really. Happy Tweening!

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.

Check out this tutorial by our on @Carl, I use Affinity Designer and with it I can to to File > Export and select SVG. With Boxy you can just copy the SVG code which is much easier when developing animation. Hope it helps and happy tweening!

Yeah, that was an issue specific to rem units and it should be resolved in the next release which you can preview at: https://assets.codepen.io/16327/gsap-latest-beta.min.js (you may need to clear your cache). Sorry about any confusion there.

Hi, One option is to create a single or just a few sprite sheets and load those instead of hundreds of single images. That shouldn't trigger the protection measures of the provider but it would require a bit of extra work in terms of using the images since using one or more spritesheets changes the way this is approached. If you want to create a video here is a thread where appropriate video compression is discussed: https://gsap.com/community/forums/topic/33683-scrolltrigger-to-play-back-video-is-laggy/ Happy Tweening!

Nope, that is nothing we can help with. You could look in to creating a video and then scrubbing the video with ScrollTrigger, but that has its own challenges and will require a deep knowledge of video formats and encodings. Which is also not a GSAP question, but it could fix your brute force issue, because you just load one file instead of hundreds. But again these are no GSAP questions, so please keep the forum guidelines in mind!

Hi, The demo of your latest post is still using the getScrollLookUp function and not the code I implemented in my previous demo. As you can see the getScrollLookUp method works fine in this demo: https://codepen.io/GreenSock/pen/popKYRW But in your's there has to be something that is breaking it, that's why I suggested a different approach, also is worth noticing that your demo still has a lot of HTML and JS that most likely is not needed to make your point in this one. The one thing I can think of is to make that particular nav pinned in a different ScrollTrigger instance without any pin spacing. Most likely that is throwing off the calculations, but as I mentioned before, we don't have the time resources to go through all that and create a custom example for you at this moment. Another option would be to create that navbar as a fixed element but that is not visible until you reach that section, then you can show/hide it using ScrollTrigger's onEnter(Back) and onLeave(Back) callbacks and see if that helps. If I was you I would start with something extremely simple and not all that HTML/CSS/JS in order to create something that works as expected and then start adding more complexity in terms of the styling. Happy Tweening!

thanks Jack and Cassie - that's exactly what I was hoping for but couldn't get done on my own. I'm so impressed by how quickly and patiently you have helped what I'm sure seems like a small query. huge huge thanks ! to help any others reading this topic - I have cleaned up the code, added comments etc so it's easier to understand and reuse for others: https://codepen.io/b-t-l/pen/abjdKPN?editors=1111

Ah yes, here's a fork that restores that scroll position: https://codepen.io/GreenSock/pen/jOpWwEg?editors=0010