Re: [pointerevents] Define a low latency event that isn't occur in the document lifecycle

Here's another use case that (while less compelling) is a lot simpler and easier to reason about IMHO: a music synthesizer / DJ application that creates/modifies sound somehow in response to touch position.  In that high frequency and low latency are very important, while aligning with any form of visual output is unimportant (though there's probably still some visual feedback somewhere, the primary output is audio).

The problem I have with a global "use high frequency" hint is that whether or not you want (and are designed to handle) high-frequency events is really a per-handler question.  We know from our touch scrolling work that the vast majority of touch event listeners installed on the web today are for non-primary use cases (eg. activity monitoring, analytics, etc.). If we change the timing of an event for one handler then invariants expected by other handlers for the event (both around timing and frequency) would be broken.  The cross-iframe case here is the worst since there's not necessarily any chance for the impacted code to co-ordinate, but the problem exists within a single frame as well.

If we don't want to introduce a new "pointerrawmove" event type then other options I can imagine that avoid the above problem are:

1. A "enable unbuffered mode" API (or option to `setPointerCapture`) that can be called on `pointerdown`.  This most directly mirrors the [Android API](https://developer.android.com/reference/android/view/View.html#requestUnbufferedDispatch(android.view.MotionEvent)).  To avoid the above issues I'd ideally want calling this API to disable event bubbling, so global activity monitor listeners would just not see the movement at all rather than force coalescing and loss of frequency for the high-frequency handler.

2. Add a polling API (like used by [Gamepad](https://w3c.github.io/gamepad/#gamepad-interface)) where an app can query, at it's own rate, for the current state of a pointer.  This has a lot of overlap with prediction - #38, I could imagine an API like `PointerEvent#estimatePointerState(DOMHighResTimestamp)` which returns a `PointerEvent` with the estimated position (and other properties) for the input pointer at the given timestamp.  Or maybe the provided timestamp is just a hint and the application should rely on the timestamp in the returned event, eg. so we can refuse to try to predict farther in the future than is reasonably practical, or even refuse to predict into the future at all if not supported by an implementation.

WDYT?


-- 
GitHub Notification of comment by RByers
Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/214#issuecomment-320454568 using your GitHub account

Received on Saturday, 5 August 2017 16:56:18 UTC