- From: Rick Byers <rbyers@google.com>
- Date: Fri, 30 May 2014 15:34:47 -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: <CAFUtAY-9j9SAOT83yhQuxByXuEwmDXmp0zisV6Ztfq-TFBq2uQ@mail.gmail.com>
+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? Is there some other way to get the full history (or disable coalescing) for stylus events? Thanks, Rick On Fri, May 30, 2014 at 3:17 PM, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote: > What scenarios do you have in mind for this? > > > > On Windows, the primary scenario we see this used for is pen inking for > higher stroke fidelity (e.g. go back and look at the pointer history to > collect more points for the stroke path). But in actuality, I suspect it’s > used by very few applications. > > > > Touch is a rather coarse input device while pens can be very fine as on > graphics artist tablets or devices like Surface Pro 3. So I think this is > less useful for touch. For pen, correct me if I’m wrong, but I haven’t seen > much interest from browser vendors other than Microsoft in targeting pen > scenarios. > > > > -Jacob > > > > *From:* Rick Byers [mailto:rbyers@google.com] > *Sent:* Friday, May 30, 2014 12:48 PM > *To:* public-pointer-events@w3.org > *Subject:* Exposing high-frequency mouse/touch movement? > > > > Platforms typically coalesce movement events, eg. possibly limiting them > to reporting at most 1 per video frame. Some applications want additional > data, for example high-precision drawing and some games. Windows 8 has a > GetPointerTouchInfoHistory > <http://msdn.microsoft.com/en-us/library/windows/desktop/hh454891(v=vs.85).aspx> API > [1] for this (why is this just touch and not all pointers?), and Android > has methods on MotionEvent > <http://developer.android.com/reference/android/view/MotionEvent.html> [2] > for getting historical data out of the event batch. > > > > Should we be exposing something similar to the web? > > > > Other platforms take the approach of having an API to disable > coalescing/batching - eg. setMouseCoalescingEnabled > <https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/Reference/Reference.html#//apple_ref/occ/clm/NSEvent/setMouseCoalescingEnabled:> [3] > on Mac OS X. One big disadvantage I see to this approach is that it treats > all event consumers the same. For a particular event, there may be one > consumer that wants high-resolution data (and can process it efficiently) > while other consumers may get backlogged by an unusually high event > reporting rate. > > > > Thanks, > > Rick > > > > [1] > http://msdn.microsoft.com/en-us/library/windows/desktop/hh454891(v=vs.85).aspx > > > [2] http://developer.android.com/reference/android/view/MotionEvent.html > > [3] > https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/Reference/Reference.html#//apple_ref/occ/clm/NSEvent/setMouseCoalescingEnabled > : >
Received on Friday, 30 May 2014 19:35:34 UTC