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 <pya...@gmail.com> wrote: > On Sat, Feb 22, 2014 at 11:22 PM, Florian Bösch <pya...@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%). >
