<div class="gmail_quote">On Tue, Jun 1, 2010 at 8:04 PM, Bill Spitzak <span dir="ltr">&lt;<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
Adrian Lopez wrote:<div class="im"><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Tue, Jun 1, 2010 at 4:29 PM, Bill Spitzak &lt;<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a> &lt;mailto:<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>&gt;&gt; wrote:<br>

<br>
    Actually Cairo&#39;s image format is ARGB32, meaning each 32-bit word<br>
    has the bits arranged so that A is the high-order 8 bits and B in<br>
    the lowest 8 bits. On a little-endian machine the bytes are then<br>
    arranged in BGRA order, but on a big-endian machine they would be ARGB.<br>
<br>
<br>
Isn&#39;t that what I said? On x86, Cairo&#39;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&#39;s IL_RGBA format looks like (R, G, B, A) on my Intel PC, so I&#39;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).<br>

</blockquote>
<br></div>
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.<br>

<br>
I am using ARGB32 as a name that means &quot;if 4 bytes are loaded into a 32-bit number then the result is 0xAARRGGBB&quot;. 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.<div class="im">
<br></div></blockquote><div><br>Cairo labels a pixel&#39;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&#39;s documentation fails to make clear exactly what it 
means by something like RGBA, so it catches programmers by surprise when they&#39;re used to something like Cairo where the order in memory is determined by endianness.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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&#39;s properly documented I&#39;m not sure how much it matters, as dealing with the order of components isn&#39;t the only transformation that you need to apply when converting from DevIL to Cairo.<br>

</blockquote>
<br></div>
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.<br>

</blockquote></div><br>Even if you modified DevIL to supply color components in the same order as Cairo expects, you still have to convert from DevIL&#39;s independent alpha to Cairo&#39;s premultiplied alpha and you also have to translate between DevIL&#39;s row alignment scheme (no padding between one row&#39;s last pixel and the next row&#39;s first pixel) and Cairo&#39;s (where each row is aligned according to the surface&#39;s stride value). In light of these differences, I&#39;m not sure how much is gained by having DevIL&#39;s color components be ordered the same as Cairo&#39;s.<br>