[cairo] cairo_format_t

[Kai-Uwe Behrmann]

Am 13.11.07, 12:12 -0000 schrieb Bill Spitzak:

> The reason for ARGB32 is to indicate that the bytes are stored in a 32-bit
> word in native endian order. On current hardware design this is very
> important. ARGB32 is the only way to describe the "fast" format used by most
> graphics in a way that is portable between big-endian and little-endian
> machines, due to the hardware bus being designed to keep 32-bit quantities in
> the same order.

> Hardware seems always to be described in bits per pixel, not bits per channel.

This reads reasonable. Fast seems always good.
 
> I think maybe a no-underscore number could indicate the size of the datatype
> the pixel is packed into, and if missing it indicates the pixel is in
> memory-address order. Thus:
> 
> ARGB32 = current scheme
> 
> ARGB32_8_8_8_8 = same, but with the channels fully specified.

Seems pretty clear what is inside.
unsigned char pixel[4]
pixel[0] == A
pixel[1] == R  ...
 
> BGRA_8_8_8_8 = same as ARGB32 on big-endian machine

So, it's better to use bit operators to access the channels platform 
independend in CAIRO_FORMAT_ARGB32 ?
 
> xRGB32 = proper description of RGB24 with an 8-bit 'x' pad field

After reading the comment to cairo_format_t I can see RGB24 is indeed a 
32-bit quantity. So by using CAIRO_FORMAT_RGB24 as a 
3 * sizeof(char) array a application could crash.
The term CAIRO_FORMAT_RGB24 is demanding some knowledge.

At least now I understand why jpeg_RGB24 <-> CAIRO_FORMAT_RGB24 should 
fail miserably.

> RGB_8_8_8 = most likely layout, in memory-address order, of data that really
> is 24 bits per pixel and not 32.

... but not exposed at all in Cairo.

> RGB32_10_10_10 = Cineon format with 10-bit fields packed into a 32-bit number
> and right-justified


kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org