GreenSock

Ah, okay, I see what you mean - that'd only happen when you're declaring your own GreenSockGlobals object and loading ColorPropsPlugin from GSAP 1.19.0 or 1.19.1. Here's a revised minified chunk of code that you can drop into your project to resolve things (it'll be in the next official release of GSAP as well, of course): /*! * VERSION: beta 1.5.1 * DATE: 2017-01-23 * UPDATES AND DOCS AT: http://greensock.com * * @license Copyright (c) 2008-2017, GreenSock. All rights reserved. * This work is subject to the terms at http://greensock.com/standard-license or for * Club GreenSock members, the software agreement that was issued with your membership. * * @author: Jack Doyle, jack@greensock.com **/ var _gsScope="undefined"!=typeof module&&module.exports&&"undefined"!=typeof global?global:this||window;(_gsScope._gsQueue||(_gsScope._gsQueue=[])).push(function(){"use strict";var a,b,c=/(\d|\.)+/g,d=/(?:\d|\-\d|\.\d|\-\.\d|\+=\d|\-=\d|\+=.\d|\-=\.\d)+/g,e={aqua:[0,255,255],lime:[0,255,0],silver:[192,192,192],black:[0,0,0],maroon:[128,0,0],teal:[0,128,128],blue:[0,0,255],navy:[0,0,128],white:[255,255,255],fuchsia:[255,0,255],olive:[128,128,0],yellow:[255,255,0],orange:[255,165,0],gray:[128,128,128],purple:[128,0,128],green:[0,128,0],red:[255,0,0],pink:[255,192,203],cyan:[0,255,255],transparent:[255,255,255,0]},f=function(a,b,c){return a=0>a?a+1:a>1?a-1:a,255*(1>6*a?b+(c-*a*6:.5>a?c:2>3*a?b+(c-*(2/3-a)*6:+.5|0},g=function(a,{var g,h,i,j,k,l,m,n,o,p,q;if(a)if("number"==typeof a)g=[a>>16,a>>8&255,255&a];else{if(","===a.charAt(a.length-1)&&(a=a.substr(0,a.length-1)),e[a])g=e[a];else if("#"===a.charAt(0))4===a.length&&(h=a.charAt(1),i=a.charAt(2),j=a.charAt(3),a="#"+h+h+i+i+j+j),a=parseInt(a.substr(1),16),g=[a>>16,a>>8&255,255&a];else if("hsl"===a.substr(0,3))if(g=q=a.match(c),{if(-1!==a.indexOf("="))return a.match(d)}else k=Number(g[0])%360/360,l=Number(g[1])/100,m=Number(g[2])/100,i=.5>=m?m*(l+1):m+l-m*l,h=2*m-i,g.length>3&&(g[3]=Number(a[3])),g[0]=f(k+1/3,h,i),g[1]=f(k,h,i),g[2]=f(k-1/3,h,i);else g=a.match(c)||e.transparent;g[0]=Number(g[0]),g[1]=Number(g[1]),g[2]=Number(g[2]),g.length>3&&(g[3]=Number(g[3]))}else g=e.black;return b&&!q&&(h=g[0]/255,i=g[1]/255,j=g[2]/255,n=Math.max(h,i,j),o=Math.min(h,i,j),m=(n+o)/2,n===o?k=l=0:(p=n-o,l=m>.5?p/(2-n-o):p/(n+o),k=n===h?(i-j)/p+(j>i?6:0):n===i?(j-h)/p+2:(h-i)/p+4,k*=60),g[0]=k+.5|0,g[1]=100*l+.5|0,g[2]=100*m+.5|0),g},h=function(a,{var c,d,e,f=(a+"").match(j)||[],h=0,i=f.length?"":a;for(c=0;c<f.length;c++)d=f[c],e=a.substr(h,a.indexOf(d,h)-h),h+=e.length+d.length,d=g(d,,3===d.length&&d.push(1),i+=e+(b?"hsla("+d[0]+","+d[1]+"%,"+d[2]+"%,"+d[3]:"rgba("+d.join(","))+")";return i+a.substr(h)},i=(_gsScope.GreenSockGlobals||_gsScope).TweenLite,j="(?:\\b(??:rgb|rgba|hsl|hsla)\\(.+?\\))|\\B#(?:[0-9a-f]{3}){1,2}\\b",k=_gsScope._gsDefine.plugin({propName:"colorProps",version:"1.5.1",priority:-1,API:2,global:!0,init:function(a,c,d,e){var f,h,i,j;this._target=a,this._proxy=h="NUMBER"===(c.format+"").toUpperCase()?{}:0;for(f in c)"format"!==f&&(h?(this._firstNumPT=i={_next:this._firstNumPT,t:a,p:f,f:"function"==typeof a[f]},h[f]="rgb("+g(i.f?a[f.indexOf("set")||"function"!=typeof a["get"+f.substr(3)]?f:"get"+f.substr(3)]():a[f]).join(",")+")",j=c[f],"function"==typeof j&&(j=j(e,a)),this._addTween(h,f,"get","number"==typeof j?"rgb("+g(j,!1).join(",")+")":j,f,null,null,):this._addTween(a,f,"get",c[f],f,null,null,b,e));return!0},set:function(a){var b,c=this._firstNumPT;for(this._super.setRatio.call(this,a);c;)b=g(this._proxy[c.p],!1),b=b[0]<<16|b[1]<<8|b[2],c.f?this._target[c.p](:this._target[c.p]=b,c=c._next}});for(a in e)j+="|"+a+"\\b";j=new RegExp(j+")","gi"),k.colorStringFilter=b=function(a){var b,c=a[0]+a[1];j.lastIndex=0,j.test(c)&&(b=-1!==c.indexOf("hsl(")||-1!==c.indexOf("hsla("),a[0]=h(a[0],,a[1]=h(a[1],)},i.defaultStringFilter||(i.defaultStringFilter=k.colorStringFilter),k.parseColor=g,a=k.prototype,a._firstNumPT=null,a._kill=function({for(var c,d=this._firstNumPT;d;)d.p in b?(d===a._firstNumPT&&(this._firstNumPT=d._next),c&&(c._next=d._next)):c=d,d=d._next;return this._super._kill(}}),_gsScope._gsDefine&&_gsScope._gsQueue.pop()(),function(a){"use strict";var b=function(){return(_gsScope.GreenSockGlobals||_gsScope)[a]};"function"==typeof define&&define.amd?define(["TweenLite"],:"undefined"!=typeof module&&module.exports&&(require("../TweenLite.js"),module.exports=b())}("ColorPropsPlugin"); Better?

Hm. I'm on a MacBook Pro. Didn't notice faint flickering on the whole browser window. Maybe a graphics card issue on your system? Do you have access to another system to test on?

Cool site! Let me guess - this is only a problem in Chrome, right? (Chrome recently added PointerEvents which have some strange behaviors) Two potential solutions to try: Update to GSAP 1.19.1. Set allowNativeTouchScrolling:false on your Draggable instance. Do either of those help?

You could place that empty path where the other one is, like d="m260,187v0". It's gotta morph from something somewhere

TweenMax.to() does work. I think the problem was that you were trying to set the transforms in different ways - with jQuery initially and then GSAP. For performance reasons, GSAP caches transform-related values so that it's super fast to lookup on subsequent animations, but you were circumventing GSAP and using jQuery. You can tell GSAP to force the parsing of the transform (again) rather than using the cached values by just setting parseTransform:true in your tween. Does that clear things up? I'd definitely recommend always using GSAP to do transform-related stuff. It's much faster than jQuery and allows independent control of each transform component (x, y, rotation, scaleX, scaleY, skewX, skewY, etc.).

Hm, I just tried with your file and didn't get any errors (well, once I removed the bottom part that referenced jQuery...because I was trying to isolate things with GSAP and didn't want a jQuery dependency). I tried a few different tweens. Zero errors. Can you please provide a reduced test case that shows the error happening?

I assume this is what you want?: http://codepen.io/anon/pen/GrmLVe?editors=0010

Hm, I don't see anywhere that'd cause that problem - could you please provide a reduced test case so we can poke around and see what's going on? It almost sounds like maybe the code you're pasting is missing some stuff or nested incorrectly or something weird like that. Very tough to troubleshoot blind, though. Any chance you could shoot us a codepen or something we can test ourselves?

Are you talking about the vertical lines sometimes looking like they get fuzzy/sharp/fuzzy/sharp as things are growing? If so, that appears to be just an issue with how Firefox handles sub-pixel rendering and scaling of rasters. Imagine a single column of pixels that lands halfway between two columns of the screen's pixels - how is it supposed to make that look? Some browsers kinda fuzz the line, some make it snap to a row (which can appear jittery). See what I mean? But maybe that's not what you were seeing. I didn't notice any other flickering when I looked in Firefox.

Great feedback everybody. I totally understand why it's common for devs to suggest using CSS for everything until you really need something that only GSAP can deliver (shape morphing? custom easing? physics? canvas? there's a long list...). After all, CSS requires no loading of a 3rd party library, and it has a reputation for being fast. Who'd argue with that? Well, I would (though not always). Here are some things to consider... Why not just use CSS/WAAPI until a GSAP-specific feature is needed? A very large global company (that shall remain unnamed) recently asked me about this as they’re figuring out how to equip their teams for animations. Here’s what I told them: What is it worth to your team to have a consistent animation API to work with day-to-day, on all their sites? What would it cost in terms of training, documentation, etc. to have your teams split their efforts across multiple toolsets (CSS/WAAPI for some, GSAP for other situations)? Remember, GSAP can be used to animate ANYTHING including canvas, WebGL, scroll position, morphing, physics, SVG, etc. whereas CSS/WAAPI is just for DOM elements. You could learn GSAP and be done. No need to shift gears constantly. How many times will someone on your team try animating sometimes hing with CSS/WAAPI and then bump into a wall, like “oh, shoot, I forgot that I can’t do an elastic or bounce ease. Does this mean I have to ‘upgrade’ this particular animation to use GSAP? Will my boss get mad at me? Ah, screw it, I’ll just use the more boring ease and keep it in CSS/WAAPI so I don’t get in trouble.” If you use GSAP, you protect your team from ever running into that wall because GSAP can do *everything* CSS/WAAPI can do plus a lot more. At the end of the day, you probably want your animators empowered to create amazing effects, not managing the technological deficiencies and gauging when they have sufficient reason to jump to GSAP. If you build some animations with CSS/WAAPI and some with GSAP, fast forward a few months or a year when you need to add a new effect to a page that might require some advanced features in the old/existing animations. For example, on the main GSAP page, there’s a pretty complex animation at the top. What if your team builds something like that in CSS/WAAPI or some other library and then you need to add a modal window (like what our “Download” button triggers) and it should pause or gradually slow down those animations in the background to 1/10th the normal speed, and then speed up again when the user dismisses the modal? Uh oh. Or maybe you want to add something to the middle of that animation that does a morph or uses an advanced ease that CSS/WAAPI simply cannot accommodate - that’s going to be a major pain to try to shoe-horn in there. If, on the other hand, your team just uses GSAP consistently throughout your sites, it’s a breeze to handle things like this with a few lines of code. It makes future edits far less painful, saving you time and money. Animation is an inherently experimental process. It never looks right the first time. It’s all about playing with the timings, the eases, etc. I’m pretty confident that if you have your team use GSAP for a while and then CSS/WAAPI for a while, they’ll report that it’s much faster and easier to “play” with animations in GSAP. Far more easing options, and the API is more concise and robust. If I was managing a team of animators and I wanted them to deliver innovative, expressive animations, I’d want to equip them with tools that are the most conducive to that end. Obviously I’d argue GSAP has the advantage, hands-down (but don’t take my word for it - ask around and see what experts say who are deeply familiar with GSAP and CSS/WAAPI). Compatibility & Other Issues Two of the BIGGEST problems I see with CSS/WAAPI: Easing. Ouch! You’re stuck with cubic bezier. No elastic, no bounce, no wiggle, no rough, etc. Even most Penner eases can’t be reproduced accurately. Nothing like http://greensock.com/custom-ease/ Independent transforms. The most commonly animated things are position, rotation, and scale (all transform-related) but you cannot control them independently with CSS or WAAPI. For example, try moving something and halfway through start rotating it and stagger a scale at the end. No-can-do. Animators NEED to be able to independently control these things in their animations. By the way, the to deficiencies above are what make it virtually impossible to use CSS/WAAPI under the hood in GSAP. If/When you run into a bug, GSAP can have a fix in a matter of hours/days whereas with CSS/WAAPI, you’ll be stuck waiting for the browser(s) to fix it. Could take months. Heck, I just stumbled across a bug today in Chrome that hasn’t been fixed since being reported in 2013! That’s no fun when you’ve got deadlines and a site to launch. Compatibility (enough said). GSAP solves a bunch of inconsistencies and bugs in browsers. You just write your animation code and let GSAP worry about making it "just work". Isn’t GSAP really “heavy”? It’s all relative. A single image on many sites is heavier. This is another very commonly misunderstood issue... It’s a ONE-TIME cost, then it’s cached and free on every page thereafter. It’s on 2.5 million sites, so it's pervasively cached. Point at the CDN, and it'd completely eliminate the load time issue for anyone who has visited a GSAP-powered site previously. Even with the initial load (assuming it's not cached), there’s a very good chance you’d see a net positive effect on load times overall across a site because the unique animation code on each page would likely be less due to the compact GSAP API. In other words, if you’ve got 5,000 pages and each one has even 10% more animation code due to WAAPI’s (or CSS’s) more verbose syntax, and each page averages 15kb of animation code, GSAP would actually save you about 7,465kb…for one visit across those pages! Multiply that by however many thousands upon thousands of page loads you get across those sites, and the savings can be immense. The “real-world” cost for the average user time-wise is perhaps a few hundred milliseconds…once, and then never again. It’s the only robust animation library that’s on every major ad network’s CDN and exempt from file size calculations (meaning it’s FREE in terms of kb). Performance-wise, you'd probably never notice a real-world difference. In some scenarios, GSAP is actually faster. CSS/WAAPI has an edge in a very particular scenario (if the main thread is really bogged down and you're ONLY animating transforms or opacity...and only on certain devices/browsers). If you animate another property at the same time, that advantage evaporates (moves everything back to the main thread). But again, in the real world it's doubtful you'd ever notice a difference. I could say a lot more, but I'll hold my tongue. It's easy to fall into the "well CSS is baked into the browser and doesn't cost anything to load, so of course I should use them" mindset and miss a lot of the factors that could affect you longer-term. This isn't meant to bash CSS/WAAPI at all. I think there's a time and place for them, without a doubt. As others have said, simple rollovers and things like that are a perfect use case (though it's totally fine to do with GSAP instead, especially if you're already loading it). Other reference articles: http://greensock.com/why-gsap/ http://greensock.com/kilobyte-conundrum/ Thanks for asking the question and giving us a chance to address the topic. Happy tweening!

A few thoughts: I mentioned it can take up to several seconds after the last tween on an element completes before it's removed from that lookup, but you set your timeout to 0.5 seconds. Maybe try waiting longer to check? It looks like you've got something in an onUpdate that's attempting to reference a property of a null object (unrelated to GSAP). Perhaps that's halting execution, thus freezing things where they were (and the lookup isn't emptied). There certainly could be a bug somewhere, but it's very difficult to troubleshoot blind and we've had quite a few GC experts look at GSAP and confirm that it's rock solid. Plus yours is the only report we've gotten about anything like this (that I can remember), despite GSAP being used on over 2.5 million sites, vetted (and endorsed) by Google and all the major ad networks, used by most of the world's biggest brands, etc. I'm not saying that means there's not a bug - I'm just surprised that if there was some underlying GC issue someone else hasn't brought it to our attention. Again, it'd be really, really helpful if you could provide a reduced test case that can run in a browser and isn't dependent on your framework. Possible? Perhaps there's a very particular context in which this happens.

It certainly seems like a Firefox rendering issue. Have you tried using a png (or any raster image) instead of an SVG? Keep in mind that the browser can't really GPU-accelerate SVG elements. You're asking a LOT of the browser in terms of calculating all those pixels 60 times per second. Some browsers use certain algorithms based on the size of the image, like if it's less than a certain number of pixels it does one thing but greater than that, another. So perhaps that "lag" you notice is when it hits a threshold in Firefox and it's switching to a different rendering technique. I'm also curious if you tried using a regular img element instead of a background-image. Browsers sometimes use different rendering algorithms for those (example: http://greensock.com/will-change).

Blake's solution is a good one of course. Just to clarify, though, GSAP works with numbers and strings (that contain numbers) But a plugin can do just about anything based on your own custom logic.

Here are two options I whipped together: Using wiggles (more "swarmy") http://codepen.io/GreenSock/pen/fd44a028769d09548f7ce9c2ca6ed02c/ (noticed I changed the cy to center the dots to begin with) And a recursive tweening action in a function that calls itself onComplete (more "just moves to random spots"): http://codepen.io/GreenSock/pen/d614fc7ea7b00eda57f752ea5b0ac792/ Do those help?

That looks like the lookup table that gets cleared out a few seconds after the last tween on that element completes (or is killed). Nothing should stay in there forever. I wonder if you just didn't wait long enough for it to get cleared out before taking your snapshot. (?)

Frankly I doubt you'd notice any difference. However, technically if you put it in a wrapper div and it is layerized (which can be done by applying a 3D transform, for example), it should force that to the GPU as one layer and then the opacity changes could affect just that layer (thus more performant...but only slightly). This also requires that nothing in the inner-divs is changing/animating (otherwise, it'd have to keep shoving new layer info to the GPU on each tick and make things run slower). Does that help?

Ah yes, I think I know what's happening - for performance reasons, CSSPlugin just stores ONE variable that points to the most-recent element whose CSS-related values were animated. It's replaced every time. It does **not** store a reference to every element tweened (ever). That'd explain the behavior you described. In terms of memory management, it would never cause a buildup because it's constantly swapped out. But yes, it does point to a single element (the most recently animated one). If that's a problem for you, you could just make it point to something else by doing a CSS tween on a different element, even one that doesn't change anything, like: TweenMax.set(otherElement, {x:"+=0"}); //does nothing Does that help?

Ah, okay, then things should automatically be released for GC within a relatively short time (typically a few seconds, though the browser decides when it wants to do the actual sweep). I think what was confusing was in your original post, you said "...w/o breaking any follow up usages of the same TweenMax instance" which sounds like you were keeping a reference of an instance (to reuse).

Maybe it'd help if I explain how it works in GSAP... When a tween renders for the first time (which is immediately with set()), it records starting/ending values for the target, and of course it must reference the target as well. Some of that is done in CSSPlugin if you're affecting CSS-related properties. Internally, GSAP maintains a lookup table that makes it super fast to find the tweens of a particular target (for overwriting). When the tween is done, it will flag itself as being eligible for garbage collection. Roughly every 2 seconds or so, GSAP clears out that lookup table of gc-eligible tweens. It's up to the browser to dump it after that, but GSAP removes its internal references to it (unless it's in a timeline, of course, which hasn't finished yet either). Are you maintaining a reference to the TweenMax instance? I assume so (your original post indicated that you want to reuse it, so you must be hanging on to it). If so, it only makes sense that it wouldn't release references to that DOM element. Otherwise, how would it work when you press that tween back into service, like tween.play(0.5)? In order for TweenMax to automatically kill its own tweens and references of elements that aren't in the DOM anymore, we'd have to add performance-sucking code that'd constantly check that stuff (loop through every target of every tween...."are you still in the DOM?"). See what I mean? I don't think that'd be a good thing. If you want to kill the tweens of a particular element, that's totally doable with TweenLite.killTweensOf(). Does any of that help?

I'm a little confused - you want to keep the tween (which specifically animates a particular element), but you don't want that tween to reference the target element (when you tell it not to)? You want to be able to rip out all the references inside the tween...but then when you go to reuse that tween instance, what do you expect will happen? How will it know what to tween, what the starting values should be, etc.? Are you saying you want to then feed in that reference again and have the tween go through all of its internal recordings and re-populate all that data? And you said "...so tearing down the whole TweenMax is not an option" - are you saying that's because the tween targets multiple objects, some that are in the DOM and some that aren't (anymore)? It may not be useful here, but do you know about the TweenLite.killTweensOf() method?

You can't really re-target a tween (swap out its target for something else). I know you're trying to optimize performance by reusing an instance, but that'd actually deliver WORSE performance because in order to be as fast and efficient as possible, GSAP records values internally based on the target, so it'd have to scrub all of that clean before re-recording new info for a new target. It'd be faster to just let that old one die/expire, and create a new tween instance when you need one for a new target. Does that answer your question?

Oh, sure, that's entirely possible to do but I don't personally have time to do it all for you. Sorry. Way too much on my plate right now Maybe someone else wants to tackle that. Typically we try to keep these forums focused on GSAP-specific questions (not so much "would you build this for me?" type of things). Happy tweening!