Re: Blink does not plan to implement pointer events

>
> The hit-testing cost is already removed for pointer-events if you do set a
> 'normal' pointer capture. The hit-testing cost is only incurred if you
> don't set a pointer capture (because it has to compute the element owning
> the event at every single pointer move, like it currently happens for the
> mouse events in all desktop browsers).
> Additonnally, any sane gesture library will definitely set a pointer
> capture for you, so this isn't something you really need to worry about.


As I see here:
https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#setting-pointer-capture
in note section:
| When pointer capture is set, pointerover, pointerout, pointerenter, and
pointerleave events are only generated when crossing the boundary of the
element that has capture as other elements can no longer be targeted by the
pointer. This has the effect of suppressing these events on all other
elements. |

And as I know that means that there still 'll be hit-testing after
setPointerCapture because browser needs to know when pointer leaves/enters
boundaries of captured element.




2014-08-21 0:08 GMT+03:00 François REMY <francois.remy.dev@outlook.com>:

> So the assumption here is that developers will continue to
>>> choose native over web because of the .3ms spent on hit
>>> testing during pointer movement? I think that's really far
>>> fetched. I've met many many developers who prefer
>>> Pointer Events over Touch Events, but less than a handful
>>> of developers who prefer Touch Events over Pointer Events.
>>> I can't imagine that many developers are concerned about
>>> the performance hit in this area over developer ergonomics.
>>>
>>
>> It would be good to have
>> element.setPointerCapture({ trackBoundaries: false });
>>
>> I understand position of Blink here, but PointerEvents are
>> already here and they have this 3ms problem. I think it
>> absolutely should be fixed.
>>
>
> The hit-testing cost is already removed for pointer-events if you do set a
> 'normal' pointer capture. The hit-testing cost is only incurred if you
> don't set a pointer capture (because it has to compute the element owning
> the event at every single pointer move, like it currently happens for the
> mouse events in all desktop browsers).
>
> Additonnally, any sane gesture library will definitely set a pointer
> capture for you, so this isn't something you really need to worry about.
>
> ------
>
> An interesting idea to ponder would be to allow auto-capture to be
> expressable in CSS using "touch-action: trap-pointer", so that you don't
> even have to register an event handler to disable hit-testing on swipe.
> Another good thing would be to specify the hit-testing should be limited to
> the current node and its children, like "touch-action:
> trap-pointer-inside", to specify you only intend your drag to span a
> reduced set of your document. To make this system complete, we could add
> another property like "touch-action: trap-pointer-outside" which would make
> sure the hit-testing during pointer move event do not consider all the
> children of an element independently.
>
> With this, it would be super-efficient to create a drag and drop between
> two columns:
> - the container would have "touch-action: none, trap-pointer-inside"
> - the column containers would have "touch-action: trap-pointer-outside"
> - the column containers would have pointerenter and pointerleave registered
> - the items in the columns would have pointerdown registered (and it would
> register pointerup on the global container)
>



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