- From: Andreas Neumann <a.neumann@carto.net>
- Date: Fri, 20 Nov 2009 10:53:16 +0100 (CET)
- To: "Jonathan Watt" <jwatt@jwatt.org>
- Cc: "Jeff Schiller" <codedread@gmail.com>, "www-svg" <www-svg@w3.org>
Hi, so - as I understand it. It is not a question of "if" these methods get properly specified and implemented, but more like "how" - is that true? I hope the fact that most other interactive technologies like Java, Flash, Silverlight, qt, etc. offer similar methods is good enough to convince SVG implementers that it is worth wile specifying and implementing intersections tests in SVG as well. I agree that it would be useful not only to test rects against shapes but also path-elements or other shapes against shapes. I wouldn't go as far as taking stroking and other decoration like markers, etc. into account. For my use cases, raw geometry would be fine. I wonder if the people who voted for those two methods in the first place are still around and explain a bit more about their reasoning back then. I am sure they also had use-cases in mind. As to implementation and speed: I am only a script programmer, but I know that in GIS a lot of Open-Source code exists for doing intersections-stuff. Also, every decent drawing package, like Inkscape or others needs to have such methods implemented. I know that one cannot just take code from other projects, but the algorithms/ideas/concepts might be useful to share. I know that in GIS, databases and applications build spatial indexes. They start with bounding box approximations (r-tree or quad-tree like structures) for the first run and later test the geometry of the elements where the bounding box intersected. If you want, I can try to dig up more information on how those index-structures are implemented in GIS. More comments below: On Fri, November 20, 2009 2:18 am, Jonathan Watt wrote: > On 2009-11-19 9:58 PM, Andreas Neumann wrote: >> Most decent drawing tools also allow to customize the selection mode: >> * select all elements that are completely inside a selection rectangle >> (.getEnclosureList()) >> * select all elements that intersect with a selection rectangle >> (.getIntersectionList()) >> >> You would need it for: >> * Full-blown drawing tools/editors >> * GIS: e.g. select all polygons where you want to sum up areas, >> population; calculate different things based on the selection, etc. > > A good example, but an API that only allows for selection based on a > rectangle > seems inadequate for this case, no? You probably want any arbitrary path, > and it > seems to me that some API to ask "is this point inside the given path" > would be > most appropriate. (So in something like the Flash demo you gave below, you > could > take the center of each area of interest and check if it was "inside".) I agree that it would be desirable to have arbitrary geometry intersection tests, but as Jeff said, it would already help a lot to have simpler tests widely available, such as the rectangle based tests. >> * Games > > What in particular are you thinking of here? Simple collision detection > with the > edges of a viewport? I think if SVG is to provide API to help with > collision > detection we'd be better off designing something completely new. I am not much of a gamer and also not a game developer, so I can't provide details here. I just had the idea that intersection tests may be important in gaming as well. >> * multimedia-apps: think about a photo light-room board where you have a >> couple of photos floating around - you want to grab some photos and >> apply some effects on them, or tag them, or remove them ... > > The demos I've seen most commonly involve drawing a path around the photos > you > want to select. I guess being able to draw a rect would provide a > poor-man's > select tool. Anyway, good concrete use case, thanks. right - but drawing a rectangle is also easier for users than drawing a polygon. I guess most users would use the rectangle tool (and then do another rectangular selection with ctrl/shift) and would use freeshape selections only in cases where the rectangular case would be too complicated. I may be wrong though. Again - both selection methods would be useful I think. >> * Technical Drawings: select elements and get a part-list > > I may misunderstand, but I'm not so convinced by this one, either as a use > case > for the current API or as a use case for similar-but-different API. I'm > assuming > you're suggesting that you can select a sub-part of a drawing, and then > work out > a list of all the component parts that make up that sub-part. The current > API > doesn't return container element's though, it returns all the leaf > graphics > elements (which isn't even a parts list...*unless* each part is only > represented > by a *single* graphical element). Maybe one way you could use it is to say > "this > sub-part is selected if all its graphical leaves are selected" though. > Hmm... A > center-points-inside-path query (or something along those lines) may be a > better > bet for this too. right - for this it wouldn't be enough to only get leaf nodes. You'd want the group nodes as well, or maybe be able to stop at a certain hierarchy and don't go into details. So having not only leave-nodes bot also group-nodes would be something to consider for an enhanced version of the getIntersectionList() and getEnclosureList() functions. >> * flow charts and mind maps where you want to drag around groups of >> elements > > Again, this is interesting because you ultimately want to tell if one of > the > nodes in the flow chart/mind map is in the selection or not, not whether > all > it's component graphics objects are in the selection. I'm wondering about > some > sort of mechanism to say on a container: when finding selections, I'm in > if X is > true about some shape that I'll give you - don't bother looking at my > descendants. Such a mechanism would be useful if we specify it in a way that is not too complicated. There may also be use-cases where you'd want only group nodes returned, but no leave nodes. But as Jeff said, developers can still filter the resulting list for special cases. >> I think the resulting node list should be in the order the elements >> appear in the DOM. The question is then if you only get shapes or also >> group/container nodes? Did you discuss that? > > The spec says "graphics elements". I.e. only elements that themselves > paint, so > not container elements. hm - see discussion above >>> * Would you really want 'pointer-events' to be taken into account? >>> >> I think there should be a parameter in the two methods that specify the >> behavior. I think there use-cases for both modes - taking them into >> account or not. > > Can you give specific examples for when you'd want to pay attention to > pointer-events? I think pointer-events is an easy way to make a visible group of elements (or single elements) non-selectable. If I'd do a drawing app and I want to implement layer functionality, I'd use pointer-events="none" for inactive but visible layers. Those inactive layers shouldn't be responsive to selections. In other cases maybe they should be included. >>> * Would you want 'visibility' or 'display' to be taken into account? >>> >> display should be taken into account - definitely. If you switch of a >> layer in a drawing app or GIS, you don't want invisible elements to get >> selected. Besides, display means "not part of the rendering tree", >> anyway? > > It does yes. Still wondering about visibility myself. I don't use visibility a lot. I mainly use display. Thanks, Andreas -- Andreas Neumann http://www.carto.net/neumann/ http://www.svgopen.org/
Received on Friday, 20 November 2009 09:54:12 UTC