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

Oh, I'm a little surprised that IE sets :hover when touching on one element
and dragging over another.  I guess this makes sense since it's consistent
with mouse behavior.  For blink, touch has always followed a model where
the user is interacting only with the element they first put their finger
on (since that's baked into the implicit capture property of touch events),
and so we've never set :hover in this way.  Your button scenario makes
perfect sense though, thanks!

Ok, I'll have to gather some more data and get back to you.  A single hit
test is relatively quick for us, but when (say) dragging an element around
with CSS 3D transforms trying to get rock-solid 60fps on a slow mobile
device, a single hit test on each frame can apparently make a non-trivial
contribution to overrunning our 16ms budget for the frame (although I
haven't looked at the data myself yet).  It's still a small fraction, but
we have LOTs of things that are a small fraction of the frame time which
can add up to overrunning the time for the frame if we're not careful.

I was trying to think of how to optimize the hit test for this case.  It's
non-trivial (both inside of blink, or in Polymer JavaScript code) because
there could be any number of unrelated elements overlapping the capturing
element so the boundary isn't easily describable.  I think a better
optimization would be to skip the hit test entirely when the capturing
element has no pointerover, pointerout, pointerenter, or pointerleave
handler and no :hover style.  For the cases I'm concerned with, I think
this would typically be true anyway.

Rick


On Tue, Jan 28, 2014 at 12:42 AM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

> 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). :-)
>
>