[cairo] The past, present and future of RGB16_565

[Jonathan Morton]

On Tue, 2009-06-16 at 10:03 +0100, Chris Wilson wrote:
> Carl noted last night that we still haven't resolved the thorny issue
> that RGB16_565 just has not died, and given the continued proliferation
> of small low-powered devices it's not going away in the need future.

Hear, hear.

> The idea I had last night was to introduce cairo_format_options_t, and
> not introduce any new image creation routines. The usage I have in mind
> would look something like:
> 
> format = cairo_format_options_create ();
> cairo_format_options_set_red_mask (format, 0xff, 16);
> cairo_format_options_set_green_mask (format, 0xff, 8);
> cairo_format_options_set_blue_mask (format, 0xff, 0);
> cairo_format_options_set_bits_per_pixel (format, 24);
> cairo_image_surface_create (cairo_format_options_get_id (format),
>                             width, height);
> cairo_format_options_destroy (format);
> 
> By making it an opaque type we can safe-guard against future
> requirements for HDR pixel-formats, or extension to un-premultiplied
> sources etc.

Hmm, I don't like the idea of calling six functions (with long names) to
set up a basic RGB pixel format.  Most people want something that "just
works", and often want only a very standard format.

The basic properties of a pixel format are, to my mind:

- The byte width of the whole pixel.  (Forget about <8 bpp.)

- The bit depth of each component (sum <= 8*bytewidth).

- The order of the components (usually one of RGB, BGR, ARGB, ABGR,
RGBA, BGRA, or just A), and if there is any padding, which end of the
word it goes (xRGB or RGBx).  This can be an extensible enum.

- Whether the components are normalised-integer, fixed-point,
floating-point, or something else (like the shared-exponent format
sometimes used for HDR).  Another extensible enum - for now,
normalised-integer is, er, normal.

Now of course, not all combinations of the above make sense, but I think
there are fewer places to go wrong than with a "fully enterprise
compliant" API scheme.

I think it's perfectly acceptable to support only a subset of the
theoretically conceivable pixel formats.  Better to let people convert
the weirder formats (like YUV420) to and from a higher-precision format
that is easier to support, and more likely to be found in a framebuffer.

Perhaps:

format = cairo_format_options_normint( 8, PIXORDER_BGR, 3, 3, 2, 0);
format = cairo_format_options_normint(16, PIXORDER_RGB, 5, 6, 5, 0);
format = cairo_format_options_normint(32, PIXORDER_RGBA, 10, 10, 10, 2);
format = cairo_format_options_float(64, PIXORDER_ARGB, 16, 16, 16, 16);
format = cairo_format_options_shexp(32, PIXORDER_EBGR, 5, 9, 9, 9, 0);

It should be easy to put cheap runtime sanity checks in such a
constructor, and the usage is quite obvious.  It's also less likely to
give programmers Cobol Fingers.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com