RE: Impact of pointer capture on hit testing requirements / performance

On Fri, Jan 24, 2014 at 8:29 AM, Rick Byers <rbyers@google.com> wrote:
>
> Hi,
> Do we think it's important that we require UA's to fire pointerover/pointerout when crossing the boundary of an element that currently has capture for that pointer?

Yes, I think this is an important behavior.  It's common for UI like buttons to take capture, and over/out effects are often used to indicate visually whether the button would activate on lift, for example.

> I ask because this requirement means that there's no way for an application to suppress the need for the UA to do hit testing on every pointermove (although in theory a UA could implement a simpler hit-testing algorithm in this case).  In our performance testing of Polymer, we've found this additional hit test to have some measurable overhead relative to using touch events directly, and it's causing some people to ask whether it's really worth using pointer events in polymer as a result (!).
> I'd like to change the Polymer PointerEvent polyfill not to do hit testing on pointermove at all when an element has capture - then a carefully designed application/framework should be able to get essentially the same performance out of using pointer events as using raw touch events.  But doing that would violate the below text we agreed to add to the spec :-)

It's always faster to do less work. But in this case, having hit testing helps tremendously in a lot of scenarios.  While, yes, touch event code can use APIs like elementFromPoint() to simulate the behavior, there's no replacement for other hit testing behaviors like :hover and it makes having true event dispatch to the hit node cumbersome and perhaps slow. Assuming UAs implement simpler hit-testing in the capture case, the fast path is only one API call away (setPointerCapture) with the current pointer events behavior should you not need the hit-testing.

That said, I'd be interesting in seeing any perf data you might have about the impact here. At least in IE, I would expect a single hit test to typically be negligible (on the order of uS). It's possible for UAs to shortcut the hit testing for a pointer when it is captured by just considering the box of the capture node. We experimented with this in IE, but found the performance wins of not hit-testing to be so small that it didn't warrant the additional complexity to our codebase. But perhaps such an optimization could be tried in Polymer. If not, then perhaps this is an argument for why a native implementation of pointer events is needed (so UAs can short-circuit the hit test with capture). :-)

Received on Tuesday, 28 January 2014 05:42:42 UTC