Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manual mouse movement detection false positives #44

Closed
1j01 opened this issue Apr 12, 2024 · 3 comments
Closed

Manual mouse movement detection false positives #44

1j01 opened this issue Apr 12, 2024 · 3 comments
Labels
affects:desktop-app Affects the Electron app bug Something isn't working closed with followup notes Generally done, but some further improvements/actions are noted.

Comments

@1j01
Copy link
Owner

1j01 commented Apr 12, 2024

There is a feature for regaining mouse control (pausing the head tracker temporarily) by just moving the mouse normally.
You don't want to interrupt head tracking by accident, so there's a threshold of movement before the mouse will take control from the head tracker.
However, I'm noticing it pausing randomly, perhaps especially when moving the cursor significantly with my head, on Windows 11.

Possible solutions:

  1. Maybe disable the mouse movement detection until the setMouseLocation promise is resolved?
    Might not work if outstanding promises overlap. If so, there wouldn't be a period of time where the mouse movement detection is enabled, or it would be enabled even though a later request to move the mouse is already in progress, making it sporadic.
  2. Maybe store a queue of mouse positions requested, and compare the current mouse position against each point in the queue.
    I think that should be robust.
    How long should the queue be? Points could be removed when setMouseLocation resolves, if and only if it's guaranteed that getMouseLocation will return the new position at that point.
    However, a simple time or count limit should be fine.

Also, this could help:

  • Might want to use a history of mouse movement, rather than just the latest position, in order to require more travel without requiring significantly higher speed.
    This would have to be a separate queue of getMouseLocation results, rather than a queue of setMouseLocation requests.
    Should consider framerate independence, and ideally define the threshold in terms of travel within a period of time.
    (Should distance be measured in pixels, inches/cm, or screen percentage? probably pixels, to keep it simple.)

Related:

@1j01 1j01 added bug Something isn't working affects:desktop-app Affects the Electron app labels Apr 12, 2024
@1j01
Copy link
Owner Author

1j01 commented Apr 13, 2024

I could simulate latency by adding setTimeout before setMouseLocation to test this.
Maybe wrap it in a function, also for tracking the positions requested.

1j01 added a commit that referenced this issue May 6, 2024
1j01 added a commit that referenced this issue May 6, 2024
1j01 added a commit that referenced this issue May 6, 2024
@1j01
Copy link
Owner Author

1j01 commented May 7, 2024

I got this to be robust by comparing the retrieved mouse position to a queue of mouse positions. It now behaves reliably even with await new Promise((resolve) => setTimeout(resolve, Math.random() * 100)); before setMouseLocation.

@1j01 1j01 closed this as completed May 7, 2024
@1j01
Copy link
Owner Author

1j01 commented May 12, 2024

Some minor notes from when I closed this:

  • I can still get a false positive if I hold down the toggle shortcut (F9) to toggle rapidly, and move my head, with artificial random latency enabled... very much an edge case
  • There's also these comments that I'm unsure of, and the behavior may have changed part way through working on this:
     const mousePosHistoryDuration = 5000; // in milliseconds; affects time to switch back to camera control after manual mouse movement (although maybe it shouldn't)
    and
     const regainControlForTime = 2000; // in milliseconds, AFTER the mouse hasn't moved for more than mouseMoveRequestHistoryDuration milliseconds (I think)

@1j01 1j01 added the closed with followup notes Generally done, but some further improvements/actions are noted. label May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects:desktop-app Affects the Electron app bug Something isn't working closed with followup notes Generally done, but some further improvements/actions are noted.
Projects
None yet
Development

No branches or pull requests

1 participant