Re: [fullscreen] Problems with mouse-edge scrolling and games

The issue with pointerlock is that it requires the app to draw its own
cursor instead of the OS cursor, which has at least two significant
drawbacks:

   - Significant pointer lag between movement input and actual movement on
   screen compared to an OS-drawn cursor (yes, even at 60fps),
   - Inability to use DOM elements with mouse events for a game overlay/HUD..

We could work around #2, but #1 is a no-go for a twitch game such as a RTS
where mouse accuracy and responsiveness is so critical.

Something like a different kind of pointer lock that uses the OS cursor and
only prevent the cursor from exiting the window canvas would be optimal.


On Sat, Feb 22, 2014 at 2:39 PM, Florian Bösch <pyalot@gmail.com> wrote:

> On Sat, Feb 22, 2014 at 11:22 PM, Florian Bösch <pyalot@gmail.com> wrote:
>
>> Caveat, I think Firefoxes implementaiton of the Pointerlock API might not
>> follow the specification yet to make it possible to have pointerlock
>> without fullscreen.
>>
>
> Just checked this against a test I wrote a while ago
> http://codeflow.org/issues/pointerlock-test.html and consulted the
> pointerlock stats for IE. You can get pointerlock in both firefox and
> chrome without fullscreen (you can also get pointerlock and fullscreen
> simultaneously). IE seems to support pointerlock in versions that have
> webgl, but they seem to have added it only recently so support is still low
> (32%).
>