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

[Carl Worth]

On Thu, 30 Dec 2004 23:19:49 -0500, Chris wrote:
> OK, I've given up trying to hack libpixman and libcairo to use the byte
> ordering that I need on all platforms.

Hi Chris,

I'm sorry that you've gotten frustrated. I hope we can find a way to
get you what you need.

> It's pretty easy to change on a little endian machine because the alpha
> byte is in the right spot, but on a big endian machine the alpha byte
> position can not be easily moved around (I need it to be last not
> first. The alpha position is hard-coded and expected to be in a
> certain location in both libpixman and libcairo.  From what I can tell
> anyway.

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.

> If anyone comes up with a clean solution please let me know because I
> would like the performance of not having to twiddle these bytes around.
> Right now I have to render to a buffer then scrub all the pixels to the
> byte ordering that I need.

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

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050113/ffb0ae99/attachment.pgp