5:6:5 RGB Considered Harmful

[Dan Williams]

On Mon, 2007-03-12 at 03:22 -0400, Albert Cahalan wrote:
> Long ago, Tux Paint used 5:6:5. This caused colors to get messed up if
> the user did repeated blur, smudge, pixelate, and similar operations.
> Tux Paint normally uses 8:8:8 RGB, with occational 32:32:32 (linear float)
> RGB for troublesome blending operations like smudge. The version that
> runs on the B2 OLPC XO is currently using 5:5:5, but this causes lots of
> conversions that require bit shifting. The situation would be much better
> if the XO used 5:5:5 or 8:8:8. While 8:8:8 is 50% bigger, it avoids lots
> of bit shifting (very slow on many processors) and preserves information.

You're completely correct.

> Eliminating the use of 32:32:32 will probably involve linear integer data,
> 16:16:16 on normal hardware at least, perhaps with MMX via gcc's vector
> support. This wouldn't be 5:6:5 either.
> 
> If I recall right, eToys was using 5:5:5 and GDK uses 8:8:8.
> Switching to one of those would be good. 5:6:5 can't even do grey.
> Not that non-linear data is any good for computation...

Sugar doesn't really use GDK, it uses hippo-canvas and cairo.  But
neither cairo or GDK really work well at 555.

> The display controller chip probably should use temporal dithering to
> overcome the 6:6:6 limit of the LCD panel. This would make 8:8:8 much
> more valuable.

Ideally we'd like to switch to 1555 with a framebuffer format of 555.
We've did a lot of performance profiling in January and February at 565
and determined that format conversions in X suck and are killers.  We
decided that either 1555 or 4444 were the best options, respectively.
Ideally we would switch to 1555.

Here are the reasons that hasn't happened yet:

1) We haven't had the time to profile 1555 to see if it really would
make a noticeable difference.  You can't take something like this on
faith, you really have to get numbers to prove it.

2) The 1555 paths in X11's and cairo's pixman are not MMX-optimized like
the 565 paths are.  This means that somebody has to write the MMX
optimized routines for pixman before we'd ever really get useful
benchmarks for #1 above.  The most useful ones are 8888 -> 1555
conversions of course.

3) Cairo doesn't have support for 1555, and it only grudgingly uses 565
when the backing Xlib visual is a 565 surface.  Native 1555 would mean
implementing 1555 support in cairo as well.

4) We've been able to fairly easily spot-optimize the pieces of Sugar
that were being really slow, which at _this_ point, with a variety of
test releases in the very very near future, was a better use of our time
than a few weeks on MMX and cairo.  But since it's an infrastructure
change, it can be done at any time without really affecting the actual
GUI stack.

5) This is a highly parallelized, focused task that is orthogonal to the
rest of the project, that somebody could "own" quite easily.  But the
benefits would be large.  If somebody can do MMX, you only need to write
the pixman routines once because both cairo and X use essentially the
same sources for MMX accel.

In short, yes, 1555 is the best option for now, but requires a lot of
work to get to the point of benchmarking and profiling it to see if it
really noticeably faster and better.

Dan