GreenSock

Yep, it's updated in the official zip downloads for members. Enjoy!

I don't have time at the moment to dig into your code and offer suggestions, but I wanted to quickly chime in and explain why your onCompleteAll wasn't working. There is no such thing It looks like you're literally trying to add an "onCompleteAll" property to the array that gets returned by the TweenMax.staggerFromTo() which won't do anything. There is, however, a parameter you can pass in to the staggerFromTo() method that'll act as an onCompleteAll. It's the 6th parameter. http://greensock.com/docs/#/HTML5/GSAP/TweenMax/staggerFromTo/ Oh, and it also looks like you're trying to add an "onComplete" property to timeline instances. There is no such thing - you define an onComplete either in the vars object you pass in, or you can use timeline.eventCallback("onComplete", yourFunction).

Hi @Nezarov. No, I'm sorry, but we don't offer installment plans like that. And actually, we haven't really been supporting the AS3 tools since the web moved away from Flash years ago. I wish I had better news for you.

Yep, by "scrubbing capabilities" I just meant having a scrubber that you can drag back and forth to control the animation (like a virtual playhead). It's pretty simple to set up as long as the animation is using GSAP. Can't do it for CSS animations or pretty much any other library (at least not that I know of).

You're absolutely right. Sorry about that. It should be fixed in the next release which you can preview (uncompressed) at: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js If you want to patch the current version, you could add this code to your project (after GSAP loads of course) which alters the prototype: TweenLite.prototype.isActive = function() { var tl = this._timeline, startTime = this._startTime, rawTime; return (!tl || (!this._gc && !this._paused && tl.isActive() && (rawTime = tl.rawTime(true)) >= startTime && rawTime < startTime + this.totalDuration() / this._timeScale)); }; TimelineLite.prototype.rawTime = function(wrapRepeats) { return (wrapRepeats && (this._paused || (this._repeat && this.time() > 0 && this.totalProgress() < 1))) ? this._totalTime % (this._duration + this._repeatDelay) : this._paused ? this._totalTime : (this._timeline.rawTime(wrapRepeats) - this._startTime) * this._timeScale; }; Thanks for reporting this.

You're welcome to write it either way. Totally up to you. But if it were me, I'd build in a config() method to pass in any variables so that it conforms more with the new API and is more streamlined. The modern API simply leverages a single parameter passed to getRatio() that's between 0 and 1, whereas the way you did it leverages a legacy function that accepts 4 parameters (plus your extraParams). Building it with a config() method would likely perform slightly better. For the record, this isn't something we document anywhere because we didn't plan to officially support 3rd party eases although it's totally fine if you want to build one (or more). There's a chance that the API will change eventually in version 2.x.x (but that won't be out for a while). Not sure though. Again, it's totally fine for you to build your custom ease - I just waned to offer the caveat. Anyway, you can just add a config() method to your Ease class and have it accept whatever you want (meaning whatever custom parameters you need). Just store the variables as instance properties (or internal variables) that you then tap into in the getRatio() method to do whatever calculations your ease requires. Happy tweening!

Ah, very interesting. Yes, it looks like that effect basically forces the length of the shape/line to be calculated at the screen level (after scaling) rather than on the raw/native shape itself. I took a crack at applying the math to adjust the length accordingly in DrawSVGPlugin and you can test it on codepen using https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/DrawSVGPlugin.min.js. Better? Once you confirm it's working the way you'd expect, I can drop it into the official bonus zip that you can download and use on your own site(s). Thanks for letting us know about this.

Yep, exactly. Thanks @slopps.

You can get those via the _gsTransform object that's attached to any element that GSAP transforms: http://codepen.io/anon/pen/EyABja?editors=0010 Just remember that _gsTransform won't exist until at least one tween has affected that element. Does that help?

Looks pretty cool, jorrit. Question: does it work for ads that are NOT using GSAP? Do you provide scrubbing capabilities while previewing? (I imagine that'd be impossible if the ads aren't build on GSAP).

Glad you got it working. I'm not an expert with node, but I wonder if it would have helped if you referred to "this" instead of "window", like: //OLD var gs = window.GreenSockGlobals = {}; //NEW var gs = this.GreenSockGlobals = {}; //OR MAYBE: var gs = global.GreenSockGlobals = {}; (that must be run before the GSAP files are loaded). Anyway, thanks for reporting back with what you changed. I'm also kinda curious about why it's important to you to avoid having GSAP values added to the global scope. Are you under the impression that there's a big performance issue (there's not)?

Yeah, it's totally fine to create new timelines on each click. That's not "bad"; it won't cause memory leaks or poor performance. The timelines will automatically get garbage collected once they're done (well, unless you maintain references to them of course). It's only slightly more efficient to reuse the same timeline and just invalidate() it on each use. Again, the whole point there is that in your particular case you're trying to make things totally dynamic so that the starting values could pick up from anywhere. That's why creating new timelines gave you that effect - you were telling it to just start from wherever the values were at that time. If, however, you reuse timelines that have already instantiated and locked in their starting/ending values, when you restart() they'll jump back to the original starting values (instead of using whatever the current values are). The other benefit of just creating new timelines each time is that you don't have to worry about pausing the old one, as it'll just get overwritten automatically by the new one(s). Hopefully that clears things up. Either technique is valid. Happy tweening!

I noticed a few problems: Since you've got two timelines that are BOTH controlling the same properties of the same element, you need to be careful about conflicts. For example, imagine TL1 is running and then the user clicks the button...if you start TL2, now you've got two animations trying to control #box.y to completely different ends. Therefore, you should TL1.pause() before you TL2.restart() (and vice-versa). The first time a tween/timeline runs, it'll record the starting/ending values but in your case, you're trying to set something up that's completely dynamic. The simplest way to accommodate this is by calling invalidate() on the timeline/tween which flushes any recorded start/end values and re-reads them from the current values. With that in mind, here's how I simplified the code a bit and made it work the way I think you intended: var TL1 = new TimelineLite({paused:true}); TL1.to("#box", 2, {y: 200,ease: Bounce.easeOut}) .call(changeText, ["Up"], this, 0.2); var TL2 = new TimelineLite({paused:true}); TL2.to("#box", 2, {y: 0,ease: Cubic.easeInOut}) .call(changeText, ["Down"], this, 0.5); $("#box").click(function () { $(this).toggleClass("register"); if ($(this).hasClass("register")) { TL2.pause(); TL1.invalidate().restart(); } else { TL1.pause(); TL2.invalidate().restart(); } }); function changeText(newText) { $("#box").text(newText); } Better?

I think you might be overcomplicating things a bit. Whenever I run into a situation like this where, for example, I find my code leaning on a very particular order of firing things that's really difficult to manage, it's a clue to me that I might have some faulty engineering or there's a simpler solution somewhere. In your example, I'm not entirely sure why you're doing all those operations on every single tick (seems a bit wasteful to me), but if your goal is to make sure that the "lastBlocks" array gets populated according to the new scrollTop AND that the colors get applied to those lastBlocks, you could just add this to your scrollTop tween: onUpdate:function() { scrollListenerCb(); updateCb(); } Oh, and a few other minor notes: There's no such thing as an "onReverse" callback I'd be careful about animating "scrollTop" directly since that doesn't always work in all browsers for all objects (like the window), plus it won't auto-kill itself when the user interacts with the scroll position. I'd recommend using the ScrollToPlugin instead for all those conveniences. I assume you were just whipping that codepen together super quick and this is irrelevant, but some of the code seemed pretty inefficient. For example, you had a loop like "for (var k = idx; k < Math.min(idx + 11, 500); k++) {..." which would be quite slow due to the fact that you're calling Math.min() and performing math on every iteration. It'd be better to save that value as a local variable and plug it in there. Again, you probably already know this stuff and just wanted to keep the code brief for the codepen without worrying about performance. Figured I'd mention it though. Does any of this help?

Yeah, unfortunately I don't think there's anything we can do. I certainly can't see any difference on my end. I wish I had a great solution to offer.

It's actually impossible to have priorities on tweens because the very nature of an animation system requires that things render in a very particular order based on timing. For example, if you've got a tween to x:100 in a timeline and another tween after that one that animates to x:500, imagine what would happen if the 2nd one (in order) rendered BEFORE the first (because you assigned it a higher priority)? x would end up at the wrong place. And everything needs to be inverted when the playhead is going the other direction. So offering priorities on tween rendering would kinda break the whole system Like Blake said, though, you can manually trigger a tween/timeline to render at whatever progress you want whenever you want, so you could just hang onto a reference of your scrollTo tween(s) and render it inside your priority:100 handler if you want.

Looking good, Blake! The biggest help, quite frankly, is the visual editor for building the curve. Good stuff, man. So the GUI just relies on PaperJS? How easy do you think it'd be to make it zoomable and style it differently?

My Mac is slower than yours and I have put my nose right up to the screen and I cannot tell the difference. So strange. I do have an AMD Radeon graphics card though. It sounds like they look radically different to you...I'm at a loss for what to suggest. Plenty of tests show that GSAP is extremely fast, often FASTER than CSS transitions although they do have a native advantage when it comes to transforms. But again, I cannot detect any difference whatsoever on my Mac between those two codepens. And I can't think of any logical reason why the JS-driven one would look bad compared to the CSS one. It's just changing the properties 60 times per second. Unless it's indeed a graphics card anomaly. Is anyone else able to verify this?

Hm, I looked at it on a Mac in Safari and couldn't see any difference. I tried like 15 times. I also noticed that you're not really comparing apples-to-apples because the GSAP animation has 3 steps and the CSS one only has 1. You've also got it set up such that the CSS version wouldn't keep the slight rotation and z translation whereas the GSAP one does. There are some clear differences that would be weighted in favor of CSS just because of the way you chose to set it up, but I'm still not seeing a performance difference. I wonder if you've got some sort of issue with your graphics card on your system or something. Not sure why you're seeing a performance difference on your system. Can anyone else see a difference?

Very glad to hear that you're picking things up so quickly. In no time, you'll be animating just about anything you can dream up Thanks for being a club member! Happy tweening!

You're right about it being unnecessary (wasteful in fact) to call getChildren() twice like that. Blake did a great job of explaining what that line was doing and that it wasn't two parameters. It's not very readable (the original, not Blake's). The original could be simplified to: tl.remove( tl.getChildren().pop() ); That just grabs the children as an array and pop() will grab just the last one from that array, using it as the parameter for remove(). Does that clear things up?

You can change the handle size with "handleSize". You can customize the cursor using the methods provided: http://greensock.com/asdocs/transform/com/greensock/transform/TransformManager.html#customizeMoveCursor() http://greensock.com/asdocs/transform/com/greensock/transform/TransformManager.html#customizeRotationCursor() http://greensock.com/asdocs/transform/com/greensock/transform/TransformManager.html#customizeScaleCursor() Docs are at: http://greensock.com/asdocs/transform/

Good question. You could just alter your SVG artwork so that the single big circle is actually composed of two paths internally (but visually it looks like one). That way, MorphSVGPlugin doesn't have to fabricate an extra path to match up with the other circle. Here's my edited version for you: http://codepen.io/GreenSock/pen/186fec3bf0e30b3cab4a81b6f691f4a1/ Notice I had to set a shapeIndex as an array that has a number for each sub-path because one of the paths wasn't quite morphing in the way I wanted. I could have just edited the path data instead, but I found it easier to just tweak the shapeIndex. Totally up to you. Oh, and I tweaked the easing and cleaned up a few other minor things to simplify your animation code a tad. Does that help?

Yep, a linked list would be much better, but I've got some ideas about further optimization but I've gotta sketch it out and do some tests. As for the final value always going to 1, you just have to set the _calcEnd property of the Ease to true if you want to make it actually calculate the final value (typically that's a total waste of CPU cycles and can actually lead to glitches due to rare scenarios where the math spits back something like 0.9999997 which throws final renders off - that's why by default GSAP just assumes the value will be 1 when the tween is done).

That's great, Blake. I wouldn't exactly call that "very primative" I didn't quite understand your question about the "current segment for a linear ease". Do you just mean, for example, that at a progress of 0.5 (halfway through the tween/curve), you want to determine which Bezier segment that lands on given the fact that there could be an unlimited number of segments? If so, the general concept (at least in my mind) would be to pre-calculate the progress value for each anchor/node and then take whatever value that comes in (0.5 in this case) and find the corresponding segment (the value is between the start and end node progress values). Then you just plot the progress on that particular segment based on the ratio. Does that help at all?