[cairo] ARGB, BGRA, RGBA mess

[Bill Spitzak]

Chris wrote:

> I don't think it's a bug in Cairo, it is just unexpected from my view.
> In my world I'm used to having an particular format that always has the
> same byte ordering no matter what platform it is used on.  So if it says
> "ARGB" then I expect the bytes in memory to be A, R, G, B on all the
> platforms.  This is just my view from working with bitmaps, targa's,
> jpeg's, etc.

I would agree that, from looking at many image library specifications, 
the term "ABCD" means that A is at a lower memory address than B in the 
virtually every single one of them. Only X has the idea that ABCD means 
A is in the high-order byte of a word. I recommend Cairo and all new 
software follow the more common conventions. It is extremely confusing 
to do otherwise. It also makes it impossible to describe formats where 
the distance between pixels is 3 in any sensible way.

Other problem is that in all my work I have *never* seen "ARGB" or 
"BGRA".  By far the most common layout is "RGBA". The second-most common 
is "ABGR". I think it would be perfectly acceptable if Cairo only 
accepted RGBA and ABGR.

The terms I am familar with and in my order of importance are:

RGBA - &R < &G, &A == &R+3
ABGR - &A < &B, &R == &A+3
RGB - &R < &G, pixels are 3 apart. Pretend A==1
BGR - &G < &R, pixels are 3 apart. Pretend A==1
MONO - one byte, treat it as R==G==B==A.
ARGB - Though logical, I have never seen this used
BGRA - Seen even less, but should be supported if ARGB is

It may make sense to also define symbols "RGBA_WORD" and "ABGR_WORD" 
that match the symbols X uses. RGBA_WORD means that R is in the 
highest-order byte of a 32-bit unsigned value. On a little-endian system 
RGBA_WORD is AGBR, on a big-endian machine RGBA_WORD is RGBA.