GreenSock

Yep, ultimately the publishers (sites) decide for themselves, but I don't think I've heard of a single site pushing back on the GSAP exemption in the last 5 months or so. I recently talked with the head IAB guy and he said he's hearing the same thing (nobody pushing back about GSAP). It seems pretty widely accepted. If you do get push-back, please let us know and I'd encourage you to point them to our articles and ask them WHY they're resisting especially because virtually the entire industry is on board with exempting GSAP from file size calculations. Perhaps they have a good reason, but sometimes they are just unaware of the wider industry stance or the arguments in favor of it, which those articles should illuminate. Good luck!

Maybe try adding this CSS: #theSVG { overflow: visible; } Is that what you're looking for? or maybe wrap it in a <g> or even another <svg> and make the inner one draggable instead of the whole (outer) container.

By the way, the updated MorphSVGPlugin is in the official zip downloads now.

I doubt you'll notice any performance issues. You could consolidate things a little by storing the result of getTimer() in a variable that you reuse, but I really doubt that'll result in anything even remotely noticeable. Feel free to run some tests. Happy tweening!

Hm, I'm not sure about that one Blake - I totally see why you'd ask about that, but I'm a bit concerned about: Sensing correctly when it's an array that should be joined like that - what if someone passes in a jQuery object that's the target shape? That'd kinda look like an array and we can't do (if obj instanceof Array) because that breaks in a multi-window environment. I'm sure I could put together enough conditions to pretty accurately determine when it's an array with the proper data and do what you're asking (check the contents of the array and look for numbers and/or strings), but I'm not sure it's worth the extra kb and processing time for something that's so simple to do externally as you showed above. Again, it's dead-simple to do manually. If it requires 8x as much code internally, is that delivering much benefit? I'm still open to that possibility, but I'm just sharing why I'm reluctant at this point. Feel free to offer other thoughts.

Yeah, I'm not sure there's a great solution in terms of combining those. It seems like you may have to pick your poison.

interesting - I never anticipated someone setting a matrix string directly on an SVG element like that (usually people define properties like rotation, scaleX, scaleY, x, y, etc.) but it's an entirely valid request. The problem simply has to do with the fact that GSAP does some advanced adjustments under the hood to make SVG transforms easier to work with in terms of the origin (more consistent with the way it works on regular DOM elements), like being able to spin an SVG element around its center (or wherever). So there are some intentional offsets applied, but they weren't being factored into the raw matrix that you were passing in. I have applied a fix to the upcoming release so that it'll "just work" in your scenario - you can see an uncompressed version at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js In the mean time, you can use this script to adjust your matrix: TweenMax.to('#g32459', 3, {transform: fixMatrix(document.getElementById("g32459"), "matrix(2.03492, -0.46932, 0.45501, 0.510676, 7.51245, 132.861)")}); function fixMatrix(element, matrix) { var version = CSSPlugin.version.split("."), m = matrix.match(/(?-|\+)?\d*\.?\d*(?:e[\-+]?\d+)?)[0-9]/ig), transform = element._gsTransform; if (m.length !== 6 || +version[0] > 2 || +version[1] > 18 || +version[2] > 2) { //skip the "fix" if an updated CSSPlugin is already loaded. return matrix; } if (!transform) { TweenLite.set(element, {x:"+=0"}); //forces creation and population of the _gsTransform object transform = element._gsTransform; } m[4] -= (transform.xOrigin - (transform.xOrigin * m[0] + transform.yOrigin * m[2]) + transform.xOffset); m[5] -= (transform.yOrigin - (transform.xOrigin * m[1] + transform.yOrigin * m[3]) + transform.yOffset); return "matrix(" + m.join(",") + ")"; } Does that help?

Good point, Blake (no pun intended). I've made the adjustment to DrawSVGPlugin to allow the other format (pure comma deliminated). Here's the codepen-specific version: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/DrawSVGPlugin.min.js - does that work well for you?

Hm, are you sure the URL is correct? I tried viewing that and it had a 404 error.

Yeah, one of the biggest benefits of using GSAP is that pretty much every major network has whitelisted it and exempted it from file size calculations because of how pervasive it is (among other reasons). So you shouldn't need to worry about GSAP's file size in your ads. You can probably load TweenMax and be done - it's got all the goodies in there and won't cost you anything. See: http://greensock.com/kilobyte-conundrum/ and also http://greensock.com/html5-banners

As you know, I'm pretty unfamiliar with Flex and all its quirks (I know there are many), but it kinda sounds like maybe the content isn't there when you're doing the update(), thus it's rendering plain white. That's a guess on my part. I suspect it's a Flex quirk - I've run into those many times where it delays rendering/painting for a while (up to 50-100ms), so there's nothing that FlexBlitMask can do about that since it's an issue with Flex. But again, that's a total guess. I wish I had a better answer for you.

I suspect Zach is right - you were talking about the findShapeIndex() utility, right? I can't imagine why MorphSVGPlugin would act differently and not honor the globals thing unless maybe you're not setting it up properly, but it's tough to say without seeing a sample codepen or your files where the error is occurring. Any chance you could show us that? We'd love to help.

I'm curious why you'd feel "stuck" using CSS. That's the primary method of controlling pretty much all properties on DOM elements, and the browser is highly optimized for that. For example, when you use CSS transforms (which is what "x" and "y" do in GSAP's CSSPlugin), it leverages GPU acceleration to make rendering cheaper. So yes, animating the position of a DOM element like a DIV is best done using CSS transforms. Does that answer your question?

I'm glad to hear you got a solution that's working for you. Did you need anything else? Shall we consider this resolved?

As far as I know, there is no such thing as "x" and "y" HTML attributes on <table> elements. Am I missing something? I checked and GSAP did indeed set them properly when you tried animating (so it is doing its job), but browsers don't recognize "x" and "y" attributes on <table> elements. Unless maybe I'm totally missing something (which is entirely possible). MDN doesn't seem to document it either: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table Perhaps you meant to animate its CSS transforms (positional data)? No need to use the attr:{} wrapper (because you don't want to animate attributes, you want to animate CSS properties). Just leverage CSSPlugin's native abilities: TweenLite.to("#bgImage", .5, {x:900, y:900, width:160, height:600, ease:Linear.easeNone}); Is that more like what you're looking for? It'd be very helpful if you created a codepen if you need further assistance - that just helps to ensure that we're all looking at the same thing in context.

First of all, welcome to the forums (and GSAP)! Nice to hear that you're enjoying things thus far. Performance-wise, it kinda depends. If you're using selector text like in your example, it will try finding matching elements and if there are none, it'll basically be like an empty tween that still runs its course but doesn't actually try setting any properties. It still runs its course so that any callbacks (like onComplete, onUpdate, etc.) work properly and so that it takes up the correct amount of time on its parent timeline, ensuring that sequenced things work as expected. If, however, you literally try tweening a null target instead of using selector text, like: TweenLite.to(document.getElementById("#somethingThatDoesNotExist"), 1, {x:100}); //throws exception It'll throw an exception because you cannot tween a null target. That'd be literally like trying to set null.x = 100. This is generally seen as a good thing (throwing an exception in this case) because it alerts you to when you've got funky code. So definitely don't try passing in null or undefined as the target. Performance-wise, I doubt you'd ever really notice a difference unless you're literally creating hundreds or thousands of unnecessary tweens all at once. I've had upwards of 10,000 tweens being spawned in staggered fashion every half-second and I barely saw a 1fps drop on my system. I personally tend to obsess about performance, so I may choose to sprinkle in the conditional logic but honestly it's probably not necessary. I'd recommend running your own tests and see if it makes any difference even on slow mobile devices. Good question, though. Happy tweening!

Jonathan is exactly right, and I also wanted to mention that the entire GSAP system is completely synchronized. You don't need to worry about one animation drifting or having two that start at the same time somehow getting out-of-sync. You can use a timeline to control them both as a whole, but you don't even need to do that. As long as both start on the same "tick", they'll remain totally synchronized (unlike most other engines - you can see a demo here: http://codepen.io/GreenSock/full/e3ac33404937de0eb77c789323367da8/). Let us know if you need anything else. And we'd love to see the final result when you're ready to share.

Interesting - I've never seen an authoring tool spit out scientific notation like that. Carl's SVGOMG is a good one, or you could clean out the scientific notation yourself using this logic: function clean(selectionText) { var e = document.querySelector(selectionText); e.setAttribute("d", e.getAttribute("d").replace(/\d+e[\-\+]\d+/ig, function(m) { var n = +m; return (n < 0.0001 && n > -0.0001) ? 0 : m; }); } clean("#path1"); clean("#path2"); But I've added that to the upcoming release of MorphSVGPlugin 0.8.3 which you can preview on codepen using this URL: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/MorphSVGPlugin.min.js - does that work well for you?

That's actually a very tricky thing because Draggable does a bunch of optimizations to calculate a concatenated global matrix based on the position in the browser window, making updates quicker while dragging (can you tell we obsess about performance?). It's quite an edge case to have the window's scroll position changing on a regular x/y drag (I don't think anyone has ever brought this up before). To force the Draggable to re-calculate things internally, you can call its update() method. So inside your onDrag, you could just call this.update(). The only down side is that the bounds don't get updated unless you call update(true), but in your particular case, it may not give you your desired result because once you hit the bound and keep dragging, your update() calls are refreshing stuff, thus when you start dragging the opposite way, it works immediately (again, I'm not sure if that's what you want or not). So I guess the short answer is "call this.update() inside your onDrag"

Hi Kim. It looks like you're talking about a Flash solution, right? I ask because you posted in the HTML5/JS forum. Did I misunderstand? And did you have a question or were you just sharing a technique you used to create a custom ease for a one-segment Cubic Bezier in ActionScript 3?

I'm still struggling to understand the overall goal. Are you saying that: Let's say you've got a delayedCall that's scheduled to be triggered 30 seconds from now... ...but the user then sets their global clock to a time in the past (like 2 weeks ago) before that delayedCall() fires... ...You want the delayedCall to fire immediately when this condition happens? So even though technically the time has gone backwards, you want it to act like it jumped forward beyond the delayedCall's trigger point? I have a feeling I'm getting it wrong. Help? Otherwise, if I am getting it right, I'm not entirely sure what can be done about that except having some threshold that'd trigger a reset of the root's _startTime. Because ultimately getTimer() is the source of truth. There's nothing else to really compare it to except itself. For example, if the getTimer() jumps by more than 10000 in one tick (or whatever), perhaps you run your adjustment logic. I definitely wouldn't want to put that into the official GreenSock code, though, because that's adding extra logic that costs CPU cycles unnecessarily for the VAST majority of users (I literally think you're the only one who has ever needed something like this and I kinda doubt anyone else ever will). See what I mean?

Great discussion, guys. Sorry I'm late to the party. Jonathan is exactly correct - the issue you described simply has to do with an order-of-operation thing. GSAP always uses the same consistent order so that you can depend on the results and you don't get the cross-contamination that often happens when you string transforms together in CSS. It has nothing to do with nesting or parent elements - it's just order-of-operation. If you rotate and then move, it's different than moving and then rotating. In my personal opinion, it's much more intuitive to always move then rotate so that the axis of movement doesn't shift with rotation. While I firmly believe this is generally more intuitive for animators, it's not necessarily "better". One could argue that our consistency is a limitation ("what if I want to have the axis of movement shift with rotation?"). CSS technically gives you more flexibility in that sense. But flexibility can be a double-edged sword (causing more confusion). I also like the idea of having even better docs/resources to help people with SVG "quirks". We'll look for ways to do that better in the future. If anyone wants to tackle that sort of thing as a blog post or something, please feel free to get in contact with us and we very well may publish it on our site. Or even just a list of pointers. Happy tweening!

Looks great, venn. Glad you got it all figured out. Nice work. Let us know if you need anything else.

I read your post a few times and I'm struggling to figure out exactly what you were suggesting change in the core exactly. Have you tried implementing your solution in the Animation.as core? Perhaps you can show me what you mean. Please keep in mind that the ActionScript tools have been sunset (no longer actively maintained), as the market made it very clear that it preferred HTML5/JS solutions and we're focusing our efforts there to help the largest portion of our user base. This certainly seems like an edge case that you described because it has never come up in all the years that the ActionScript tools have been out there (I think it was around 2006 when it started) so unless it's clearly a bug in GreenSock code, we probably won't release an update but you're absolutely welcome to tweak the source code to work around this issue you're running into.