Building WebKit2GTK+ with Wayland as the target

September 21, 2013

In WebKit2GTK+, a number of targets can be chosen at configure-time – X11, Win32, Quartz, DirectFB. As a result of my work for the GSoC 2013 project, the Wayland build target is now also available.



The obligatory demo screenshot of the MiniBrowser running under Weston

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.


One Response to “Building WebKit2GTK+ with Wayland as the target”

  1. […] 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 […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s