On Tue, Aug 2, 2016 at 3:56 PM, marcel.taeumel <Marcel.Taeumel at hpi.de>
wrote:

> Hi, there.
>
> In Color class >> colorFromPixelValue:depth: we have:
>
> ...
> d = 32 ifTrue: [
>                 "eight bits per component; 8 bits of alpha"
>                 r := (p bitShift: -16) bitAnd: 16rFF.
>                 g := (p bitShift: -8) bitAnd: 16rFF.
>                 b := p bitAnd: 16rFF.
>                 alpha := p bitShift: -24.
>                 alpha = 0 ifTrue: [^Color transparent].
>                 (r = 0 and: [g = 0 and: [b = 0]])  ifTrue: [^Color
> transparent].
>                 alpha < 255
>                         ifTrue: [^ (Color r: r g: g b: b range: 255)
> alpha: (alpha asFloat /
> 255.0)]
>                         ifFalse: [^ (Color r: r g: g b: b range: 255)]].
> ...
>
> This denotes black to transparent. Is this still right?
>

It was never "right" but a hack ... Some code treats the pixel value 0 to
mean "transparent". In particular (IIRC) 16 bit forms which do not store an
alpha value, and 32 bit forms that don't have a proper alpha channel. So
they use 0,0,0 to mean "transparent" and "0,0,1" for solid black.

I don't think there's a good reason for this anymore, since we do have
enough memory and computation power to do alpha properly. But since it will
break some code I'd suggest starting to fix it only after this release.

- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160802/7569e5f0/attachment.htm