cairo has now 16bit surfaces (was Fwd: rendering-cleanup)

S Page skierpage at
Fri Aug 6 19:14:29 EDT 2010

On Tue, Aug 3, 2010 at 7:26 AM, Tomeu Vizoso
<tomeu.vizoso at> wrote:
> This means that graphic operations would be considerably faster on the
> XO-1 because to date we are rendering to 24bit surfaces that the X
> server has to convert to 16bit every time.

This Cairo change is in 1.9.8 onwards so isn't in the
cairo-1.8.8-1.fc11.i586 in XO release 10.1.2.  Also, the separate
Mozilla bug to allow use of 16-bit surfaces was fixed in June, , so XULRunner
will sometimes use 16-bit surfaces or can be coerced to do so.   I
don't think the Mozilla fix is in any released XULRunner package.

An unrelated Cairo performance issue is whether the pixel scaling of
Browse on XO means that the browser's efforts to pixel-align its
drawing with Cairo is defeated.  Supposedly you can figure this out
using cairo_trace, which is available in cairo-tools for 1.9.6
onwards.  Fedora packages for Cairo 1.9.10 are available, but it's a
development release leading up to the often-delayed 1.10 stable

> ---------- Forwarded message ----------
> From: Soeren Sandmann <sandmann at>
> Date: Tue, Aug 3, 2010 at 15:22
> Subject: Re: rendering-cleanup
> To: Yasushi SHOJI <yashi at>
> Cc: gtk-devel-list at
> ...
> Note that cairo 1.10 (which GTK+ 3.0 will depend on, as I understand),
> has a client side 565 buffer: CAIRO_FORMAT_RGB16_565.

More information about the Devel mailing list