I believe it's past time to break the silence here, so what follows is a short update on the progress we've made at Igalia toward 3D CSS transforms and hardware accelerated animation in WebKitGTK+ (otherwise known as accelerated compositing). I'm happy to say that both the initial WebKit1 and WebKit2 implementation of this work have finally landed, and you can try it out now in the latest unstable releases. Epiphany in Gnome 3.6 will include accelerated compositing (smooth animations and fast WebGL), a port to the brand new WebKit2GTK+ API (stability and security), and a new interface. It's quite pleasant to watch the progress of my own rounding error as each day it continues transforming into a modern browser.
There were some interesting design choices to make when implementing accelerated compositing in WebKit2. Ports typically choose one of two possibilities for where to actually composite the content of page layers. The first and simplest path, taken by the GTK+ and Mac ports is to do all GPU composition in the WebProcess, which the same process that renders the layer content. This is by far the simplest and most straight-forward path, as WebKit does not have to send bitmap and layer data across the process boundary. The Qt and EFL ports have chosen to do composition in the UIProcess, which is the process that controls the user interface components surrounding the page content. From what I understand, this more complex design is an attempt to lower the latency of touch events and to decrease the number of OpenGL context switches. It's unclear now what the best approach is for browsers on embedded systems, but composition in the WebProcess works quite well for Epiphany at the moment.
During this development cycle we'll continue to improve the implementation of accelerated compositing, but we hope to start looking at other rendering and interactivity improvements such as accelerated canvas, a tiled backing store, touch event handling and a threaded scrolling implementation. I'm most excited about accelerated canvas, because of the work we've been doing recently on Cairo GL. The GL backend of Cairo has been experimental for some time and isn't widely distributed, but recently there's been an attempt to increase its performance and to make it more suitable for embedded platforms.
Once we integrate Cairo GL with our accelerated compositing architecture in WebKitGTk+, canvas content can be rasterized directly on the GPU instead of the CPU. For most systems accelerated canvas means better performance and lower power usage. Hopefully, I can land the patches to enable this as early as Gnome 3.6, but I'm still not sure when the OpenGL backend in Cairo will be officially supported. This means that, for the moment at least, you'll need to compile Cairo yourself to test accelerated canvas.
Accelerated compositing update
07 July 2012