ku.b at gmx.de
Wed Nov 14 06:06:45 PST 2007
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
pixel == A
pixel == 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
> 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
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the cairo