On Mon, Oct 15, 2018 at 1:17 PM tim Rowledge <tim@rowledge.org> wrote:


> On 2018-10-15, at 1:57 AM, commits@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.

0-0-0-0 is transparent because alpha is 0, that is not the issue. But 255-0-0-0 also used to be treated as transparent because that's what you get when converting from a 16 bit form, in which 0-0-0 is treated as transparent by certain bitblt rules, whereas 0-0-1 is black. Cf. fixAlpha.

(Color black pixelValueForDepth: 16) hex
=> 16r0001
(Color black pixelValueForDepth: 32) hex
=> 16rFF000001

(Color transparent pixelValueForDepth: 16) hex
=> 16r0000
(Color transparent pixelValueForDepth: 32) hex
=> 16r00000000

If you've found a way to avoid it and not break all that code - or better yet, I'm misremembering! - then good.
 
We're not doing a lot of 16/32 bpp conversions nowadays so I expect we won't run into too many issues. Someone should check the bitblt rules to see which ones treat the x-0-0-0 value specially.

- Bert -