[Cuis-dev] suggestion for BoxMorph class comment

[Juan Vuletich]

Hi Mark,

(inline and abridged)

On 12/23/2024 10:13 PM, Mark Volkmann via Cuis-dev wrote:
> Thanks so much for taking the time to reply! See my feedback inline below.
>
> ...
>
> I see the artifacts. After selecting "Restore Display" from the World 
> menu, I also see that the star seems to be clipped to the rectangle 
> defined by the extent. I think I confirmed that by adding the 
> following to the drawOn: method.
>
> aCanvas strokeWidth: 2 color: Color red do: [
>     aCanvas
>         moveTo: 0 @ 0;
> lineTo: extent x @ 0;
> lineTo: extent x @ extent y;
> lineTo: 0 @ extent y;
> lineTo: 0 @ 0
> ].
>
> That renders the attached screenshot.
>
>      Your hypothesis is not correct. The system expects the shape of a
>     subclass of BoxMorph to be a rectangle confined to (0 at 0 corner:
>     extent), as described in the class comment.
>
>
> Is it wrong to say that a BoxMorph clips its contents to the rectangle 
> defined by 0 at 0 and its extent?

Yes. Clipping is done to submorphs. A morph can state that it wants to 
clips its submorphs to its own shape. But its shape is only defined by 
its #drawOn: method. The exception is that BoxMorph are expected to fill 
their box, and not draw outside of it.

> It seems to do that regardless of what is drawn on the BoxMorph. I 
> think the point you are making is that it is *bad* to draw outside of 
> a BoxMorph (and violates a restriction stated in the class comment) 
> due to the artifacts that appear if the morph is dragged. I understand 
> that now. Thanks for explaining that!
>
>     Perhaps what could be added to the BoxMorph class comment is that
>     the framework system expects that behavior, and will break otherwise.
>
>
> Where "break" means it will result in drawing artifacts only if the 
> morph is dragged?

It will also result in different artifacts if the morph is rotated. It 
will also mean that grabbing the morph with the hand doesn't work as 
expected (you'd only be able to grab it from pixels that are actually 
painted, not if you click on holes). Submorph clipping will also be 
broken. Redisplays because of oclusions may be broken too. And other 
things I don't recall right now. And things that work today could break 
in the future (yes, I know this is always the case, but still).

Essentially, you're not respecting the spec, and going to "undefined 
behavior" ( https://en.wikipedia.org/wiki/Undefined_behavior ). "Misuse 
will void your warranty", as they say. In theory, Cuis could crash, your 
PC could be set on fire, whatever.

Just don't use BoxMorph outside its spec. Not worth the trouble. Just 
use PlacedMorph instead.

>     And that the reason is to allow for simple, high performance
>     implementation of SystemWindow and other simple rectangular
>     morphs, where these assumptions mean that the framework doesn't
>     need to do the extra work for arbitrary shapes to work correctly.
>
>
> Got it.
>
>     As a last comment, play with Sample07Clipping. Grab the inner star
>     with the brown handle and move it around a bit. This will show the
>     kind of expensive stuff that regular morphs do, but BoxMorphs avoid.
>
>
> Nice!
> -- 
> R. Mark Volkmann
> Object Computing, Inc.

Cheers,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241227/7d09e977/attachment.htm>