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 -