I tried this on both the latest Spur VM (the one we will use for the
release) and on an interpreter VM. I see no difference in the display
in either case. So I think that the VM is not a concern here.

Dave

On Mon, Feb 24, 2020 at 10:21:24PM +0100, karl ramberg wrote:
> 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
> >>
> >>
> >



>