In any discussion about animations, the GPU always comes up for good reason: anything that runs in the GPU will simply perform better in terms of UX and power consumption. If you hear the term “independent animation,” this refers to an animation that fully runs in the GPU. A “dependent animation” is one that runs on the UI thread.

In JavaScript, anything that you animate directly within setInterval, setTimeout, and requestAnimationFrame is a dependent animation, because you’re clearly doing all the work in code. This is unavoidable in many scenarios, like games, but then the point of the game is to play with graphics and animations so you’re not quite as worried about the GPU. It’s worth noting that at present, apps written in JavaScript don’t have access to the GPU outside of doing independent animations via CSS. Eventually I imagine that WebGL will become available which should change that story.

To run a CSS animation in the GPU, the key thing to remember is that you must be animating only the opacity and transform properties of an element. That’s it. You can actually do quite a bit with just these two properties: any kind of fades along with manipulations of size, 2D and 3D rotation, perspective, and so on. It just means that you need to be aware of how you and third-party libraries you might use define animations.

The animations library in WinJS.UI.Animation are all defined to be independent. The little bounce animation for a button click, pointerDown, for example, does a 97% scale transform, and its counterpart, pointerUp, restores the scale to 100%. You could, of course, achieve the same effect through the margin or padding properties, but then the animation would run in the UI thread.

In designing your dynamic UX, then, really become versed in what you can achieve with opacity and transform, and design around that. If, on occasion, you need dependent animations, that’s fine too. Just be careful to not overuse them to keep your app performing its best.

Comments are closed