14

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);
}
BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
Domenic
  • 110,262
  • 41
  • 219
  • 271
  • The first time I saw such a technique was in [this question](http://stackoverflow.com/questions/9012753/is-there-a-firefox-equivalent-to-chromes-translatez0-to-force-gpu-accelera), with a nice little "nope" answer by one of Mozilla's developers. It's *almost* as ridiculous as adding `!important` to solve a specificity conundrum... *almost*. – BoltClock Feb 02 '12 at 00:51

2 Answers2

27

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.

zhuman - MSFT
  • 1,028
  • 12
  • 16
  • Wow, great answer; thank you. I'll leave this open a while longer to see if anyone can provide more insight on the WebKit side of things, but this is much appreciated. – Domenic Jan 30 '12 at 18:07
  • 3
    This answer contains some misunderstanding. "has never really been adapted to have more than simple layers acceleration" is simply wrong. Because of platform abstraction approach of WebKit (see http://ariya.ofilabs.com/2011/06/your-webkit-port-is-special-just-like-every-other-port.html), the acceleration of primitive drawing is delegated to the platform graphics stack. On Mac, CoreGraphics leverages GPU to certain extent. Even on Qt WebKit port, there are choices from OpenVG, OpenGL, OpenGL ES, etc for drawing acceleration. – Ariya Hidayat Feb 06 '12 at 04:37
  • It's true that it mostly delegates drawing to the platform, but none of the platform graphics stacks use much hardware acceleration currently except Direct2D on Windows. CoreGraphics only does simple acceleration for blitting and such, and complicated things like text aren't really accelerated at all. I talked about Android's new version of Skia in an edit above. The Qt port isn't used by any major browser implementations that I am aware of, and while using OpenVG would be great, there aren't many working implementations of that either. – zhuman - MSFT Feb 09 '12 at 04:00
  • What I was trying to say was that with WebKit architecture, portion of GPU acceleration responsibilities lie in the platform graphics stack. – Ariya Hidayat Feb 10 '12 at 05:16
  • Another example: on iOS, 3-d transform is not necessary to trigger layer compositing. As long as an element is animated/transitioned using CSS, compositing will kick in (even if that element does not have explicit 3-d transformation matrix). – Ariya Hidayat Feb 10 '12 at 05:17
  • @zhuman I have question. Why does my firefox browser render slower then my webkit css translate3d()? – skmasq Jan 27 '13 at 18:38
  • @skmasq Even though Firefox's hardware-accelerated front-end generally renders faster than software WebKit rendering, the code to perform DOM manipulations, animations, and JavaScript execution is slower in many cases. They are definitely improving though. – zhuman - MSFT Mar 28 '13 at 00:24
1

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.]

Michael Mullany
  • 30,283
  • 6
  • 81
  • 105