Hi,
 shadowForm does what I want.

(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}) shadowForm asMorph openInHand

Best,
Karl

On Mon, Feb 24, 2020 at 10:36 PM David T. Lewis <lewis at mail.msen.com> wrote:

> 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
> > >>
> > >>
> > >
>
>
>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200225/4994c8ff/attachment.html>