[squeak-dev] The Trunk: Graphics-pre.404.mcz
bert at freudenbergs.de
Mon Oct 15 22:56:14 UTC 2018
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
(Color black pixelValueForDepth: 32) hex
(Color transparent pixelValueForDepth: 16) hex
(Color transparent pixelValueForDepth: 32) hex
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...
More information about the Squeak-dev