[cairo] Re: [Inkscape-devel] NEW: cairo rendering in outline mode

[Bill Spitzak]

On Feb 25, 2007, at 4:10 PM, bulia byak wrote:

> Last night, with the help of Carl Worth, the issue of cairo/inkscape
> not working on mac was more or less clarified. Here's how I understand
> it.
>
> When drawing into a memory buffer, cairo uses a fixed byte order of
> the R, G, B, A bytes regardless of the platform.
>
I suspect there is a problem either in Cairo or in Inkscape where some 
"ifdef __APPLE__" is being used to determine endianess, thus causing 
ppc big-endian code to be used on Intel.

Anyway:

Cairo, at least on PC's, actually stores the bytes of an image in 
B,G,R,A order. This may look like a strange order, but that is because 
most code treats the 4 of them as a single 32-bit number, which if 
written in hex, would look like 0xAARRGGBB. When stored "backwards" on 
the little-endian PC, it ends up B,G,R,A in a byte array.

I am not sure about Cairo, but I suspect that on a PPC mac, it still 
works with 32-bit quantities, not with bytes. This results in A,R,G,B 
order (still not R,G,B,A but easily confused with it). If Cairo 
accidentally worked with bytes so that they worked on Intel machines, 
it would write B,G,R,A order and produce 32-bit words of 0xBBGGRRAA.

Back on a Intel Mac it should resort to B,G,R,A order like on the PC. 
However accidental inclusion of ppc fixes for byte-based code may 
result in A,R,G,B.

Other annoyance is that Apple's Quartz api is a bit cryptic. Being 
designed on a big-endian machine, they kind of assume that everywhere, 
and will talk about "RGBA" without any indication of whether they are 
talking about a word or bytes. After some guesses and poking around in 
working code, I discovered the following is the "bitmapinfo" (7th 
argument to CGImageCreate()) correctly for *words* of 0xAARRGGBB on 
both Intel and PPC:

#if __BIG_ENDIAN__
# define BE(x) x
#else
# define BE(x) CGImageAlphaInfo(x|(2<<12))
#endif
bitmapInfo = BE(kCGImageAlphaPremultipliedFirst);