The current implementation of getIntersectionList et al is somewhat lacking though. From a spec PoV it makes a lot of sense to implement it using the/a hit-testing code path. (And from a code-sharing PoV it makes even more sense.)
Seems that I'm affected by this, IntersectionObserver doesn't work as expected in SVG.
https://jsbin.com/debugawuno/edit?html,css,js,output
`boundingRect`, `intersectionRect` and `rootBounds` have all 0 values.
@c#6: That sounds like something similar in spirit to issue 847623 , so I'd suggest that you file a separate issue for that. (AFAIU, rect-based hit-tests are not used by IOv1.)
Labels: -Pri-3 Pri-2 Status: Started (was: Assigned)
Plan of action:
1. Refactor the code in PaintLayer that applies transforms into
the HitTestLocation class (not sure how much of it is needed to refactor though).
2. Change all SVG uses of NodeAtFloatPoint to use NodeAtPoint, and delete
NodeAtFloatPoint.
HitTestingTransformState will be used and passed recursively somehow (not sure whether
as additional parameter yet) to avoid re-multiplying matrices on every recursion.
The only concern I can think of with this plan is to preserve the floating-point accuracy
of NodeAtFloatPoint. However, HitTestLocation already has FloatPoint and FloatRect
internally, so it seems that there is no loss of accuracy.
Upping to P2 because this blocks IOv2.
Sounds fine. The use of the floating-point point/rect probably won't be any issue if all new "Intersects" variants that get added use the float query state. (I'd worry a bit about the current Intersects(const FloatRect&) because it seems to do a LayoutRect -> FloatRect conversion for each call.)
I think I feel more worried about all the more or less dead state that HitTestingTransformState + HitTestLocation carry when it comes to hit-testing SVG. Makes not setting them up unnecessarily important I think. (Not sure we have a perf test which has both lots of primitives and transforms.)
Comment 1 by schenney@chromium.org
, Mar 20 2018