Grow your CSS skills. Land your dream job.

[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."

Slides

Comments

  1. Russ
    Permalink to comment#

    He also demoed a useful feature of Safari: Enabling the Debug menu and turning Show Composition Borders on. Which showed the number of times a texture is sent to the GPU.

  2. The Popcorn demo from the Montage team is a great demo of how smooth you can render a UI.

    I was stoked to see that in his talk! :)

  3. Permalink to comment#

    Chris, is there a video to this article? In viewing the slides I find it very interesting!

  4. Morgan
    Permalink to comment#

    This is exactly why Opera switched to Webkit. Developers just can’t be bothered to add prefixes for other browsers even if it’s easily fixed with mix-ins..

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".