GreenSock

This one took a while to track down (sorry for the delay) - it looks like a bug in some browsers that don't properly apply the touch-action on SVG elements. To work around the browser bugs, the upcoming release of Draggable applies it to the root <svg> element as well which seems to work. You can preview it (uncompressed) at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable-latest-beta.js @Pete Barr that should resolve things for you, but you could also just manually apply touch-action:none to your <svg>. Better?

Right, the condition shouldn't be looking for an exact match because it's extremely unlikely that it'd land EXACTLY on top of that number when it's iterating and zeroing in on it back and forth. It keeps getting closer and closer is the point. In fact, while animating it's very unlikely it'd ever hit the value EXACTLY anyway. Remember, the way an animation works is that roughly 60 times per second, it updates the playhead and renders it at a new position, so animating 0 to 100 might result in frames like 1.02154, then 2.3541, then 4.000214, etc. It all depends on the update cycles, main thread performance, the ease, etc. I didn't quite understand your question about the main timeline. The solution I provided allows you to embed it into a timeline, thus it'd remain perfectly synchronized regardless of pause(), timeScale, etc. I must be misunderstanding something - can you provide a reduced test case in codepen that demonstrates the problem?

@OSUblake I was exploring a workaround that takes into consideration the potential problems you noticed with the lowercase attribute names, but it seems like even if I get the "outerHTML" of an element that contains camelCased attributes, they're always converted to be lowercase by the browser. Are you seeing the same thing? I'm wondering if the current solution is actually much more durable than anticipated. Do you still think we need to accommodate various cases?

No problem, @alan0buchanan - push through the learning curve and I think you're gonna really like the tools and see how intuitive they become as you grow familiar with the API. Happy tweening!

Yeah, if you haven't checked out CustomBounce, I think it'll save you a LOT of time and hassle with an effect like this. https://greensock.com/wiggle-bounce If you don't want to get a Club GreenSock membership, you could still build your own CustomEase and draw the bounce yourself. It'd still probably be easier than stringing together all those tweens (which is fine, of course - nothing "wrong" with it).

Good feedback, @kreativzirkel. It sounds like the speed/compatibility claims don't matter much to folks like you and it's more about the developer ergonomics of the API. @Carl is actually working on a video that I'll make that point really well (in my opinion). It's not a 30-second teaser or anything, but it takes some time to illustrate concepts that could be game-changers for a lot of people workflow-wise. Keep an eye out for that (likely several weeks out at least, realistically). I couldn't agree more that one of the biggest things GSAP has going for it is the community around here. I'm so proud of the caliber of people that hang around here and dish out advice. @kreativzirkel I wouldn't be surprised if we fast-forward 6 months, you'll have a similar story to Craig's (@PointC) and you'll be dishing out advice to others daily. It's a fun challenge.

You get the award for the most unique, poetic post in the forums, possibly ever I really appreciate the kind words and enthusiasm! Sometimes we struggle with how to best explain to the uninitiated why they should at least try GSAP. Lists of features can be overwhelming or dull. Comparing it to other technologies can come across as critical or arrogant. Hearing stories like yours makes me want to tap into that experience and unearth what REALLY matters...what's compelling? Now that you've gotten past that initial hurdle with positive results, what would you say to that pre-GSAP version of you? What do you see now that you wish you saw before? @PointC told a really nice story of his experience as well. He has come such a long way and inspires a lot of people today (along with Blake, Jonathan, Rodrigo, Dipscom, Diaco, Carl, and others). Lately I've realized that it's more about a feeling...a feeling of confidence that whatever the client throws at you, whatever you're tasked with, you can rest assured that there's probably a way with GSAP and it won't be too arduous. At least I hope that's true. Anyway, thanks again for taking the time to share the encouragement.

Glad you guys found some solutions. Impressive as usual, Blake. As for adding that kind of option to SplitText, it's not a trivial thing otherwise I'd totally do it. I think you're the only person who has requested this, though I can see why it'd be handy in certain situations. If enough people request it, we'll certainly consider adding it down the road but for now we're focused on a few other features that will likely serve a lot more people (trying to be strategic about where we focus our limited resources). Cheers!

Here's an idea: Basically I'm doing the work up-front instead of on every onUpdate. You simply feed in an animation (could be a tween or timeline) and a function that checks whatever condition you want and returns true or false. It'll iterate the progress to find the spot at which that condition changes to true and spit back the playhead time. You can then use that however you want - in this case, it's to place your other animation(s) into the timeline. // this function is the key - it iterates over the timeline at large (20%) increments until the condition is true, then reverses by half the amount (10%) until it flips back, then half that amount forward, etc. for 20 direction-changes (you can change that number by feeding in a precision parameter). This is typically better than just iterating by a certain small amount because it affords greater precision in less loops. function calculateTimeAtCondition(animation, condition, suppressCallbacks, precision) { precision = precision || 20; suppressCallbacks = (suppressCallbacks !== false); var startingProgress = animation.progress(), inc = 0.2, progress = inc, curState = false; animation.progress(1).progress(progress, suppressCallbacks); //jump to the end and back to the start to ensure that all nested tweens are rendered/instantiated while (--precision > -1) { while (curState === condition() && progress > 0 && progress < 1) { progress += inc; animation.progress(progress, suppressCallbacks); } curState = !curState; inc *= -0.5; } animation.progress(startingProgress, suppressCallbacks); return animation.duration() * progress; } I also cached a few variables to make the condition-checking faster but that's relatively minor. The other problem with the way you were doing it previously is that it'd keep firing those new animations once the condition is true (on every onUpdate) which probably isn't what you wanted. This new way prevents that and would be much faster at runtime for the actual animation(s). Does that answer your question?

Yep, I just sent you a PM with the .swc. Please let me know if that works well for you.

A catch-22 indeed, Blake. Yeah. The other tricky thing is that anytime we make something public (even "experimental"), we've gotta spend a fair amount of time documenting things, providing examples, etc., etc. And the API may evolve based on feedback, requiring more edits to docs. We're actually in the middle of rebuilding the tech that undergirds the docs (not the content of the docs - just all the plumbing for how they're built and displayed), so hopefully that'll make it a little less painful to do in the future. We've got a bunch of stuff we've been focused on, so it's tough to set those aside to push PathEditor out there (even in an experimental state), but I actually agree that it'd be cool to do at some point. We'll definitely keep it in mind.

I was pretty excited about PathEditor when I created it, and thought it'd be cool to share but then I thought it could turn into a support nightmare due to the complexity and I'm not entirely sure it'd work perfectly on every touch device, etc. If enough people request it, we very well may release it (at least to club members) And yeah, Blake, I saw that Chrome extension and was equally frustrated with it.

@duzhongkai I'm curious what made you ask about this. Were you just pulling apart the Ease Visualizer and got curious? Got a specific need for something?

That's because you created conflicting/overlapping tweens of the same property of the same object. In other words, your first staggerTo() is moving xPercent to certain values, but then before those animations are done, you've got another staggerTo() that's trying to push xPercent to a completely different value, so the auto-overwriting feature kicks in and kills the first tween(s) when the second starts. That's expected behavior. I'd recommend against creating conflicting tweens. Or, you could set overwrite:false on the 2nd staggerTo() stuff, but that just tells GSAP to let the conflicts occur (two tweens fighting for control of the same properties). See what I mean?

Thanks so much for the kind words, @manny2003! Happy tweening!

Welcome to the forums & GSAP, @manny2003! I think you'll like it around here. By default, GSAP always applies transforms to the "transform" attribute of SVG elements because: That's what the SVG spec calls for They're more predictable and reliable across browsers. There are various quirks when transforms are applied via CSS styles in Safari, Chrome, Firefox, and Edge (different problems with each). We originally applied things to CSS by default and then later switched to the "transform" attribute in order to normalize behavior and conform with the spec. The main problem you're facing in that situation is that you end up with competing sources of truth. In other words, if the CSS has one value, and the transform attribute has a completely different value, which should the browser render? Some browsers prioritize CSS, while others prioritize the transform attribute. Yuck, I know. That's one of the reasons we always recommend setting values via GSAP whenever possible. Specifically: It works around browser bugs It allows GSAP to cache the values to improve speed It ensures rotational accuracy, especially beyond 360 degrees. GSAP can parse existing CSS that's applied to an element (it must do this to record starting values), but the browser always reports computed styles as matrix() or matrix3d() in which rotational values can get very muddy and it's actually impossible to decompose in a way that always discerns the original components. For example, rotations of 0, 360, and 720 would all result in the same matrix. When you mix in 3D stuff, it gets way more complex, like a rotationY of 180 would be the same as a scaleX of -1. In fact, there are infinite options and ways to decompose the values, and they often don't really match what went in originally. So when you set the via GSAP, they get locked in, cached, and always remembered so that it's perfectly accurate every time. No messing with decomposition, parsing a string of 16 values and trying to pull out the data, etc. Does that clarify things? Technically, in browsers that support it, you could set CSSPlugin.useSVGTransformAttr = false to tell GSAP to use CSS instead but it's not really something I'd generally recommend. We place a high priority on browser consistency and when it comes to SVG, CSS transforms aren't entirely reliable in my experience.

Thanks for chiming in, Rodrigo. If I understood @UncommonDave correctly, he wasn't saying that the problem was the duration of the tweens. He's not waiting for things to finish normally - he's literally making all of their durations 0 (just for testing), but there's still a lot of processing time due to all of what GSAP must do (even with durations of 0) since there are so many tests that must be run. Is that correct, @UncommonDave?

Understood, and I was totally kidding about the "just get a faster computer" thing. Tongue-in-cheek. Definitely keep us informed about your progress.

Well, a set() is exactly the same as a to() with a zero duration, so that won't help much It might seem like it'd be simple to just immediately set the properties to their end values, but an animation engine is a very different beast than something like jQuery.css(). Keep in mind that: Even a zero-duration tween (set()) must record start/end values internally so that it can render at its starting state, ending state, or anywhere inbetween. Example: drop a set() onto a timeline and the playhead could be placed before, on, or after that spot and things must render properly. GSAP is highly optimized for runtime performance which can sometimes mean a bit of a tradeoff on the initialization code. Example: transforms are parsed and the components (x, y, scaleX, scaleY, rotation, skew, etc.) are separated out and stored independently in a cached mechanism which makes it very fast to work with on every tick. Overwriting is pretty critical in an animation engine, so GSAP must store some information about each tween and the properties it's controlling so that when another tween on that object starts, it can find that information EXTREMELY quickly and kill whatever aspects are necessary. Like if you're halfway through an "x" tween when another one gets fired off. There's a lot of optimized logic in place that, while it might look costly when you're only doing mocha tests with zero-duration tweens, actually make it possible for animations to run with butter smoothness at runtime. I wouldn't really recommend monkey-patching GSAP with mostly-empty functions like you're describing because it kinda defeats the purpose of the testing in some ways. In other words, you wouldn't actually be testing the real stuff - you'd be testing your hacked versions of the methods. See what I mean? I think it could get pretty messy too because you'd have to make a lot of very specific modifications to accommodate all the various values that plugins can handle. It's easy enough to just set "top" and "left" or "opacity" CSS properties in a monkey-patched set(), but how would you handle drawSVG, morphSVG, autoAlpha, svgOrigin, special transforms like x/y/rotation/scale, or the various browser inconsistencies that are handled automagically under the hood for transform-origin and a bunch of other stuff? I worry that you'd either miss stuff, or once you tackle it all perfectly, you'd end up with something that takes almost as long to process in your tests I wish I had an easier answer for you. Maybe just get a faster computer to make the tests run quicker

Thanks for letting us know. Glad you got it resolved.

I think I know what was going on, and I sent you a private message about it with an update to the plugin. Let us know if that works better for you. And thanks for creating the reduced test case. Very helpful.

That means a lot coming from someone with 50 years of coding experience. Wow! Good luck with your project. Let us know if there are any other GSAP-related questions we can help with.

I’m so sorry to hear about the disappointment. I just issued a full refund. Your satisfaction is guaranteed. We’re passionate about having happy customers around here and I’m really bummed to hear that you didn’t feel like the membership was worth the cost. And yes, if your goal was to have GSAP do all the physics logic in your game including collision detection and bouncing, etc., that’s not really what the animation engine was designed for. A physics engine is a totally different beast, and there are some significant down sides to physics engines that make it poorly suited for a tween-based system. Each has its pros and cons, of course. You could definitely use GSAP’s ticker to run whatever logic you want, but that doesn’t solve the problems you referenced regarding collision detection, bouncing, imposing boundaries, etc. I’m very sorry if we communicated things poorly on the site and gave you the wrong impression about what GSAP is for. To answer your question about the event callback, you could definitely do the collision detection in an onUpdate (or TweenLite.ticker.addEventListener()) and then just create a new tween at that point when you're changing direction. GSAP has auto-overwriting enabled by default so you don't even have to kill the old tween (though you could if you want). Happy tweening (or physics-engining)

It looks like the TweenMax file isn't being loaded for some reason ("ERR_BLOCKED_BY_CLIENT" is what it says in the console). Not entirely sure why without seeing the client setup. Maybe an ad blocker extension or something? I don't recall ever hearing something like that before. But again, it doesn't appear to be a GSAP issue - it's a loading of the file issue.