Re: Again with the getIntersectionList()

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
>
>
>