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

2014-04-16 2:15 GMT+04:00 Rick Byers <>:

> Merging threads.  See inline.
> On Tue, Apr 15, 2014 at 5:15 PM, Arthur Stolyar <>wrote:
>> Forgot to add subject, prev. comment:
>> 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.

Sorry, I was not clear. I understand why, but I not understand why need to
check ancestors since only element with active 'pointer capture' can recive
pointer events for that pointer. So if one or more ancestors has out/over
listeners then that listeners 'll not be called anyway, only out/over
leave/enter 'll be called right on element with 'pointer capture'.

> On Tue, Apr 15, 2014 at 2:54 PM, Arthur Stolyar <>
>  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.

Yes, 'none' for both axes. But with pan-x for example, JS 'll recive
pointermove events if user swipes along Y axis. Sorry, phrase 'get full
control' was wrong. It is hard to me to explain on English.

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

Yes, I understand that. But for case with 'pointer capture' target element
is locked on setPointerCapture and subsequent hit testing calls needs only
for determining that pointer leaves captured element or not.
I try to explain:

pointerdown starts at target A
then A.setPointerCapture(pointerId) is called for that pointer
then all events from that pointer are redirected to A element
for pointermove/pointerup/pointercancel there is not need for hit testing
because target is always A
but for firing pointerout/ove/leave/enter hit testing is required to
determine relatedTarget
if relatedTarget found i.e. pointer (finger for example) in not over
element A
then pointerout and pointerleave are fired for A

I am not sure which event should be erlier pointermove or pointerout/leave,
if pointermove must be fired before out/leave then hit testing for
out/leave may be canceled by calling preventDefault() of pointermove event.

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

@nekrtemplar <>

Received on Tuesday, 15 April 2014 22:44:03 UTC