Re: Mouse Lock

Basically this is what I said in
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0978.html. But
your pros & cons summarize it nicely.

2011/8/29 Glenn Maynard <glenn@zewt.org>

> 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
>
>