Re: Exposing high-frequency mouse/touch movement?

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 <> wrote:

> On Fri, May 30, 2014 at 5:08 PM, Jacob Rossi <>
> wrote:
>> On Fri, May 30, 2014 at 3:34 PM, Rick Byers <> 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:
>> 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
> <>
> 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