Re: Guidance for how best to implement smooth multi-touch behavior

On Mon, Mar 9, 2015 at 12:00 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 09/03/2015 15:12, Rick Byers wrote:
>
>> Hi,
>> In working on my InputDevice proposal
>> <https://docs.google.com/a/chromium.org/document/d/
>> 1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit#>,
>> I was digging into Windows lower-level pointer API and was surprised to
>> find that it bundles movements of multiple pointers into a single event
>> (like touch events does, but unlike W3C Pointer events).
>>
>
> Is this related to Gesture Events https://msdn.microsoft.com/en-
> gb/library/ie/dn433243%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
> (which obviously aren't part of Pointer Events, and have so far not - if
> ever - been submitted to W3C standardisation)


Not really.  If MSGesture was implemented entirely in JS then they'd have
to address this question in their implementation.  But I suspect MSGesture
has hooked into Windows gesture system (rather than simply being a JS
library), and so probably already gets event bundles.

 This got me thinking about the differences between these two models.
>> How would we recommend developers implement smooth multi-touch handling
>> with the pointer events API?  Eg. say I want to smoothly handle rotation
>> and zooming by tracking two fingers.  Should I do my calculations on
>> every pointermove event, or (for example) in a RAF callback each frame?
>>
>
> FWIW I've been giving advice to do any heavy calculations of this kind
> using RAF (only storing coordinates on each movement, and then on the
> scheduled RAF call actually do the calculations based on those
> coordinates), and sometimes even using some form of throttling/debouncing
> (even for handling touchmove-related stuff), just to avoid swamping
> lower-end devices. I'd be interested to hear if this is indeed a good
> approach, and what the potential drawbacks would be.
>
> http://patrickhlauke.github.io/getting-touchy-presentation/?full#135


We've told folks there's no benefit to doing this in Chromium for touch
events - it's essentially redundant given our implementation.  You can see
this with http://rbyers.net/event-timing.html - on modern Android we
reliably fire exactly one touchmove event immediately before RAF.  There's
little harm in doing what you suggest for touch events in chromium, so if
it helps with other browsers - go head.  It's a little more subtle for us
at the moment on non-Android platforms (or on Android prior to Jelly Bean),
but we consider that essentially a bug in chromium that we'll get around to
fixing eventually.  Basically Android JB+ has OS support (and on some
devices hardware support) for aligning touch input with screen refresh, and
we leverage that.  We've got code to do this alignment ourselves inside
Chrome on other platforms, but haven't shipped it yet (not clear how much
effort it's worth really).

-- 
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>