GreenSock

Funny, guys. I'm just a dork who geeks out over code. Anyway, yeah, we've got several plugins that allow you to set merely a velocity and/or acceleration and it'll handle the rest. Physics2DPlugin and PhysicsPropsPlugin specifically. And ThrowPropsPlugin adds another dimension, letting you optionally define an end position (or range or array of specific values and it'll pick the closest natural one) and then it'll glide to a stop. Super useful in some cases. And this stuff doesn't only work for x/y positional values (well, except for Physics2DPlugin which kinda makes sense). You can use it for pretty much any property. Rotation, width, yourCustomProperty, whatever. Once you get the hang of it, it can create some really fun and advanced effects with minimal code. ThrowPropsPlugin can even track the moment-by-moment velocity of any property so that you can feed in that velocity to your tweens. ThrowPropsPlugin.track(element, "propertyName"), then ThrowPropsPlugin.getVelocity(element, "propertyName") Note: all of the plugins mentioned above are membership benefits of Club GreenSock. http://greensock.com/club/

I don't think so, no. That'd be a question for Adobe

That's probably more of a question for Adobe. I'm not very familiar with what's supported in the mobile AIR stuff, but it wouldn't surprise me if filters weren't available. Did you make sure you activated the GlowFilterPlugin?

Yep, we do that in order to keep the smallest footprint in terms of requirements. You can totally use TweenMax for that stuff if you want. Keep in mind that tweenTo() and tweenFromTo() are just convenience methods that: Pause the timeline Create a linear tween of the timeline's "time" That's it. So you could do it yourself like: var from = tl.getLabelTime("nowhere"); var to = tl.getLabelTime("somewhere"); tl.pause(); TweenMax.fromTo(tl, Math.abs(to - from), {time:from}, {time:to, ease:Linear.easeNone, repeat:-1, yoyo:true}); Does that help?

That sounds like a funky glitch in Firefox related to SVG and the fact that it burps if you try animating a property of an SVG element that's not visibly rendered in the DOM (weird, I know). Have you tried the latest version of GSAP? https://cdnjs.cloudflare.com/ajax/libs/gsap/1.18.4/TweenMax.min.js We implemented a workaround a while back. Keep in mind that CloudFlare (who runs the CDN) refuses to support the "/latest/" directory anymore (we begged and pleaded but to no avail). So it's probably forever stuck on 1.18.0. You should always target a specific version from now on. 1.18.4 is the latest at this point, although we plan to push out 1.18.5 within the next week. Oh, and the other option is to just make sure that your SVG elements that you plan to animate are actually in the DOM and rendered visually before you try animating them.

Here are a few of the reasons that I can recall: I was trying to compare some JS-based things with CSS animations/transitions. The only way to do an FPS meter is with JavaScript. The browsers were not reporting things accurately for non-JS things. For example, if I used a requestAnimationFrame loop to measure how many times the screen actually got repainted, it might report as 12fps even though visually it was blatantly obvious that it was more often than that. This is at least partially due to the fact that JS always runs on the main thread but *sometimes* transforms or opacity animations are spun off to a different thread. I found that Dev Tools wasn't reliably reporting things, particularly for CSS-based animations. See http://greensock.com/css-performance/ It made them *appear* to be much less expensive than they actually were. I was told by extremely well-respected members of the Chrome team that they knew FPS counters were inaccurate and there was no way to solve that (at least at that point). Some animations entailed a hybrid of JS and CSS, like Zepto would use JS to fire off animations by applying CSS transitions (via JS). Thus when the CSS stuff was doing its thing, it actually slowed the main thread way down (again, because even if things are theoretically spun off to another thread, there is a bunch of overhead expense, as shown in my video link above). So you'd see this funky delay between when animations would start (they'd get clumped together) and then during the actual animation it'd appear smoother. Since the FPS counter was in the JS level, it was inaccurate. Some FPS counters used requestAnimationFrame while others used setTimeout or setInterval. Some of the core engines (like jQuery) used setTimeout() for animation ticks/iterations, but if you try to measure things with a requestAnimationFrame meter, it's again inaccurate because it's not synced with those setTimout calls. In other words, if jQuery is set to try to run at 100fps, that means 1 tick every 10 milliseconds whereas requestAnimationFrame is capped at 60fps (1 every 16.7ms). You could have some occasions where jQuery runs 2 updates inbetween requestAnimationFrame ticks (two movements, one screen refresh). You can't really use setTimeout() to drive an FPS counter because those aren't synced with screen refreshes (which are typically what people associate with a "frame"). So basically, in order to have a somewhat accurate FPS meter, you must make sure that **everything** you're measuring is also perfectly in sync with requestAnimationFrame ticks. The browser doesn't always cooperate. Oh, and some older browsers don't even offer requestAnimationFrame support. So it just gets really tricky to build something that you can measure accurately across a bunch of devices. In my opinion, it's very easy to miss the point of FPS meters and get side-tracked by the tech. Ultimately, why do we even care about FPS meters? Typically it's because we want to benchmark things so that we know which one will perform better. For animation, "perform better" almost always means "looks smoother". So I tend to put a lot more emphasis on that. Use your eyes. Push things to their limits and see where they break down, and measure the different techniques at that point rather than getting hyper-focused on FPS numbers. I've seen cases where an animation reports a higher frame rate but looks visibly worse than something with a lower FPS number. I have also seen things that made it seem like CSS was better on Chrome on a fast Mac, but then I tried it on some mobile devices and the JS version blew the doors off the CSS one. So it wasn't as easy as just cracking open Chrome and saying "oh, look, the FPS meter says this way is better...cool, we'll go with that." There are other factors too, like the way animation delays are calculated, avoiding layout thrashing, and synchronization across every part of an engine. I explain some of that here along with some comparisons: http://greensock.com/gsap-1-12-0. Again, if you myopically focus on an FPS counter, you may miss some of these other factors that make a big difference in how things will actually look. I hope that's at least a little bit helpful rather than just being utterly confusing.

Glad you've got some solutions to choose from. As for performance, remember not to just test the getRatio() function itself - one of the key optimizations we made in the engine was baking in support for the Power eases right inside the render loop, thus getRatio() doesn't even need to get called for Power functions. Skipping function calls helps. So if you're trying to measure performance, make sure you're doing it in the context of actual tweens. But honestly I doubt you'd ever notice a difference unless you're tweening hundreds (probably thousands) of things simultaneously.

I don't think I've ever heard of someone wanting an ease that's stronger than Power4, and you're right - we put a heavy emphasis on optimization which is one of the reasons we didn't offer something like you're explaining, but I also see your point about offering a less optimized (but more flexible) option for the rare cases when someone needs it. That being said, we have some other exciting plans that would make this sort of thing irrelevant You'll have to wait and see about that, though. I can't explain too much yet. In the mean time, you're welcome to main your own easing function that does exactly what you're talking about. You can analyze the code in the other eases like Sine to see how to format things. Basically you need to make sure there's a getRatio() method that takes a progress value between 0 and 1 and spits back the converted eased value. Thanks for offering the suggestion. Feel free to keep telling us about ideas you have for improvement.

The "jump" at the end is just the browser honoring your "stroke-miterlimit:10" which is set in your HTML inside a <style> block. That basically tells the browser how far to go with rendering the stroke around pointy edges. Change it to stroke-miterlimit:1000 and you'll probably get the effect you want. Or maybe consider changing the stroke-linejoin to "round" (that would be my preference visually)

Another technique you could use is with a label: tl.addLabel("dots", 2) .to(".dot1", 0.3, {x:"+=150"},"dots") .to(".dot2", 0.3, {y:"+=150"},"dots+=0.2") .to(".dot3", 0.3, {rotation:"+=150"},"dots+=0.7") .to(".dot4", 0.3, {alpha:0},"dots+=6.2"); I personally prefer Carl's technique with splitting things up into child timelines just because it makes things so modular and easy to create functions that spit back animations that can be nested however/wherever you want. Some people prefer using labels, though. Totally up to you.

Yep

Working well for you?

I'm not at all familiar with Ionic 2, no. Sorry. But I cannot imagine how or why it would be a problem to use GSAP with it because GSAP doesn't care about the rendering layer - it just changes properties over time. Literally, like any properties. Anything JavaScript can touch, GSAP can animate. It was specifically designed to be rendering-layer-agnostic so that once you learn GSAP, you should be able to use it pretty much anywhere, with any framework (or no framework). Let us know if you run into any trouble, though. If anyone here knows about Ionic, my guess would be OSUblake (he's our resident Angular expert too)

Yep, Blake did a great job summarizing things. I'd guess that 95% of the time when someone is running into a performance problem, it has nothing to do with the animation engine itself - it's almost always the graphics rendering load that the browser is struggling with. For example, it may take 1 millisecond for GSAP to set the value of a filter (or any property), but it might take 200ms for the browser to do its work under the hood to calculate all the changes to the pixels on the screen and do the rendering. SVGs are particularly performance-sensitive because of their resolution-independent nature. The browser basically has to fabricate all the pixels on-the-fly (it can't just use the GPU to stretch/scale/shift a set of raster pixels around). I love SVG, and it can be fantastic for many things, but you just have to be careful performance-wise. As for specific tips with GSAP, we've already done a bunch of work to make sure you don't have to worry about much. It's a deep topic, but for most people the main thing to keep in mind is just which properties they choose to animate (which actually has very little to do with GSAP - it's about being mindful of which properties are more expensive for the browser rendering-wise). So stick with transforms and opacity, like Blake said, as much as possible. Great job on the crab(s). Congrats on getting noticed on codepen too Happy tweening!

There are many ways to do it, but here's the most concise: tl.staggerTo([".dot1", ".dot2", ".dot3", ".dot4"], 0.3, {x:"+=150"}, 0.2, "-=2");

Glad you figured it out. Let us know if you need anything else.

The simplest way would involve a TimelineMax with a TweenMax in it: var tl = new TimelineMax({repeat:-1}); tl.to("#box", 2, {x: 400, yoyo:true, repeat:1, repeatDelay:1}); Or, if you're limited to loading TweenLite, you could do it with some logic and a delayedCall(): TweenLite.to("#box", 2, {x:400, onComplete:onComplete, onReverseComplete:onReverseComplete}); function onReverseComplete() { this.play(); } function onComplete() { var tween = this; TweenLite.delayedCall(1, function() { tween.reverse(); }); } Or an alternate with only one function: TweenLite.to("#box", 2, {x:400, onComplete:onComplete, onReverseComplete:onComplete}); function onComplete() { var tween = this; if (tween.reversed()) { tween.play(); } else { TweenLite.delayedCall(1, function() { tween.reverse(); }); } }

Yep, {self} would be a reference to the tween instance itself (not the target). That's why you had to add ".target" to it, to reference the tween's target (the DOM node in this case) Another way you could do this is with another staggerTo() call instead of callbacks. You just delay those tweens a bit so that they line up where you want. This way, all the animation is inside a single timeline instance that you can easily seek(), reverse(), timeScale() or anything like that: http://codepen.io/anon/pen/aNgRWz?editors=0010 Notice I created some variables at the top that you can play with for the timing of all the staggers, durations, etc. Happy tweening!

Draggable has a static hitTest() method that you can just feed two elements into, but beware that it simply uses the bounding boxes to measure overlaps, so it's not literally pixel-perfect for rotated or oddly-shaped things (that'd be a lot more processor-intensive). For example: //simple overlap test if (Draggable.hitTest(element1, element2)) { //do stuff } You can also check that a certain amount or percentage of the elements overlap. See the docs: http://greensock.com/docs/#/HTML5/GSAP/Utils/Draggable/hitTest/

An easier workaround would be to simply call TweenLite.ticker.wake() first (no need to add a dummy listener). But yes, I see what you mean and it should be fixed in the upcoming 1.18.5 release which you can preview [uncompressed] here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js

Excellent, glad you figured it out. Thanks for letting us know. Sorry you had to bloody your head over this

It's pretty difficult to troubleshoot blind (without a reduced test case codepen or jsfiddle), but I'm guessing this has something to do with the fact that from() tweens render immediately by default and of course they use the *current* values as the destination ("to") ones. Thus, if you create multiple from() tweens on the same element, you'll run into a logic problem (not a bug in GSAP). For example, let's take something super simple: var obj = {x:0}; //obj.x starts at 0 TweenLite.from(obj, 1, {x:100}); //immediately makes obj.x 100, and records the current value (0) as the destination. TweenLite.from(obj, 1, {x:100}); //immediately makes obj.x 100, and records the current value...100 because of the previous line...as the destination. So when you run this code, you'll just see obj.x sit at 100 and never animate. That's exactly what it's logically supposed to do (no GSAP bug), but the author might be confused thinking "wait, shouldn't obj.x go from 100 to 0?" from() tweens can be pretty useful, but they can also be a source of confusion in cases like this. You might have better luck if you use fromTo() tweens, or just to() tweens just because people generally think in those terms better. The whole "use the current value as the destination value" can cause logic hiccups like this. Another option is to set immediateRender:false on your from tweens, but the risk there is that you'll see a brief flash of the original values until the next tick. That could be mitigated by calling TweenLite.render() after you've run all your logic and you've got things set up the way you want. But frankly, I think you might find it easier to work with fromTo() or to() tweens. A 3rd option is to force your timeline to completion before killing it, assuming you've only got "from" tweens in there (solely for the purpose of making the elements return to their original positions). Does that help at all?

If I understand your question correctly, this has nothing to do with GSAP. IE uses a different default way of scaling things. You can probably just tweak your CSS and/or the width/height attributes to normalize things. A quick Google search got me here: http://tympanus.net/codrops/2014/08/19/making-svgs-responsive-with-css/ and https://css-tricks.com/scale-svg/. Sara Soueidan, for example, suggests explicitly setting the width to 100%. Does that help?

Welcome to the forums. I took a peek at your codepen and I think you might be misunderstanding a few things: 1) When you select something with jQuery, it's not really a constantly-updating "live" selection. For example, $(".open") will grab whatever elements have the "open" class at that particular moment (when that call is executed), but then if you add the "open" class to some other element later, it doesn't suddenly update your $open variable to contain that new element as part of the selection. That's just how jQuery and pretty much all selector engines that I know of work. 2) You had a typo in your code - you had $(search) instead of $search (or $("#search") would work too). 3) You were executing your tween immediately (before any click and before anything had an "open" class). It seems like maybe you assumed that somehow the tween would sit and wait and get activated as soon as something had the "open" class applied to it, but that's not how things work. You can easily get that effect, though, with the right code of course. But keep in mind that by default tweens begin running immediately unless you pause them. So in your case, the tween ran on an empty jQuery object (because nothing had the "open" class applied when the tween was created). Then, onclick, you toggled the class but never actually created a tween for that freshly-adorned "open" element. You can just move your tween code into that block to solve this. I also assume you wanted to animate the "y" back to 0% when the class was toggled off. You had no code for that either. So here's my [somewhat more verbose for educational purposes] forked codepen that shows what I assume you wanted: http://codepen.io/anon/pen/qZzpmv Better?

Nice work