Performance hit while working with screen depth 16

[S Page]

On Mon, Jul 13, 2009 at 2:40 AM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:

> Btw, the issue of depth transformations have been known in the Geode
> for quite some time. We didn't switched to 24bpp because of the amount
> of memory available.

Right, and in 8.2.1 xdpyinfo indicates my default screen visual is
still RGB 565.

> AFAIR the problem was that Cairo has no 16bit surfaces on which we
> could work,

The most recent discussion of the issue in the Cairo graphics library
is in the threads
<http://lists.cairographics.org/archives/cairo/2009-June/017400.html>
and <http://www.nabble.com/Bringing-back-the-dead...-RGB16_565-td21622602.html>
where Cairo expert Behdad says
"Most of the situations where RGB16_565 may be needed,
[cairo_surface_create_similar]() does a better job."
If you use this function to create a surface matching your eventual
Xlib target window that is  16bpp, Cairo will internally use a 16bpp
drawing surface.  This technique was discussed on the sugarlabs list
in <http://lists.sugarlabs.org/archive/sugar-devel/2007-April/002373.html>
and again in December 2008.

However many graphics libraries use cairo_image_surface_create() to
create a bitmap for rendering independent of the eventual target
window .  These graphics libraries are willing to provide you a 565
bitmap (saving memory and improving performance) but the explicit
CAIRO_FORMAT_RGB16_565 format is still deprecated, despite patches
that fix this (see below).

> so we use 32 (or is it 24?)
I dunno, what does GTK on OLPC do?  I don't know enough pycairo to
check what's going on.

> and those need to be converted
> by the X server. I have heard a rumour about someone (OpenMoko?
> Maemo?) having invested resources in adding 16bit surfaces to Qt so it
> ran properly on their hardware.

Cairo is unrelated to Qt.  However, the Maemo project has cairo paches
for 565 support, see
<https://stage.maemo.org/svn/maemo/projects/haf/trunk/libcairo/debian/patches/003-cairo16bpp.diff>
and also Mozilla is pushing for a Firefox that works in 16bpp and has
similar cairo patches, see
https://bugzilla.mozilla.org/show_bug.cgi?id=491357

Staying 16bpp all the way should be a win for memory and performance,
it's just a matter of getting all the layers lined up.

Prepend "AIUI" in front of every paragraph I wrote  8-)
--
=S Page