September 23, 2013
This is the last post in the last-minute and short-spanned reporting on my GSoC 2013 project. I’ll only write some final thoughts and a bit about what’s still missing when it comes to support for the Wayland display protocol in WebKit2GTK+.
Over the previous posts I’ve described three main objectives I’ve managed to complete. I added a Wayland build target that can be enabled both on its own or in parallel with the X11 target, implemented support for running the large layout test suite under the Weston compositor, and added support for running WebGL content under Wayland displays.
The work was fun, challenging and I also learned a lot. I’m glad I took up this specific task, as I’m pretty much devoted at this moment to the WebKit project and, specifically, the GTK port. A great group of people is producing fascinating work, and that’s valuable to me as it’s something I can look at, examine and learn from it.
Thanks again to Martin Robinson for the mentoring, giving great advice and doing helpful code reviews. He’s immensely smart and gladly shares his knowledge and experience, which I greatly appreciate. Thanks also to everyone else involved in the WebKit2GTK+ project that chipped in with advice.
While the work I’ve done did improve the WebKit2GTK+ experience under Wayland and I did manage to achieve all the goals I’ve set for the GSoC period, there are still some features that need further attention, mainly the accelerated compositing. I’ve put forth some details about this in the Wayland target report blog, outlining the problem and the most likely solution. The plugin support also needs work, and there are most likely other bugs that need polishing before the experience is optimal.
I better get started.
September 23, 2013
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.
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.
September 22, 2013
WebKit2GTK+ utilizes the WebKit‘s massive layout test suite to test for any regressions that might happen with the enormous amount of commits flying into the tree. The whole suite contains over 30,000 tests of various types that are run in a custom and tightly controlled environment. The Wayland display protocol support can be of use here as well, so that’s another part to which I’ve dedicated attention during my GSoC 2013 project.
That environment is automatically set up through a Jhbuild moduleset, located in the WebKit2GTK+ trunk, when building developer builds. This way the fonts and icons used in tests are the same across different systems. To further avoid the default systems’ affects on rendering of the Web content, Xvfb is used. Xvfb works well because an actual display and input devices are not required, so it also fits nicely with the CI builders that must run the whole suite without an actual display and input devices being present in the system. Multiple instances of Xvfb are launched and the whole test suite is run in parallel to speed up the testing step.
Xvfb has its shortcomings as well though, as it makes it very hard to test proper rendering of the WebGL content or the accelerated compositing output. Mesa’s offscreen rendering might be a viable solution here, and there were attempts at this but no real results.
In comes Weston. The reference Wayland compositor fits perfectly here. Multiple instances of it can be launched in parallel, each providing proper hardware acceleration, opening the path to testing WebGL, CSS shaders, accelerated compositing output and additional features. To put all these instances under control in any developer’s environment, they can all be grouped under an additional Weston compositor which the developer can then dismiss and focus on other stuff. The obvious downside is that real hardware is required, mainly a proper GPU.
A bit on the implementation – WebKit relies on a large Python framework, dubbed webkitpy, for a large set of modern-day tools (a parallel test runner, patch processing utilities, IRC bots and separate Web applications for test management) used by the developers. There are also older scripts, written in Perl, that are still used today, but are not really important in this context. In the webkitpy’s test runner infrastructure, ports can define their own set of rules when it comes to the environment in which the tests should be run. This basically means that the GTK port must define the DISPLAY environment variable and also properly set up the Xvfb instance. The same applies for the WAYLAND_DISPLAY environment variable and Weston, with the so-called WestonDriver class being chosen over the XvfbDriver class when running the test suite under a Wayland display.
This blog post really covers the very specifics (and only a part of that) of running the layout tests under WebKit2GTK+ (or, again, WebKit1GTK+, even if that framework is moving towards deprecation) and how the Wayland support was added for that scope of the project. I wanted to outline the benefits of using Weston as the for-testing display and the neat hack of keeping all the parallel instances (of which there can be a lot) under control, and I hope I’ve managed just that.
September 21, 2013
Different targets require different dependencies and also determine which platform-specific set of files must be built. In WebKit2GTK+, the target is chosen when running the configure script, passing the `–with-target` option on the command line. The new Wayland target can be selected along with the X11 target (by executing `./configure –with-target=x11,wayland`) or can be the only chosen target (by executing `./configure –with-target=wayland`). Choosing the Wayland target via the `–with-target` option will be available in the forthcoming 2.2 stable release series of WebKit2GTK+ (and WebKit1GTK+ too, though that technical name is not really used). For future stable releases, I plan to provide multiple `–enable-*-target` configuration options as the current approach involves some nasty hacks to support builds that enable both the X11 and Wayland targets in parallel. The new flags should be coming to trunk relatively soon (if the approach is accepted).
Wayland is under rapid development and with other projects lagging behind with the support for it, WebKit2GTK+ is unfortunately no exception. In order for the basic functionality to work, WebKit2GTK+ under Wayland disables accelerated compositing at run-time (and also at build-time if Wayland is the only chosen target), and disables Netscape plugins entirely.
Accelerated compositing for WebKit2GTK+ under Wayland is quite a hard cookie to crumble due to the multi-process nature of the WebKit2 infrastructure upon which WebKit2GTK+, the GTK port, sits. The crux of the issue is the fact that EGL surfaces cannot be shared between processes. I won’t go too deep into technicalities at this point, but you can brush up on the problem by reading this blog post by Iago Toral. Note that the basic painting of the Web content is not an issue as in this case using shared memory between the two processes is possible.
Plugins, the bane of the Web, are not yet working with WebKit2GTK+ under Wayland due to, again, the multiple process architecture. The Plugin process that’s provided by WebKit2GTK+ is linked against GTK+ 2.0 so plugins like Flash can still be used. At least in the case of the Flash plugin, Adobe concluded any further development apart from security updates, meaning the plugin will never progress towards GTK+ 3.0. I’d be the first to join the revolution and completely disable the Plugin process, but this probably won’t be possible anytime soon. Given that, the Plugin process will have to use GTK+ 2.0 as long as required. With Wayland only supported in the latest releases of GTK+ 3.0, this means that the plugins will most likely have to be run through XWayland.
Even with accelerated compositing and plugins not yet supported, WebKit2GTK+ under Wayland is still functioning quite well. Video playback works well, WebGL support is on its way, and input is properly processed. A great deal of functionality is already assured because of great work being done to support Wayland in the GTK+ toolkit itself.
September 19, 2013
I’ve been accepted into this year’s Google Summer of Code to work on adding support for running WebKit2GTK+ under the Wayland display protocol. While the work started back in late May and with the hard pencils-down date looming just around the corner, this is actually the very first blog post on the project.
Turns out, I suck at reporting. Don’t worry, I’ve been working on the project throughout the summer and achieved solid results, but I failed completely on providing timely updates on the status and progress of my work. I apologize for that.
WebKit2GTK+, the GTK port of the WebKit2 web engine infrastructure, needed a fair amount of attention so it could properly run under Wayland displays. With the whole GNOME ecosystem moving towards the new cool display protocol, it quickly made sense what to propose as the GSoC project earlier this year. The project got accepted, and Martin Robinson kindly volunteered to be my mentor, and I’m very thankful for all his hints, pointers and reviews.
On Monday the GSoC work period finishes and the final evaluations follow. This being written on Thursday evening, I’m left with three more days I can spend on documenting the project’s results and shortcomings, filling up the project’s Wiki page. Therefor, for the next three days, I’ll write three more posts, presenting three main goals of the project that I’ve managed to achieve (more or less successfully). On Monday, I’ll post the final conclusions and also some information on what bits are still needed to have a complete, smooth experience of WebKit2GTK+ under Wayland displays.