On Tue, Aug 3, 2010 at 7:26 AM, Tomeu Vizoso <tomeu.viz...@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 <sandm...@daimi.au.dk> > Date: Tue, Aug 3, 2010 at 15:22 > Subject: Re: rendering-cleanup > To: Yasushi SHOJI <ya...@atmark-techno.com> > Cc: gtk-devel-l...@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. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
