Alp Toker

A friend pointed out a slightly confused post by a Mozilla developer regarding WebKit/GTK+.

I don’t really care much for browser wars, but since this post touches on so many aspects of the browser that I’m working on, like Cairo graphics, native widget styling, transparency and complex script support, I thought I’d give a reply.

• WebKit/GTK+ doesn’t really attempt to compete with Mozilla or Firefox in the browser space. It instead targets application developers who want a full-featured browser engine with a fun, powerful GTK+-style API. gtkhtml and gtkmozembed have proved to be inadequate, too heavy or un-portable.
• In the mobile and embedded space, WebKit/GTK+ is mostly competitive with Opera and NetFront rather than Gecko. I can think of only once that a vendor has come along and asked how it compares to Gecko on mobile devices.
• We’re working with the developers of general purpose browsers like Epiphany and Midori, as well as domain-specific Web applications like the GNOME documentation browser Devhelp, and mobile platforms like the Maemo browser EAL and OpenMoko’s browser and feed reader to make sure WebKit can provide all the features they need. It turns out they don’t need a UI toolkit like XUL since GTK+ provides the functionality they need, so we aren’t attempting to bundle a toolkit with our browser engine.
• WebKit/GTK+ is not tied to Linux. It’s portable to OS X and Windows. Behaviour on those platforms is intended to be similar to that on Linux, and the API on all platforms is identical.
• It can render that “Hello” button correctly. It also supports a bunch of fancy features from HTML5 and CSS3 that Gecko does not and loads pages faster before optimisation work has even started, but I don’t think we need to go into a feature-for-feature debate here.

An application hosting OS X Dashboard widgets (widgets can store data locally using HTML5 client-side database storage):

An implementation of Freedesktop notifications using Growl WebKit styles (incidentally, work is ongoing to provide integration with various Freedesktop specifications where appropriate):

An example of native widget styling:

glyph-pixmaps

Carl’s glyph-pixmaps work has been merged to xserver. This provides a speedup for text rendering by hashing and caching glyph data to avoid constant re-uploads. Eric Anholt breaks it down for us.

Cairo and XShm

Shared memory has had a bad rap when it comes to X11, and it’s been found in the past that it doesn’t provide a significant performance benefit over sockets at the transport level (SMT).

However, when it comes to image data, XShm can provide a “sensible performance optimization” by avoiding gratuitous copies. To take advantage of this, you need to do a little work to ensure that the data can be shared directly with the X server. Chris Wilson has just proposed a patch to support this in Cairo.

WebKit and complex text

I’ve started work on support for complex text in WebKit/Gtk+ using Pango. This includes support for non-Western writing systems.

To continue today’s performance theme, it’s worth noting that WebKit provides two code paths for text rendering:

1. Blazing flast: Known as the CG path on OS X, this path caches glyph data and avoids expensive computations wherever possible. In the GTK+ port, this code path requires direct use of the font-system on every supported platform. Luckily, it turns out the WebKit code base already has optimised text implementations for several platforms, which we can just borrow and plug in to our own port.
2. Fast: The ATSUI path on OS X, this path is capable of complex text rendering, while still providing opportunities for caching layout information from previous text runs. Here, we use Pango, along with a few clever tricks.

A heuristic is applied to detect which code path can be used. Since the capabilities of Pango are slightly different to ATSUI, this may yet need some tweaking to avoid more fallbacks then are necessary.

WebKit/Gtk+ gets a reviewer

I am now an official WebKit reviewer. This should help speed up development of the Gtk+ port. Thanks go to Apple and the WebKit team!

Canvas support using Cairo

A few hours ago I landed support for the Canvas HTML element, rendered using Cairo (just like everything else in the browser engine, including ordinary content and SVG graphics). This feature paves the way for significant bling, with WebKit having been the originator of the Canvas standard for use in the Mac OS X Dashboard.

This screenshot demonstrates some dynamic frame/rotation/shadow effects applied to an image on the Web.

Public API refactoring

I’ve now re-factored WebKit/Gtk+’s public API so that the types are named WebKitPage, WebKitFrame etc. This looks and feels a lot better than the old naming convention, and is part of an ongoing effort to provide an elegant and seamless GObject C API for the browser engine. I’ve also updated the Epiphany browser and the EAL wrapper to track these changes so disruption to these projects should be minimal. If you are not having fun embedding WebKit/Gtk+ in your application we’ve done something wrong!

A special thanks

Mark Rowe (who works at Apple) can be considered godfather of the Gtk+ port. He has provided unfaltering enthusiasm and patch review since I started hacking on the browser over a year ago, and last night stayed up till 5AM making sure the Gtk+ port worked on the upcoming feature branch. Earlier that day, he had been hacking on GdkPixbuf image and animation loading support (which has unfortunately stalled since the GdkPixbufAnimation API is something of a black box).

Moving on

In other news, I’ve left Collabora Ltd. for something completely different. Do try to avoid sending email to my old work address. I believe they are hiring someone to continue their WebKit/Gtk+ contracting business. (Other aspiring GNOME companies that have started to contribute to WebKit/Gtk+ include Imendio and Igalia.)

P.S. I left a little treat for you guys in the office