Just noticed ideologically wrong situation. Formally Mozilla uses device-independent format array of color-triplets + array of alphas (1 or 8 bits). But actually it is platform-dependent in bad way. Each component of libpron defines order of colors in its won way for different platforms, like that: http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/decoders/bmp/nsICODecoder.h#54 and converts images in that platform-dependent format. I don't know if there is generic API to get that order from there, but I didn't notice that in nsIImage.h. So, each platform uses hackish assumption about that. Which can result in strange things, like: https://bugzilla.mozilla.org/show_bug.cgi?id=412168 For me, ImageBits, supplied to nsImage should be platform-independent, and nsImage consumers shouldn't rely on any assumption about that order, but there must be some API in nsImage to get pixelmap order, if consumer is getting Bits from ther, or, at least, global mozilla-wide define about that - used in standard way by all libpron decoders/encoders and other image consumers.
Product: Core → Core Graveyard
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.