Impact of pointer capture on hit testing requirements / performance

Hi,
Do we think it's important that we require UA's to fire
pointerover/pointerout when crossing the boundary of an element that
currently has capture for that pointer?

I ask because this requirement means that there's no way for an application
to suppress the need for the UA to do hit testing on every pointermove
(although in theory a UA could implement a simpler hit-testing algorithm in
this case).  In our performance testing of Polymer, we've found this
additional hit test to have some measurable overhead relative to using
touch events directly, and it's causing some people to ask whether it's
really worth using pointer events in polymer as a result (!).

I'd like to change the Polymer PointerEvent polyfill not to do hit testing
on pointermove at all when an element has capture - then a carefully
designed application/framework should be able to get essentially the same
performance out of using pointer events as using raw touch events.  But
doing that would violate the below text we agreed to add to the spec :-)

Thanks,
   Rick

On Wed, Nov 13, 2013 at 2:31 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

> These changes are now reflected in today's Editor's Draft [1]. Please let
> me know if you have any concerns with the changes. Thanks.
>
> -Jacob
>
> [1]
> https://dvcs.w3.org/hg/pointerevents/raw-file/bd674b11481a/pointerEvents.html
>
> -----Original Message-----
> From: Arthur Barstow [mailto:art.barstow@nokia.com]
> Sent: Sunday, November 3, 2013 9:56 AM
> To: public-pointer-events@w3.org
> Subject: Re: Impact of pointer capture on pointerover/pointerout events
>
> Re this comment and the CR comment tracking doc, I set the Resolution to
> "add non-normative note"
> <http://www.w3.org/wiki/PointerEvents/CR-pointerevents-20130509>.
>
> On 10/31/13 4:40 PM, ext Cathy.Chan@nokia.com wrote:
> > Works for me, as long as you
> > s/by targeted by/be targeted by/
> >
> > - Cathy.
> >
> >
> >> -----Original Message-----
> >> From: ext Jacob Rossi [mailto:Jacob.Rossi@microsoft.com]
> >> Sent: Thursday, October 31, 2013 3:49 PM
> >> To: Chan Cathy (Nokia-CIC/Boston); rbyers@google.com
> >> Cc: scott.gonzalez@gmail.com; public-pointer-events@w3.org
> >> Subject: RE: Impact of pointer capture on pointerover/pointerout
> >> events
> >>
> >> "Note: 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 by targeted by the pointer. This has the
> >> effect of suppressing these events on all other elements."
> >>
> >> -----Original Message-----
> >> From: Cathy.Chan@nokia.com [mailto:Cathy.Chan@nokia.com]
> >> Sent: Thursday, October 31, 2013 12:20 PM
> >> To: rbyers@google.com; Jacob Rossi
> >> Cc: scott.gonzalez@gmail.com; public-pointer-events@w3.org
> >> Subject: RE: Impact of pointer capture on pointerover/pointerout
> >> events
> >>
> >> Correct me if I'm wrong. The way I see it (which was not immediately
> >> obvious from the prose), pointer capture effectively redirects all
> >> pointerup, pointermove and pointercancel(?) events of the pointer to
> >> the element that has capture, while suppressing the pointerover,
> >> pointerout, pointerenter and pointerleave events of that pointer on
> >> all other elements. Maybe that's what should go into the note?
> >> - Cathy.
> >>
> >>> From: ext Rick Byers [mailto:rbyers@google.com]
> >>>
> >>> On Thu, Oct 31, 2013 at 2:51 PM, Jacob Rossi
> >> <Jacob.Rossi@microsoft.com>wrote:
> >>>> I'm ok with a note as well. Here's suggested text to be placed in
> >>>> section
> >>>> 10:
> >>>>
> >>>> "Note: when pointer capture is set, pointerover, pointerout,
> >>>> pointerenter, and pointerleave events are only generated for the
> >>>> element that has capture as other elements can no longer by
> >>>> targeted by
> >> the pointer. "
> >>> Good, but a little ambiguous as to the precise behavior I think.
> >>> How about replace "for the element that has capture" with "when
> >>> crossing the boundary of the element that has capture" - just to
> >>> make it crystal clear that they're not generated "for" the capture
> >>> element when crossing over other elements.
> >>>
> >>>> -----Original Message-----
> >>>> From: Cathy.Chan@nokia.com [mailto:Cathy.Chan@nokia.com]
> >>>> Sent: Thursday, October 31, 2013 11:39 AM
> >>>> To: rbyers@google.com; Jacob Rossi
> >>>> Cc: scott.gonzalez@gmail.com; public-pointer-events@w3.org
> >>>> Subject: RE: Impact of pointer capture on pointerover/pointerout
> >>>> events
> >>>>
> >>>>> From: ext Rick Byers [mailto:rbyers@google.com]
> >>>>>
> >>>>> This makes sense, thank you.  Do you think it's worth adding a
> >>>>> note to this effect - the reasoning is a little subtle (but the
> >>>>> behavior is intuitive so maybe it's not necessary).
> >>>>>
> >>>> +1 for an informative note.
> >>>> - Cathy.
> >>>>
> >>>>> Sounds like we just need to add a 'not' to the description in the
> >>>>> test (
> >>>>> https://github.com/InternetExplorer/web-platform-tests/blob/ddffbd
> >>>>> c5ed
> >>>>> d63c972b9ee42df1f161fc17778125/pointerevents/capture.html#L16),
> >>>>> and ideally expand the test to validate this.
> >>>>>
> >>>>> Rick
> >>>>>
> >>>>>
> >>>>> On Thu, Oct 31, 2013 at 1:47 PM, Jacob Rossi
> >>>>> <Jacob.Rossi@microsoft.com
> >>>>> wrote:
> >>>>>
> >>>>>> Pointer capture makes it so that pointer events cannot hit test
> >>>>>> to any other element but the one with capture. It follows, then,
> >>>>>> that a move can only be detected to have entered or left the hit
> >>>>>> test bounds of the element with capture ("A user agent MUST
> >>>>>> dispatch this event when a pointing device is moved into the hit
> >>>>>> test boundaries of
> >>>> an element." [1]).
> >>>>>> So, pointerover/pointerout only fire for entering/leaving the
> >>>>>> element with capture but do not fire for entering/leaving other
> >>>>>> elements. This is what occurs in the test case where pointerover
> >>>>>> is dispatched to the element
> >>>>>> (#target0) that has capture.
> >>>>>>
> >>>>>> -Jacob
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Oct 30, 2013 at 2:43 PM, <Cathy.Chan@nokia.com> wrote:
> >>>>>>
> >>>>>>   I don't have anything to add (yet) except a link to the
> >>>>>> original
> >>>> thread:
> >>>>>> http://lists.w3.org/Archives/Public/public-pointer-events/2013Ap
> >>>>>> rJun
> >>>>>> /0120.html
> >>>>>>
> >>>>>>   - Cathy.
> >>>>>>
> >>>>>>   > From: ext Rick Byers [mailto:rbyers@google.com]  > Sent:
> >>>>>> Tuesday, October 29, 2013 10:43 PM  > To: Scott González; Jacob
> >>>>>> Rossi
> >>> Cc:
> >>>>>> public-pointer-events@w3.org  > Subject: Re: Impact of pointer
> >>>>>> capture on pointerover/pointerout events
> >>>>>>
> >>>>>>
> >>>>>>   > Reviving this old thread - I don't think we ever talked about
> >>>>>> it on a call  > (I was away for the following call and it looks
> >>>>>> like we never re-scheduled  > discussing of it).
> >>>>>>   >
> >>>>>>   > The Microsoft test submission says it expects to receive a
> >>>>>> pointerover  > event in exactly this scenario (  >
> >>>>>> https://github.com/InternetExplorer/web-platform-tests/blob/ddff
> >>>>>> bdc5
> >>>>>>
> >> edd63c972b9ee42df1f161fc17778125/pointerevents/capture.html#L16
> >>>>>> ),
> >>>>>>   > but it's not actually validating that it happens and IE11
> >>>>>> appears not to do  > it.
> >>>>>>   >
> >>>>>>   > I think we need some clarity on what the spec intends here.
> >>>>>> Is IE11's  > behavior correct?
> >>>>>>   >
> >>>>>>   > Thanks,
> >>>>>>   >    Rick
> >>>>>>   >
> >>>>>>   >
> >>>>>>   > On Mon, Apr 29, 2013 at 12:08 PM, Scott González <
> >>>>>> scott.gonzalez@gmail.com>wrote:
> >>>>>>   >
> >>>>>>   >> On Fri, Apr 26, 2013 at 4:32 PM, Rick Byers
> >>>>>> <rbyers@google.com>
> >>>> wrote:
> >>>>>>   >>
> >>>>>>   >>> Should we explicitly specify that?
> >>>>>>   >>>
> >>>>>>   >>
> >>>>>>>> I wouldn't expect any over/out events during capture.
> >>>>>>   >>
> >>>>>>   >> Also should we explicitly specify the meaning of
> >>>>>> relatedTarget for the  >>> pointer events analogous to the mouse
> >> events?
> >>>>>>   >>>
> >>>>>>   >>
> >>>>>>   >> This seems like a good idea.
> >>>>>>   >>
> >>>>>>
> >>>>
>
>
>
>