W3C home > Mailing lists > Public > www-svg@w3.org > November 2009

Re: Again with the getIntersectionList()

From: Alex Danilo <alex@abbra.com>
Date: Sun, 08 Nov 2009 14:09:26 +1100
Message-Id: <QRSRSK.QFCUL1XOHHRC@abbra.com>
To: www-svg <www-svg@w3.org>
Yes, good point.

Totally different, and a lot more work too...

The original post with the subject 'Pointer-events
Suggestion' was about hit-testing from a point.

checkIntersection adds a whole new level of pain
for the implementer. That introduces polygonal
intersections which generally are expensive
operations (although the rectangle case makes
things a bit less onerous).

Alex


--Original Message--:
>All of this discussion misses the fact that we are not hit-testing a point, we have to hit-test a rectangle for checkIntersection.  This means we really need to determine if the sides of the rectangle intersect any shape's fill or stroke depending on the value of pointer-events on that shape.  Doesn't that make it a totally different algorithm altogether?
>
>
>On Nov 7, 2009 7:37 PM, "Alex Danilo" <alex@abbra.com> wrote:
>
>Boris Zbarsky wrote: >Andreas Neumann wrote: >> I guess every implementor already has the prerequis...
>
>Well almost.
>
>Yes you do bail out when you get a hit, that's true.
>
>But the code to walk the tree and hit-test is there
>already. So a bit of refactoring to handle that case
>could inhibit the bail out, and instead accumulate
>a list of hit nodes. The top most node in that list
>is the traditionally hit node that would normally
>cause a bail out.
>
>Normally, when you bail out it saves walking the rest
>of the tree, but worst case requires a full walk of
>the tree. Accumulating a list in the process of the
>walk is the same cost, so it could be pretty cheap.
>Much better to do this in the UA than trying to make
>script authors walk through (slow) hoops.
>
>This discussion does bring up an interesting aside
>with relation to the proposals for rendering order.
>Current hit-testing is based in the tree/document order.
>If rendering order changes come in, there will be
>serious performance hits for the changed render model
>so that needs to be included as part of all this too.
>
>In any case, what makes author's lives easier is
>what we really want as much as poor implementors
>have to suffer - but they only suffer the
>implementation pain once...
>
>Alex
>
>
>>-Boris
>>
>>
>>
>
>
>
>
>
>
Received on Sunday, 8 November 2009 03:10:09 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:43 GMT