Search the Community

Hi, I want to ask can animation synchronize with timeline? Mean first we define the timeline then animation will start depend on the timeline, for example the timeline have 10 second and will run from 1 to 10, at second 2 the animation A will start and at second 6 the animation B will start, if user seek at second 7 the animation B will start half way instead from start, like ScrollTrigger with scub, for example: // Create timeline with 10 second const timeline = gsap.timeline({duration: 10}); // At second 2 this animation will run gsap.to('divA', {x: 100, y: 100, startAt: 2}); // At second 6 this animation will run gsap.to('divB', {x: 900, y: 900, startAt: 6}); // Start count from 1 to 10 timeline.start(); // When user click will seek to second 7 document.querySelector('timelineBar').addEventListener('click', function() { timeline.seek(7); }); Thanks

Hey Folks, We're excited to launch a new feature that allows you to save your favorite threads as, well, favorites! 1: Press the favorites button at the top of any thread. 2: View a list of all your favorites by visiting: https://greensock.com/forums/favorites On the favorites screen you can remove favorites. So now you know longer have to dig through pages of Blake's "content" too find that killer demo you need Thanks to everyone that requested this feature. Let us know what you think.

Hi! I'm today trying to get something, but i'm failed. I did own javascript animation platform, that can do part of thing of GSAP! But i need "In-Sync" tweening, basic users don't need that, but for sliders, tab-changed, Timeline GSAP script is best working. Missing some feature i need. TweenMax.to('#element', 1, { width : 200, height : 200, x : 100, ease : { width : 'QuadInOut', height : 'ExpoInOut' }}); // these syntax is for example, maybe have wrong syntax, sorry I can create this plug-in (pls let me read useful docs for creating plugin) and have already? It's reduces memory, CPU and size too. Thanks, Any reply appreicate. Sorry for english

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?

I searched around a bit to see if this had been suggested before - I'm guessing it has, but just in case - you can already pass in an array of clips to have their properties tweened - why not allow passing in a vector (e.g. Vector.<DisplayObject>) as well? mostly for the sake of sheer convenience in not having to switch collection formats when you need to tween things.

Hi I'm wondering if this already exist in TweenMax, or if not, if it's possible to request for a feature here. Sometimes when working on something, you might want to have an update loop temporarily (say mousedown, until mouse up). The way to do that in JS would be to create a request animation frame, and then kill it later etc etc. However since TweenMax is already running one in the background, I was wondering if it was possible to hook into it somehow. Taking advantage of the nice, remove / pause features TweenMax provides I imagine something like, (or whatever you guys see fit!) var updateReference = TweenMax.onEnterFrame(scope, myFunction); updateReference.pause(); updateReference.resume(); updateReference.remove();