Tom Wiltzius on web.dev

Accelerated Rendering in Chrome

2013-03-11T00:00:00Z

Introduction #

For most web developers the fundamental model of a web page is the DOM. Rendering is the often obscure process of turning this representation of a page into a picture on the screen. Modern browsers have changed the way rendering works in recent years to take advantage of graphics cards: this is often vaguely referred to as “hardware acceleration”. When talking about a normal web page (i.e. not Canvas2D or WebGL), what does that term really mean? This article explains the basic model that underpins hardware accelerated rendering of web content in Chrome.

Big, Fatty Caveats #

We’re talking about WebKit here, and more specifically we’re talking about the Chromium port of WebKit. This article covers implementation details of Chrome, not web platform features. The web platform and standards don’t codify this level of implementation detail, so there are no guarantees anything in this article will apply to other browsers, but knowledge of internals can nevertheless be useful for advanced debugging and performance tuning.

Also, note that this entire article is discussing a core piece of Chrome’s rendering architecture that’s changing very fast. This article attempts to cover only stuff that’s unlikely to change, but no guarantees that it’ll all still apply in six months.

It’s important to understand that Chrome has had two different rendering paths for a while now: the hardware-accelerated path and the older software path. As of this writing all pages go down the hardware accelerated path on Windows, ChromeOS, and Chrome for Android. On Mac and Linux only pages that need compositing for some of their content go down the accelerated path (see below for more on what would require compositing), but soon all pages will go down the accelerated path there, too.

Lastly, we’re peeking under the hood of the rendering engine and looking at features of it that have a big impact on performance. When trying to improve the performance of your own site it can be helpful to understand the layer model, but it’s also easy to shoot yourself in the foot: layers are useful constructs, but creating lots of them can introduce overhead throughout the graphics stack. Consider yourself forewarned!

From the DOM to the Screen #

Introducing Layers #

Once a page is loaded and parsed, it's represented in the browser as a structure many web developers are familiar with: DOM. When rendering a page, however, the browser has a series of intermediate representations that aren’t directly exposed to developers. The most important of these structures is a layer.

In Chrome there are actually several different types of layers: RenderLayers, which are responsible for subtrees of the DOM, and GraphicsLayers, which are responsible for subtrees of RenderLayers. The latter is most interesting to us here, because GraphicsLayers are what get uploaded to the GPU as textures. I’ll just say “layer” from here on out to mean GraphicsLayer.

Quick aside on GPU terminology: what’s a texture? Think of it as a bitmap image that’s moved from main memory (i.e. RAM) to video memory (i.e. VRAM, on your GPU). Once it’s on the GPU, you can map it to a mesh geometry -- in video games or CAD programs, this technique is used to give skeletal 3D models “skin.” Chrome uses textures to get chunks of web page content onto the GPU. Textures can be cheaply mapped to different positions and transformations by applying them to a really simple rectangular mesh. This is how 3D CSS works, and it’s also great for fast scrolling -- but more on both of these later.

Let’s look at a couple examples to illustrate the layer concept.

A very useful tool when studying layers in Chrome is the “show composited layer borders” flag in the settings (i.e. little cog icon) in Dev Tools, under the “rendering” heading. It very simply highlights where layers are on-screen. Let’s turn it on. These screenshots and examples are all taken from the latest Chrome Canary, Chrome 27 at the time of this writing.

Figure 1: A single-layer page #

<!doctype html>
<html>
<body>
  <div>I am a strange root.</div>
</body>
</html>

Screenshot of composited layer render borders around the page's base layer

This page has just one layer. The blue grid represents tiles, which you can think of as sub-units of a layer that Chrome uses to upload parts of a large layer at a time to the GPU. They aren’t really important here.

Figure 2: An element in its own layer #

<!doctype html>
<html>
<body>
  <div style="transform: rotateY(30deg) rotateX(-30deg); width: 200px;">
    I am a strange root.
  </div>
</body>
</html>

Screenshot of rotated layer's render borders

By putting a 3D CSS property on the <div> that rotates it, we can see what it looks like when an element gets its own layer: note the orange border, which outlines a layer in this view.

Layer Creation Criteria #

What else gets its own layer? Chrome’s heuristics here have evolved over time and continue to, but currently any of the following trigger layer creation:

3D or perspective transform CSS properties
<video> elements using accelerated video decoding
<canvas> elements with a 3D (WebGL) context or accelerated 2D context
Composited plugins (i.e. Flash)
Elements with CSS animation for their opacity or using an animated transform
Elements with accelerated CSS filters
Element has a descendant that has a compositing layer (in other words if the element has a child element that’s in its own layer)
Element has a sibling with a lower z-index which has a compositing layer (in other words the it’s rendered on top of a composited layer)

Practical Implications: Animation #

We can move layers around, too, which makes them very useful for animation.

Figure 3: Animated Layers #

<!doctype html>
<html>
<head>
  <style>
  div {
    animation-duration: 5s;
    animation-name: slide;
    animation-iteration-count: infinite;
    animation-direction: alternate;
    width: 200px;
    height: 200px;
    margin: 100px;
    background-color: gray;
  }
  @keyframes slide {
    from {
      transform: rotate(0deg);
    }
    to {
      transform: rotate(120deg);
    }
  }
  </style>
</head>
<body>
  <div>I am a strange root.</div>
</body>
</html>

As mentioned earlier, layers are really useful for moving around static web content. In the basic case, Chrome paints the contents of a layer into a software bitmap before uploading it to the GPU as a texture. If that content doesn’t change in the future, it doesn’t need to be repainted. This is a Good Thing: repainting takes time that can be spent on other stuff, like running JavaScript, and if the paint is long it causes hitches or delays in animations.

See, for instance, this view of Dev Tools timeline: there are no paint operations while this layer is rotating back and forth.

Screenshot of Dev Tools timeline during animation

Invalid! Repainting #

But if the layer’s content changes, it has to be repainted.

Figure 4: Repainting Layers #

<!doctype html>
<html>
<head>
  <style>
  div {
    animation-duration: 5s;
    animation-name: slide;
    animation-iteration-count: infinite;
    animation-direction: alternate;
    width: 200px;
    height: 200px;
    margin: 100px;
    background-color: gray;
  }
  @keyframes slide {
    from {
      transform: rotate(0deg);
    }
    to {
      transform: rotate(120deg);
    }
  }
  </style>
</head>
<body>
  <div id="foo">I am a strange root.</div>
  <input id="paint" type="button" value="repaint">
  <script>
    var w = 200;
    document.getElementById('paint').onclick = function() {
      document.getElementById('foo').style.width = (w++) + 'px';
    }
  </script>
</body>
</html>

Every time the input element is clicked the rotating element gets 1px wider. This causes relayout and repainting of the entire element, which in this case is an entire layer.

A good way to see what’s getting painted is with the “show paint rects” tool in Dev Tools, also under the “Rendering” heading of Dev Tools’ settings. After turning it on, notice that the animated element and the button both flash red when the button is clicked.

Screenshot of show paint rects checkbox

The paint events show up in the Dev Tools timeline, too. Sharp-eyed readers might notice there are two paint events there: one for the layer, and one for the button itself, which gets repainted when it changes to/from its depressed state.

Screenshot of Dev Tools Timeline repainting a layer

Note that Chrome doesn’t always need to repaint the entire layer, it tries to be smart about only repainting the part of the DOM that’s been invalidated. In this case, the DOM element that we modified is the size of the entire layer. But in many other cases, there will be lots of DOM elements in a layer.

An obvious next question is what causes an invalidation and forces a repaint. This is tricky to answer exhaustively because there are a lot of edge cases that can force invalidations. The most common cause is dirtying the DOM by manipulating CSS styles or causing relayout. Tony Gentilcore has a great blog post on what causes relayout, and Stoyan Stefanov has an article that covers painting in more detail (but it ends with just painting, not this fancy compositing stuff).

The best way to figure out if its affecting something you’re working on is to use the Dev Tools Timeline and Show Paint Rects tools to see if you’re repainting when you wish you weren’t, then try to identify where you dirtied the DOM right before that relayout/repaint. If painting is inevitable but seems to be taking unreasonably long, check out Eberhard Gräther’s article on continuous painting mode in Dev Tools.

Putting it together: DOM to Screen #

So how does Chrome turn the DOM into a screen image? Conceptually, it:

Takes the DOM and splits it up into layers
Paints each of these layers independently into software bitmaps
Uploads them to the GPU as textures
Composites the various layers together into the final screen image.

That all needs to happen the first time Chrome produces a frame of a web page. But then it can take some shortcuts for future frames:

If certain CSS properties change, it isn’t necessary to repaint anything. Chrome can just recomposite the existing layers that are already sitting on the GPU as textures, but with different compositing properties (e.g. in different positions, with different opacities, etc).
If part of a layer gets invalidated, it gets repainted and re-uploaded. If its content remains the same but its composited attributes change (e.g. it gets translated or its opacity changes), Chrome can leave it on the GPU and recomposite to make a new frame.

As should now be clear, the layer-based compositing model has deep implications for rendering performance. Compositing is comparably cheap when nothing needs to be painted, so avoiding repaints of layers is a good overall goal when trying to debug rendering perf. Savvy developers will take a look at the list of compositing triggers above and realize that its possible to easily force the creation of layers. But beware just blindly creating them, as they’re not free: they take up memory in system RAM and on the GPU (particularly limited on mobile devices) and having lots of them can introduce other overhead in the logic keeps track of which are visible. Many layers can also actually increase time spent rasterizing if they layers are large and overlap a lot where they didn’t previously, leading to what’s sometimes referred to as “overdraw”. So use your knowledge wisely!

That’s all for now. Stay tuned for a couple more articles on practical implications of the layer model.

Additional Resources #

Jank busting for better rendering performance

2012-11-02T00:00:00Z

Introduction #

You want your web app to feel responsive and smooth when doing animations, transitions, and other small UI effects. Making sure these effects are jank-free can mean the difference between a "native" feel or a clunky, unpolished one.

This is the first in a series of articles covering rendering performance optimization in the browser. To kick things off, we'll cover why smooth animation is difficult and what needs to happen to achieve it, as well as a few easy best practices. Many of these ideas were originally presented in "Jank Busters," a talk Nat Duca and I gave at Google I/O talk (video) this year.

Introducing V-sync #

PC gamers might be familiar with this term, but it's uncommon on the web: what is v-sync?

Consider your phone's display: it refreshes on a regular interval, usually (but not always!) about 60 times a second. V-sync (or vertical synchronization) refers to the practice of generating new frames only between screen refreshes. You might think of this like a race condition between the process that writes data into the screen buffer and the operating system reading that data to put it on the display. We want the buffered frame contents to change in between these refreshes, not during them; otherwise the monitor will display half of one frame and half of another, leading to "tearing".

To get a smooth animation you need a new frame to be ready every time a screen refresh happens. This has two big implications: frame timing (that is, when the frame needs to be ready by) and frame budget (that is, how long the browser has to produce a frame). You only have the time between screen refreshes to complete a frame (~16ms on a 60Hz screen), and you want to start producing the next frame as soon as the last one was put up on the screen.

Timing is Everything: requestAnimationFrame #

Many web developers use setInterval or setTimeout every 16 milliseconds to create animations. This is a problem for a variety of reasons (and we'll discuss more in a minute), but of particular concern are:

Timer resolution from JavaScript is only on the order of several milliseconds
Different devices have different refresh rates

Recall the frame timing problem mentioned above: you need a completed animation frame, finished with any JavaScript, DOM manipulation, layout, painting, etc, to be ready before the next screen refresh occurs. Low timer resolution can make it difficult to get animation frames completed before the next screen refresh, but variation in screen refresh rates makes it impossible with a fixed timer. No matter what the timer interval is you'll slowly drift out of the timing window for a frame and end up dropping one. This would happen even if the timer fired with millisecond accuracy, which it won't (as developers have discovered) -- timer resolution varies depending on whether the machine is on battery vs. plugged in, can be affected by background tabs hogging resources, etc. Even if this is rare (say, every 16 frames because you were off by a millisecond) you'll notice: you'll be dropping several frames a second. You'll also be doing the work to generate frames that never get displayed, which wastes power and CPU time you could be spending doing other things in your application.

Different displays have different refresh rates: 60Hz is common, but some phones are 59Hz, some laptops drop to 50Hz in low-power mode, some desktop monitors are 70Hz.

We tend to focus on frames per second (FPS) when discussing rendering performance, but variance can be an even bigger problem. Our eyes notice the tiny, irregular hitches in animation that a poorly timed animation can produce.

The way to get correctly timed animation frames is with requestAnimationFrame. When you use this API, you're asking the browser for an animation frame. Your callback gets called when the browser is soon going to produce a new frame. This happens no matter what the refresh rate is.

requestAnimationFrame has other nice properties too:

Animations in background tabs get paused, conserving system resources and battery life.
If the system can't handle rendering at the screen's refresh rate, it can throttle animations and produce the callback less frequently (say, 30 times a second on a 60Hz screen). While this drops framerate in half, it keeps the animation consistent -- and as stated above, our eyes are much more attuned to variance than framerate. A steady 30Hz looks better than 60Hz that misses a few frames a second.

requestAnimationFrame has been discussed all over the place already, so refer to articles like this one from creative JS for more info on it, but it's an important first step to smooth animation.

Frame Budget #

Since we want a new frame ready on every screen refresh, there's only the time in between refreshes to do all the work to create a new frame. On a 60Hz display, that means we've got about 16ms to run all JavaScript, perform layout, paint, and whatever else the browser has to do to get the frame out. This means if the JavaScript inside your requestAnimationFrame callback takes longer than 16ms to run, you don't have any hope of producing a frame in time for v-sync!

16ms isn't a lot of time. Luckily Chrome's Developer Tools can help you track down if you're blowing your frame budget during the requestAnimationFrame callback.

Opening up the Dev Tools timeline and taking a recording of this animation in action quickly shows that we're way over budget when animating. In Timeline switch to "Frames" and take a look:

A demo with far too much layout

Those requestAnimationFrame (rAF) callbacks are taking >200ms. That's an order of magnitude too long to tick out a frame every 16ms! Opening up one of those long rAF callbacks reveals what's going on inside: in this case, lots of layout.

Paul's video goes into more detail about the specific cause of the relayout (it's reading scrollTop) and how to avoid it. But the point here is that you can dive into the callback and investigate what's taking so long.

An updated demo with much reduced layout

Notice the 16ms frame times. That blank space in the frames is the headroom you have to do more work (or let the browser do work it needs to do in the background). That blank space is a Good Thing.

Other Source of Jank #

The biggest cause of trouble when trying to run JavaScript-powered animations is that other stuff can get in the way of your rAF callback, and even prevent it from running at all. Even if your rAF callback is lean and runs in just a few milliseconds, other activities (like processing an XHR that just came in, running input event handlers, or running scheduled updates on a timer) can suddenly come in and run for any period of time without yielding. On mobile devices sometimes processing these events can take hundreds of milliseconds, during which time your animation will be completely stalled. We call those animation hitches jank.

There's no magic bullet to avoid these situations, but there are a few architectural best practices to set yourself up for success:

Don't do a lot of processing in input handlers! Doing a lot of JS or trying to rearrange the whole page during e.g. an onscroll handler is a very common cause of terrible jankiness.
Push as much processing (read: anything that'll take a long time to run) into your rAF callback or Web Workers as possible.
If you push work into the rAF callback, try to chunk it up so you're only processing a little bit each frame or delay it until after an important animation is over -- this way you can continue to run short rAF callbacks and animate smoothly.

For a great tutorial covering how to push processing into requestAnimationFrame callbacks rather than input handlers, see Paul Lewis's article Leaner, Meaner, Faster Animations with requestAnimationFrame.

CSS Animation #

What's better than lightweight JS in your event and rAF callbacks? No JS.

Earlier we said there's no silver bullet for avoiding interrupting your rAF callbacks, but you can use CSS animation to avoid the need for them entirely. On Chrome for Android in particular (and other browsers are working on similar features), CSS animations have the very desirable property that the browser can often run them even if JavaScript is running.

There's an implicit statement in the above section on jank: browsers can only do one thing at a time. This isn't strictly true, but it's a good working assumption to have: at any given time the browser can be running JS, performing layout, or painting, but only one at a time. This can be verified in the Timeline view of Dev Tools. One of the exceptions to this rule is CSS animations on Chrome for Android (and soon desktop Chrome, though not yet).

When possible, using a CSS animation both simplifies your application and lets animations run smoothly, even while JavaScript runs.

  // see http://paulirish.com/2011/requestanimationframe-for-smart-animating/ for info on rAF polyfills
  rAF = window.requestAnimationFrame;

  var degrees = 0;
  function update(timestamp) {
    document.querySelector('#foo').style.webkitTransform = "rotate(" + degrees + "deg)";
    console.log('updated to degrees ' + degrees);
    degrees = degrees + 1;
    rAF(update);
  }
  rAF(update);

If you click the button JavaScript runs for 180ms, causing jank. But if instead we drive that animation with CSS animations the jank no longer occurs.

(Remember at the time of this writing, CSS animation is only jank-free on Chrome for Android, not desktop Chrome.)

  /* tools like Modernizr (http://modernizr.com/) can help with CSS polyfills */
  #foo {
    +animation-duration: 3s;
    +animation-timing-function: linear;
    +animation-animation-iteration-count: infinite;
    +animation-animation-name: rotate;
  }

  @+keyframes: rotate; {
    from {
      +transform: rotate(0deg);
    }
    to {
      +transform: rotate(360deg);
    }
  }

For more information on using CSS Animations, see articles like this one on MDN.

Wrapup #

The short of it is:

When animating, producing frames for every screen refresh matters. Vsync'd animation makes a huge positive impact on the way an app feels.
The best way to get vsync'd animation in Chrome and other modern browsers is to use CSS animation. When you need more flexibility than CSS animation provides, the best technique is requestAnimationFrame-based animation.
To keep rAF animations healthy and happy, make sure other event handlers aren't getting in the way of your rAF callback running, and keep rAF callbacks short (<15ms).

Lastly, vsync'd animation doesn't only apply to simple UI animations -- it applies to Canvas2D animation, WebGL animation, and even scrolling on static pages. In the next article in this series we'll dig into scrolling performance with these concepts in mind.

Happy animating!

References #

Using requestAnimationFrame for drag events