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

2014-04-16 2:15 GMT+04:00 Rick Byers <rbyers@google.com>:

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

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

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 <https://twitter.com/nekrtemplar>
>>
>
>


-- 
@nekrtemplar <https://twitter.com/nekrtemplar>