On 2/25/07, Niko Kiirala <niko@...1267...> wrote:
Umh, ok... So this means, that NRPixBlocks have different byte orders depending on system?
Yes, looks like it.
Is it just that, that colours are somewhere handled as 32-bit integers and as such, the platform byte order (high endian / low endian) makes a difference? Or is there some still deeper problem here?
As I understand it, the difference is that Inkscape code reads/writes the 4-byte value by individual components, i.e. as char values to char* pointers. Cairo always does it as uint32 values to uint32* pointers. And these two methods give different results on a Mac.
So, perhaps a more correct description is that, on the contrary, it's Inkscape that always uses the fixed order of r, g, b, and a bytes. Cairo on the other hand relies on uint32 values, and these get written with different byte order depending on endianness of the plarform. Perhaps some cairo expert can chime in to confirm or deny this.
Sorry for the confused explanations. I've never dreamt of being an expert on these ugly topics :)
And further, how do I properly determine the byte order for rgba images? I am now coding the support for the feBlend filter, and for that it is really important to know, from which byte to read the opacity value ;)
I think that so long as you do this by getting individual chars and so long as it works on one platform, it will work everywhere, as our entire codebase confirms. Problems start only when you try to mix in cairo with its uint32s.
(Also, this really should be documented. As the mode for rgba images is called NR_PIXBLOCK_MODE_R8G8B8A8P, I've always assumed, that the format is R8 G8 B8 A8)
Yes, I think that's a correct assumption.