Re: Mouse Lock

I agree with you that the deltas should be in a separate event. That would
also be the most logical because moving the cursor(corresponding to a
"mousemove" event) and physically moving your mouse are separate things. If
"mousemove" wasn't already used for cursor movement("mousemove" imo should
have been called "cursormove"or "pointermove"), that would be the most
appropriate name for this new mouse delta event. Unfortunately that isn't
the case so a different name has to be chosen. Maybe:
"mousepositionchanged"? This event should have the same security
restrictions as "mousemove".

Constraining the cursor to an element could work almost the same as the
proposed lockMouse method. The only difference is that the cursor isn't
locked to the center, but limited to the bounds of some element so you get
something like this:

x = document.getElementById("some_element");

x.clipCursor(

function() {

    x.freeCursor();

couldLock = true;

}

);

ClipCursor is the name Windows is using for this, but is could also be
called something like "wallCursor".

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

> On Fri, Aug 12, 2011 at 7:50 PM, Vincent Scheib <scheib@google.com> wrote:
>
>> BTW, draft spec currently states, "When mouse lock is enabled clientX,
>> clientY, screenX, and screenY must hold constant values as if the mouse were
>> located at the center of the mouse lock target element...". I chose this to
>> pick something concrete, but not all zeros which may be used as magic values
>> in JS code, etc. I'm not strong in this opinion.
>
>
> Some things that come to mind:
>
> - Delta movement may be received separately from cursor movement.  For
> example, an implementation may use WM_MOUSEMOVE to generate mousemove
> events, and WM_INPUT to generate mouse delta events, as Klaas pointed out.
> These window messages aren't defined relative to each other; a WM_INPUT
> event may or may not be followed by a WM_MOUSEMOVE event.  A mouse may
> generate WM_INPUT events at 1kHz, but WM_MOUSEMOVE events may only be
> generated at 60 or 120Hz.
>
> This means that you'd either end up generating far more mousemove events,
> eg. three events with delta information followed by a single event with
> cursor information (possibly placing unwanted stress on unrelated mousemove
> event handlers--this is a particular problem with Klaas's model, see below);
> or discarding information, which also seems undesirable.  Using a separate
> event avoids this issue.
>
>
> - The deltas may not be comparable to corresponding cursor movement.  For
> example, mouse cursors often have acceleration and snap-to-axis filters
> applied.  I think these filters aren't applied to the data received by
> WM_INPUT.  Is this a good thing or not?
>
> It's probably a good thing for an FPS, to avoid snap-to-axis cursor filters
> from affecting the viewport.
>
> It's probably a bad thing for dragging Google Maps around.  Having the map
> drag at a different rate than the cursor normally moves may be strange.
> (Using deltas for dragging is useful: you can continually drag the map,
> without having to reposition the mouse cursor every time you reach the edge
> of the screen.)
>
>
> - If mousemove events when locked put clientX, etc. at some arbitrary
> position, are mouseover events generated, as if the cursor had actually
> moved there?  If deltas do end up packed into mousemove events, I'd suggest
> that these properties not change while locked: continue reporting the
> last-generated position, as if the unseen cursor is stationary while
> locked.  When the mouse is unlocked, the cursor is back where it was
> originally; no mouseover events are generated at all, as the cursor
> (distinct from the mouse) never moved.
>
>
> - Klaas suggests an entirely different approach.  Instead of having a
> separate delta mode, mouse deltas would always be available.  "Mouse lock"
> would be achieved by locking the mouse within a rectangle (a separate
> feature entirely from mouse deltas), and hiding the cursor with CSS.
> There's some appeal to having delta information always available, without
> forcing the cursor to be hidden and locked to use them.  It makes the
> dragging (Google Maps) use case simpler: no actual locking is needed, as you
> don't care if the mouse cursor stays within the window--so this use case
> wouldn't be burdened by any security mechanisms required by locking. The
> first two points above still apply here; using a separate mousedelta event
> would still make sense in this model.
>
> --
> Glenn Maynard
>
>