Re: Again with the getIntersectionList()

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 UTC