Hi,
I tested a PolygonMorph with intentional internal holes. Should those be
filled ?

(PolygonMorph new setVertices:{150.0 at 150.0 . 50.0 at 100.0 . 150.0 at 50.0 .
50.0 at 150.0 . 150.0 at 100.0 . 50.0 at 50.0}) filledForm asMorph openInHand


Best,
Karl

On Mon, Feb 24, 2020 at 2:35 PM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Thank you all for keeping up these efforts! :-)
>
> I just added this issue to our automated test suite. I was just a little
> bit confused that the bitmap (bytes) created by #filledForm does look to
> irregular even though -- visually -- distinguishing just between black and
> transparent.
>
>
>
> Best,
> Marcel
>
> Am 23.02.2020 22:21:34 schrieb Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
> Hi all,
> just to be clear, I underlined the mistakes for the purpose of explaining
> what I did change and why, not for bashing anyone.
> It's fairly easy to correct a posteriori once we have a failing test case
> exposing the problem (thanks Stephane for that!).
> It was less obvious to analyze and review the change made by Eliot at the
> time they were introduced.
> These changes were SUPER important because they made us progress toward
> complete elimination of buffer overrun (fingers crossed...).
> I'd say Eliot initiate this move and made 80% of the work, so kudos!
> And thanks to all those reporting and isolating reproducible test cases!
>
> Tim, I took a look at arm code, but there are too many macros to my taste
> and I can hardly follow the code just by reading (I would need live
> debugging session, which means messing with QEMU etc...).
> The hints are:
> - it's case of H-OVERLAP, so we copy bits from right to left
> - we're fetching one extra word from the source (the equivalent of
> preload) though we shall not
> Not so many operations perform a Form under (bitOr) operation, so it's
> fairly straight forward to put a conditional breakpoint in the debugger and
> just observe what's going on... Good luck :)
>
> Le dim. 23 févr. 2020 à 20:22, Eliot Miranda <eliot.miranda at gmail.com> a
> écrit :
>
>>
>>
>> On Sun, Feb 23, 2020 at 11:17 AM tim Rowledge <tim at rowledge.org> wrote:
>>
>>>
>>>
>>> > On 2020-02-23, at 4:42 AM, Fabio Niephaus <lists at fniephaus.com> wrote:
>>> >
>>> > On Sun, Feb 23, 2020 at 1:48 AM tim Rowledge <tim at rowledge.org> wrote:
>>> > >
>>> > >
>>> > > Well, that's interesting. The bug is different on a Raspberry Pi (I
>>> was hoping non-existent) because the bitblt code is quite different as a
>>> result of the Pi Foundation paying to get much faster ARM assembler blt
>>> code written.
>>> > > Same sort of pattern but not identical. Sigh. This will be 'fun' to
>>> investigate.
>>> >
>>> > Hi Tim,
>>> > Seems very similar to this:
>>> > <image.png>
>>> >
>>> > This is what it looked like on GraalSqueak without the fix. Note that
>>> GraalSqueak's BitBlt is written in Java, so it cannot read past forms etc.
>>> Maybe this is also the case on ARM for some reason?
>>>
>>> Yes, that is interesting. It certainly looks identical - so at least the
>>> bug should be the same to fix!
>>>
>>> Having to think about the ARM specialised code reminds me - we really,
>>> really ought to try to make a way to JIT the blit. I did an ARM version 30+
>>> years ago but it was all rather simpler back then; no cache to fart around
>>> with (not just no cache instructions with strange permissions stuff,
>>> actually no cache at all) and simple monochrome Forms.
>>>
>>> We have the key components to hand. It seems like an idea that could be
>>> widely useful.
>>
>>
>> I dare say it is trivial with the framework we have in the JIT (but then
>> it applies only to the JIT VM, not the stack interpreter).
>>
>>
>>> It would surely make a fine thesis.
>>>
>>
>> Dan Amelang's Gezira is much more interesting.  We should productize
>> that.  We have to accept that we badly need a pixel independent imaging
>> model that can be compiled to and executed by the GPU. The world has moved
>> on and Squeak is limited by its graphics infrastructure.
>>
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200224/c0630028/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 35349 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200224/c0630028/attachment.png>