maskedbacon

For sure! This may prompt some interesting learning on my end, since I'm not super aware of all of GSAP's new features. A lot of us are ex-Flash developers, so GSAP has a wonderful familiarity. GSAP is great for complex, custom, and JS-controlled animations, but it understandably can't do everything. GSAP can be overkill for stuff that we can do with vanilla Javascript, and certain types of rapid user interactions can glitch (since GSAP is time based and not physics-based like React-Spring). We use vanilla JS for scroll tracking (via Intersection Observer), and CSS animations wherever possible. So far, we're using GSAP for our more intricate animations, timelines to coordinate synchronized and scroll-controlled animations, and ticker for canvas rendering. And there's no avoiding SplitText GSAP is always in our toolbelt, but depending on the seniority of our devs and the demands of our projects, we may lean more or less on built-in features versus custom, specialized utilities.

Hey there @SteveS! We're using GSAP for the majority of our animations, but we also have RAF loops for other functions, such as scroll detection, fancy interactions, and some canvas stuff. Our goal is to avoid layout thrashing, normally caused by having measure, mutate, measure, mutate methods on the same frame. We were using fastDOM, but realized that even if it nicely splits measure and mutate, but there's no guarantee its timing coincides with GSAP's internal optimization. And since we can't do without GSAP, it makes sense to unify our RAF cycle by using calls from your system

That sounds like exactly what we need! By default, does anything else use priority: true (aside from set())? If priority basically gives us the "before GSAP work" queue, that's perfect. Thanks as always, Jack.

Looking at this thread... And this linked documentation... Would using set() with lazy: true effectively be a mutate() call? And therefore imply that anything outside set() is measure()?

We want to use GSAP as our main RAF ticker, but we're also looking to avoid layout thrashing and I'm wondering how we can subscribe to measure and mutate separately (similar to https://github.com/wilsonpage/fastdom). From reading other threads it looks like GSAP already functions internally in this way. Would add() with prioritize put a callback into the measure stack? Or is there another method?

Correction -- this is actually happening to any element with a preset z-index and transform matrix applied via fromTo() or set(). I know you'd ideally like a link or codepen to see what's going on, but the material I'm working on is sensitive for the time being. However, it launches today so I could provide a dev link tomorrow if needed. Thanks!

Hi guys, I'm having some issues on iPad with GSAP setting my scaled animation elements to z-index 0. This only happens if you set the initial value of the scale. I tried with scaleX and scale. I also tried adding a delay between a TweenMax.set() and a TweenMax.to(), but the same thing happened. Here is an example of one line that has the issue. This element is position absolute with a specified z-index of 2 to begin with. TweenMax.fromTo($label, 0.3, {opacity:0, scaleX:0.1}, {opacity:1, scaleX:1, delay:0.4 + d, ease:Quint.easeOut}); I appreciate all you've done with GSAP, and I hope you can resolve this bug! Thanks, David

Ohhhhhhhh. Oh. OHHHHHHHH. I never knew duration was read/write I'll give this a whirl in a little bit once my other code stops exploding.

Yay! Is there documentation to this addition? I'm snooping around the API Docs and I'm not sure where you put it... Thanks!

Hey, thanks for replying guys. I was hoping that changing the duration would have some algorithm for compensating for the time difference... so, say, you were 50% of the way through a 2 second tween and changed it to 4 seconds, it would then take 4/2 = 2 seconds to complete the last 50%. updateTo already has the option to reset the time... I assume this doesn't reset the entire tween, so it's effectively changing the last, say, 50% of the tween to go at a different rate. It seems natural that you'd be able to change, the duration. No? The problem with making new tweens instead of changing the duration of them is that it also resets the easing. So you get visual stutters instead of just sped up smooth completions. You could imagine many situations where you have a slow moving object that you'd just like to speed up depending on an action, and this would be awesome for that. And by the way, if that's you Jack, I love your platform! I've been using it for years and I've converted many other developers to see the light

Hi guys, Is it possible to change the duration of a tween mid-tween? I'm not seeing much in the documentation or around the interwebs about this (but maybe I'm blind). It would be an incredible feature for game development and the like so we could use fancy eases with dynamic movement. Thanks! David