WebGL in WebKit2GTK+ under Wayland

This part of the belated reporting on my GSoC 2013 project covers support for running WebGL content through WebKit2GTK+ under Wayland displays. This was by far the most fun I’ve had during the summer as it was quite challenging, and I’ve also learned much.

 

The WebGL implementation uses a 3D rendering-specific class that is basically a wrapper around OpenGL ES function calls but also sets up the textures and framebuffers appropriately. That class further relies on an additional class that wraps the OpenGL context as it can be provided by the port-specific code that tries to do its best to create a valid context instance, depending on the underlying system and, of course, the display protocol in use.

 

A bit on how the context is acquired under X displays. The implementation relies on GLX, and tries to create either a window-, pbuffer- or pixmap-based context. A shared X11 display is used for all operations. A context can only be produced through GLX if running under X displays and if the X11 display support is actually enabled at build-time.

 

For Wayland the GLX-based context of course won’t be of use – instead, EGL-based context will have to be created. As a part of my work I’ve had to refactor a good part of the current code to provide support for three different code paths that differ in the EGL display that must be used and the context creation process. The first is the default one that relies on the EGL_DEFAULT_DISPLAY and tries to create either a window- or pbuffer-based surface that’s then used to create the context. The second is the X11-specific one that again relies on the shared X11 display and additionally also tries to provide a pixmap-based surface for the context. It’s quite similar to the GLX-based acquiring of the context but ultimately uses the EGL interface.

 

The new, third path to creating the context is Wayland-specific. The shared display is acquired from the wl_display instance that is provided by the default GdkDisplay (which is guaranteed to be of the GdkWaylandDisplay type, since we’re only choosing this code path when running under Wayland). The Wayland platform of the EGL interface unfortunately only implements window-based surfaces, but that’s not really an option here – a hack that works is creating a dummy 1x1px window, but there’s a better solution in the form of the EGL_KHR_surfaceless_context extension. This allows for creating a context without any surface, and using that context works just as fine. The extension is currently only implemented in Mesa, but you’re pretty much depending on that project if you’re running Wayland at this point.

 

Rendering of the simple WebGL demo in MiniBrowser under Weston.

 

The work displayed here is still ongoing but rapidly approaching a finished state. Because of that the WebGL support under Wayland is missing from the forthcoming WebKit2GTK+ 2.2.0, but I hope I’ll be able to convince the maintainers to include it in the 2.2.1 release.