Animation Acceleration

Precursor had a problem.

Our large sweeping animations for the menu were becoming more expensive to animate as we added more features. Last week I rewrote the CLJS and LESS handling those animations while focusing on a few things:

Don't animate everything all at once.
If you have one big animation that's not performing well, try breaking it into smaller bits, and then cascade them. When the above menu opens, several things happen at once: the canvas shrinks, the background shrinks, the menu items slide in, etc. These used to happen all at once, so I added noticeable delays between each.

Animate things individually.
I split visual elements into their own layers when possible. The canvas background is a good example—I detached it from the canvas and made it a sibling in DOM. Now it gets animated as a separate layer and doesn't directly affect the canvas.

Use keyframes for better control.
I switched from transitions to keyframes so I could time things more precisely. Now I can tweak movement and speed until I find a good balance. Best of all, I wrote these as functions, so it'll be easy to come back later and improve even more.

Avoid animations when possible.
The menu animation was affecting colors in the canvas and chat. The background changes significantly, so colors had to change to adjust contrast. Now I just use white with specific opacity levels to get the appearance I want on both backgrounds, using the same exact RGBA values. No transition required.

There's a lot more that made this refactor a success, but these are a few of the more important parts. The whole process made the menu much snappier and especially improved performance for iOS and Firefox. It's not perfect yet, but now that I have a system, it'll continue getting better and better!

That's how we solved it.

More by Danny King

View profile