2011-12-08-webkitgtk-hackfest-wrapup-accelerated.html

---
layout: post
title: "WebKitGTK+ hackfest wrapup: accelerated compositing"
date: 2011-12-08
comments: false
tags:
 - Gnome
 - Igalia
 - WebKit
---

<div class='post'>
I just returned from this year's&nbsp;<a href="http://live.gnome.org/Hackfests/WebKitGTK2011">WebKitGTK+ hackfest</a>. Not only was it the most productive hackfest to date, the diversity of the people involved was incredible. Attendees included hackers from Igalia, Collabora, RedHat and Motorola. It's great to be part of a company which can pull this kind of event together.<br /><br /><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; position: static; text-align: left; z-index: auto;"><tbody><tr><td style="text-align: center;"><span style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><a href="http://www.flickr.com/photos/mariosp/6429999491/in/photostrea"><img alt="WebKitGTK+ 2011 Hackfest" height="160" src="http://farm8.staticflickr.com/7035/6429999491_82a5d7d58e_m.jpg" width="240" /></a></span></td></tr><tr><td class="tr-caption" style="text-align: center;"><a href="http://www.flickr.com/photos/mariosp/6429999491/in/photostream">Planning</a></td></tr></tbody></table>&nbsp;One of the things different about this hackfest were the <a href="http://en.wikipedia.org/wiki/Birds_of_a_feather_(computing)">BoFs</a>, which were mainly planning sessions. The WebKitGTK+ community has shifted from a ragtag group of developers unafraid of <tt>g_object_ref</tt> and <tt>g_object_unref</tt> furiously hacking on a tiny WebKit port to an integral piece of the Gnome renaissance moving steadily toward ambitious goals. I'm obviously biased, but I believe the investment of small companies with strong ideals like <a href="http://igalia.com/">Igalia</a> and <a href="http://collabora.co.uk/">Collabora</a> is directly responsible.&nbsp; <br /><br />Others have already reported on <a href="http://blogs.igalia.com/juanjo/2011/12/04/webkitgtk-hackfest-wrap-up/">some of the incredible work</a> at the hackfest including the <a href="http://blogs.gnome.org/xan/2011/12/04/a-new-design-for-epiphany-web/">bold new Epiphany redesign</a>, <a href="http://blogs.igalia.com/mario/2011/12/06/webkitgtk-hackfest-wk2-a11y-and-ephiphanys-ad-blocker/">accessibility support for WebKit2</a>, and <a href="http://blog.kov.eti.br/?p=223">JHBuild-ification</a>. I'd like to talk a bit about something in which I'm personally involved: <a href="http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome">accelerated compositing</a>.<br /><br /><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; position: relative; text-align: right; z-index: 0;"><tbody><tr><td style="text-align: center;"><span style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><a href="http://live.gnome.org/Design/Apps/Web"><img border="0" height="240" src="http://blogs.gnome.org/xan/files/2011/12/web-overview.png" width="320" /></a></span></td></tr><tr><td class="tr-caption" style="text-align: center;"><a href="http://live.gnome.org/Design/Apps/Web">Epiphany's new look</a></td></tr></tbody></table>Accelerated compositing was introduced in 2009 with the bulk of the work provided by Apple and Google. GPUs are quite fast, but because of the overhead of moving bits from main main memory to GPU memory, <a href="https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s">you need to use them intelligently to see any speedup</a>. Accelerated compositing is the smarts needed to use the GPU intelligently in WebKit. We're also trying to push these smarts down into painting libraries such as <a href="http://cairographics.org/OpenGL/">Cairo</a> and <a href="http://code.google.com/p/skia/wiki/GrContext">Skia</a>, but that's a more difficult task, with less immediate benefit. The best performance improvements come from using the GPU at the place that maintains the drawing state.<br /><br />In the context of WebKit, drawing state is the rendered page itself, with all its layered divs, canvas elements, video tags and WebGL contexts. WebKit stores elements to render in a data structure called the "<a href="http://www.webkit.org/blog/114/webcore-rendering-i-the-basics/">render tree</a>." Members of the the render tree which are drawn in main memory must be sent to the GPU to be displayed on the screen. Furthermore, some of these elements may be rendered on the GPU itself, so ideally we want to avoid copying them to main memory only to copy them back to the GPU at a later stage.<br /><br />CPUs are very fast, so it's often sufficient to rasterize things into main memory. On the other hand, when the entire page is rendered by the CPU, it spends a lot of time doing "boring" tasks that the GPU loves doing, such as compositing (blending images into each other). Accelerated compositing attacks this by slicing the page into layers of related content. The way this slicing works is a heuristic, but generally speaking divs at the same z-index, with the same CSS transform, WebGL contexts and hardware accelerated video are their own layer. It renders each of the non-GPU layers into an image and then uploads all the images to be composited by the GPU along with layers that are already there.<br /><br />Collabora, which created the Clutter port of WebKit has an implementation of accelerated compositing using Clutter. At the hackfest, Joone Hurr and Gustavo Noronha Silva started integrating this version into WebKitGTK+. The nice thing about the Clutter implementation is that it's almost complete. The unfortunate thing is that Clutter uses COGL which has very poor support for using raw OpenGL in the application. Obviously this means that the WebKitGTK+ port would need to rewrite it's WebGL backend. Igalia is also working on two implementations (OpenGL and the Cairo fallback) using No'am Rosenthal's very nice TextureMapper abstraction.<br /><br />During the hackfest, we decided to attempt to integrate all three approaches into the tree. The Clutter version is a nice stopgap for people who want to play with accelerated compositing or are using Clutter already. The intial parts of this implementation should be landing soon. Over the next few months we'll also be submitting OpenGL and Cairo versions of accelerated compositing. We already made great progress at the hackfest. If you're interested in following the work, you can follow the <a href="https://bugs.webkit.org/show_bug.cgi?id=74087">accelerated compositing metabug</a>.<br /><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://foundation.gnome.org/"><img border="0" src="http://www.gnome.org/wp-content/themes/gnome-grass/images/gnome-logo.png" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://igalia.com/"><img border="0" src="http://3.bp.blogspot.com/-T1wYSHpQsiQ/TuDcfC9AmXI/AAAAAAAAASY/oii41HDU3tA/s1600/igalia.png.4KFG6V" /></a></div><div class="separator" style="clear: both; text-align: center;"><a href="http://collabora.co.uk/"><img border="0" height="104" src="http://laszlopandy.com/blog_files/collabora-logo.png" width="320" /></a></div></div>