155941 - cleanup of nsPNGDecoder

Status: VERIFIED WONTFIX

(Core :: Graphics: ImageLib, enhancement)

Description

[tor]

Remove unused RGBA code, let libpng do the word padding for MacOS.

Comment 1

[tor]

Attachment: patch

Comment 2

[tor]

Attachment: merge to tip

Comment 3

[Christopher Blizzard (:blizzard)]

Comment on attachment 120310 [details] [diff] [review]
merge to tip

sr=blizzard

Comment 4

[tor]

Checked in.

Comment 5

[Glenn Randers-Pehrson]

Please reopen.  The checkin triggered bug #202376 and its duplicates.

Glenn

Comment 6

[tor]

Backed out.

Comment 7

[Greg Roelofs]

Red is full-range but appears to be inverted--at least approximately; some of
the yellow areas appear darker than they should, but that may be due to gamma
correction.

Both green and blue are compressed into the upper quarter of the range (191+ and
188+, respectively), and both appear to be folded or wrapped--for example, the
chicken should be nearly black, but only its edges are darker, while the middle
is as bright as the wall above it.  The main kitten is darkest in its
medium-level parts, equally light in both its lightest and darkest regions.

I don't see anything immediately obvious in the patch that could do that, but as
noted in the other bug, the set-filler call will boost the reported number of
channels from 3 to 4, which presumably screws up the logic elsewhere.

Two other things come to mind:  despite the code it replaces, might it be
worthwhile to set the filler value to 0xff so that it can be used as alpha (if
only to test an alternate code path)?  And is decoder->colorLine ever allocated
if channels is _not_ greater than 3? (Maybe it doesn't need to be...)  I'm
looking only at the patch itself, not the full source code, so I could well be
missing things.  (Was it the intent to remove the RGBA/BGRA code path even for
non-Mac builds?)

Comment 8

[tor]

png_set_filler() wasn't doing what I expected and will cause the interlace
buffer to bloat.  Closing as WONTFIX.