W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mouse Lock

From: Klaas Heidstra <klaas1988@gmail.com>
Date: Mon, 29 Aug 2011 01:40:41 +0200
Message-ID: <CAHtyvgbpM6f66z--1gj_vH0rbpOhyp_hmaY01O0=Ud-tR8A2-A@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Vincent Scheib <scheib@google.com>, Yuzhu Shen <yzshen@google.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jonas Sicking <jonas@sicking.cc>, robert@ocallahan.org, Brandon Andrews <warcraftthreeft@sbcglobal.net>, Olli@pettay.fi, Ryosuke Niwa <rniwa@webkit.org>, Adam Barth <w3c@adambarth.com>, "Gregg Tavares (wrk)" <gman@google.com>, Charles Pritchard <chuck@jumis.com>, Kenneth Russell <kbr@google.com>, public-webapps@w3.org
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
Received on Sunday, 28 August 2011 23:41:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC