Implement getIntersectionList(), getEnclosureList()

Status

()

Core
SVG
8 years ago
2 months ago

People

(Reporter: Jeff Schiller, Assigned: Felipe Corrêa da Silva Sanches, NeedInfo)

Tracking

(Blocks: 1 bug, {dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 4 obsolete attachments)

(Reporter)

Description

8 years ago
Created attachment 386062 [details]
Test case revealing the problem.

As mentioned here: http://www.mozilla.org/projects/svg/status.html please support the following methods on the <svg> DOM element:

getIntersectionList()
getEnclosureList()
checkIntersection()
checkClosure()

Spec details here: http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGSVGElement

Opera supports these methods.

I have attached a very basic test case that covers getIntersectionList and getEnclosureList.
Reading that that Firefox 3.5- didn't support these methods [1], I got the impression that this was working post 3.5, and quickly launched my nightly build (3.6a [2])... But apparently not yet. :-|

[1] http://code.google.com/p/doctype/wiki/SVGSVGElement
[2] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090724 Minefield/3.6a1pre (.NET CLR 3.5.30729)

Comment 2

7 years ago
Shouldn't this bug be for all platforms?
(In reply to comment #2)
> Shouldn't this bug be for all platforms?

Yup. :-)
OS: Mac OS X → All
Hardware: x86 → All
Duplicate of this bug: 589646
Blocks: 554013
(Assignee)

Comment 5

7 years ago
Created attachment 475682 [details]
interactive test case

This is a testcase in which you move a rectangle by moving the mouse cursor. Fill color indicates whether the rect is enclosed by the box (another svg:rect). Stroke indicates whether the rect intersects the box.
(Assignee)

Updated

7 years ago
Assignee: nobody → juca
(Assignee)

Comment 6

7 years ago
Created attachment 475692 [details] [diff] [review]
wip. Need some advice please

This is work in progress. This patch works partially. With this patch the test case (475682) passes. But this patch is still incomplete. It is my first attempt at solving a non-trivial bug, so I'd like to have feedback on it. I am not sure I am doing things the best way.

some questions:

1) referenceElement is the root of a subtree for which every node should have its bbox checked against the provided rect for enclosure or intersection, right?

2) what is the precise definition of intersetion? I guess that an element that is intersecting rect must not be enclosed by rect at the same time, but that is not clear in the SVG spec.

3) when referenceElement is nsnull we should use the svg:svg element as root of the subtree to be searched for enclosure/intersections?

Please, give me some feedback on overall code quality / coding style.
Attachment #475692 - Flags: review?(dholbert)
(Reporter)

Comment 7

7 years ago
It's great that you're working on this - these methods are invaluable, in my opinion (equivalent of getElementsByClassName() etc for SVG).

For 1), please follow up with this issue I raised last year: http://www.w3.org/Graphics/SVG/WG/track/actions/2695 it looks like the spec was resolved and tests added.  Unfortunately I don't remember how it was resolved :/
(Reporter)

Comment 8

7 years ago
Here's the thread I started on www-svg: http://lists.w3.org/Archives/Public/www-svg/2009Nov/0015.html
Comment on attachment 475692 [details] [diff] [review]
wip. Need some advice please

I'm not familiar with the APIs being implemented in this bug, so I'd defer to jwatt or longsonr on giving feedback on this.  Also, I'm changing "review?" to "feedback?", since (as you said) this isn't done yet & you're just looking for feedback.

Since you asked, here are some coding-style nits:

>+void
>+nsSVGSVGElement::evaluateList(PRBool enclosure_test, nsIContent* node,
>+                           nsBaseContentList* contentList,
>+                           gfxRect* ref){

Mozilla coding style is to have function names be capitalized in  C++, so "evaluateList" should be capitalized.

Also (though we don't follow this everywhere), function-arguments should generally be prefixed with an "a" and be camelCase, not underscore_separated. (e.g. "aEnclosureTest", rather than "enclosure_test")

And the 2nd & 3rd lines quoted above need two more spaces of indentation to line up.

>+      if (ref->Contains(nodeBBox)){
>+        contentList->AppendElement(node);
>+      } else {
>+        return;
>+      }

>+  nsCOMPtr<nsINode> _node = do_QueryInterface(node);

Rename "node" to |aContent| or |aElement| (since it's a nsIContent*), and rename "_node" to "node".

>+  for (i=0; i < length; i++){

Add a space on either side of the "=".

>+  nsBaseContentList* contentList = new nsBaseContentList();
>+  NS_ENSURE_TRUE(contentList, NS_ERROR_OUT_OF_MEMORY);

"new" never fails in Mozilla code now (or rather, it aborts instead of failing), so there's no need to check for out-of-memory.

>+  void evaluateList(PRBool enclosure_test, nsIContent* node, nsBaseContentList* contentList,
>+                           gfxRect* ref);
>+

This line is too long -- please wrap to <80 characters. (also, the indentation is off on the second line)
Attachment #475692 - Flags: review?(dholbert) → feedback?(jwatt)
(Reporter)

Comment 10

7 years ago
1) And checking SVG 1.1 second edition: http://www.w3.org/TR/2010/WD-SVG11-20100622/struct.html#__svg__SVGSVGElement__getIntersectionListIt says that referenceElement: "If not null, then any intersected element that doesn't have the referenceElement as ancestor must not be included in the returned NodeList."2) My interpretation of "intersects" is in the mathematical sense: If an element's bbox overlaps in any way with the argument rectangle.3) I would agree with your interpretation, another way to interpret this is when referenceElement is null, all elements are checked (so start at <svg>).
(Assignee)

Comment 11

7 years ago
hmmm... It seems that the implementation of these functions is much more complicated than I had thought! I was considering only intersections of bounding boxes. We are really talking about intersection of the verctors themselves? That is certainly more complicated...
(Assignee)

Comment 12

7 years ago
(In reply to comment #9)
> Also (though we don't follow this everywhere), function-arguments should
> generally be prefixed with an "a" and be camelCase, not underscore_separated.
> (e.g. "aEnclosureTest", rather than "enclosure_test")

Does this rule apply also to _retval ? should it be aRetVal instead or is it a special case where we prefer _lowercase ?
Mm, good question - "_retval" should be all-lowercase, according to an MXR search I just did.  I'm not sure why, but that's the convention. :)
(Assignee)

Comment 14

7 years ago
Created attachment 475884 [details] [diff] [review]
wip. Works but only with simple boundingbox checks

This is an updated version of the previous patch.
It has some refactoring work and it is closer to the mozilla coding style.

I have added 2 auxiliary methods to check for enclosure and for intersection of an element (nsIContent*) with a given gfxRect. These methods are currently only checking for enclosure and intersection of the bounding box of the element. These must be improved to also consider the pointer-events criteria.

I need feedback on:

1) proper iteration of the subtree (I am not sure about the correctness of my implementation)
2) how to get a reference for <svg> root element (for the case when referenceElement is nsnull)
3) how to proceed to implement the proper pointer-events criteria
Attachment #475692 - Attachment is obsolete: true
Attachment #475884 - Flags: feedback?(jwatt)
Attachment #475692 - Flags: feedback?(jwatt)
(Reporter)

Comment 15

7 years ago
I wrote a simple test for Opera this morning and they don't use bounding boxes for getIntersectionList()

Comment 16

5 years ago
Any chance this bug could get some love? Been open for a couple of years now.

I agree with Jeff's testing as far as Opera is concerned. Opera's implementation could thus be used as a reference.
Created attachment 717967 [details]
more complete testcase for getIntersectionList

Here is a more complete testcase. This checks complications such as non-rectilinear shapes, transforms, filters, stroke, pointer-events, marker, clipPath and mask.

The fill of any path elements that are included in the list returned by getIntersectionList will turn green.

I've not tested IE, but Webkit and Opera behave very differently.
Attachment #386062 - Attachment is obsolete: true
Attachment #475682 - Attachment is obsolete: true
Created attachment 717969 [details]
more complete testcase for getIntersectionList
Attachment #717967 - Attachment is obsolete: true
Comment on attachment 475884 [details] [diff] [review]
wip. Works but only with simple boundingbox checks

Things that are unclear in the spec:

 * what "rendered content" means

 * what the effect of non-rectilinear shapes, transforms, filters, stroke,
   pointer-events, marker, clipPath and mask should be

 * what "Each candidate graphics element is to be considered a match only
   if the same graphics element can be a target of pointer events as
   defined in ‘pointer-events’ processing" means. (Opera seems to take this
   to mean something like "points that render that would also react to
   pointer events" contribute, whereas Webkit only seems to pay attention
   to whether or not pointer-events="none".

I think at least these points need to be clarified before there's any point reviewing a patch, since the answers will greatly influence the patch.
Attachment #475884 - Flags: feedback?(jwatt) → feedback-

Updated

4 years ago

Comment 20

3 years ago
There seems to be problems with getIntersectionList in FireFox 29, seems like it's currently not included ?
Keywords: dev-doc-needed
Comment hidden (advocacy)

Comment 22

2 years ago
This does not seems to be implemented in Nightly build 42.0a1

test FF (fails)  Chrome IE (succeeded)
http://www.xn--dahlstrm-t4a.net/svg/interactivity/intersection/sandbox_hover.svg


Any confirmation ?

Comment 23

2 years ago
Test case for these and the other related methods (elementFromPoint, elementsFromPoint, etc)

http://jsfiddle.net/y0mthrd5/2/

FF is the last major browser not to have implemented these.

Comment 24

2 years ago
Although Chrome and Safari support getIntersectionList(), their implementation has a bug which severely limits the usefulness of the API:
- http://crbug.com/370012
- https://bugs.webkit.org/show_bug.cgi?id=81137
Comment hidden (advocacy)
Blocks: 1262352
Hi, Felipe Corrêa da Silva Sanches. If you don't mind, I would like to take over this bug.
Flags: needinfo?(juca)

Comment 27

a year ago
It seems we're waiting for answers to comment 19. Do you have them?
Flags: needinfo?(dmu)
Not yet really. I will think about it
Flags: needinfo?(dmu)

Comment 29

8 months ago
Hi guys is there any update on the implementation of the getIntersectionList() API? is this being actively looked it? its hindering a lot of applications that use that api on chrome and IE. They have to put a polyfill for this

Comment 30

2 months ago
(In reply to Robert Longson from comment #27)
> It seems we're waiting for answers to comment 19. Do you have them?

The SVG1.1 2e spec (16 August 2011) seems abundantly clear on the behavior, https://www.w3.org/TR/SVG11/struct.html#__svg__SVGSVGElement__getIntersectionList reads in full:


    Returns the list of graphics elements whose rendered content intersects the supplied rectangle. Each candidate graphics element is to be considered a match only if the same graphics element can be a target of pointer events as defined in ‘pointer-events’ processing.


Put another way, you're given a rectangle and an element in question. If the element were "frontmost", could an anywhere within said rectangle result in a pointer event?

You must already have that logic for determining whether an element is under a given point for interaction purposes (clicks, hovers, etc.), right? Whatever "rendered content" and "non-rectilinear shapes, transforms, filters, stroke, pointer-events, marker, clipPath and mask" rules that apply *there* are clearly intended to apply *here*.

Comment 31

2 months ago
Sorry, bad editing on my key point:

If the element were "frontmost", could an _interaction_ anywhere within said rectangle result in a pointer event?

Rephrasing for mouse-only: could you click somewhere inside the given rect and hit the element in question, assuming nothing else in the way? If so, it's part of the list.
You need to log in before you can comment on or make changes to this bug.