Re: Mouse Lock

2011/10/20 Vincent Scheib <scheib@google.com>

> I'm moving a conversation thread about the mouse lock specification
> from a webkit bug https://bugs.webkit.org/show_bug.cgi?id=68468#c10 to
> here:
>
> Alexey Proskuryakov has several questions:
>
> > On an unrelated theme, the definition of movementX/movementY seems too
> platform dependent to me. The spec says "movementX/Y must continue to
> provide the change in position of the mouse as when the mouse is unlocked".
> That's likely not what will work for games given dynamic acceleration on
> some platforms. Such acceleration would yield unacceptable results if
> applied to FPS shooter movement control.
>
> On the contrary, this decision is based on offering a consistent
> experience on all platforms. The movement is 100% backwards compatible
> with mouse events available today. Users on systems calibrate, if
> needed, their input devices to a reasonable and comfortable setting.
> As they move between platforms and input devices they maintain their
> ability to control the mouse cursor in the dimension of screen pixels.
> Under moues lock the same data is provided.
>
> On the topic of acceleration and calibration, there seems to only be
> speculation that this is harmful. Developers such as Unity and myself
> have voiced first hand experience that this is not a concern. Users
> who desire no acceleration can configure it the same way they do with
> games today (system configuration, drivers, or in game). There is a
> substantial FAQ item which covers this topic as well. If you'd like
> more details, please see the public-webapps thread.
>
>
In fact, games that implement their custom acceleration and mouse
sensitivity are annoying in the fact that they generally don't have the
correct setting right off, and you have to fiddle with the settings
(sometimes with frustration) because the game doesn't adapt to your already
preset options on your OS.

I think, for now, pixels is the best measure unit, hardcore gamers will
anyways want to play a native version of the game (till HTML5 can compare to
native) and the spec mustn't deal with this specific scenario right now...
maybe later in a revision when enough browsers have matured this
functionality.


> > I'm surprised by "jog movement over spinner controls" use case. Doesn't
> that work already? E.g. I can drag the mouse outside of browser window,
> while <input type=range> will continue to respond. Getting use cases right
> seems fairly important.
>
> You can not today drag a job control in a single direction with
> unlimited input. You will encounter a screen edge. Mouse lock enables
> this by locking the mouse for the duration of the drag, e.g. the Maya
> DCC tool does this I believe.
>
>
Another example which is freely available on the net is Blender, which uses
this kind of control a LOT.


> > I see that the spec used to say something about touch events, and no
> longer does. Regardless of what it used to say, it seems critically
> important to explain what happens with mouse events that are synthesized
> from touch events on mobile devices. Should touch capable devices such as
> phones and tablets just avoid supporting MouseLock?
>
> I agree that the spec should explicitly state the result, since touch
> events are quite important. I believe the mouse events generated from
> touch gestures under mouse lock should behave the same way mouse
> events from a mouse or trackball would. There are issues around mouse
> lock mode escape the user agent would need to solve to support mouse
> lock if no keyboard is present, but the spec leaves that to the user
> agent and future spec versions.
>
> I think touch devices must evolve a little more before being included here,
because the use-case of "touching" the device to move the cursor cannot be
relative because the screen bounds are real bounds for your finger, and
there's no way to specify relative movement (and the software that
implements this kind of relative movement has often failed miserably).