Re: [polymer-dev] PSA: PointerEvents and PointerGestures are being replaced by polymer-gestures, breaking changes for pointer* events

Thanks Daniel.  I know this was a tough decision for the Polymer team.  I'm
glad we can continue to collaborate on Pointer Events and the polyfill!

Rick


On Mon, Apr 14, 2014 at 11:58 PM, Daniel Freedman <dfreedm@google.com>wrote:

> Yes, there are no plans to move it anywhere else.
> On Apr 14, 2014 8:18 PM, "Jacob Rossi" <Jacob.Rossi@microsoft.com> wrote:
>
>>  Will the polyfill continue to live here:
>> https://github.com/polymer/PointerEvents?
>>
>>
>>
>> *From:* Daniel Freedman [mailto:dfreedm@google.com]
>> *Sent:* Monday, April 14, 2014 4:42 PM
>> *To:* Rick Byers
>> *Cc:* polymer-dev; public-pointer-events@w3.org
>> *Subject:* Re: [polymer-dev] PSA: PointerEvents and PointerGestures are
>> being replaced by polymer-gestures, breaking changes for pointer* events
>>
>>
>>
>> It is my hope that when PointerEvents has a few more native
>> implementations, then polymer-gestures can transition to being a consumer
>> of PointerEvents only, and we can reinstate the polyfill for other browers.
>>
>> To that end, I plan to maintain the PointerEvents polyfill to follow the
>> spec as it evolves (thankfully there have been few breaking changes since
>> the WG started).
>>
>>
>>
>> Unfortunately, the polyfill's performance penalty on mobile is an
>> information problem, and not one I see workarounds for in the near to
>> medium term.
>>
>> Target finding seems to be expensive no matter which way I try to slice
>> it, and mobile already operates at a tremendous speed disadvantage.
>>
>>
>>
>> I do not intend this change to be negative signal on the part of
>> PointerEvents, but an (unfortunate) acceptance of the practical realities
>> of mobile devices and polyfill performance.
>>
>>
>>
>> On Mon, Apr 14, 2014 at 4:23 PM, Rick Byers <rbyers@google.com> wrote:
>>
>> +public-pointer-events
>>
>> What does this mean for other consumers of the PointerEvents polyfill?
>> Will it be effectively orphaned?
>>
>> On Apr 14, 2014 7:15 PM, "Daniel Freedman" <dfreedm@google.com> wrote:
>>
>>   Hi Polymer users,
>>
>>
>>
>> We recently had a big perf investigation of mobile use cases and found
>> that our gesture layer was not performant enough to get 60 FPS[1].
>>
>> For this reason, I have created the polymer-gestures library which
>> gesture events in a mobile-performant way.
>>
>>
>>
>> In the next release, polymer-gestures will replace (the now deprecated)
>> PointerGestures, and PointerEvents will be removed from the default build.
>>
>>
>>
>> These are the supported events of polymer-gestures:
>>
>>    - down
>>    - up
>>
>>
>>     - Same target as down, provides the element under the pointer with
>>       the relatedTarget property
>>
>>
>>    - trackstart
>>    - track
>>
>>
>>     - Same target as down
>>
>>
>>    - trackend
>>
>>
>>     - Same target as down, provides the element under the pointer with
>>       the relatedTarget property
>>
>>
>>    - tap
>>
>>
>>     - Targets the nearest common ancestor of down and up.relatedTarget
>>       - Can be prevented by calling any gesture event's preventTap
>>       function
>>
>>
>>    - flick *
>>    - hold *
>>    - holdpulse *
>>    - release *
>>    - pinchstart *
>>    - pinch *
>>    - pinchend *
>>
>> * = "Not yet implemented"
>>
>>
>>
>> If you listen for pointerdown, pointermove, pointerup, pointerover,
>> pointerout, pointerenter or pointerleave, you will need to change your code.
>>
>> If you require an event for every movement of the pointer, you can use
>> the "track" event.
>>
>>
>>
>> This change was not made lightly, but only after careful consideration of
>> device constraints and lack of cross-browser PointerEvent implementations.
>>
>> The Polymer team still believes that PointerEvents are the best technical
>> solution for handling user input, but mobile use cases are too important to
>> be gated on native implementations.
>>
>>
>>
>> I apologize for the churn.
>>
>>
>>
>>
>>
>> [1]: The big culprit was the gymnastics the PointerEvents polyfill had to
>> make to be spec compliant and target the correct elements with ShadowDOM.
>>
>> In particular, the encapsulation mechanics of ShadowDOM made target
>> finding for pointermove very expensive, requiring recursive
>> elementFromPoint calls.
>>
>> Another large chunk of time was wasted on having gesture recognizers
>> listen for dispatched, normalized pointerevents.
>>
>> Polymer-gestures will use the lower-level events directly without
>> spinning up the DOM event system N times each pointer movement.
>>
>> Follow Polymer on Google+: plus.google.com/107187849809354688692
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Polymer" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to polymer-dev+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/polymer-dev/CAAUAVAgorf1-V2iiB%3Dub02QiJtMd%2BE4cXPzGXK3LrQDCxFXNQQ%40mail.gmail.com<https://groups.google.com/d/msgid/polymer-dev/CAAUAVAgorf1-V2iiB%3Dub02QiJtMd%2BE4cXPzGXK3LrQDCxFXNQQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> Follow Polymer on Google+: plus.google.com/107187849809354688692
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Polymer" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to polymer-dev+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/polymer-dev/a2f5ee249e5d4028862d8dd5998cac6a%40BY2PR03MB457.namprd03.prod.outlook.com<https://groups.google.com/d/msgid/polymer-dev/a2f5ee249e5d4028862d8dd5998cac6a%40BY2PR03MB457.namprd03.prod.outlook.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>