GreenSock

From what I can tell, that's actually a browser limitation. Open up Dev Tools and you'll see that transforms are being applied properly by GSAP, but have no effect visually (in Chrome at least). Draggable wasn't really designed for multiple nested <svg> roots anyway. A pretty easy solution would probably be to just wrap your inner <svg> with a <g> and make that Draggable instead. Seemed to work fine in my test.

@T.Gregory let me know if you still need any help. Between Carl's answers and your "aha" moments, it seems like you've got what you need here, right?

It would be best if you could provide a codepen demo in the future - that makes it much easier for all of us to make sure we're on the same page about what's happening. The "y" describes how far **from the native position in the document flow** it should render. So in your example, they're all coming from 15 pixels above. From your text description, one should use y:20, two should use "x" instead of "y" (because you want it to come from the right which is horizontal), like x:20, and three should use x:-10 (again, because it's horizontal movement). I think you'll really enjoy playing around with things on codepen because it's so fast to change and see what's going on. If you're not familiar with it, see http://greensock.com/forums/topic/9002-read-this-first-how-to-create-a-codepen-demo/

You definitely shouldn't be doing a className tween to a CSS class that has CSS transitions applied, as they'll basically fight with GSAP for control of the same properties. You either animate with GSAP -or- CSS (not both at the same time on the same properties). I was struggling a bit to understand what your specific question is regarding GSAP. Can you please clarify and also provide a reduced test case in codepen so that we can see what's going on in your code? That'd really help. Were you just trying to figure out how to rewrite that jQuery-based code that used fadeOut() to be GSAP instead?

Interesting. Do you know why exactly? What's the conflict? I'm struggling to figure out how/why anything would get in the way of GSAP performing well. Does angular-material try to control the same properties during the animation or something (wrestling for control)?

Is there any way somebody with React experience could provide a reduced test case in codepen (or whatever) that demonstrates the problem that we need to overcome? In other words, if you use React's findDOMNode() to find the correct target and then animate that directly with GSAP, what do I need to do in order to break it? Sorry, I'm very new to React. Is React literally trashing the node that's animating at some point (when render() is called), and then swapping in a new node, thus GSAP is targeting the wrong thing at that point (nor more animation)? I just need something that shows the issue so that I can dig in and fix it (or try at least). I'm hearing lots of talk about React, how it abstracts away the DOM updates, etc., how it's not well-suited to any animation library except ones that are built specifically for it, but I'm having a very tough time finding anyone who can actually show me a demo with it broken using GSAP. I don't doubt that it's breaking - I just really need something to explore and tinker with. I've already gotten several things to animate fine in React using GSAP and the findDOMNode() method but I'm sure I'm missing some obvious stuff. Again, I'm a total React newbie. Help?

Seems to work great with inline SVG: http://codepen.io/anon/pen/kXwrOV If you're still having trouble, please post a reduced test case that we can explore.

Is there any way somebody with even a little React experience could provide a reduced test case in codepen (or whatever) that demonstrates the problem that we need to overcome? In other words, if you use React's getDOMNode() to find the correct target and then animate that directly with GSAP, what do I need to do in order to break it? Is React literally trashing the node that's animating at some point (when render() is called), and then swapping in a new node, thus GSAP is targeting the wrong thing at that point (nor more animation)? I just need something that shows the issue so that I can dig in and fix it (or try at least). I'm hearing lots of talk about React, how it abstracts away the DOM updates, etc., how it's not well-suited to any animation library except ones that are built specifically for it, but I'm having a very tough time finding anyone who can actually show me a demo with it broken using GSAP. I don't doubt that it's breaking - I just really need something to explore and tinker with. I've already gotten several things to animate fine in React using GSAP and the getDOMNode() method but I'm sure I'm missing some obvious stuff. I'm a total React newbie. Help?

If you want to use Draggable, you need to load it. https://cdnjs.cloudflare.com/ajax/libs/gsap/1.18.5/utils/Draggable.min.js You just listed all the bonus plugins (none of which have anything to do with Draggable, although ThrowPropsPlugin does unlock the momentum-based flicking feature in Draggable). Does that help? So basically, you can load Draggable and TweenMax and you'll be able to do almost anything (Draggable requires TweenMax or TweenLite/CSSPlugin)

Exactly However, I'd definitely recommend using "x" instead of "left" if you can because generally it's more performant (browsers don't have to worry about reflow/layout).

By the way, I noticed that most of the performance issues were encountered when SVGs were moving. You might want to just try swapping in PNG files for those temporarily to see if you notice a significant difference. Another thing to try would be inlining the SVG directly into the HTML. You shouldn't have to do that, of course - the browser should handle it fine, but perhaps you're stumbling on a Safari rendering bug related to SVGs inside <img> tags or something. Oh, and maybe make sure that the raw artwork in the SVG itself is sized appropriately. For example, perhaps if the native size is 2000x2000 but you're only dropping it into a 100x100 area, Safari's rendering engine may rasterize the full 2000x2000 pixels before scaling it down which could cause a lot more overhead. Again, I'm totally taking shots in the dark here, but I figured I'd give you some thoughts to try in case it helps.

Tough to say without a reduced test case, but I would definitely recommend using the transform-related shortcut properties like "x", "y", "rotation", etc. instead of literally tweening the "transform" property because they are more performant (and more precise for rotational values beyond 360 due to inherent limitations of matrix decomposition). In other words: //OK: TweenLite.to(...{transform:"translate3d(100px,0px,0px)"}); //MUCH BETTER: TweenLite.to(...{x:100, y:0, z:0}); Beyond that, though, if you still need some help it'd significantly increase your chances of getting a good answer if you create a reduced test case in codepen. Often times the process of creating something like that will reveal the problem to you, and you won't even need our help

I didn't have much time to analyze all the JS, but from a cursory glance it seems to support gotoAndStop() and to get the total frames there appears to be an m_frameCount property. Again, you'll need to verify this, but if it's true then it should be as simple as: function GSAPify(movieClip, fps) { movieClip.stop(); fps = fps || 60; //default to 60fps var playhead = {frame:1}; var totalFrames = movieClip.m_frameCount; var currentFrame = 1; return TweenLite.to(playhead, totalFrames / fps, {frame:1}, {frame: totalFrames, onUpdate:function() { var frame = Math.round(playhead.frame); if (frame !== currentFrame) { movieClip.gotoAndStop(frame); currentFrame = frame; } }); } Then you'd feed your MovieClip instance into that function, along with the frames per second, like GSAPify(yourMC, 30) and it'll spit back a tween that you can control very easily, like seek(), progress(), reverse(), play(), or whatever. Again, you might need to tweak the property names or methods based on the official API for SVGAnim but hopefully this gets you going in the right direction. Does that help at all?

Hm. Do you have a link to any docs for that SVGAnim? Is there any reason you couldn't use GSAP to control it already? Does it have frames or the concept of seek() or currentTime that could be tweened?

Thanks for the input, Visual-Q.

And by the way, you can use getBBox() on an SVG element to get its bounding box measurements. So, for example, if you're trying to figure out what 100% would be, you could do yourRect.getBBox().width. That's the un-transformed measurement, by the way. Happy tweening!

No problem, thanks for letting us know. I was scratching my head

Are you saying that you want artwork inside the SVG to rotate in 3D? If so, that's not possible because the SVG spec itself doesn't support 3D at all. You can take the entire SVG element itself (like the container/canvas) and flip it around in 3D because it's a regular DOM element, but NOT the guts of an SVG.

There are a LOT of ways to do this. If you want concise code, you could probably do it with staggers kinda like: var tl = new TimelineMax(); tl.staggerTo(".box", 1, {x:400},3); tl.staggerTo(".box", 1, {x:800, autoAlpha:0},3,2); tl.addLabel("round2", "+=1"); tl.staggerFromTo("#box2, #box3, #box4, #box5", 1, {autoAlpha:1, x:0}, {x:400}, 3, "round2"); tl.staggerTo("#box2, #box3, #box4", 1, {x:800, autoAlpha:0}, 3, "round2+=2"); But I tend to like to build things in ways that are conceptually clearer. For example, you could have a couple of helper functions that spit back timeline instances and then build your master timeline with those: function animateBox(element, linger) { var tl = new TimelineLite(); tl.fromTo(element, 1, {x:0, autoAlpha:1}, {x:400}); if (linger != Infinity) { tl.to(element, 1, {x:800, autoAlpha:0, delay:linger}); } return tl; } function animateBoxes(boxes, linger, overlap) { var tl = new TimelineLite(); boxes = document.querySelectorAll(boxes); for (var i = 0; i < boxes.length; i++) { tl.add(animateBox(boxes[i], linger), "-=" + overlap); } return tl; } var tl = new TimelineMax(), linger = 1, overlap = 0; tl.add(animateBoxes("#box1, #box2, #box3, #box4", linger, overlap)) .add(animateBox("#box5", linger + 1), "-=" + overlap) .add(animateBoxes("#box2, #box3, #box4", linger, overlap)) .add(animateBox("#box5", Infinity), "-=" + overlap); Hopefully that gets you going in the right direction http://codepen.io/anon/pen/ZOeNbe?editors=1010

I doubt you'd need a special plugin or anything. You should be able to just use a simple function like this: function tweenForwardTo(tl, timeOrLabel, vars) { if (typeof(timeOrLabel) === "string") { timeOrLabel = tl.getLabelTime(timeOrLabel); } if (timeOrLabel < tl.time()) { var sequence = new TimelineLite(); return sequence.add(tl.tweenTo(tl.duration(), vars)).add(tl.tweenFromTo(0, timeOrLabel, vars)); } return tl.tweenTo(timeOrLabel, vars); } Then you can just call tweenForwardTo(yourTimeline, 2). I haven't tested that (in a bit of a rush), but in theory it should work Is that what you're looking for?

You can definitely re-animate the same element as many times as you want in the same timeline. And I wouldn't recommend using clearProps unless you must (it's very rare that you'd need that). If I understand your goal correctly, you can simply use a fromTo() the second time to make it jump back to 0 and animate to 200 again: t1.to(".box1", 1, {x:200}) .to(".box2", 1, {x:200}) .fromTo(".box1", 1, {x:0}, {x:200}); http://codepen.io/anon/pen/beqZMv There are other ways to do it too, like using a repeat with a repeatDelay, or even using a tween of a tween, but those are more advanced techniques that probably aren't necessary here.

GSAP only switches to matrix() or matrix3d() when there is some sort of rotation at play, or a 3D property like perspective or scaleZ (because you can't describe those with a simple translate3d()). If you're truly only altering x/y/z, it'll only use translate3d(). Performance-wise, in all my tests it was definitely faster to use matrix() or matrix3d() when there were any of those 3D properties or rotation applied. When you do the chained syntax like that library you're using does, it forces the browser to create a matrix for each one (under the hood) and multiply all the matrices together (at least I'm pretty sure that's what it does). That's slower. I think the issue in your example was caused by the fact that the library you loaded was assigning a "z" property to the DOM node itself. When GSAP initializes a tween, it automatically creates a css:{} object for you and shuttles what it believes are the CSS-related properties into that object so that the CSSPlugin handles them. One of the checks it uses to discern what should be CSS is if the raw target element has that property itself. For example, there's no such think as element.backgroundColor; it's element.style.backgroundColor. Anyway, in this case, your library added a "z" property to the element, so GSAP thought "oh, I better tween that property on the element itself rather than handing it to CSSPlugin". The solution is easy - you can define your own css:{} object and put the properties in there that you want. For example: //OLD: TweenLite.to(myBox3d, 5, {z:200}); //NEW: TweenLite.to(myBox3d, 5, {css:{z:200}}); That eliminates any confusion. If you need super-tight control over building up the transform string the way you want, you can just animate a generic object and then apply it in an onUpdate, like: myBox3d.position = {x:0, y:0, z:0}; TweenLite.to(myBox3d.position, 5, {z:200, onUpdate:function() { var p = myBox3d.position; myBox3d.style.transform = "translate3d(" + p.x + "px," + p.y + "px," + p.z + ")"; }}); (or something like that). Does that help?

Hm, could you elaborate a bit about what exactly you'd like GreenSock to do in this regard? Like what would you want/need from us for your dream workflow? GSAP is rendering layer agnostic, so you can use it pretty much anywhere you want (well, anywhere JavaScript runs). Perhaps you could ping the SnapSVGAnimator and/or Adobe folks asking if they'd offer an option to export GSAP-based code. We don't have much control over what Adobe's tool spits out but I agree with you that it'd be pretty cool to be able to consistently use GSAP as the runtime engine for animations and have total control using a familiar API.

Thanks for the info/suggestions, Rodrigo. Ryan, it would be super helpful if you had a reduced test case that shows a key problem that you're running into inside of React when using GSAP. That'd help shed light on exactly what's going on under the hood and how we might be able to help. I'm not a React guy, so any hints you could offer would be appreciated. Again, that reduced test case would be amazing.

A slightly simpler way to make the example go the opposite way is: //OLD: return x % 500; //NEW: return 500 - (x % 500); You keep the x:"+=800"; no need to change it to -= Regarding your question about attr and drawSVG values, no. ModPropsPlugin is just for regular values and ones that are handled by CSSPlugin. What's particularly tricky (and the reason why we don't really offer a TweenLite.get() method) is that many plugins have to juggle a bunch of values that are kinda merged into one. For example, drawSVG affects the stroke-dashArray and stroke-dashOffset. So it's not simple to just start translating that data back and forth every time the tween updates. It's entirely possible, but a bit expensive. This is also part of my hesitation for including it in the public package. I can rework all the plugins to accommodate this new functionality, but it's pretty far-reaching. Almost every plugin will have to get updated and rewired.