Chromium Graphics Overhaul
Friday, August 27, 2010
For some time now, there’s been a lot of work going on to overhaul Chromium’s graphics system. New APIs and markup like WebGL and 3D CSS transforms are a major motivation for this work, but it also lets Chromium begin to take advantage of the GPU to speed up its entire drawing model, including many common 2D operations such as compositing and image scaling. As a lot of that work has been landing in tip-of-tree Chromium lately, we figured it was time for a primer.
At its core, this graphics work relies on a new process (yes, another one) called the GPU process. The GPU process accepts graphics commands from the renderer process and pushes them to OpenGL or Direct3D (via ANGLE). Normally, renderer processes wouldn’t be able to access these APIs, so the GPU process runs in a modified sandbox. Creating a specialized process like this allows Chromium’s sandbox to continue to contain as much as possbile: the renderer process is still unable to access the system’s graphics APIs, and the GPU process contains less logic.
With this basic piece of infrastructure, we’ve started accelerating some content in Chromium. A web page can naturally be divided into a number of more or less independent layers. Layers can contain text styled with CSS, images, videos, and WebGL or 2D canvases. Currently, most of the common layer contents, including text and images, are still rendered on the CPU and are simply handed off to the compositor for the final display. Other layers use the GPU to accelerate needed operations that touch a lot of pixels. Video layers, for example, can now do color conversion and scaling in a shader on the GPU. Finally, there are some layers that can be fully rendered on the GPU, such as those containing WebGL elements.
After these layers are rendered, there’s still a crucial last step to blend them all onto a single page as quickly as possible. Performing this last step on the CPU would have erased most of the performance gains achieved by accelerating individual layers, so Chromium now composites layers on the GPU when run with the --enable-accelerated-compositing flag.
If you’d like to read more about this work, take a look at this design doc which outlines Chromium’s accelerated compositing system. Over time, we’re looking into moving even more of the rendering from the CPU to the GPU to achieve impressive speedups.

16 comments:
EverAndAnon said...
Speaking of CSS [rather a lot], where's that support for user style sheets?
August 27, 2010 12:00 PM
Pierre said...
Thanks for posting this! You've done a great job leveraging the GPU! Solid design.
August 27, 2010 12:11 PM
Richard said...
Is this the reason for the canvas shadows "burp"?
http://code.google.com/p/chromium/issues/detail?id=50641&q=commentby:richard.heyes&colspec=ID%20Stars%20Pri%20Area%20Feature%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS
http://dev.rgraph.net/tests/_line.html (bottom chart)
August 27, 2010 12:50 PM
MK said...
@EverAndAnon: User stylesheets are partially supported (Issue 2393), but Chrome doesn't recognize "@-moz-document url-prefix", so you have to remove the enclosing curly-braces, and then the style is applied to all websites. (If you're on Chrome 5, I think you also need to launch the browser with the "--enable-user-stylesheet" command-line flag)
August 27, 2010 2:09 PM
Brian said...
Beautiful. I'm about to buy a new PC. What sort of GPU will I need to be able to take advantage of this?
August 28, 2010 4:51 AM
Zazu said...
Please make sure to support proper color profiles and management. I had to switch back to Firefox because of this.
August 28, 2010 7:05 AM
Grigori said...
Why aren't you using the operating system's native 2D acceleration APIs? I.e XRender (X.Org, Linux), Direct2D (Windows) and Quartz/Core Image (OS X)?
August 28, 2010 1:41 PM
broc said...
What hardware does it support? Does it support my Intel GMA 3100?
August 29, 2010 6:06 AM
Jon said...
Will text be drawn using DirectWrite on Windows when the text rendering is moved to the GPU?
August 29, 2010 7:28 AM
EverAndAnon said...
@MK: yes, thanks, I'm well aware of Issue 2393, which is my point really. Native support just ain't there yet (and, of course, Gecko at-rules aren't supported in WebKit).
August 29, 2010 3:52 PM
Ardentra said...
Finally catching up to IE9? You guys have a LONG way to go...
August 30, 2010 11:58 AM
Andre said...
Ardentra: Are you kidding?! Compare here Google Chrome 7 dev with IE 9 preview:
http://html5test.com/
IE 9 has a LONG way to go.
August 30, 2010 5:23 PM
A1programmer said...
I Love it! This is pretty awesome stuff
August 31, 2010 4:25 AM
Brian said...
Awesome work, y'all. You convinced me to go back to the dev versions on my home computer!
September 2, 2010 3:23 PM
Robert said...
The design document mentions that you use some sort of IPC (inter process communication) to communicate between the processes. As a coder, I'm curious as to what your using for the IPC part. Something home-grown?
September 7, 2010 11:34 AM
il gufo said...
Nice to see at last all vendors are beginning to ship features that become available in all major browsers. This way features can really be used by developers and we do not have to stare at a fish tank while the acid3 score slowly grows...
September 13, 2010 6:07 PM
Post a Comment