A good week for text and graphics


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.

WebKit Pango Thumbnail

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.