<div dir="ltr"><div>Hi,<br></div><div> shadowForm does what I want.<br></div><div><br></div><div>(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}) shadowForm asMorph openInHand</div><div><br></div><div>Best,</div><div>Karl<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 24, 2020 at 10:36 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I tried this on both the latest Spur VM (the one we will use for the<br>
release) and on an interpreter VM. I see no difference in the display<br>
in either case. So I think that the VM is not a concern here.<br>
<br>
Dave<br>
<br>
On Mon, Feb 24, 2020 at 10:21:24PM +0100, karl ramberg wrote:<br>
> Hi,<br>
> I tested a PolygonMorph with intentional internal holes. Should those be<br>
> filled ?<br>
> <br>
> (PolygonMorph new setVertices:{150.0@150.0 . 50.0@100.0 . 150.0@50.0 .<br>
> 50.0@150.0 . 150.0@100.0 . 50.0@50.0}) filledForm asMorph openInHand<br>
> <br>
> <br>
> Best,<br>
> Karl<br>
> <br>
> On Mon, Feb 24, 2020 at 2:35 PM Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>><br>
> wrote:<br>
> <br>
> > Thank you all for keeping up these efforts! :-)<br>
> ><br>
> > I just added this issue to our automated test suite. I was just a little<br>
> > bit confused that the bitmap (bytes) created by #filledForm does look to<br>
> > irregular even though -- visually -- distinguishing just between black and<br>
> > transparent.<br>
> ><br>
> ><br>
> ><br>
> > Best,<br>
> > Marcel<br>
> ><br>
> > Am 23.02.2020 22:21:34 schrieb Nicolas Cellier <<br>
> > <a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:<br>
> > Hi all,<br>
> > just to be clear, I underlined the mistakes for the purpose of explaining<br>
> > what I did change and why, not for bashing anyone.<br>
> > It's fairly easy to correct a posteriori once we have a failing test case<br>
> > exposing the problem (thanks Stephane for that!).<br>
> > It was less obvious to analyze and review the change made by Eliot at the<br>
> > time they were introduced.<br>
> > These changes were SUPER important because they made us progress toward<br>
> > complete elimination of buffer overrun (fingers crossed...).<br>
> > I'd say Eliot initiate this move and made 80% of the work, so kudos!<br>
> > And thanks to all those reporting and isolating reproducible test cases!<br>
> ><br>
> > Tim, I took a look at arm code, but there are too many macros to my taste<br>
> > and I can hardly follow the code just by reading (I would need live<br>
> > debugging session, which means messing with QEMU etc...).<br>
> > The hints are:<br>
> > - it's case of H-OVERLAP, so we copy bits from right to left<br>
> > - we're fetching one extra word from the source (the equivalent of<br>
> > preload) though we shall not<br>
> > Not so many operations perform a Form under (bitOr) operation, so it's<br>
> > fairly straight forward to put a conditional breakpoint in the debugger and<br>
> > just observe what's going on... Good luck :)<br>
> ><br>
> > Le dim. 23 f??vr. 2020 ?? 20:22, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> a<br>
> > ??crit :<br>
> ><br>
> >><br>
> >><br>
> >> On Sun, Feb 23, 2020 at 11:17 AM tim Rowledge <<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>> wrote:<br>
> >><br>
> >>><br>
> >>><br>
> >>> > On 2020-02-23, at 4:42 AM, Fabio Niephaus <<a href="mailto:lists@fniephaus.com" target="_blank">lists@fniephaus.com</a>> wrote:<br>
> >>> ><br>
> >>> > On Sun, Feb 23, 2020 at 1:48 AM tim Rowledge <<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>> wrote:<br>
> >>> > ><br>
> >>> > ><br>
> >>> > > Well, that's interesting. The bug is different on a Raspberry Pi (I<br>
> >>> was hoping non-existent) because the bitblt code is quite different as a<br>
> >>> result of the Pi Foundation paying to get much faster ARM assembler blt<br>
> >>> code written.<br>
> >>> > > Same sort of pattern but not identical. Sigh. This will be 'fun' to<br>
> >>> investigate.<br>
> >>> ><br>
> >>> > Hi Tim,<br>
> >>> > Seems very similar to this:<br>
> >>> > <image.png><br>
> >>> ><br>
> >>> > This is what it looked like on GraalSqueak without the fix. Note that<br>
> >>> GraalSqueak's BitBlt is written in Java, so it cannot read past forms etc.<br>
> >>> Maybe this is also the case on ARM for some reason?<br>
> >>><br>
> >>> Yes, that is interesting. It certainly looks identical - so at least the<br>
> >>> bug should be the same to fix!<br>
> >>><br>
> >>> Having to think about the ARM specialised code reminds me - we really,<br>
> >>> really ought to try to make a way to JIT the blit. I did an ARM version 30+<br>
> >>> years ago but it was all rather simpler back then; no cache to fart around<br>
> >>> with (not just no cache instructions with strange permissions stuff,<br>
> >>> actually no cache at all) and simple monochrome Forms.<br>
> >>><br>
> >>> We have the key components to hand. It seems like an idea that could be<br>
> >>> widely useful.<br>
> >><br>
> >><br>
> >> I dare say it is trivial with the framework we have in the JIT (but then<br>
> >> it applies only to the JIT VM, not the stack interpreter).<br>
> >><br>
> >><br>
> >>> It would surely make a fine thesis.<br>
> >>><br>
> >><br>
> >> Dan Amelang's Gezira is much more interesting.  We should productize<br>
> >> that.  We have to accept that we badly need a pixel independent imaging<br>
> >> model that can be compiled to and executed by the GPU. The world has moved<br>
> >> on and Squeak is limited by its graphics infrastructure.<br>
> >><br>
> >><br>
> >> _,,,^..^,,,_<br>
> >> best, Eliot<br>
> >><br>
> >><br>
> ><br>
<br>
<br>
<br>
> <br>
<br>
<br>
</blockquote></div>