Bug in PolygonMorph>>#filledForm

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@150.0 . 50.0@100.0 . 150.0@50.0 .
> 50.0@150.0 . 150.0@100.0 . 50.0@50.0}) filledForm asMorph openInHand
>
>
> Best,
> Karl
>
> On Mon, Feb 24, 2020 at 2:35 PM Marcel Taeumel <[hidden email]>
> 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 <
> > [hidden email]>:
> > 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 <[hidden email]> a
> > ??crit :
> >
> >>
> >>
> >> On Sun, Feb 23, 2020 at 11:17 AM tim Rowledge <[hidden email]> wrote:
> >>
> >>>
> >>>
> >>> > On 2020-02-23, at 4:42 AM, Fabio Niephaus <[hidden email]> wrote:
> >>> >
> >>> > On Sun, Feb 23, 2020 at 1:48 AM tim Rowledge <[hidden email]> 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
> >>
> >>
> >



>

>   shadowForm does what I want.

Then maybe we should consider basing #containsPoint: on #shadowForm
instead of #filledForm. It seems that both take about the same time to
compute, and using #shadowForm would make holes act like holes for
dragging and halo-selecting.

Stef

> On 2020-02-23, at 11:21 AM, Eliot Miranda <[hidden email]> wrote:
>
> [snip]

>
> Dan Amelang's Gezira is much more interesting. 

Yup. We (as in 'the board' in this case) tried contacting him some time ago to ask about any progress, plans etc. My email archive suggests that was around sept '17 and nothing came of it that I can discover.

The very last thing I can find is
"

A discussion on the open source nature of the Nile/Gezira/Frank on tinlizzie.org started today on http://mailman.mit.edu/mailman/listinfo/fonclist

Specifically, I asked Yoshiki:

> The Squeak board asked me to ask Alan Kay, Yoshiiki Oshima and other VPRI reseachers if this code is published as open source. When we have reconstructed the ‘final’ version of Frank and all its projects we would like to ask permission to republish it in a running state.


http://mailman.mit.edu/mailman/private/fonclist/2017-November/000048.html

"
... from Nov 2017.

I have no access to that mailing list archive unfortunately. Does anyone out there? Did it explain anything we would care about?


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RLB: Ruin Logic Board