[cairo] cairo_format_t [was: static array allocation caused a segfault]

[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.

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.

BGRA_8_8_8_8 = same as ARGB32 on big-endian machine

xRGB32 = proper description of RGB24 with an 8-bit 'x' pad field

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

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

Kai-Uwe Behrmann wrote:

> I find it always confusing to say CAIRO_FORMAT_ARGB32 and mean a 8-bit 
> per channel thing. At a first glace I seriously expect it to be a IEEE 
> float format, which it is not. Most users will expect to multiply by the 
> channels count to get the pixel size not to divide the pixel size by the 
> channel count.

-- 
Bill Spitzak, Senior Software Engineer
The Foundry, 1 Wardour Street, London, W1D 6PA, UK
Tel: +44 (0)20 7434 0449 * Fax: +44 (0)20 7434 1550 * Web: 
www.thefoundry.co.uk
The Foundry Visionmongers Ltd * Registered in England and Wales No: 4642027