<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hi Hilaire, On 6/26/2021 8:49 AM, Hilaire Fernandes via Cuis-dev wrote: <blockquote cite="mid:4276b21d-a7d1-2758-f054-7bca2c119e83@drgeo.eu" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Hi Juan, Answer in the text. <div class="moz-cite-prefix">Le 25/06/2021 à 15:01, Juan Vuletich a écrit : </div> <blockquote type="cite" cite="mid:60D5D3C3.9080409@jvuletich.org">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") </blockquote> That is more like that. I want to select the morphs (views of math models) at a given distance of the mouse cursors: <pre>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]]] </pre> </blockquote> 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. <blockquote cite="mid:4276b21d-a7d1-2758-f054-7bca2c119e83@drgeo.eu" type="cite"> 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: <pre>DrGCircleMorph>>containsPoint: aPoint "it is a circle so height and width is the diameter" ^((self center dist: aPoint) - (self height / 2)) abs < 20 </pre> 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. </blockquote> 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. <blockquote cite="mid:4276b21d-a7d1-2758-f054-7bca2c119e83@drgeo.eu" type="cite"> 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. </blockquote> 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. <blockquote cite="mid:4276b21d-a7d1-2758-f054-7bca2c119e83@drgeo.eu" type="cite"> Thanks Hilaire <pre class="moz-signature" cols="72">-- GNU Dr. Geo <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://drgeo.eu">http://drgeo.eu</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://blog.drgeo.eu">http://blog.drgeo.eu</a></pre> </blockquote> Cheers, <pre class="moz-signature" cols="72">-- Juan Vuletich <a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a> <a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a> <a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a> <a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a> @JuanVuletich</pre> </body> </html>