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

>
>
> > 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.
>

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 -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181015/850806f5/attachment.html>