[squeak-dev] The Trunk: Graphics-pre.404.mcz

Eliot Miranda eliot.miranda at gmail.com
Wed Oct 17 01:29:55 UTC 2018

On Tue, Oct 16, 2018 at 3:17 PM Bert Freudenberg <bert at freudenbergs.de>

> On Tue, Oct 16, 2018 at 10:29 AM <patrick.rein at hpi.uni-potsdam.de> wrote:
>> Hi all,
>> the change is reverted now but I would like to document our findings and
>> our insights for future changes.
>> From Berts mail I gathered that the 255-0-0-0 to be transparent is
>> required for 16bit -> 32bit conversion to work. As this has been around for
>> quite some time some code relies on it. At the same time this regularly
>> leads to problems when working with images loaded from external sources.
>> For example, loading a PNG and using collectColor: to recolor it does not
>> work if the PNG includes pure rgb black pixels. For this to work we would
>> have to map pure black to Squeak Form black on loading and reconvert it on
>> storing. This would however destroy information as we can not distinguish
>> between 0-0-1 and 0-0-0 anymore. The other way to go would be to change the
>> 16bit -> 32bit conversion to set alpha explicitly, but I do not know
>> whether that is actually possible efficiently.
>> Are there other aspects which I am missing? Is it likely for external
>> packages to heavily rely on this functionality?
> I didn't say you need to revert this change ;)
> I was only explaining where the odd convention comes from.
> Now, early in the dev cycle is a good time to try this. There are
> certainly other places that need clean up (e.g. isTransparent).
> If we can limit the odd color treatment to the 16 bpp case (and only do it
> when between 16 and 32) I'd be pretty happy.

+1.  Why don't we reinstitute the change in trunk and fix as required?

- Bert -

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181016/c1331bbf/attachment.html>

More information about the Squeak-dev mailing list