On Fri, Aug 12, 2011 at 7:50 PM, Vincent Scheib <sch...@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