Hi all,

the change is reverted now but I would like to document our findings and our insights for future changes.

>From Berts mail I gathered that the 255-0-0-0 to be transparent is required for 16bit -> 32bit conversion to work. As this has been around for quite some time some code relies on it. At the same time this regularly leads to problems when working with images loaded from external sources. For example, loading a PNG and using collectColor: to recolor it does not work if the PNG includes pure rgb black pixels. For this to work we would have to map pure black to Squeak Form black on loading and reconvert it on storing. This would however destroy information as we can not distinguish between 0-0-1 and 0-0-0 anymore. The other way to go would be to change the 16bit -> 32bit conversion to set alpha explicitly, but I do not know whether that is actually possible efficiently.

Are there other aspects which I am missing? Is it likely for external packages to heavily rely on this functionality?

Bests
Patrick

>
>
>> On 2018-10-15, at 1:57 AM, commits at source.squeak.org wrote:
>> 
>> Patrick Rein uploaded a new version of Graphics to project The Trunk:
>> http://source.squeak.org/trunk/Graphics-pre.404.mcz
>> 
>> ==================== Summary ====================
>> 
>> Name: Graphics-pre.404
>> Author: pre
>> Time: 15 October 2018, 9:57:15.384742 am
>> UUID: a816199d-b2b6-7247-a8f8-898c605829df
>> Ancestors: Graphics-pre.403
>> 
>> Removes odd behavior of colorFromPixelValue:depth: which returns transparent instead of 32bit rgb black
>
>Umm, as best I remember we expect and require 32bit 0.0.0.0 to be transparent. It is an artefact from way back and has caused much confusion; but a lot of code is based on it.
>
>If you've found a way to avoid it and not break all that code - or better yet, I'm misremembering! - then good.
>
>
>tim
>--
>tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>Advanced design: Upper management doesn't understand it.
>
>
>