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

[S Page]

On Tue, Aug 3, 2010 at 7:26 AM, Tomeu Vizoso
<tomeu.vizoso at collabora.co.uk> 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,
https://bugzilla.mozilla.org/show_bug.cgi?id=545632 , 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
release.

> ---------- Forwarded message ----------
> From: Soeren Sandmann <sandmann at daimi.au.dk>
> Date: Tue, Aug 3, 2010 at 15:22
> Subject: Re: rendering-cleanup
> To: Yasushi SHOJI <yashi at atmark-techno.com>
> Cc: gtk-devel-list at gnome.org
>
> ...
> 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.