Hi,
It seems to be this that causes the problem when depth is 32 bits.

Form >> #copyWithColorsReducedTo:
...
colorMap := (1 to: (1 bitShift: depth)) collect:
....

This doIt will cause same problem from a workspace:
(1 to: (1 bitShift:32)) collect:[:i | i = 100]

We should not use this for bit depth > 16 as it will cause problems


Best,
Karl



On Wed, Jun 29, 2022 at 2:40 PM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Karl --
>
> In a 64-bit image, that algorithm tries to allocate about 35 GiB of
> memory. CMD+Dot will not work because we are sitting in a primitive during
> that allocation.
>
> I think that Form >> #copyWithColorsReducedTo: was originally (2001) used
> to reduce colors in 16-bit forms or maybe 8-bit forms, given a 32-bit image.
>
> (1 << 32) * 8. "34 359 738 368 bytes"
> (1 << 32) * 4. "17 179 869 184 bytes"
> (1 << 16) * 4. "262 144 bytes"
> (1 << 8 )* 4. "1024 bytes"
>
> We cannot #collect: this:
>
> (1 to: 1 << 32) collect: [:ea | ...].
>
> :-)
>
> In #copyWithColorsReducedTo: it looks like that we expect a color map. In
> 32-bit forms, there is no color map. Maybe we should move this algorithm
> down to ColorForm? See its class comment.
>
> Best,
> Marcel
>
> Am 28.06.2022 22:49:43 schrieb karl ramberg <karlramberg at gmail.com>:
> Hi,
>
> If I do Form>>copyWithColorsReducedTo:256 on any form the image stops
> responding.
> No debug log.
>
> This is on a updated Trunk image.
> I'm on a Windows machine.
>
> Best,
> Karl
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220629/aebe820b/attachment.html>