[cairo] ARGB, BGRA, RGBA mess (was: Radial gradiant bug?)

[Chris]

On Thu, 2005-01-13 at 10:24 -0500, Carl Worth wrote:
> I'm sorry that you've gotten frustrated. I hope we can find a way to
> get you what you need.

Not a big deal.  The issue I was frustrated with is that some things are
rendered using the pixman library and formatting while in other places
(gradients) the Cairo image surface was doing the rendering.  I think I
got that worked out though.  It just did not "click" in my head because
normally I would expect the "image surface" and libpixman to be grouped
together as a "plugin" to Cairo.  Which it is in a way, but the source
is in separate projects.  :)

> Cairo currently exports a very limited set of formats, including the
> ARGB32 format.
> 
> According to my understanding, ARGB32 here means that given a 32-bit
> pixel value, the alpha channel is in the most-significant byte down to
> blue in the least significant byte. The format is consistent according
> to this definition regardless of endian-ness.
> 
> As Keith mentioned earlier, the reason for taking a pixel-wise
> approach to the image format, (as opposed to a byte-wise approach), is
> because the pixman code is designed to work with formats (such as 565)
> that do not align channels with bytes.

Yes, this makes sense on one hand.  On the other hand, and maybe it's
because I'm used to using other imaging libraries, if I'm rendering to
an image buffer I would normally expect a certain platform independent
byte ordering (like PNG, TGA, Jpeg, bitmaps, etc.).  Or at least the
ability to specify such things.

> I'm still not exactly sure what you need. Is there an endian-ness bug
> in the gradient code, (eg. it doesn't adhere to the format description
> above?). Or do you really need rendering that is byte-wise consistent
> regardless of endian-ness?
> 
> And we can support more image formats in cairo as needed, (the code in
> libpixman already supports more than what cairo exposes). I'd just
> like to see the small set of formats that users think are really
> important, (rather than exposing a totally general format interface).

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'm probably not using the image the way it was originally intended.  It
just seemed like a convenient way to get image data without having to
create my own Cairo surface type.  It just wasn't as consistent as I
expected.

-- 
// Chris