Re: Mouse Lock

>
> But do you agree with me that "post ballistics", accelerated and low
> resolution is exactly what you don't want for most use cases? Why should it
> not be possible to specify the units I described in my last mail:
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0978.html.


That email describes computing distance traveled of input device presuming
DPI, sampling rate, and a sample's delta data. DPI is unknown (unless I'm
not finding it in APIs e.g. around
http://msdn.microsoft.com/en-us/library/ms645589.aspx).

I believe first developers seek a specifiable solution that will provide a
consistent application experience on all platforms and API implementations.
I further believe that post ballistics data will satisfy most developers and
users; I have asked some e.g. Unity developers about their implementations
and needs, and checked source of other games (e.g. SDL library). Finally, I
believe that it is worthwhile to consider adding some rawer form of the
input data if possible in a v2 implementation and or spec.


>> > 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.)
>>
>>
Sorry, some confusion here. This topic "Modify MouseEvent, or a new type
returned by new mouse events?" presumes the "hide cursor and warp" method,
as do all other sections in my recent summary except section "Provide mouse
deltas without hiding the cursor, alternatively provide a bounding rectangle
for  mouse".

This section is trying to lay out the pros/cons of where to put movement
data. The Option A is to provide movementX/Y when locked and unlocked. When
locked, the cursor disappears and movement data is provided without limit.
When unlocked the mouse events continue to contain that data member and
values are provided with best effort. The system cursor exists and mouse
events are not available when the cursor is not over the window (unless the
mouse is captured). Movement values will stop when the cursor hits a screen
edge. The movement members then become only a convenience because javascript
code can compute the same values by storing last known positions of
screenX/Y and tracking motion with mousemove mouseover.


>> > 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)
>
>
Correct, the proposal is NOT to use raw APIs as described above.

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.)
>
>
I'm deferring consideration for higher resolution mice data and sampling
frequency to a future version of this specification. This was discussed some
in "Provide mouse deltas without hiding the cursor, alternatively provide a
bounding rectangle for mouse". But a summary of my position is that:
- Specification is difficult and may not be possible.
- Implementation is more complex and doesn't seem justified yet.
- Graceful addition of more 'raw' data and higher sampling frequencies is
possible. I'm not saying "We shouldn't implement raw data", but I am saying
we should defer it.
I'm happy to review any prototype patches to the chromium/webkit projects
that answer these issues.


>
>>
>> > 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".)
>>
>>
This was vaguely suggested in that no one made a clear proposal of what
separate events would look like. click, down, and up events are needed. The
current events use the MouseEvent type. I believe that for the same reason
mousedown includes more context than just "the mouse button was pressed"
that the mouse lock equivalent would too. Thus, the mouse lock version of
click, down, and up events should contain .movementX/Y data.