There is a third way

After a weekend hack session with Øyvind Kolås, I got WebKit/GTK+‘s Cairo backend rendering straight to OpenGL with Cairo’s new OpenVG backend and ShivaVG:

At first the colours were a bit off and performance was nothing to write home about. But Øyvind promptly pushed a fix and cooked up a patch to prevent static images being re-uploaded, and things started to fly.

The performance boost is most noticable for SVG and Web pages with large, animated graphics and dynamic content. We’re looking at full repainting is in the hundreds-of-FPS range.

I then turned my attentions to accelerating the canvas element. WebKit/GTK+’s canvas is already the fastest free implementation around, but traditional approaches to rendering the canvas will only get you so far.

Sure enough, with a little more work I had Ilmari Heikkinen’s Canvas Animation Kit Experiment (CAKE) running faster:

(The screenshot was caught during a GL buffer swap, it’s all very smooth in reality.)

Accelerating the canvas was slightly tricky since canvas makes some assumptions about image data, but as we see here it’s quite possible to make it go fast.

Patches should start to appear on #16885. There’s work to be done to improve rendering quality, get text smoothing back etc., but it’s a start.

This feature can be used both to acelerate WebKit/GTK+ and in a standalone configuration with only a GLib dependency, as requested by Linden Lab who are looking at integrating WebKit into their virtual 3D environment.

It should also be usable with the brand new Cairo-based WebKit Windows port (#16979) that’s on its way.

If you’re running a WebKit nightly, your browser supports two new ways of specifying custom fonts.

CSS2 ‘WebFonts’

With WebFonts you can define custom font faces by passing a URL to the font file:

@font-face {
  font-family: 'Bitstream Vera Sans';
  src: url('http://www.freedesktop.org/~alp/tmp/Vera.ttf') format(truetype);
}
 
h1 {
  font-family: 'Bitstream Vera Sans', sans-serif;
}

The font gets downloaded and used without installation. A List Apart has some fancy CSS Zen Garden examples showing off the feature:

Now that the WIP Acid3 test requires TrueType/@font-face support, I expect other browser engines will be quick to join Opera and WebKit in implementing this.

SVG fonts

Then there’s the recently added support for SVG fonts.

When #16880 lands, it’ll be possible to use SVG fonts not only in SVG content, but also as a standard WebFont format with @font-face:

@font-face {
  font-family: 'SVGraffiti';
  font-weight: normal;
  font-style: italic;
  src: url("SVGraffiti.svg") format(svg);
}

This is still under development but works remarkably well. Nice work, Nikolas!

SVG font backend for Cairo

SVG fonts aren’t just for the Web — work is under way to make it possible to use them throughout the desktop with the experimental SVG font backend for Cairo. More on this coming very soon.

Checking it out

Building WebKit/GTK+ is now easier with the newly introduced autotools build system. Try the build instructions on GNOME Live! or just use jhbuild (module ‘WebKit’).

What do you get when you take WebKit/GTK+, add GStreamer and finish off with a sprinkling of code from Clutter?

Pierre-Luc Beaudoin has been working on a GStreamer-based media backend for WebKit.

Last week, we landed his work (#16145), which adds support for the WHATWG HTML5 video/audio specification allowing streaming media to be embedded in web pages without the need for plug-ins.

The last couple of days, I’ve been integrating this media backend with our Cairo-based graphics pipeline (#16356). The result is that streaming web video can now be CSS transformed, embedded in SVG, bounced around the page and generally manipulated with JavaScript.

And the screenshot? It’s a video (one of many GUADEC flicks rescued by Thomas Wood) of Federico talking about Sabayon, played back natively in Epiphany at an angle of 45° and with an alpha value of 0.6.

The semi-transparent user controls superimposed on the video are defined entirely in HTML/CSS complete with animated transition effects (WebKit-only right now, other browsers will fall back gracefully).

Exciting stuff!

In the last month, we’ve started to look more seriously at the WebKit public API and how it fits with GLib/GTK+ principles. Some of the fixes have been obvious:

• #16174: Use “URI” not “URL” in public API
• #15691: The main widget should be called WebView, not Page

Policy changes have been made to ensure consistency:

• Any public entry point, property or signal that does not match GTK+ conventions is now considered a Major bug alongside security issues and crashers (with some exceptions like the new portable JavaScript engine C API (#15687) — more on this in my next post.)
• Any new API contributions without corresponding GTK-Doc documentation will be rejected. Enough said.

The Hacker’s guide to WebKit/GTK+ now covers topics such as API design, patch contribution and optimisation (including Cairo/SVG/canvas performance and memory reduction).

Sources of inspiration

GtkTextView

GtkTextView has a solid design and well-understood data model thanks to its heritage, being a synthesis of the venerable Tk text widget. Some applications like Tomboy are starting to push the limits of GtkTextView as they look towards integrating rich media and Web content synchronisation.

Challenges:

• Can we provide a GtkTextIter implementation that works with the W3C DOM (and our upcoming GObject DOM binding), or is the concept of GtkTextTags too limiting to make this worthwhile?
• How faithfully can we bridge between Markup and HTML?

GtkMozEmbed

GtkMozEmbed is a thin binding around a stable and mature browser engine, Gecko. The primary consumers here are Epiphany, Devhelp and Yelp. To make serious use of the underlying engine, these applications have to resort to C++ and Gecko’s internal APIs which can be inconvenient.

GtkMozEmbed seems to be awkward on non-X backends since it just uses the Mozilla port for that platform, not a GTK+ backend. WebKit/GTK+ on the other hand supports all GTK+ backends natively including DirectFB, OS X and Windows. Looks like there is nothing much worth keeping from the GtkMozEmbed API, but we’ve gained valuable insight from the ways in which developers have struggled to use it.

Challenges:

• Accessibility: We have several accessibility features, but no formal accessibility using ATK. Contributions here are welcome, otherwise I’ll look into adding support in a few weeks.
  • #16135: We’re adding caret-based browsing support straight into WebCore.
• Patches already available but not yet integrated:
  • #15610: International/complex text rendering support using Pango. The Imendio guys are working to complete and integrate my initial work on this feature.
    
  • #14120: Input method support using GTK+ input methods
  • Inline search API (Update: Adam Roben from Apple has pointed out that this can be worked around by calling into window.search using the JS C API for now)
  • #15576: GtkPrint support using Cairo

GtkHTML

GtkHTML is used primarily in Evolution. Again, there is nothing much worth keeping from the GtkHTML API as far as I can tell. WebKit now has excellent editable content support and exposes necessary public API for basic editing. Complex modifications will soon be possible using the GObject DOM, but until then, the DOM can be easily manipulated using the JavaScript C API (more on which soon).

Challenges:

• emacs keybinding support using GtkBindingSet (see also #15911). Perhaps an emacs user can provide this?

Is your application hitting limitations in these text viewing/editing components? Any that I’ve missed? Do speak up now so we can cater for your use-case in WebKit!

In my talk at LCE 2007, I touched on the issue of proprietary branches and their effect on developer morale.

On the WebKit/GTK+ team, we’ve had to deal with this issue a few times.

• A year ago, Adobe promised great new graphics features from their AIR fork of WebKit that never materialised. We chose to redouble efforts to improve the open Cairo graphics backend instead of sitting about waiting for their contributions, a decision that has paid off.
• More recently, a company has been working on a largely proprietary fork of the browser called OWB. It is remarkable that, looking at some of their recent code drops (which cannot be easily merged back to trunk due to refactoring), they still have bugs and performance issues that we fixed in WebKit trunk several months ago. It’s sometimes unpleasant to implement features that others are working on behind closed doors, but we do it in an open forum with peer review. What’s more, we do it better.

Fast forward, November 2007

Today, Google announced that it’s developing a WebKit-based browser as part of its Linux-based Android mobile platform.

In the hours since this news came about, contributors have already started to ask whether their work is about to be obsoleted or replaced by a Google code drop. It’s inevitable that there will be some overlap.

I’d like to make it clear that we’ve already discussed this scenario, and it’s life as usual for the GTK+ port. If there are contributions to components of the GTK+ port, they will be reviewed through the same processes as any other contribution.

Furthermore, it’s likely that WebKit/GTK+ already has superior graphics capabilities to any forked browser since we’ve been tracking the very latest features including recent SVG updates, CSS transformation and CSS animation support. Another WIP feature of particular interest to mobile devices is the upcoming full page scaling support.

With current efforts to bridge Web applications and the underlying platform and research into features like bridging JavaScriptCore to D-Bus and other frameworks, it’s likely that we are also ahead of the game in the Web-as-a-platform department.

All that said, I look forward to working together with the developers of the Android platform towards a more open and flexible mobile Web!

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.