Why aren't browsers smart enough to hardware accelerate without tricks?

Question

There are tons of webpages these days recommending you add these rules to your content to make it hardware accelerated:

transform: translate3d(0,0,0);
-webkit-transform: translate3d(0,0,0);

This always struck me as ridiculous. Why should the browser need my help to decide to hardware accelerate? It's going to be faster, right? So why not just do it? Why wait for me to "trick" the browser into it?

---

Another way of asking this question might be, why doesn't every baseline/reset stylesheet include the lines

* {
    transform: translate3d(0,0,0);
    -webkit-transform: translate3d(0,0,0);
}

Answer 1

It's not so much that browsers can't be or aren't smart enough to use hardware-acceleration. Instead, what you are referring to only really applies to WebKit, and especially to mobile versions of WebKit. Firefox and IE both hardware-accelerate everything, and they automatically split the page into "layers" that are composited on the GPU. That's why they usually blow past Chrome on rendering speed tests. WebKit, on the other hand, has never really been adapted to have more than simple layers acceleration.

Because Firefox and IE can take advantage of Direct2D rendering on Windows platforms (where every single drawing operation is hardware-accelerated), it was essentially a requirement that they be able to do hardware-accelerated compositing as well. If they had only accelerated the drawing operations and not the compositing, they would have lost most of the speed advantage from using Direct2D in the first place because it would have required copying between GPU and system memory, which is slow. On the other hand, all WebKit rendering backends that I'm aware of perform rendering completely in software, and incur the copy-to-GPU penalty when they composite (if GPU compositing is being used). So, it ends up being a tradeoff. If the layer you are compositing doesn't take much time to render on the CPU, it doesn't always make sense to perform the copy and composite on the GPU at all.

Due to this, and also to the extremely limited nature of mobile GPU's, none of the WebKit browsers have yet begun to do automatic hardware-acceleration except when it's absolutely required (e.g. when setting a 3D transform). If you wanted my opinion, I would also add that I think laziness on the part of WebKit developers and supporting companies is a bit of a factor here as well. Using the GPU is a major source of bugs, so it is easier for them to just not use it rather than fix the problems.

By the way, Firefox for Android can do GPU compositing all the time, although you might have to enable it in about:config; I don't know if it's on by default. For PCs, I would recommend using Firefox or IE for really fast rendering.

EDIT: I should also add that in the very latest versions of Android, Google has added hardware-acceleration to Skia, which handles nearly all 2D rendering on the OS. Not many devices in the wild have this yet, but it does mean that performance will improve for everything on Android in the near future. That said, I don't know whether their Skia implementation works as seamlessly with OpenGL as we may like. Compositing still might incur some extra copies until they deal with it.

Answer 2

For more on the webkit approach, Ariya Hidayat (webkit reviewer) wrote a pretty good introductory blog post on hardware acceleration and webkit for our blog. Enjoy.

[The punchline is that HW acceleration can chew up lots of memory, so be judicious.]