5:6:5 RGB Considered Harmful

[Jim Gettys]

It's not quite that simple:

565 is less likely to show objectionable "banding" of images, as the eye
is most sensitive to green, and getting the extra bit helps
significantly to avoid this on natural imagery.

As Dan says, for performance reasons, right now 565 is the only thing
short of ARGB 8888 that is feasible.  If someone wants to improve the X
server and Cairo, the entire community will benefit.  Of course, the GX
graphics processor doesn't like depth switching, so we already have one
conversion headache in software.
                                  - Jim


On Mon, 2007-03-12 at 10:17 -0400, Dan Williams wrote:
> 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
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
-- 
Jim Gettys
One Laptop Per Child