[cairo] cairo_format_t [was: static array allocation caused a segfault]
spitzak at thefoundry.co.uk
Tue Nov 13 04:12:30 PST 2007
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
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:
The Foundry Visionmongers Ltd * Registered in England and Wales No: 4642027
More information about the cairo