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

Hey Daniel,
I see you recently marked
<https://github.com/Polymer/PointerEvents/commit/b80d4c2f282758e68c0e9805ee3700b0c36256f2>
the PointerEvents repo as "deprecated".  Does this reflect a change to your
position earlier in this thread ("plan to maintain"...)?  Any advice for
people in the PointerEvents community looking to use the polyfill in their
own projects?

By the way, I'm working on a hit-test cache feature
<https://code.google.com/p/chromium/issues/detail?id=398920> in blink that
I hope will (among other benefits) address the shadow DOM hit-test perf
problem you hit (without requiring any new shadow-piercing API - yay!).

Thanks,
  Rick



On Tue, Apr 15, 2014 at 9:12 AM, Rick Byers <rbyers@google.com> wrote:

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