• Launchpad Entry: here

  • Roadmap Requirement: here

  • Created:

  • Contributors: Marc Ordinas i Llopis

  • Packages affected:


Use WebKit as a test of cairo-gles, by modifying the webkit-clutter port.


WebKit would be a good test case for cairo-gles2, as it uses most of the cairo features.


Currently both the Gtk+ and the Clutter ports of WebKit use cairo to render 2D graphics, but they both use in-memory cairo surfaces. It would be easier to modify one of these ports so that it uses cairo-gles instead of creating a completely new port. Depending on the port selected, the work to be done changes.

Use Cases

  • Dave is one developer working on cairo-gles. He would like to have a good, real-life, test case for a new feature he's adding. A WebKit port using cairo-gles would provide such a test.

  • Alice is working on an OpenGL ES driver, and would like to check if some of her changes increase the performance of an operation.

Implementation Plan

For Clutter's port:

  • Create a ClutterCairoTexture that uses cairo-gl instead of a memory surface. This can create problems with cogl, so some way of having two different GL contexts has to be found.

  • Use that actor in the webkit-clutter port instead of the in-memory ClutterCairoTexture.

For Gtk+'s port:

  • Find a way to pass a cairo-gles drawing context to a WebKitWebView instead of the one GDK uses to draw.

Outstanding Issues

  • Which port should we use? I used to think that, as the Clutter one already used OpenGL, it would be easier to modify for our purposes. But after speaking with the webkit-clutter devs, they think that it'd be more difficult. because the library that manages OpenGL for clutter, cogl, doesn't allow to mix other GL calls with its own easily.
    • Using the clutter port would mean finding a way around clutter's GL-abstraction library cogl, because right now it assumes complete control over the GL context and there's no easy way of creating a subcontext from it.

    • Using the Gtk+ port would mean having to create and manage our own GL view, as Gtk+ doesn't provide a GL widget.
    • In the future, it's very possible that Clutter gets integrated into Gtk+ version 4 1. Right now there's a discussion about how that would work, and important for this project, how would cogl allow other GL contexts to coexist with its own 2. It's also important to note that Clutter developers have developed a different cairo backend, cairo-cogl, intended for use in clutter applications instead of cairo-gl or cairo-gles.

BoF agenda and discussion

We'll have a meeting on this spec at Linaro Connect Q3.11.

WorkingGroups/Middleware/Graphics/Specs/1111/engr-components-webkit (last modified 2011-10-25 14:54:17)