327580 - fix image decoder endianness/RGB issues

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

We've had some hacks in the decoder/image code that fell apart once we started building on mac, with both big and little endian support.  Need to formalize the contract that all data going in to nsThebesImage is to be in R G B order.

Later on we should look at converting the image decoders to just output ARGB directly.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: fix image decoder rgb order & endianness

Patch fix.  Forces all decoders to give us RGB data if MOZ_CAIRO_GFX, and then we assemble that data into a dword based on the current endianness.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Er, ignore the two Paint/Fill hunks in there, typo.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 212185 [details] [diff] [review]
fix image decoder rgb order & endianness

+    // Output is always ARGB with A in the high byte of a dword
+#ifdef IS_LITTLE_ENDIAN
     return (aAlpha << 24) | (r << 16) | (g << 8) | b;
+#else
+    return (b << 24) | (g << 16) | (r << 8) | aAlpha;
+#endif

but, this doesn't always put it in the high byte. you put it in the low byte on bit-endian platforms. isn't that wrong?

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Er, yes.  Good catch, I had my mind going crazy last night trying to figure out who was swapping where.. I'll fix that and test on OSX/PPC over the weekend.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: fix endianness & pixel format in decoders and nsThebesImage

Updated patch; tested on win32, intel mac, ppc mac.