[squeak-dev] PNGReadWriter bug?

tim Rowledge tim at rowledge.org
Fri Jun 13 20:53:41 UTC 2014


Hi Juan,

On 12-06-2014, at 6:54 PM, J. Vuletich (mail lists) <juanlists at jvuletich.org> wrote:
> I checked with the debugger and I'm pretty sure the pixel value for those pixels coded in the PNG file is 16r00FFFFFF. This is really transparent. Value for opacity (alpha) is zero, making values for R, G and B irrelevant.

Yup, that’s what I see too. I think the difference is that the old code for #copyPixelsRGBA: carefully checks the alpha bits and sets the entire pixel to 0 when alpha = 0. The new code doesn’t, and I guess would be relying upon the blend combinationRule being used ‘properly’.

[snip]

> I think your problem lies elsewhere. Someone is handling the pixels 16r00FFFFFF incorrectly. For example, in the script above, using  rule 'Form paint' instead of blend paints those pixels white. What are you trying to do with the bananas and how does it fail?

I think you’re right but it’s probably going to be ‘fun’ to fix. The Scratch code is handling forms with transparency pretty well in almost all cases (except this dratted banana bunch!) using ‘paint’. I’ll have to see if the ARM specific bitblt improvements allow me to use ‘blend’ without killing display performance. Hmm, maybe if I ‘blend’ it into another Form and ‘paint’ that? 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"Oh bother" said Pooh, as he reached for the reset button




More information about the Squeak-dev mailing list