WebKitGTK+ hackfest improves HTML renderer for GNOME apps

Contributors to the WebKitGTK+ project recently gathered for a hackfest to …

The open source WebKit HTML rendering engine is increasingly being used in Linux desktop applications to enable richer user interfaces that seamlessly integrate Web content. We first looked at this phenomenon a few years ago when WebKit variants for the GTK+ and Qt application development toolkits first began to emerge. These variants are much more mature today and are used in a growing number of applications. WebKit has also been adopted in some native Linux Web browsers, including GNOME's Epiphany.

Contributors to the WebKitGTK+ project recently participated in a hackfest in Spain. The event was sponsored by Igalia and Collabora, open source software companies that do GNOME engineering. WebKitGTK+ leverages several components from the GNOME platform ecosystem, including the Cairo rendering framework and the libsoup network library. One of the major goals for the hackfest was to improve the integration between these components and upstream Webkit. The developers also planned to implement or improve support for some key features that are used in Epiphany.

Many of the developers who participated in the hackfest wrote blog entries about the work they did during the event. A lot of nice improvements were made to the GStreamer-powered WebKitGTK+ HTML5 video implementation, including support for fullscreen playback and improved user interface controls. DOM bindings, accessibility, support for controlling the user-agent string, form persistence, and many other areas were addressed during the hackfest.

I suspect that Epiphany users will be pretty happy with the next version of the browser thanks to all of these improvements. There are a lot of changes that will benefit application developers, too. As a WebKitGTK+ user, an area that I'm particularly interested in is cache control. The developers made some good progress in this area, but it's still not quite there yet.

They have finally added APIs for controlling caching of in-memory resources. This is a big win because it will help application developers reduce the memory footprint of GTK+ applications that use WebKit. Right now, the WebKitGTK+ caching behavior is largely designed around assumptions that are applicable to Web browsers, but aren't necessarily ideal for other applications. The newly-added cache control APIs make it possible for developers to configure an instance of the rendering engine to use the new "document viewer" caching model, which will significantly reduce the memory consumed by the renderer.

The other major feature that I want is support for a disk cache. Unfortunately, that hasn't been fully implemented yet for WebKitGTK+. The developers plan to facilitate disk caching directly through libsoup, which is currently undergoing a major overhaul. When that work is complete, WebKitGTK+ will have a configurable disk cache that can be programmatically controlled.

WebKitGTK+ vs. QtWebKit

I've done quite a bit of experimentation with both the GTK+ and Qt variants of WebKit. In general, the Qt version has a more comprehensive feature set, richer APIs, and better toolkit integration. Disk caching, for example, is already well supported in QtWebKit and very easy to manage with the QNetworkDiskCache class. Qt 4.6 introduced really excellent DOM APIs that are inspired by JQuery.

There are obviously areas where WebKitGTK+ is still catching up, but there are also some areas where it really shines. It seems to handle actual rendering better than QtWebkit in some places, particularly for things like antialiasing on text and CSS rounded corners.

As we have shown in some of our previous technical coverage of WebKitGTK+, there are a lot of compelling ways that WebKit and emerging standards can bring value to desktop applications. The ongoing efforts of the desktop Linux development community to enable WebKit adoption are going to translate directly into better software for end users.