nsImage format should be platform-independent (?)

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
11 years ago
4 years ago

People

(Reporter: sergei_d, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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.
(Assignee)

Updated

10 years ago
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.