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