Chuck Taylor

Thank you for taking a quick look! It runs just fine for me (again a fast mac), and runs just fine on my phone. I think I am going to add in some logic to pause and play it depending on whether or not it is in the viewport and clean it up some of the markup a little bit more. Aside from that, and someone commenting that was simply too much for their device to handle, I think I am going to call this done for the time being. Thanks again to everyone for the advice!

I have taken another crack at this. I was hoping someone could give this a run and see how their computer handles it? Note: It might be necessary to close the codepen I had previously uploaded at the start of this thread so that it is not negatively impacting you before trying out this new one. I have taken @GreenSock's advice, and removed excess shape outside the clipPath are so that it is not being calculated. I then used temporary shapes to get the rotation point, and then removed those elements after I got the numbers I needed. I removed several gradients. They were not being animated, but I did this just in case, and feel that it looks great without the ones I took out. I also removed extra paths that were being used on each gear to imply thickness, and instead am embracing more of a flat design. I'm curious if this did the trick, or if anyone is still seeing issues / their device quickly gets warm? https://codepen.io/chucktaylor/pen/qBogWbY

@GreenSock, yes that walkthrough makes complete sense! I've never used svgOrigin before (always transform origin), but I found your demo here on codepen. https://codepen.io/GreenSock/pen/waKrNj Thank you immensely!

Thanks for the reply. Yes, I was struggling with getting the exact right point for 'spinning' a piece of gear. Figuring out how to supply a precise transformOrigin (outside the piece of gear bounding box, but where the center would have been for a full gear) to make it look right eludes me. Again, thanks for your time and thoughts. I have a couple of very young kids, and this is outside the scope of my regular work hours, so I squeeze these efforts in where I can. If I had all day to keep trying things out I certainly would. So your's and everyone else's thoughts and expertise has been really appreciated.

Hey @GreenSock, I had a follow-up question regarding this - curious if you know the answer. Does the browser only have to fabricate pixels that would be visible if the mask were not there? To clarify, I am working on slicing some of the gears so that they do not extend so far outside the clippath - and I am struggling to visually animate a precise rotation on the supposed center since the end gear 'piece' after reducing them down to a visible portion might be more of a rectangular bounds. A possible solution I had was to group the portion of gear with a circle that has the full size - but no fill or stroke. Then, I would rotate that group's center to keep the movement correct. Let me know if that description makes sense or not. It's not a bad question. I've thought about this. I want to use some transparency, and still might add some parallax effect. I'm not entirely ready to give up on this quite yet, but a video is a possible alternative.

I didn't realize this. Might be a good option. Thanks for the suggestion! Interesting. The gear in the bottom-left (foreground), is huge. So yeah, lot's of pixels being unnecessarily calculated... As that gear does a sort of clock-like ticking motion, I suppose I could Just be drawing a much smaller portion of that gear, calculate the amount of rotation for 1 tooth, and repeat it. Currently it rotates 9degrees on each rotation - a bit arbitrary, and does not line up on each 'tick'. As I am not animating any of the gradients, or strokes, and only have the 1 non-animated clippath, I think I may first try to eliminate as much stuff as possible that exists outside the clippath first. See where that gets me... My feeling was this too. I am using Nuxt (Vue) with SSR for this project. As this is the first big image that shows right on the homepage, I loved the idea of an inline SVG here as it could be pre-rendered (showing up fast), and then start moving after the scripts have loaded. I was concerned about having a Lottie animation right at the top as I don't think anything would show until the supporting javascript was loaded. Once again, thank you all for your time. I know this is not a GSAP specific thing, so I really appreciate the input. I think I will start off with minimizing the content outside that clippath. If the performance still seems off (better way to actually measure this?), I will remove some of the extra gradients which give the 'glow' between the gear layers, and check again. If there are still issues, I think I will look at the suggestion of @elegantseagulls and consider breaking out each of those groups into their own svg element, and do some absolute positioning inside a container to try and recreate it that way.

Thank you both for your time in checking this out. @SteveS thank you also for letting me know what the result was like on your machine. Looks like I will be delving into the world of canvas. Seems like canvg might be a good place to start with converting this over.

Hello everyone, I realize this is not a GSAP specific question, but I would love an opinion on this. I have created the attached animation for a website's homepage hero section - so it would be something that loads up right away. I am currently using an inline SVG and animating the elements. I notice that while I am developing this page and the animation is running, if I look at another browser window open on another screen, there is a lag when I scroll around on other webpages. I do not have a wimpy machine either - Macbook Pro - Apple M1 MAX with 64gb memory. This surprised me, but maybe there is no need for alarm - as the page I am currently working on runs fine on its own - it's just other sites on other screens when this animation is running. I'm also unsure how to measure performances - perhaps this is a Google Chrome (v104) thing... Anyway, I have read general guidelines that SVG is great for simple things like logos, and canvas is great for things with lots of objects, and interactions (like games). Since this example falls between these 2 things, I was looking for any advice or feedback from fellow gsap users who likely have much more experience with both svg and canvas - before I embark on the task of converting all this work to canvas (something I admittedly know very little about). In terms of svg optimization - I took time to merge many of the overlapping shapes, and run it through SVGOMG to reduce the file size substantially from where it was at the beginning. I realize the gradients are likely affecting some of this. Lastly, it seems to run fine on my phone, so I am taking that as a positive sign that it might be okay as is. I initially planned to throw Scrolltrigger into the mix in order to have some parallax with the different layers of gears moving vertically at slightly different rates when scrolling down the page - but I am concerned I may be pushing things too far. Thanks in advance for everyone's time taking a look.

Thanks @OSUblake. I saw in your code that you had setup your own drag handlers to work with Raphael. I'll study the implementation you came up with in that example you had done.

So I tried to take it a step further and have it so the 'handles' felt solid and could not overlap. I had a number of failed attempts using Draggable.hitTest() and the InertiaPlugin. I later found another post , where @OSUblake demonstrated a solution using Separating Axis Theorem, and the package https://github.com/jriecken/sat-js for handling this. As that post is a bit over 3 years old and the package has not seen much in terms of updates, I just wanted to see if that would still be a recommended solution, or is there another package anyone is aware of for helping with this, which may offer any additional benefit? I mean math is math, so I can certainly see why it hasn't had much in terms of updates. Just thought I'd check if anyone was aware of any additional solutions that might assist in this.

Was not familiar with ModifiersPlugin, thanks for sharing that! ? Now that the kiddos are in bed, I'm going to take a better look at this. Thank you as always for pointing me in the right direction @OSUblake!

Thank you both for taking the time to look at this. I feel like every time I come on this forum with a question @OSUblake swoops down and points out some utility function I wasn't aware of! @iDad5 To answer your question about what I hope when the two handles meet; It would be ideal if they felt solid. So if the blue handle was at a target, and the red one was dragged in, the red one would 'hit' the blue one and not overlap. The blue one would stay put though. This is partly why I was wondering if I might try using Draggable.hitTest() in addition. @OSUblake, thank you for taking the time to add to this with some sample code to get me in the right direction. I would love to better understand the arguments being used in one of the functions. I see now in the docs that we can supply: a function-based value to run your own snapping logic, like liveSnap: {points: function(point) { //run custom logic and return a new point }} I see now that this is the approach you took. What is the 'point' argument in that function, and where does it come from?

Here is a basic demo with two handles - one red and one blue. I have two yellow circles showing as snap points. I want to make it so that the handles can snap to either of the yellow circles, but only if it is not already 'occupied' by a handle. So essentially the two handles cannot snap to the same target point at the same time. I see the liveSnap property accepts a function, so maybe this is where the magic will happen, but I'd love anyone's thoughts on this if they have run into a similar issue. Perhaps Draggable.hitTest() might be a good thing to combine as well...

Ah! I don't think that this showed up for me when I looked again. I refreshed and see it! Thanks.

Just thinking how I work, (and this is clearly not everyone), my default workflow is I add the plugin to my project (intellisense in my editor allows me to see all the plugins pretty easily while doing the import). Then, I try to just have something basic work, and if that is not going as planned, I check out the docs. I'm used to reading in most of your documentation clarifications or overview explanation near the top before you get into methods and properties that can be played with. So perhaps clarifying that CustomEase is a dependency of CustomWiggle and must be included in your project (as opposed to just mentioning that it extends CustomEase), would be the clearest? Again, this is just likely a result of my workflow, but as a result of it, I really don't default to installation notes to see this information. Lastly, thank you for this plugin extension! An old one, but a good one! I was able to get the effect I was after in about 6 lines of code (x, y, and rotation separated) and quickly iterate over variations to find the result I was after. WAAAAY better than fiddling with paths in illustrator and going back and forth over and over again. ?