Hi,
I made a simple workaround for the issue. Convert to 16 bit first, and try
again :-)

http://source.squeak.org/inbox/Graphics-kfr.527.mcz

Best,
Karl


On Fri, Jul 1, 2022 at 9:35 AM Marcel Taeumel <marcel.taeumel at hpi.de> wrote:

> Merged. Thanks!
>
> Am 30.06.2022 21:44:21 schrieb karl ramberg <karlramberg at gmail.com>:
> Hi,
> I'm not sure what the best solution is here.
> I put 2 simple changes in the inbox that avoid the problem
>
> http://source.squeak.org/inbox/Morphic-kfr.2014.mcz
> http://source.squeak.org/inbox/Graphics-kfr.526.mcz
>
> Best,
> Karl
>
> On Thu, Jun 30, 2022 at 9:11 AM Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
>
>> Hi Karl --
>>
>> > It seems to be this that causes the problem when depth is 32 bits.
>>
>> Yes, 32-bit depth forms are not meant to have a color map. See class
>> comment in ColorForm.
>>
>> > This doIt will cause same problem from a workspace:
>> > (1 to: (1 bitShift:32)) collect:[:i | i = 100]
>>
>> Because it will try to allocate about 35 GiB of memory. See my previous
>> answer.
>>
>> > We should not use this for bit depth > 16 as it will cause problems
>>
>> Maybe we should move the algorithm #copyWithColorsReducedTo: from Form
>> (32-bit depth) down to ColorForm (up to 16-bit depth).
>>
>> Best,
>> Marcel
>>
>> Am 29.06.2022 20:19:06 schrieb karl ramberg <karlramberg at gmail.com>:
>> 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/20220701/d86be00b/attachment.html>