Intent to Implement: PointerLock unadjustedMovement
Ella Ge
Contact emails
eir...@chromium.org, nzol...@chromium.org
Design doc/Spec
https://github.com/w3c/pointerlock/pull/49/
Summary
Adds the ability to request unadjusted and unaccelerated mouse movement data when in PointerLock. If this unadjustedMovement is set to true, then the pointer movements will not be affected by the underlying platform modifications such as mouse acceleration.
Motivation
The accelerated movement is that pointer speed increasing faster than the physical speed of the touchpad/mouse movement. For example moving the touchpad/mouse 3x faster could result in the pointer on the screen moving 9x more than if moved at a slower speed.
Accelerated movement is the default behavior in the major operating systems. However, for some games, it’s important to disable mouse acceleration to achieve a better gaming experience (1, 2). It’s a common option for native gaming app but not available in web gaming yet.
Risks
Interoperability and Compatibility
Compatibility risk is low as it’s adding new capability without affecting existing use case.
Interoperability:
Edge: No Signals
Firefox: No Signals
Safari: No Signals
Web / Framework developers: There are positive signal from web gaming developers in the spec issue.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No. Will Not support on Android because pointerlock is not supported on Android yet.
First version of the implementation will only support Windows. There is also plan to support Linux & Mac.
ChromeOS is working on adding OS level option to disable mouse acceleration (crbug/589190), but per offline discussion, it’s not possible to expose this to Chrome browser yet. We will investigate how to add the support on ChromeOS afterwards.
Is this feature fully tested by web-platform-tests?
Yes. Will add wpt to test the API
Testing the functionality will require low level system api so it’s hard to write an automated test using current testdriver API. We will at least add some manual test.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5723553087356928
Requesting approval to ship?
No.
Vincent Scheib
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0ef11b0-fbdf-48aa-b0e2-a409fd500d8f%40chromium.org.
eir...@google.com
On Friday, August 30, 2019 at 4:06:54 PM UTC-4, Vincent Scheib wrote:
This will address a long standing request. It has my support, as initial specification author.I recommend you keep in mind interesting scenarios such as applications wishing to switch back and forth between modes. Consider a game with in-game options UI that enables users to toggle the setting. The app would like to capture pointerlock, and while locked exit and re-enter in the other lock mode.With the current API proposal: Should it go from adjusted pointerlock to requesting unadjusted, it might fail to regain lock, and then immediately re-request adjusted lock. That should be possible without re-displaying Chrome UI for exiting lock.It may be beneficial to expose the capability directly, so that a lock doesn't need to be exited and re-entered. From a 'fingerprinting' point of view, the information will be exposed either way.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.