Historical points API implementation interest in Gecko?

Hey,
As discussed in the PEWG call today, we're interested in implementing the
historical points API <https://github.com/w3c/pointerevents/issues/22> in
blink.  We care mainly because it allows us to improve smoothness and
performance of common scenarios (by better coalescing and aligning
pointermove events to vsync), while still giving art scenarios a mechanism
for getting the full position detail for input devices whose frequency is
greater than the display frequency (following the same model already common
on iOS and Android).  For example, we consider Android stylus art scenarios
to already be pretty crippled without this feature (since on Android the OS
already throttles input events to vsync so we're already limited to 60hz
reporting rate).

Ted says this API is unlikely to make it into Edge in the next year.  So
the question is whether there's any interest from Mozilla in implementing
it in Gecko eg. in the next 6 months or so.  If not then we likely can't
take Pointer Events v2 to REC with this API in there, and we should just
move it now to a separate post-v2 incubation document.  But if it might
make it into Gecko in time for V2 to go REC then we might as well put it
into the V2 spec.  Of course we can always pull it out later if we guess
wrong and don't want to hold REC on this, but we might as well make our
best guess now.

So what do you think, worth planning on Gecko having this API sometime in
time for REC (eg. the next 6 months), or better to expect that it will not?

Thanks,
   Rick

On Tue, Oct 4, 2016 at 4:50 PM, Rick Byers <rbyers@chromium.org> wrote:

> Hey,
> Chatting with some folks at TPAC, Once Chrome's implementation hits stable
> (and hopefully Firefox isn't far behind) I expect we'll start feeling the
> pressure to get PEL2 to REC status.  To do this I suggest we start by
> triaging issues and adding the "v2-blocking" label to those we think should
> be resolved before trying to go to CR
> <https://www.w3.org/2015/Process-20150901/#candidate-rec>.  IMHO (without
> being an expert on the W3C process) I think this should include:
>
>    - Any issues where the spec deviates from multiple implementations in
>    a non-trivial way
>    - All outstanding test issues (eg. incorrect failures) - we'll be
>    required to explain any test failures (though it's probably OK if we have a
>    couple - no software is bug free).
>    - Any high-priority features with impl plans in more than one browser.
>
>       - The only one I can think of from the blink side is the historical
>       points API <https://github.com/w3c/pointerevents/issues/22>, which
>       is now urgent for us.  Is Microsoft or Mozilla also interested in
>       implementing this, say, sometime in the next 6 months or so?  If not, then
>       we could move it from PEL2 into incubation instead (eg. a separate WICG
>       spec that extends PEL2).
>    - Any little things that are relatively easy to just fix (no point
>    carrying a bunch of little easy issues)
>
> In contrast, things that are probably not v2-blocking include:
>
>    - New features without concrete implementation plans in 2 or more
>    implementations
>       - we can continue to iterate on these in an incubation mode, eg.
>       either in a separate spec somewhere or, if we prefer, a branch.  But they
>       shouldn't delay the substantial benefits of getting our spec to REC.
>    - Issues that track a deviation in behavior in one browser of the 3,
>    especially when developers are unlikely to be hit by it
>       - Ideally we'll still address all of these, but they don't seem
>       worth blocking L2 on to me (none of us has bug-free software). As long as
>       we have 2 implementations matching the spec in each area that's good enough
>       for REC.
>    - Editorial issues that are hard to get consensus on or otherwise
>    address
>       - Again we should try to make progress, but probably not worth
>       blocking REC.  My personal opinion is that as long as we have good tests
>       that explain concretely what we mean, we can live with some less than ideal
>       spec text.
>
> Sound reasonable?
>
> BTW I have a conflict tomorrow and won't be able to make a call, but
> perhaps it'll be cancelled anyway?  We can iterate on e-mail / GitHub.
>
> Rick
>
>