Re: [w3c/pointerlock] Add lock options to requestPointerLock (#49)

@james-howard commented on this pull request.



> +                current [=pointer-lock options=] and [=options=] are not
+                supported:
+                  <ol>
+                    <li>[=Queue an element task=] on the [=user interaction
+                    task source=], given this, to perform the following steps:
+                      <ol type='i'>
+                        <li>[=Reject=] <var>promise</var> with a
+                        "{{NotSupportedError}}" {{DOMException}}.
+                        </li>
+                      </ol>
+                    </li>
+                    <li>Return <var>promise</var>.
+                    </li>
+                  </ol>
+                </li>
+                <li>If [=options=] are not equivalent to the current

Are you asking why an application would want to change their unadjustedMovement flag without unlocking and re-locking?

As in, is there is a use case for the following pattern?

```
element.requestPointerLock({unadjustedMovement: false})
// ... some time later, but still with the pointer locked
element.requestPointerLock({unadjustedMovement: true})
// ... some more time later, but still with the pointer locked
element.requestPointerLock({unadjustedMovement: false})
```

We use this pattern in cloud gaming. The reason is even when the mouse cursor is visible (you're using the mouse as a pointer), we need to confine the cursor within the window for certain types of games (e.g. real time strategy games that scroll the map when the cursor is placed at the edge of the window). So in that case we want accelerated movement to match mouse feel at the desktop, but we move a cursor image around the screen rather than relinquishing pointer lock. When the game requests the cursor be hidden and locked such as for 1st person 3D camera control, we switch the unadjustedMovement flag to true so that the 3D camera control feels natural. When the game exits this mode and unhides the game cursor, we go back to unadjustedMovement = false so that the cursor control feels right for use as a pointer again, but we continue with pointer lock so the cursor cannot exit the browser window.

If we didn't have the ability to change unadjustedMovement without relinquishing pointer lock, we would run the risk that in between unlocking and re-locking the cursor that the cursor could escape the window and the user would inadvertently click on something else. There are games that rapidly swap between unaccelerated (for 3D camera control) and accelerated (for pointer control) that can get intense and losing focus due to the cursor escaping the window would be a big problem.

I can think of some other solutions to these problems, but they would be quite large changes to the spec. 

One potential solution would be to not have an unadjustedMovement option at all, but instead just include unacceleratedMovementX/unacceleratedMovementY on all events that user agents could populate. One reason I suspect that wasn't done in the first place is on some platforms (e.g. Windows), it's not easy to correlate accelerated movement events with unaccelerated movement events (they come from different subsystems at possibly different times).

Another potential solution would be to add API for mouse confinement, which the spec [currently notes as a possible future enhancement](https://www.w3.org/TR/pointerlock-2/#why-bundle), that could then be used in lieu of unacceleratedMovement = false in the application described above. This would actually be best, because the difference between the native hardware cursor vs a cursor image being repositioned by javascript is something you can feel, but of course it would be a big change and it's somewhat of a separate topic.

---

P.S Sorry if I just wrote a novel in response to the wrong question, but I wanted to jump in here and represent our use for changing movement types without relinquishing pointer lock rather than lose it in the final version of the spec.





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

Message ID: <w3c/pointerlock/pull/49/review/1709123038@github.com>