Search the Community

I hope this is a fairly simply question I'm moving an item like this gsap.fromTo("#graphMaskHandle", 60, {x:-155}, {x:0}); It seems to start moving more quickly then slow down as it goes on. Is there some kind of easing on as default for gsap? If so, how do I turn it off and get linear motion? If not, any ideas what's going on? (I'm forbidden from sharing my code on CodePen, unfortunately) I'm using it to reveal a graph over a 60 second period, so the graph needs to be revealed to match up with "seconds" on the x axis. I'm a newbie to green sock; I'm finding it brilliantly useful, but, on top of my poor maths, I'm having a bad day with this. Any help would be appreciated.

Hi Chaps, I'm just mapping out a Greensock animation and I've noticed there is a very minor delay between tweens on a timeline. Is this dictated by the graphics processor / quality of my device, or is there a very small delay added as default? In the attached codepen link I've done a tween of a box moving on the x and y axis. On the final tween I've put a negative delay value of '-=0.15' to fire the tween early, and the tween seems to fire immediately. I appreciate by default there probably has to be some minor delay otherwise the movements could look too unnatural / move unnaturally fast if not. The reason I ask is the timeline I'm building is going to be quite a complex animation and knowing any default value may well be useful. If there isn't, I guess I'll have to eyeball it. Thanks as ever, Emily.

Hi, I figured how to do it, But I Cannot understand the real logic behind it. if I ask a centered div to move X by 250px, then the next animation one by the same distance. they should end up a 500px ... with equal mouvement right ? .. I've made a simple codepen. I need to understand, even things this simple !

We're considering a switch to force3D:"auto" as the default in GSAP 1.14.3 because: Performance: whenever an element has a 3D transform applied (like matrix3d(...) or translate3d(...)), even when only 2D components are needed, that element gets "layerized" (put onto its own compositor/GPU layer), meaning it's much cheaper processing-wise to move/rotate/scale as long as its internals don't change (like its color or contents). Think of it like taking a photo of it and shuttling those pixels to the GPU and then just shift those around. The performance difference is particularly evident on mobile devices that have weak CPUs. More fair comparisons: We've seen some people comparing CSS animations on mobile devices with GSAP, and since those browsers "layerize" elements in CSS animations of transforms, the animations can look smoother and people assume GSAP is just slower when in reality the perceived difference is almost entirely related to the fact that CSS is layerizing things. These users often don't know that you can simply set force3D:true or force3D:"auto" in GSAP to get that layerizing and instantly see better performance especially on mobile devices. Also, we've seen some comparisons with VelocityJS that weren't fair because Velocity automatically uses 3D transforms on mobile devices, so the same sort of discrepancy was introduced. Once again, most people didn't realize they could get a speed boost in GSAP by setting force3D:"auto" which would make the comparison with Velocity more fair. To be clear the change would look like this in the applied CSS: //current behavior of rotation:45: transform: matrix(0.7071, 0.7071, -0.7071, 0.7071, 0, 0); //behavior if force3D:"auto" was applied to rotation:45: transform: matrix3d(0.7071, 0.7071, 0, 0, -0.7071, 0.7071, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1); So what are the down sides?: There is a small performance hit when an element is first "layerized" because the browser has to take that raster image and feed it to the GPU. In most cases, this is negligible, but if you're starting a ton of tweens at the same time of hundreds or thousands of elements and they all have to get layerized, you'll see a lag at the beginning and then things will run smoothly. Most would prefer to pay the up-front cost to get smoother animation during the tween though. There's an upcoming "will-change" attribute that you'll be able to apply to elements in modern browsers that should provide the same benefits as the 3D transform "hack". So is the force3D:"auto" behavior something that will only be relevant/beneficial in the shorter term? Should we design our API in a way that directs people toward a more standards-compliant, recommended approach heading into the future? (Keep in mind that the will-change attribute is NOT applied in most browsers yet. I think only Chrome has it right now). We've heard reports of some browsers blurring things a bit when they have a 3D transform applied, especially if you're scaling above 1. Memory is limited on the GPU, so if you just "layerize" everything, you can run out of memory and cause things to crash or perform poorly. For example, if you're animating 2000 divs on a mobile device (doubtful), this change could cause your web page to crash whereas the old version of GSAP didn't. Legacy code would perform differently (although things should look the same). Some people would just see an instant speed boost, but some might get a slightly blurry display because of #3 above. Some people consider this technique a "hack" because we'd be defining a 3D transform even if only 2D is technically needed. In general, our philosophy at GreenSock has been to avoid making a lot of assumptions or stepping on the developer's toes - give them tools to get the effect they need (like force3D:"auto") but don't force it on them by default. In this case, however, the practical reality of how things work, what's common, and the tradeoffs of not doing it may trump the "hands-off" philosophy. If we do apply this change (which is the direction we're leaning right now), we'd provide a static property to change it so that you can easily get the old behavior back if you prefer, like: CSSPlugin.defaultForce3D = false; By the way force3D:"auto" means that it will only use a 3D transform DURING the tween and then revert to 2D at the end (unless the ending values require 3D of course). force3D:true would causing the transform to remain 3D even after the tween is finished. We'd love to hear what you think. Cast your vote, and feel free to comment. Any other concerns or recommendations?