Re: Again with the getIntersectionList()

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".)

> * 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.

> * 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.

> * 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.

> * 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.

> 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.

>>  * 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?

>>  * 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.

>>  * How about opacity, markers, masking or filters?
>>   
> not so sure. I would say no. I am mostly interested in the "raw" 
> geometry, not the decorations.
> 
>>  * Would you want elements that are fully inside the rectangle
>>    that you specify?
>>   
> yes - with getEnclosureList()
> 
>>  * Would you want elements that have overlap with the rectangle
>>    that you specify?
>>   
> yes - with getIntersectionList()
> 
>>  * Would you only want elements that intersect with the *edges*
>>    of the rectangle that you specify (i.e. not elements that are
>>    fully inside)?
>>   
> For getIntersectionList() I would want both: elements that are inside 
> the selection rectangle and elements that intersect. Both cases are 
> actually intersection. Inside is also an intersection of the two areas 
> (the shapes and the selection rectangle)
> 
>>  * Would bbox intersection checking be sufficient?
>>   
> Not for all cases. I think there should be a parameter: bounding box 
> checks (faster) and checks on full geometries (slower, but more accurate)
> 
> I hope that the use cases above are strong enough to be properly 
> specified by the SVG WG and picked up by the implementors.

They're very helpful use cases (keep them coming), but are actually highlighting
to me how poorly the existing four methods fit what you want to do.

> Thank you for discussing and working on this! I think there would be a 
> lot of applications that would benefit from proper and compatible 
> .getIntersectionList() and .getEnclosureList()

Sure thing. Thanks for your help coming up with use cases.

Jonathan

Received on Friday, 20 November 2009 01:18:48 UTC