[w3c/pointerlock] Allow applications to access higher-precision mouse movement data (Issue #102)

The [main uievents specification](https://w3c.github.io/uievents/#mousemove) leaves the frequency of mousemove events up to the implementation. In many major browsers this is around 15-60 events per second, which can result in the pointer skipping tens or even hundreds of pixels in between consecutive events. This poses a problem for applications that need careful tracking of the mouse position, as it results in unavoidable lag that can be very noticeable to the user. ([Example](https://stackoverflow.com/questions/25036169/latency-when-following-mouse-cursor-on-canvas))

If the PointerLock API is intended to bring web applications more in line with what's possible in a native app, it needs to address this limitation.

The most straightforward way to do this would be to mandate a minimum frequency of mousemove events on PointerLocked elements, such as at least 120 times per second while the pointer is moving, or at least once for every pixel of movement. However this may lead to performance and/or implementation difficulties given the complexity of the Javascript event system.

So perhaps a better approach would be to allow the application to query raw mouse location data whenever it needs it via a separate `getPointerLockMousePosition()` method. This method would return an x and y value that represent the *true* mouse position down to the ~millisecond level; not the position it had the last time a mousemove event was fired.

(Since PointerLocked elements stop using the normal screen coordinates, the coordinate system used by this method would be arbitrary; the values only matter in relation to other values. Perhaps 0,0 could be set to the location where the pointer was when the PointerLock was created.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/pointerlock/issues/102
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/pointerlock/issues/102@github.com>

Received on Thursday, 28 November 2024 23:15:03 UTC