Leaderboard

@barthendrix, that was correct and thank you for liking the animation and continue the thread! @GreenSock, thank you, now I learned something new, didn't know about auto-round. That cleared things up.

Hi Cassie, You're 100% correct with all your questions. The the 2 paths are very similar. Mainly going round roundabouts the correct way and leaving junctions on the return journey. Let me take the idea away and see if the features adds enough value to get funding for consultation. Your contribution has been fantastic and I thank you so much for your time and effort today. Have a great rest of your week. Happy coding.

Hi @Maxence_34 and welcome to the GreenSock forums! The issue is super simple, you're creating your selector outside the function that defines and creates the component/page, therefore by the time that code runs there is no element with that particular class rendered in the DOM. You have to run that inside the scope of the component's function. On top of that is highly recommended to do that inside a useLayoutEffect hook (in Next with SSR is best to use this approach though). Here is a simple example of a Next App using GSAP for the animations: https://stackblitz.com/edit/nextjs-bzndnh?file=pages%2Findex.js I strongly recommend you to check this guide: Finally when using React GSAP Context is your best friend: https://greensock.com/docs/v3/GSAP/gsap.context() Hopefully this clear things up. Let us know if you have more questions. Happy Tweening!

As stated before, you can't do that with ScrollTrigger. You probably can, but then you have to engineer it all your self. As stated by the previous post: You can look in to the Observer plugin this will allow you to do certain actions based on user input, but this is separate from ScrollTrigger https://codepen.io/GreenSock/pen/XWzRraJ Yes you shouldn't, that makes it really complicated and it is better to post a new pen each time you ask a followup question. Personally I would recommend getting in the habit of forking you pens, I for instance usually have a finished demo around version 20 of a particular pen.

It looks to me that's just because by default when GSAP animates px-based values it generally rounds them to whole numbers because in most cases the browser doesn't do sub-pixel rendering (for example, on values like top, left, etc.). You can disable it by setting autoRound: false: https://codepen.io/GreenSock/pen/PodoqyJ?editors=1010 Does that clear things up?

Thanks again @Cassie, I had no idea if this will-change property !

Thank you so much. You saved me Best wishes

Wow.. Got it. I missed many things in my code. Thanks for detailed explanation.

It's because NONE of these are functions: // regular values scaleX: (Math.random() < 0.5 ? getRandomInRange(1, 1.5, 2) : getRandomInRange(-1, -1.5, 2)), scaleY: getRandomInRange(1, 1.5, 2), rotation: getRandomInRange(-20, 20, 0), You're just passing in the returned value of those function invocations. If you want things to get refreshed, you've gotta use function-based values like: //function-based values scaleX: () => (Math.random() < 0.5 ? getRandomInRange(1, 1.5, 2) : getRandomInRange(-1, -1.5, 2)), scaleY: () => getRandomInRange(1, 1.5, 2), rotation: () => getRandomInRange(-20, 20, 0), No, transformOrigin has absolutely nothing to do with the "d" attribute. It solely affects transforms. Does that clear things up?

Hi @jeffballinger. Welcome to the forums! It's super duper helpful when you can provide a minimal demo, like in CodePen. You pasted in some code, but the paths don't work (like to your Lottie animations). I did the work to create a CodePen for you and swapped in a different json file: https://codepen.io/GreenSock/pen/mdGdbwO?editors=0110 It looks to me like you had an old LottieScrollTrigger() helper function maybe. Seems to work fine when I use the latest one...right?

Hi Rodrigo! Yes I think I have complicated myself too much. This is very helpful and it is the behavior I was looking for. Thank you so much!

Sorry about the confusion there. You actually hit an edge case that exposed a bug - if you have a repeating timeline with yoyo: true and you also have a repeatDelay, it didn't do the repeatRefresh. That should be fixed in the next release which you can preview at https://assets.codepen.io/16327/gsap-latest-beta.min.js (you probably need to clear your cache) Better?

Thanks a lot for your help 💙 Let me try and dive in yours links. Fun is coming...

Ah ok, perfect, thanks for the explanation ☺️ If I were you I'd separate out the up/down direction logic and the motion path following logic by creating a container element that tracks and an inner element that switches direction. https://codepen.io/GreenSock/pen/MWqWvom?editors=1010

Hi Cassie, Thank you for your prompt response. So I want the arrow to always face the direction it's heading. could not get the balance with the self.direction on ScrollTrigger and the autoRotate.

Also, this article And this article Have a lot of tips. Specifically https://greensock.com/react-advanced#communication

Thank you so much for your detailed answer and time @Cassie!

I personally would never use an infinite repeat on an SVG animation. Even on canvas animations looping something over and over is going to get a bit resource intensive. Of course that entirely depends on *what* the use case is. I made some animations that were displayed on a screen at an event, they only ran in chrome and on a very fast machine. Whereas if you're infinitely looping a big SVG animation for web use and people are going to be viewing it on low end mobile devices that's a different story 🫠 If it's on a webpage, my advice would be to stop the animation playing as it scrolls out of view and start the animation as it comes into view again. That will help. In terms of debugging these are the two most useful options in chrome dev tools Kapture 2023-02-14 at 12.33.38.mp4 Kapture 2023-02-14 at 12.33.38.mp4

If it works it works. Maybe check if you're on a smaller screen and draw less elements, but I don't see why this couldn't work. I don't see any slow down on my end. Please include a minimal demo next time, saves anyone time wanting to jump in and it really helps us help you! Hope it helps and happy tweening! https://codepen.io/mvaneijgen/pen/mdGdrNJ

It's all clear now. Thank you :)

Yup, that looks perfectly smooth. Interesting to learn about autoRound, thanks for pointing that out!

Hi Jack, Yep, swapping out hero section margin-block for padding-block (in the real project) fixed it right up, thanks a bunch! Chris - ViVO

Thank you! I didn't use this exact technique since I couldn't figure out what to interpolate on a duplicate timeline but I was able to use interpolation on something else that did the trick!

Thanks @Rodrigo I thought that last parameter was just to group elements to animate together, didnt know it would affect timing. I wanted them all to move at the same time so I just passed a string instead and its working as expected now.

That isn't entirely accurate - clearProps is indeed just for CSS properties and it is solely for clearing them which has nothing to do with returning them to the previous state before the animation. For example, if the "x" was 100 before the animation started and you clearProps, it's not as if it returns it to 100. The revert() method, on the other hand, does return individual properties that the tween affects back to the pre-animation state. You could just set the properties back to 0: https://codepen.io/GreenSock/pen/eYLOqwK?editors=1010

Maybe just use the conditions syntax: https://codepen.io/GreenSock/pen/YzOKmpB?editors=0010 Does that help?

Hi @mvaneijgen Here's a codepen which shows the original issue - https://codepen.io/barthendrix/pen/MWqgyzM If you uncomment the commented css lines (which handle the transition of the pie wedges on hover) and put a return at the top of the js file, the css animation is smooth. When you use the js only approach, the pink wedge has a flicker when it's animating. It seems like it's the combination of animating stroke-dashoffset and stroke-dasharray that's causing the flicker. Hope I got that right @Devotee007 - and the animation is starting to look pretty cool!

Hi, As far as I can tell the clear props is not working in the case of PIXI display object. Is worth noticing that clear props will remove all the applied styles and set the element back to it's previous state before the animation, with that in mind you could achieve the same result using the revert method: https://greensock.com/docs/v3/GSAP/Timeline/revert() Here is a fork of your codepen: https://codepen.io/GreenSock/pen/OJoLwWB Hopefully this clear things up. Let us know if you have more questions. Happy Tweening!

Hello @Romanus You have your timeline set up to repeat infinitely into the future. When at some point in time you tell gsap to reverse that timeline, it will reverse it with every repitition that was played up until that point - so I do think it's behaving just like you tell it to. What you could do instead of reversing it in your example, is to e.g. tween the time to 0 via tl.tweenTo(0)to make it go back to its initial position. https://greensock.com/docs/v3/GSAP/Timeline/tweenTo() In that context it might also be helpful to get familiar with the different variations of time measured by GSAP, like e.g. .time() vs .totalTime(). https://codepen.io/akapowl/pen/NWLKgyQ

Hey there! There are some demos and articles here https://greensock.com/docs/v3/UsingGSAPwith Hope it helps get you going in the right direction!

Oh, now I see what you mean. Yeah, there are 3 solutions: 1) Hide the overflow with CSS (by FAR the best and most common fix): body { overflow-x: hidden; } That's almost always a better solution anyway because it's extremely common for scroll-based animated pages to have content fly in from the left or right, and in those cases you'd see a horizontal scrollbar anyway (without the fix above). 2) Don't pin elements that have transforms applied. If your element needs a transform, just put it inside a container <div> (or whatever) that doesn't have transforms, and pin that container. 3) It may be possible for me to add a bunch of code to ScrollTrigger to attempt to factor in all the transforms (x, y, xPercent, yPercent, rotation, skewX, skewY, etc.) to calculate the offset and apply it to the top/left instead but (and this is a big but) the reasons I'm extremely hesitant to do this are: Added kb and performance hit for all pinned elements (because they'd all have to do these calculations). So even though maybe 0.1% of users might find this useful, the other 99.9% still have to pay the "tax". There's a chance it'd break existing use cases that rely on the current behavior There are some edge cases that may make it virtually impossible, like if the browser reports top/left as something other than px units. It's just more brittle overall. So again, I wouldn't really consider this a "bug" anyway - it's more like the nature of the beast. It's easily worked around with a simple line of CSS and if we tried to implement a complex workaround inside ScrollTrigger, it seems more brittle and definitely more costly. See what I mean?