[W3Conf] Ariya Hidayat: “Fluid User Interface with Hardware Acceleration”

Published by Chris Coyier

Ariya Hidayat (@ariyahidayat) works at Sencha and created PhantomJS and Esprima. He talked about front end web performance.

These are my notes from his presentation at W3Conf in San Francisco as part of this live blog series.

Oversimplified advice: "Use translate3d for hardware acceleration."

Browsers are complicated: User Interface - Browser Engine - Render Engine - Graphics Stack - JavaScript Engine - Networking Engine.

Getting content to pixels is complicated too. Painting to the screen is only the last step in a long chain. We're mostly familiar with the DOM Tree, but there is also a Render Tree.

Style recalculations are easy (e.g. changing background color). Layout changes are more difficult and thus slower / "more expensive" (e.g. changing positioning of an element). There are lots of properties that change layout.

This demo (add boxes to slow down performance easily).

There are varying expenses to different brushes/fills. No fill is easy, gradients are harder, textures hardest. This concept applies to all kinds of properties. For instance CSS transforms: scaling is easier than dealing with perspective.

GPU's are optimized for games. Less-so for simple things like lines (Call of Duty doesn't need straight horizontal lines). The web doesn't have predictable content (like games do). The web is mostly text. Games are mostly images.

GPUs = Low memory; Lots of processing power; Data transfer is the bottleneck; Requires a good amount of power.

So how do we take a GPU that is optimized for games and use it on the web?

Fluid animation is a huge goal on the web. So: push as much of it to the GPU as you can. Less efficient = loop over and move a box. More efficient, put box in buffer and move buffer. Good example of this is Falling Leaves demo by WebKit. Makes it the job of the compositor to figure out where leaves are.

translateZ(0) isn't needed if you're already using animation.

  • Doesn't require re-upload to GPU = opacity, position, size, filter
  • Does require re-upload to GPU = everything else (avoid!)

Cool things:

"It's not just the speed of the car, it's the traffic conditions."

Avoid overcapacity.

If you change color, that's one of the things that requires re-upload and thus isn't great for performance. But there is a trick! It uses twice as much memory, but you can make it smooth.

More info on all of this: Jank Busters.

"Graphics programming is full of tricks. It always will be."