'The GPU bottleneck is a reality on heavyload animations.'

[erikb]

http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/#comment-1112648601

> The GPU bottleneck is a reality on heavyload animations.

 

I think it would be helpful to explore this claim in more detail so as to help developers understand which tools make sense in which scenarios.

[erikb]

For example, see this problem reported on iOS devices:

http://stackoverflow.com/questions/17824060/ios-safari-runs-out-of-memory-with-webkit-transform

[GreenSock]

Yeah, this has mostly to do with layer creation on the GPU. The GPU has limited memory, and in most situations it's perfectly adequate but if, for example, you're animating 500 things and each one is promoted to a layer on the GPU (which typically happens whenever a 3D transform gets applied), you can quickly run into a situation where the GPU actually becomes the bottleneck and the very thing that's supposed to deliver improved performance (layer promotion on the GPU) ends up killing performance. 

 

You do indeed get better performance if you can promote your animating elements to their own layers on the GPU as long as it's only a few. That's usually the case in the examples that people write about on the web. But if you look at the speed test we created at http://www.greensock.com/js/speed.html and compare the scale/translate ones with the regular (top/left/width/height) ones, you'll notice that as you crank up the number of dots, performance for the transform-driven ones really starts to fall off and the top/left/width/height animations do much better. 

 

Also notice the initial lag in the start of the animation - that's because it takes time for the browser to CREATE the layers on the GPU (none of this has anything to do with GSAP, by the way). If you just animate top/left/width/height, no layers are created, thus startup is faster.

 

Animating top/left/width/height also forces things to land on whole pixel values whereas transforms can do sub-pixel rendering. At slow speeds, sub-pixel rendering can deliver smoother-looking motion, but pixel-snapping can keep things from getting a little fuzzy and text antialiasing doesn't shift like it often does when things break from standard 2D rendering in the browser to being composited on the GPU as a 3D element. Imagine a single-pixel horizontal line that is positioned inbetween two rows of screen pixels - how would the screen render that? Cases like this is what can cause some "fuzzing". 

 

So while the article on html5rocks is great and points out some valuable information, it's important to keep in mind that it's not always smoother to animate with transforms instead of top/left. The Pauls do mention some caveats, but I think most people blow right past them and walk away thinking that the article's point is to ultimately ALWAYS animate with transforms, but I'm pretty sure that's not exactly what Paul Irish and Paul Lewis intended to say. 

 

In general, I'd agree that animating with transforms instead of top/left is probably better, but I'd encourage folks to do their own tests in their particular scenarios to see which one is best.