Re: Exposing high-frequency mouse/touch movement?

I've added exposing such an API to our v2 wishlist here:
https://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements

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