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

Merging threads.  See inline.

On Tue, Apr 15, 2014 at 5:15 PM, Arthur Stolyar <nekr.fabula@gmail.com>wrote:

> Forgot to add subject, prev. comment:
> http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0022.html
>
> Also I am a bit confused with this 'avoid pointerover/out handlers on the
> element and all its ancestors'--why need to check ancestors for
> pointerover/out events when pointer capture is active? In case with js
> polyfill. this check might be slower than just hit test.
>

Earlier in this thread Jacob argued why a captured pointer needed to send
pointerenter/leave/over/out events when the pointer crosses the bounding
box of the capturing element (to show/hide any pressed state).  So if a
browser / polyfill is going to implement an optimization to avoid hid
testing entirely, it can only do that if it knows no-one cares about these
events.

On Tue, Apr 15, 2014 at 2:54 PM, Arthur Stolyar <nekr.fabula@gmail.com>
 wrote:

> Hi, Rick
>
> I am developing Pointer Events polyfill for my library and this is also
> very important for me.
>
> As I understand, to get full control over element with pointer capture
> (i.e. recive all pointermove events) element should have at least
> touch-action: pan-[x|y];. Therefore UA has no perf problems with scrolling
> and send pointemove events 'synchronously' (in terms of multi-tread
> arhitecture, I think).
>

That's incorrect.  The pointer events spec specifies that you never receive
pointermove events while scrolling (you get pointercancel as soon as
scrolling starts).  So you need to set touch-action: none to disable
scrolling and get all pointer events.

My propose is to add to the pointermove evebt default action which
> implicitly is already -- hit testing. So, if pointermove 'll be cancelable
> event, then any developer may prevent his testing by calling
> preventDefault() on pointermove, at least when pointe capture is active.
>

Once the event is dispatched to an element it's too late to "prevent hit
testing".  The results of hit testing was used to determine which elements
to send the event to.


> Thanks
>
>

> 2) Pointer Events requires a hit test on every move, although it can be
>> avoided if the developer is careful. Eg. they must call setPointerCapture
>> AND avoid any pointerenter/leave handlers on the element with capture, and
>> also avoid pointerover/out handlers on the element and all its ancestors.
>> We are concerned that in practice developers will rarely be this careful.
>
>
>
> --
> @nekrtemplar <https://twitter.com/nekrtemplar>
>