[cairo] How to load a BMP/JPG/TGA to a Surface?

[Adrian Lopez]

On Tue, Jun 1, 2010 at 8:04 PM, Bill Spitzak <spitzak at gmail.com> wrote:

>
>
> Adrian Lopez wrote:
>
>  On Tue, Jun 1, 2010 at 4:29 PM, Bill Spitzak <spitzak at gmail.com <mailto:
>> spitzak at gmail.com>> wrote:
>>
>>    Actually Cairo's image format is ARGB32, meaning each 32-bit word
>>    has the bits arranged so that A is the high-order 8 bits and B in
>>    the lowest 8 bits. On a little-endian machine the bytes are then
>>    arranged in BGRA order, but on a big-endian machine they would be ARGB.
>>
>>
>> Isn't that what I said? On x86, Cairo's format looks like (B, G, R, A)
>> when addressed as individual bytes, where A is the most significant byte of
>> the 32-bit number. DevIL's IL_RGBA format looks like (R, G, B, A) on my
>> Intel PC, so I'm assuming its format is not affected by endianness (it would
>> be silly to call it RGBA if stored as ABGR on big-endian systems).
>>
>
> I think the problem is to find a name that is consistent between big-endian
> and little-endian machines. Apparently the way the hardware is designed, a
> graphics card designed to work best with BGRA byte order on a little-endian
> machine, will work best with ARGB order on a big-endian machine. This is
> because the bus to the card is designed to not mangle 32-bit quantities
> depending on the endianess.
>
> I am using ARGB32 as a name that means "if 4 bytes are loaded into a 32-bit
> number then the result is 0xAARRGGBB". This implies different byte orders on
> different machines. My recommendation is that a single symbol be chosen to
> mean exactly this, rather than having to #if between two symbols depending
> on the endianess.
>
>
Cairo labels a pixel's components in order of most significant byte to least
significant byte, while DevIL labels these components in byte-addressable
memory order. Folks writing software that involves copying data between
DevIL and Cairo must take this into account. Alas, DevIL's documentation
fails to make clear exactly what it means by something like RGBA, so it
catches programmers by surprise when they're used to something like Cairo
where the order in memory is determined by endianness.


>  On x86 systems you can get the same ordering as Cairo by loading images as
>> IL_BGRA, but I think that makes the labeling differences even more
>> confusing. In any case, so long as it's properly documented I'm not sure how
>> much it matters, as dealing with the order of components isn't the only
>> transformation that you need to apply when converting from DevIL to Cairo.
>>
>
> This sounds like what I thought would be needed. So I would recommend using
> a library like DevIL but use that setting to get the images in the order
> Cairo wants. DevIL propbably should add a symbol that means ARGB32 as
> described above, it would be exactly this symbol on a little-endian machine.
>

Even if you modified DevIL to supply color components in the same order as
Cairo expects, you still have to convert from DevIL's independent alpha to
Cairo's premultiplied alpha and you also have to translate between DevIL's
row alignment scheme (no padding between one row's last pixel and the next
row's first pixel) and Cairo's (where each row is aligned according to the
surface's stride value). In light of these differences, I'm not sure how
much is gained by having DevIL's color components be ordered the same as
Cairo's.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100601/885c8f05/attachment.htm>