- From: Rick Byers <rbyers@google.com>
- Date: Fri, 30 May 2014 17:30:51 -0400
- To: Jacob Rossi <Jacob.Rossi@microsoft.com>
- Cc: "public-pointer-events@w3.org" <public-pointer-events@w3.org>, input-dev <input-dev@chromium.org>
- Message-ID: <CAFUtAY9Pbi5=nEVrZp2xAYtAxvwpJDMOQMvwSLwu+DGppjiVZw@mail.gmail.com>
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 Friday, 30 May 2014 21:31:38 UTC