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 12:35:29 +1100
Message-Id: <5FORSK.20JJQ8T94AMG@abbra.com>
To: www-svg <www-svg@w3.org>

Boris Zbarsky wrote:
>Andreas Neumann wrote:
>> I guess every implementor already has the prerequisites
>> for this method, since they have to do hit-testing for graphical elements
>> anyway ... so it is mainly a matter of testing not only the top elements,
>> honoring the pointer-events attributes.
>
>Which means a complete rewrite of the hit-testing algorithm, since the 
>hit-testing algorithm bails out once you get a hit, right?

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 01:36:22 GMT

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