[cairo] Re: [Inkscape-devel] NEW: cairo rendering in outline mode
spitzak at d2.com
Mon Feb 26 17:17:23 PST 2007
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
> 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.
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:
# define BE(x) x
# define BE(x) CGImageAlphaInfo(x|(2<<12))
bitmapInfo = BE(kCGImageAlphaPremultipliedFirst);
More information about the cairo