GreenSock

Hm, pretty tough to troubleshoot blind but it sounds like more of a rendering issue related to how the browser is baking all those pixels Have you tried setting will-change: transform in the CSS on the element(s) you're animating? I generally don't recommend that because...well...read this: http://greensock.com/will-change/ but according to some choices Chrome is making (which I completely disagree with), in some situations like this it could be advantageous (and in other situations, it'll have the opposite effect).

Weird. It copied/pasted fine from your post in the forums here. Not sure what the issue could be. Let me know if you've got any ideas.

Yeah, the performance stuff is an obsession of mine, and I totally see what you mean about some opportunities in your code to eek out better results. In fact, it could probably be made to be 10x or more faster at runtime. I don't have a lot of time right now to show you all of it, but the general idea is that I've got some methods that plot points along the curve (at small increments) and then significantly reduce the number of those points by tracing it and using as few as possible (based on a threshold of deviation). Then, that SVG is used for the CustomEase. CustomEase, in turn, has its own optimizations to create a super-fast lookup table of sorts that leans on linear interpolation. It's not quite as advanced, but there's actually a CustomEase.getSVGData() method you could use, and just feed in an object that has a "getRatio()" method (all GSAP eases have that) and it'll plot all the points and spit back an SVG path data for you. That could be used to create your own CustomEase instance accordingly. So, again, you'd just need to modularize your code so that there's an object with a getRatio() that accepts a progress value between 0 and 1 and then spits back the adjusted/eased value (also typically between 0 and 1, but not always, like for Elastic, etc.) https://greensock.com/docs/#/HTML5/GSAP/Easing/CustomEase/getSVGData/

@OSUblake, are you saying you pasted that into the visualizer itself and it didn't look like this?: http://d.pr/i/ZeO0 Or are you just saying that you did the URL parameter thing and it didn't work? The URL parameter is supposed to be the "cleaned" version of the data (after conversion that happens when you paste it in).

Cool, thanks for sharing!

Sorry, that would simply be impossible to wedge into the API like that. I'm curious why it's problematic to have in the regular vars object as it is now? In other words, what is it exactly that makes it difficult to store the data? Hint: you can define eases as strings if that's easier for you. Like ease:"Linear.easeNone"

Hm, it looks like your code is only creating a Draggable for the very first one. Right? Seems perfectly draggable to me And you're keeping it within the bounds of its parent. You're doing a document.querySelector('.drag') once (and of course that only returns one element), and creating a draggable instance for its children. But each of your nav elements are nested in a different ".drag" element. See what I mean? Sorry, I'm not an Angular person and I don't have a lot of time to rework the demo, but hopefully that'll get you moving in the right direction.

Just curious - those kb weights are uncompressed, right? It was jut a little confusing because TweenMax is less than 40kb. Anyway, yes, we're moving toward building stuff in ES6 to better accommodate situations like this. If you've got specific suggestions for how we could do more of a band-aid fix in the mean time with the current codebase, please let us know. (Like a pull request)

Sure, I just changed .../latest/... to .../1.19.1/... in the CDN links: https://plnkr.co/edit/9nFw7joNcFbFGPWwC06s?p=preview For convenience I also added the allowNativeTouchScrolling:false to the Draggable.create(), though that's probably not necessary. Very happy to hear you're spreading the word about GSAP among the ng2 community. Let us know if you need anything else. Happy tweening!

Let me guess: you're looking in Chrome? Yeah, they implemented pointer events recently along with some bugs (thanks Chrome!). I'll spare you the explanation (unless you request it), but you should be able to fix it by either using the latest version of GSAP/Draggable (I noticed you're linking to "latest" in the CDN, but the CDN provider refuses to update that directory for the past year or more, so it's best to link directly to 1.19.1) -OR- by setting: allowNativeTouchScrolling:false.

Howdy atomboy. Thanks for being a club member! I must admit I'm not terribly familiar with all the build systems, packagers, bundlers, transpilers, etc. available (I know there are MANY), but we've done several things to make GSAP workable in most (if not all) of them. The latest version (1.19.1) can be installed via NPM with "npm install gsap" and then you can: //typical import import {TweenMax, Power2, TimelineLite} from "gsap"; //or get to the parts that aren't included inside TweenMax (works as of 1.19.1): import Draggable from "gsap/Draggable"; import ScrollToPlugin from "gsap/ScrollToPlugin"; Is that what you're looking for? Disclaimer: GSAP is not authored in official ES6 modules, but we do hope to move in that direction once we verify there's not too much of a performance tradeoff (I've seen some articles that are a little scary in that regard). It's a big project to rewrite it all in ES6, so it might take some time. Thanks for your patience.

ThrowPropsPlugin isn't intended to accommodate constantly changing distance/velocity inputs on-the-fly, but you could absolutely create new tweens when the values changed and it'll pick right up where it left off. If you're literally doing that like 30-60 times every second, it wouldn't make a lot of sense - in that case you're not really looking for a tweening engine; you're looking for a physics engine. Rendering loops for a physics engine vs. a tweening engine are radically different. There are pros and cons of each. But yeah, the rendering loop for ThrowPropsPlugin (the part that runs on every tick) was roughly 2-10x faster (depending on the browser). That probably doesn't matter much, though, real-world-wise unless you're pushing things really hard and animating a ton of elements simultaneously.

Yeah, it does look slightly fuzzy. Thanks Chrome! From what I can tell, it's unrelated to GSAP - any percentage-based transform makes things blurry. Sheesh, Chrome used to be the best browser by far...lately they've been implementing all kinds of weird stuff that makes things look terrible or behave poorly. Another example: http://greensock.com/will-change I'd encourage folks to let them know whenever you see stuff like this so that they can gauge how many people actually care.

Oh, then you're not morphing - you can just set visibility:"hidden", right? Or autoAlpha:0? Do a set() or a to() with a zero duration. Make sense?

Thanks for sharing, killroy. It looks a lot like what ThrowPropsPlugin does, but your implementation requires a lot more processing on each tick. Are you familiar with ThrowPropsPlugin? It'll let you set an initial velocity (heck, it'll even track moment-by-moment velocity of any property) and smoothly glide to a stop at any destination value, conserving initial velocity. So like your spinning wheel, you can have it naturally stop at any spot. In fact, it'll even figure out the natural stopping point and let you alter that from the very beginning. Even feed in an array of potential ending values and it'll select the closest natural one based on initial velocity. Anyway, perhaps I misunderstood the goal of the technique you shared. Is there a particular benefit it delivers that isn't possible with ThrowPropsPlugin?

I totally see what you're saying, Mango. At first, it may seem odd. But over the years, we've had many, many people ask us about an ease that returns to its starting values. They complained that eases shouldn't always HAVE to go to an end value. A "wiggle" is a perfect example - typically that effect results in whatever's wiggling returning to its end state (like a button that says "click me"). Furthermore, let's say for a moment that we did make make it go to the end value you describe in your tween - how would you control the strength of the wiggle? Remember, an ease is all about ratios, not hard values. So, for example, if rotation starts at 0 and you define a wiggle ease to rotation:30, would it first shoot way past 30 (to 60? 50? 100?) and go back down, and oscillate back and forth to land at 30? How exactly would you define all that? Furthermore, what if you did want to get the most common use, which is to return to the original state - would it be intuitive to "tween" to rotation:0 if it's already at 0 (no change)? For a lot of people, that'd seem very odd indeed. I could explore the possibility of adding an option to the ease like endAtStart:false, but we'd still have the problem of determining how far the "squiggles" in that line go. It certainly complicates things quite a bit and would likely require a revamp of the API.

Yep, if your goal is to get back to the beginning state, that sounds like the right approach (set timeline.progress(0) quickly before doing your other stuff). Let us know if you run into any other issues.

Yep, TweenMax has all of those, so they should all be available to you. It's also fine to just load things from the CDN (in fact, I'd generally recommend that because you instantly get the benefits of ubiquitous caching).

Good question. The package.json file defines the "main" as TweenMax.js, and TweenMax contains all of the following (as exports): Core TweenLite TweenMax TimelineLite TimelineMax Plugins CSSPlugin AttrPlugin BezierPlugin DirectionalRotationPlugin RoundPropsPlugin Eases (everything in EasePack) Power0 Power1 Power2 Power3 Power4 Back Bounce Circ Cubic Elastic Expo Linear Quad Quart Quint RoughEase Sine Strong SlowMo SteppedEase TweenMax is intended to be the feature-rich, "gimme-the-essentials-plus-some-goodies-without-having-to-load-multiple-files" package. As of 1.19.1, if you're using NPM you can reference most of the individual files, like require("gsap/TweenLite") and require("gsap/CSSPlugin"), but the eases aren't all broken out like that, otherwise it'd get pretty nuts with the number of files. We're aiming to do an ES6 rewrite later this year, but that's a much bigger task and I need to do more testing to make sure there won't be too much of a performance drop (I've read that a lot of these ES6 options are actually slower in the browser which is certainly a concern for us).

Unfortunately, pseudo elements aren't part of the DOM, so as far as I know it's impossible to edit their individual styles directly. You can animate the CSS rules themselves (which is what CSSRulePlugin is for), but not the elements (or element.style). I'd recommend avoiding pseudo elements if your goal is to animate things.

Ah, got it. Ha. Well double-thanks

Ah, that's because it looks like you're a "Simply Green" member. ThrowPropsPlugin is for "Shockingly Green" and "Business Green" members

I'm pretty sure that the only difference is "unpacking" the pixels. Either way, the browser has to grab all those pixels and get them on the screen. The format is just a delivery mechanism to get it through the Internet pipes to the browser So at runtime, it shouldn't make any difference at all. Perhaps one format is slightly faster than the other to decompress but I'd be shocked if it were noticeable in the real-world. But if you're comparing JPG/PNG to SVG, then SVG is definitely slower for the browser to render. The GPU can keep a raster image and shove pixels around very easily - with SVG, the pixels need to be fabricated on-the-fly whenever resizing/movement occurs (typically at least).

It's fine to just use for your own personal use as a convenience, but no, we're not prepared to sublicense the ease visualizer for use in 3rd party applications. It's not officially part of the codebase that we distribute and license at this point. That's a different ball of wax that could have broader implications (especially support, plus you'd need to have protections in place to help prevent giving folks free access to CustomEase that's for GreenSock account holders only). We built the Ease Visualizer as a service to our users and to help drive traffic to our site as well. If anyone wants to sublicense the visualizer, feel free to reach out to us directly and we can discuss terms. It'd require some extra effort on our part to refine the code and figure out what it might take to support that type of usage, but we're certainly willing to chat with folks who have interest in getting behind that. The other thread you linked to mentioned a different MIT-licensed curve editor which is probably totally fine to use in your app (we have nothing to do with that tool, but OSUblake said it was MIT-licensed). Maybe that's what you were talking about this whole time

Yep, that was a little confusing. Sorry about that - it just has to do with the onUpdate not firing for the immediateRender in that vary particular case (a fromTo() tween). The "from" vars are used under the hood to render the initial state; since your onUpdate was in the "to" vars (as it should generally be), it wasn't along for the ride on that initial render. I'll work around that in the next release, but in the mean time it should be as simple as adding the onUpdate to the "from" vars. tl.fromTo(... {onUpdate:yourFunc, ...}, {onUpdate:yourFunc, ...}); Better?