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

On Sun, Feb 23, 2014 at 1:57 AM, Thibaut Despoulain <thibaut@artillery.com>
 wrote:

> The issue with pointerlock is that it requires the app to draw its own
> cursor instead of the OS cursor
>
I fully agree with motivation, it is usually preferrable to give the user
an OS-themed cursor (not always, but often).

>
>    - Significant pointer lag between movement input and actual movement
>    on screen compared to an OS-drawn cursor (yes, even at 60fps),
>
> I've written a test for this here:
http://codeflow.org/issues/software-cursor.html

My observation from testing on linux is that I can't distinguish latency
for the software cursor from the OS cursor (or not by much anyway) in
google chrome. In firefox however there's noticable lag. Mileage may vary
for other platforms.


>
>    - Inability to use DOM elements with mouse events for a game
>    overlay/HUD.
>
> The test I've written here http://codeflow.org/issues/software-cursor.htmlalso tests mouse event synthesis (as hinted at by an example in the
pointerlock spec) and it works satisfactory in chrome and firefox on linux.
To get all subtleties right one would also have to do most other mouse
events I guess (mouseover, mouseout, mousemove etc.).


On Sun, Feb 23, 2014 at 2:15 AM, Brandon Jones <bajones@google.com> wrote:

> Chrome a software cursor will experience visible lag, which these types of
> games are highly sensitive to.

Not as much lag as I expected, see this test:
http://codeflow.org/issues/software-cursor.html


> I'm not sure about the latency of Firefox or others

Pretty bad, see this test: http://codeflow.org/issues/software-cursor.html



> , but in general a hardware cursor is preferable any time you have a
> visible cursor. As a result this is still a use case worth considering.

It's not always preferrable (sometimes people want custom cursors). But in
general it is preferrable.


When providing the OS cursor there's several issues to be addressed:

   - If you are in fullscreen, capture the cursor to the viewport but show
   the OS cursor, that does *NOT* mean you'll want the annoying slide-down
   that some browsers provide if you hit the top edge. If you wanted that,
   you'd never have restricted the cursor in the first place. I would suggest
   as a resolution that if somebody requests cursor restriction, and gets it,
   that the slide down is never shown regardless if the OS cursor is shown or
   not.
   - It should be possible to show and hide the OS cursor separately, but
   retain pointerlock. The reason for that is that you might want to avoid
   synthesizing your own cursor, but you may also want to keep pointerlock
   because your game switched to some UI interaction for instance from an FPS
   interaction mode. I would suggest this could be resolved with an additional
   API call of the form: document.hideCursor() and document.showCursor() or
   something similar. If the sequence is myContainer.requestPointerLock();
   document.showCursor(); the cursor is shown, but confined to the container.
   Outside of being in pointerlock, these calls would have no effect.