Leaderboard

Hi Sketchin, you could use i.e. timeline for this. Would it be a solution for you ? The last parameter inserts the tween at 1 which will be respected every time you restart the timeline. var toggle = document.getElementById('toggle') toggle.addEventListener('click', toggleHandler, false) var tl = gsap.timeline({paused:true}); tl.fromTo('#square', 1, { x: 0,}, { x: 500 },1); var state = true; function toggleHandler() { if (state) { tl.play() } else { tl.reverse() } // Update state state = !state }

Hey, just wanted to share a small fun pin i made today morning with you guys.. Greensock rocks things, and make so easy and smooth the animation, so you can focus on he rest of the codes always, and let Gsap do what he can best. Btw. i read about the pipe() and gsap.quickSetter() which maybe would make things even more smooth here ? Do you think it would make a big different? Feel free to use this and or give feedback if you think things could be done better, smoother, cooler ! Thanks and Happy Tweening to you all !

Another approach: use delayedCall. I also added a check to only allow users to click when the tween (including delay) is not active. https://codepen.io/GreenSock/pen/zYxVjRE?editors=0010

Hey @themepunch that's a clever solution! Good to see you helping out. Another approach is to use restart(true). The true means delays will be honored: https://greensock.com/docs/v3/GSAP/Tween/restart() function toggleHandler() { if (state) { tween.restart(true) } else { tween.reverse() } // Update state state = !state }

Just added Flattering Wings, Red Eyes when you fly closer to the Guy and blinking eyes for the fly using following smart GreenSock Features: To calculate the distance between two objects: https://greensock.com/docs/v3/HelperFunctions and https://greensock.com/docs/v3/Plugins/MotionPathPlugin To get Number between a range from 0-1: https://greensock.com/docs/v3/GSAP/UtilityMethods/normalize() and to random blink the eyes: https://greensock.com/docs/v3/GSAP/gsap.delayedCall() Looks more fun now. Btw. Zach. thanks again for your inputs, here is the Result: https://codepen.io/themepunch/pen/BaygzQV Cheers and Happy Weekend !

Hey themepunch. Nice work! It looks good and appears to be well made. Pipe is more so a convenience method, I don't think switching to it would affect the smoothness. quickSetter could have an impact on performance depending on what you're using alternatively and how you're calling it. If you can create some quickSetters when it initializes (and perhaps resizes) and only funnel in values then that's where you'll get the best performance (meaning not having to create a new quickSetter each update). Based on a quick look at your code, using quickSetter wouldn't help too much. If you do tests with both versions I'd be interested in seeing the results though! Something that makes pens like this stand out is additional animation, such as the eyes blinking, nose twitching, wings flapping, some ability for interaction on click, etc.

Hey Chris. Welcome to the forums and thanks for being a Club GreenSock member! This is the intended behavior. If you want to restart the animation, you could use .play(0) or .restart(). I noticed that you can save a lot of code by using GSAP's defaults. You're already using some GSAP 3 features - you should use more! That also means using the shorter string form of eases and moving the duration to inside of the vars parameter: https://codepen.io/GreenSock/pen/MWYMZWa?editors=0010 Side note: You don't need MorphSVG if you're just scaling things and moving them around. You could use an array of values instead and it'd actually perform even better and be a smaller file size. But this is also a valid use of MorphSVG

Hey Nubie, GSAP only affects properties that it needs to change. Maybe you were trying to animate the background property whereas you should be animating the backgroundColor instead? Without seeing a demo or at least your code it's impossible for us to say what's causing this exactly.

If it can find the js files, then it should be able to find the definitions automatically. You can manually tell it where the definitions are in your tsconfig. { "compilerOptions": { ... }, "files": [ "node_modules/gsap/types/index.d.ts" ] } But I think there is still something wrong with some of your config files because it shouldn't be looking for a CSSRulePlugin.ts file. Rather, it should be looking for CSSRulePlugin.js. The only thing I can think of at the moment is that your moduleResolution isn't correct... or that you don't have gsap installed.

It sounds like something is wrong some of your config files because it says it cannot find CSSRulePlugin.ts. It should not be looking for files with a .ts extension as gsap modules have a .js extension. Another side note. Using the CSSRulePlugin is kind of an outdated technique as you can just use CSS variables. https://codepen.io/GreenSock/pen/PowWgOz

Hi Zach, I found the guilty style-rule and thought it worth mentioning on this forum. I'd been experimenting with an experimental css property and had tried at some point scroll-behaviour:smoothbut hadn't detleted it from my stylesheet. It really messed with scrollTo in Chrome (understandably) thanks again for y our help

Yep, I see the problem and I'll need some time to dig into it and explain why that's happening. It's a very tricky scenario indeed, as I'll show you later.

Yep, that's expected. Remember, by default, tweens/timelines start playing immediately. They are placed on a timeline (the root one by default) and their playhead is controlled by the parent's playhead. In other words, as the parent timeline's playhead moves, it moves the child's too (unless it's paused, of course). So in your example, you never paused the timeline, thus it basically kept trying to move its playhead WHILE you also had another tween that was attempting to control its playhead as well. The tween would put it in a new position, and then it would try to continue playing from there...and the tween would move the playhead to a new position, and it'd try to keep going from there. It's like a remote control car that has its wheels spinning, and as soon as you put it on the floor, it takes off moving. You pick it up and move it somewhere else, and...it takes off from there. Pausing the timeline is like powering down the wheels on that car - you can place it down wherever you want and it stays there. Anyway, that's what'd make it hit the onComplete multiple times. When the external tween puts the playhead close to the end, the "wheels are spinning" on the timeline and it hits the end on its own, but on the next tick the external tween moves the playhead to the end (or just before) and...again, it could hit the end. Does that makes sense? You should always pause a tween/timeline whose playhead you're animating.

Addressed! Simple oversight, really. I havent a clue why I was adding 1 to the snap formula. I changed the snap equation from: snap: value => Math.floor(value / xFactor + 1) * xFactor to snap: value => Math.round(value / xFactor) * xFactor,

I'm not trying to convince you one way or another, but I would just like to add this: If you put a general-purpose utility method in a toolbox, you don't know what people are going to use it for. It could end up being used for a number of non-animation purposes, and nobody will question whether they are getting an even distribution of randomness until somebody else notices it. <soapbox>If code size is the primary concern, my personal opinion is that the shuffle method should be removed (unless it is required by something else) rather than return mediocre results. </soapbox>

Yeah, here's what I whipped together for if I end up switching: let shuffle = a => { for (let j, v, i = a.length; i; j = ~~(Math.random() * i), v = a[--i], a[i] = a[j], a[j] = v); return a; } Which is still certainly more verbose than: let shuffle = a => a.sort(() => .5 - Math.random()) Again, if anyone has a real-world scenario where that 2nd one doesn't deliver desirable results in an animation context, I'd love to see it.

Hey Ainsley. I would use a different approach. Instead of trying to keep track of which slide is next and previous, just make use of how the document select elements by removing and appending the elements. It's best to use clones of the elements so that there's no jumps perceived. I also recommend animating a container instead of each individual element. Take a look at my implementation and let me know if you have any questions! https://codepen.io/GreenSock/pen/XWJPxBB?editors=0010

@Sahil @GreenSock Super helpful! Thanks again! Sahil, your CodePens are amazing, inspiring, and very easy to follow, just wanted to give you an extra thanks! I ended up using ticker for the animation I'm working on I posted it on the other thread, but will here as well in case someone stumbles on this.

Yep, @Sahil is exactly right. An onUpdate is tied to a particular animation (which can be a good thing if you want it to only run during that animation), but if you've got a bunch of animations and they've all got onUpdate callbacks triggering the same function, it's just cleaner to use a "tick" event listener. Also keep in mind that the "tick" event listener allows you to ensure that the function runs after ALL of the animations have updated on a particular requestAnimationFrame cycle. Think of it almost like a global onUpdate. Or you can actually increase the priority so that it runs before the whole engine updates instead, but the default is to run after all animations render. Does that help?

I don't think there is any performance difference just both are applicable in different scenarios. You must be familiar with requestAnimationFrame, that gets called when browser is ready to render. So internally GSAP relies on rAF in browsers that support it otherwise falls back to setTimeout. Ticker's tick event occurs each time GSAP's engine updates and onUpdate gets called when particular tween/timeline updates. In your case we suggested you to use ticker(or you can use requestAnimationFrame) so you can avoid 100 clearRect calls and call it just once on entire canvas. Same goes for draw calls. Plus ticker made more sense because your canvas was updating on every frame. Instead if you had 4-5 tweens that won't repeat then using ticker won't be good idea because once animations complete you are executing those statements unnecessarily . In most cases when you are dealing with canvas, you will want to use ticker. With DOM you might want to use ticker in situations where you are adding some easing effect like mouse follow effect etc. Plus using ticker has some benefits over rAF, like you can easily add or remove event handler, pass paremeters or set scope. A lot more flexible.