Yet again my mighty Scratch related Nemesis is biting at my ankles. I’m more than a little puzzled how a single, simple file can cause so much trouble, but there y’go. Life.
In an old image - the one Scratch is originally built in - loading the attached ‘banana.png' produces a 32bpp image where the transparent outer area is made of pixels with a value of 0. Autocorrect wanted to make the ‘pixies’ which would be so much more attractive, but it is what it is, so ‘pixels’ will have to do. The bits are processed in PNGReadWrite>processNonInterlaced and are written to the actual Form via copyPixelsRGBA:
In a 4.5 image, the same file (yes, made sure of that) is processed via the PNGReadWriter code as above and results in outer area (supposedly transparent) pixels with value 16rFFFFFF. Which aint’ really transparent.
So far as I can tell the likely change that is causing the difference is in PNGReadWriter>copyPixelsRGBA: which dates back to 2004, so clearly not a lot of files manage to trigger any obvious issue. It looks like the chief difference is that the old code used 'Form paint’ combination rule instead of the new code’s Form over rule - but simply changing that makes no difference to the result, so that shows how well I’m doing with this. So maybe it is the rgbaDecoderMapForDepth: that is at fault?
If anyone actually has a decent understanding of the whole PNG related stuff, do tell. It’s driving me ...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Compatible: Gracefully accepts erroneous data from any source.
