W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2014

Re: Exposing high-frequency mouse/touch movement?

From: Rick Byers <rbyers@google.com>
Date: Mon, 2 Jun 2014 15:27:23 -0400
Message-ID: <CAFUtAY9GyMj2UZCegzzzjeGFndz14KCiVmJFmsYs0jFD3wLfSw@mail.gmail.com>
To: Jacob Rossi <Jacob.Rossi@microsoft.com>
Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>, input-dev <input-dev@chromium.org>
I've added exposing such an API to our v2 wishlist here:

That's good enough for me for now, I don't think this is urgent.

On Fri, May 30, 2014 at 5:30 PM, Rick Byers <rbyers@google.com> wrote:

> On Fri, May 30, 2014 at 5:08 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
> wrote:
>> On Fri, May 30, 2014 at 3:34 PM, Rick Byers <rbyers@google.com> wrote:
>> >
>> > +chromium input-dev since some folks there have been involved in
>> specific scenarios.
>> >
>> > We've had some complaints about gaming scenarios involving the mouse
>> (for games that are fast enough to process more than one input event during
>> a frame).  We are also starting to put a bit of effort into stylus
>> scenarios (eg. working with Wacom to add some minimal support to ChromeOS
>> via MouseEvents). I agree that it's unlikely to be very important for touch
>> due to the inherent imprecision, but in general we're always looking to
>> expose all the power of our underlying platform - so we at least want to
>> understand this problem better to help prioritize.
>> >
>> > So if it's stylus scenarios that are more important to you, why does
>> Windows 8 seem to have a touch-specific API here?
>> My team doesn't build Windows Runtime APIs, but I'll speculate.  Since
>> WinRT is Windows only and there's a versioning system in place for apps,
>> they can afford to err on the side of the kitchen sink approach to provide
>> more capabilities.
>> > Is there some other way to get the full history (or disable coalescing)
>> for stylus events?
>> History, yes:
>> http://msdn.microsoft.com/en-us/library/windows/desktop/hh454889(v=vs.85).aspx
>> Disable coalescing, no (for any input type).
> Ah, sorry.  I totally missed that - makes sense how.  I searched for a
> similar mouse API but just found the confusing MOUSEEVENTF_MOVE_NOCOALESCE
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms646273(v=vs.85).aspx>
> flag.  So I gather you're not aware of any mouse gaming scenarios here
> (like I said, I don't know how legitimate those arguments are)?
> So the conclusion I take from this is that if there's cross-vendor
> interest in better supporting stylus scenarios, we should consider a 'get
> historical events' API for them (and at that point generalizing for all
> pointer types may be reasonable).  We're trying to improve Chrome's
> (virtually non-existent) stylus support, but this piece isn't likely to be
> high priority for us in the near future.
> Rick
>> -Jacob
Received on Monday, 2 June 2014 19:28:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:26 UTC