Re: Again with the getIntersectionList()

Hi Jonathan,

On Thu, Nov 19, 2009 at 7:17 PM, Jonathan Watt <jwatt@jwatt.org> wrote:
> On 2009-11-19 7:10 PM, Jeff Schiller wrote:
>> On Thu, Nov 19, 2009 at 11:38 AM, Jonathan Watt <jwatt@jwatt.org> wrote:
>>
>>>  * Would you really want 'pointer-events' to be taken into account?
>>
>> nah
>
> Is that an active "no", or "it wouldn't matter either way for my use cases"?

I can't see it mattering for my use cases.

>
>>>  * Would you want 'visibility' or 'display' to be taken into account?
>>
>> nah
>
> Same question.
>

I felt that if the browser can do the main filtering on elements, then
I can easily loop through this reduced set and filter on
visibility/display if I want to.  Adding a whole bunch of options to
methods seems messy unless you made it a CSS selector to additionally
filter out elements (hey, that'd be cool!):

* getFilteredIntersectionList( myRect, "ellipse[visibility=visible][fill=red]" )
   - gets me all visible, red ellipses intersecting the rectangle myRect
   - please choose a better name than this

* getFilteredIntersectionList( myRect, "someElem *")
  - gets me all elements that are descendants of someElem that
intersect the rectangle myRect


>>>  * Would you want elements that are fully inside the rectangle
>>>   that you specify?
>>
>> To me intersection should mean "does this element's area intersect
>> with this other area".  It's not about whether it crosses this other
>> border.  Thus, {x:20, y:20, width:20, height:20} intersects with {x:0,
>> y:0, width:50, height:50}.
>>
>>>  * Would you want elements that have overlap with the rectangle
>>>   that you specify?
>>
>> That's what 'intersection' means. I must have misunderstood you.
>
> I'm not looking for use cases for getIntersectionList only, but rather for
> getIntersectionList, getEnclosureList, checkIntersection, checkEnclosure, or any
> other similar-but-different-in-details functionality. I'm trying to get a grasp
> of specific things this "type" of behavior is useful for, and get people to
> think about (and explain) the exact details of the behavior they'd prefer/need.

Ok, but it looked like you had a basic misunderstanding of what
'intersection' meant in this context.  I wanted to make sure we are on
the same page.  I don't think anyone's after 'find me all elements
that intersect with the border of my test rect'

>From my perspective as SVG-edit-developer: I could see having two
different multiselect modes:  one in which all elements fully inside
my rubber-band box becoming selected (enclosure) and one in which all
elements touching the rubber-band box becoming selected (intersect).
That's the main reason both methods are useful to me.

Here's another one in the context of a graphics editor:  the ability
to cut a hole in a series of stacked shapes so that the background
shows through (internally implemented using mask).  Need to find all
the elements that overlap with the region of the hole to attach a
mask.

>
>> If I am only able to get across one message to the WG it's this:
>>
>> * getIntersectionList() and getEnclosureList() are the visual
>> equivalent of getElementsByTagName/ClassName/etc.  SVG _is_ a visual
>> language, right? :)
>>
>> Letting developers query/filter elements is incredibly powerful.  See jQuery.
>
> Putting on that hat, limiting the query to objects that are fully or partially
> under a rectangle sounds very limiting. But what else would be desirable? Maybe
> being able to pass in a string of path data (possibly limited to straight lines
> for performance reasons) and ask for the elements that it intersects/overlaps?
> Some other suggestions would be useful here.

Your use of the term 'limiting' is odd here.  We start with nothing.
Then we add the SVG 1.1 spec :)  I'm going by what the SVG 1.1 spec
has and what's been (partially) implemented.  I thought I'd start with
that functionality first.

Sure, elements enclosed by or intersecting an arbitrary path would be
even more useful (lasso selection) but for my current use case
(SVG-edit), a rectangular test area is exactly what I was after.

You folks are free (and encouraged) to build more interesting/powerful
interfaces in SVG 2.0 - but the purpose for me starting this chain was
in the context of:

  * needing these methods for SVG-edit and not having them
  * wanting to write code for WebKit and Mozilla so that in 2 years or
so I can use it (yes, I am insane)
  * needing to understand what the heck the SVG 1.1 spec was trying to say

I am looking forward to ed's investigation into this matter in terms
of what Opera has implemented, whether the spec could even be changed
at this point, etc.

> Your comparison with jQuery is cute, and I do buy it to a certain extent, but
> I'd also note that the performance concerns are vastly magnified in SVG.

Yes, this is true.  And while I do understand that you, as a browser
vendor, need to be concerned about performance, I'm left a little
confused by the comment.  Hopefully you are at least convinced that
some form of intersection/enclosure testing in the DOM is valid,
worthwhile, needed, required, sensible, obvious?  The whole point of
retained-mode graphics is for beautiful things like this :)

For SVG-edit, I'm using bbox intersection testing brute-forced in
JavaScript.  For now it suits my purposes - I'd just like that to be
faster and less work for me.

If it won't be done in the browser, it's going to be done in
JavaScript generally leading to poorer performance and frustrated
developers who will ultimately have to compare the 'open web stack' to
other platforms and have to decide which way to go:

* http://msdn.microsoft.com/en-us/library/system.windows.media.visualtreehelper.findelementsinhostcoordinates(VS.95).aspx
* http://qt.nokia.com/doc/4.5/qgraphicsscene.html#items
* http://www.adobe.com/livedocs/flex/3/langref/flash/geom/Rectangle.html#intersects()
* http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Graphics2D.html#hit(java.awt.Rectangle,
java.awt.Shape, boolean)

Regards,
Jeff

Received on Friday, 20 November 2009 06:50:39 UTC