[Cuis-dev] Selecting Morph

[Juan Vuletich]

Hi Hilaire,

On 6/26/2021 8:49 AM, Hilaire Fernandes via Cuis-dev wrote:
>
> Hi Juan,
>
> Answer in the text.
>
> Le 25/06/2021 à 15:01, Juan Vuletich a écrit :
>> So, what is that you are in need for?
>> - The ability to select several morphs at a time (without grabbing 
>> them), so you can later do something with them? (this could include 
>> ways to add / remove morphs from "current selection")
>
> That is more like that. I want to select the morphs (views of math 
> models) at a given distance of the mouse cursors:
>
> DrGDynamicTool>>myMorphsNear: aPoint
> "Only morphs where feedback and action are wished,
>    not hidden, wanted and under mouse cursor"
>      | globalPoint |
>      globalPoint _ self drawable morphPositionInWorld + aPoint.
>      ^self app morphs select: [:aMorph |
>          aMorph style isNotHidden
>              and: [(self isWanted: {aMorph mathItem})
>              and: [aMorph containsPoint: globalPoint]]]

Ok. So your immediate need is to ask for the morphs from code. I was 
also thinking in user gestures, and I think that will be useful too, we 
can start with just querying morphs from code.

> Previously I was doing this computation per type of morph. For 
> example, for a circle morph, I wrote a simple method (wrongly named 
> btw) like bellow to detect when the  mouse cursor is at distance below 
> 20 pixels of the circle line:
>
> DrGCircleMorph>>containsPoint: aPoint
>      "it is a circle so height and width is the diameter"
>      ^((self center dist: aPoint) - (self height / 2)) abs<  20
>
> With thin morphs as line, to ease the user experience, you really 
> don't want to limit morph selection to the width of the line, it will 
> make a terrible usability. Of course I  can rewrite these methods, but 
> as Vector Graphics comes with a new way to detect the morph at a given 
> coordinates, it will be a great addition to have a general method to 
> detect if a morph is within a given distance of a point.
>

Of course. We don't want to add per-morph specific code for that. I 
think that all the morph should say about its shape is the #drawOn: 
method, and the framework should be able to deduce anything else from it.

> Just random though: If I understood correctly, you use an array of 
> points to represent the pixels of the screen and the morphs id filling 
> these pixels. I guess you can have several morph id per pixels, then 
> selecting the morph ids bellow a disc on this field of pixel is 
> reasonably doable. I guess morphs collision could be done too.
>

Not just a random thought! Yes, MorphicCanvas holds a parallel "Display" 
that instead of pixels, it stores the morphID (and clipping alpha) at 
each point (32 bit per pixel). The canvas also has 2 other arrays: for 
counting edges at each pixel (for fills) and for storing alpha during 
drawing operations. These last 2 are 8 bit per pixel if not doing 
subpixel anti aliasing. In total, if display is a typical full hd 
screen, we have 8MB for Display, and 12MB or 24MB for these additional 
arrays. Knowing several morphID per pixel could mean adding perhaps 80MB 
of memory. I think it would be too much. Additionally, things would get 
slower because of this.

Last evening I started looking for an alternative solution. The first 
thing I thought about was, only for morphs who need it, add a property 
with an 1 bit per pixel Form, the size of the Display Rectangle the 
morph is in. Here, each bit would say if the morph is really at that 
pixel or not. This is somewhat expensive, but if done only for a few 
morphs, it could work.

Today I kept thinking about this, while my daughter was at at her horse 
riding class. I thought about Apple Lisa's regions, and how to use them 
to store a "shadow", a convex area, disregarding, for example, holes and 
concavities. Then I came up with something simpler. Each morph (who 
wants it) can hold an array, where each position is an y pixel position 
affected by it. For each pixel y, it would store xStart and xEnd, the 
first and last x positions affected by that morph. No extra information 
about each line would be stored. So, it is a specification of the convex 
"shadow" I said before. Additionally it is pretty cheap to compute 
(during the blend stage of VectorEngine) and uses little memory (just 
proportional to the height and not to the area). For each morph using 
this, the overhead would be in the KBs and not in the MBs.

I need to start implementing this, first in the Smalltalk version of the 
VectorEngine, and then in the Plugin code. I think this could work.

> Thanks
>
> Hilaire
>
> -- 
> GNU Dr. Geo
> http://drgeo.eu
> http://blog.drgeo.eu

Cheers,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210626/4a7c6152/attachment.htm>