Re: Mouse Lock

On Mon, Aug 22, 2011 at 8:13 PM, Vincent Scheib <scheib@google.com> wrote:

> What are the units of .movementX/Y if we're reading 'raw' input device
> coordinates? Are they consistent across devices and platforms? Can we
> specify them?
>

I don't think any units can be specified here, since it's device-dependent
and possibly OS-dependent (even if all systems give access to unprocessed
USB units, units from devices are probably device-specific anyway).  I don't
think it's important, as long as it's clear to developers that delta units
are *not* the same as coordinate units: they can't assume that a dX of 1 is
the same as moving the mouse cursor one pixel to the right.

In that case, it seems preferable for the delta units to *always* have
different units.  If some implementations have the same units in both,
people would start depending on that, which would obviously cause problems.

> Option A: as currently drafted: reuse existing mouse events, make minimal
modification to MouseEvent to include movementX/Y valid regardles of mouse
lock state, mouseover & mouseout will never be fired under mouse lock.
> pro 2. movementX/Y available even when mouse is not locked. Purely a
convenience, apps could compute similar data by tracking the last position
of a mouse event and computing deltas (resetting last position on a
mouseover event).

"Purely a convenience" is incorrect.  Once the mouse cursor reaches the edge
of the screen, you can no longer detect motion in that direction by
examining the cursor position.  That's why you either need to warp the mouse
or use raw input events.  (Remember, mousemove events are still sent when
the mouse is outside of the window, if the user is dragging.)

> MouseEvent to include movementX/Y valid regardles of mouse lock state

I don't think it's possible to both 1: use the same units as the cursor
(screen pixels) and 2: get this information when the cursor is visible.  If
you use the raw APIs (eg. WM_INPUT), you get untouched device units, not
screen units; so you lose #1.  If you use the higher-level APIs, you need to
warp the cursor to the center continually (to prevent clamping against the
edge of the screen), in which case you lose #2 instead.  (An OS could
provide the necessary APIs to implement this, but I don't think they do.)

You forgot a con with this approach: There's no way of exposing
functionality of high-res mice.  You can only detect mouse motion when it's
far enough to cause the (unseen) cursor to move a pixel, because you're
reporting motion in terms of cursor movement, rather than the
higher-resolution data provided by the device.  You're also forced to
receive mouse acceleration and I believe axis locking ("improve pointer
precision" in Windows), which may not always be wanted for first-person
games.  (You also can't expose the ability of modern mice to report at
higher rates, eg. 1khz, for the same reason; I'm personally ambivalent about
this since I don't have any use cases for it, but others may.)

> New mouse events created with unique names for click, down, up, move, e.g.
mouselockclick, mouselockdown, mouselockup, mouselockmove.

I'm confused: was this suggested?  I suggested a single event fired for
delta movement, eg. "mousedelta", but of course there wouldn't be separate
events for clicks, too; clicks are orthogonal to motion.  (I'm confused that
you dismissed what seems like the obvious approach as "not worth
discussing".)

Also note that in this model, there would be no "mouse lock" to begin with;
mousedelta events would simply be fired all the time, alongside and
independent from mousemove events, presumably on the document or the
window.  A separate feature would be needed to contain the mouse to a
rectangle (to prevent the cursor from drifting into another window where
clicks might do something unwanted); and if the application wants to hide
the cursor it would need to do so itself.

In summary, pros:

- High-resolution mouse movements can be reported accurately, which isn't
possible with anything based on cursor movement.
- Axis-locking won't be applied; games don't want this.
- Mouse acceleration won't be applied; games may not want this.
- High-frequency data can be reported (if anyone cares).
- Mouse deltas can be used without invoking any API that might prompt the
user.  It's okay to ask "allow this site to lock the mouse?" when you start
a game for the first time, but it would be unacceptable for GMaps when the
user simply tries to drag the map around.  (Note that the abovementioned
mouse containment API would ask permission, but you wouldn't need to use
that for the dragging use case.)
- This is much simpler.  There's no need to talk about locking screenX, etc.
to some position, whether mouseover events are fired, restoring the cursor
position on unlock, and so on; all of that just goes away.

Cons:

- Units don't match cursor movement.  The only case I can think where this
matters is dragging, eg. GMaps: dragging would move the map at a different
rate than the cursor ordinarily moves.

-- 
Glenn Maynard