[Bug]: Windows cursor lags behind

[webadderall]

Search existing issues

• I have searched the existing issues

Describe the bug

Windows cursor lags behind to the point where it noticeably misses clicks, this behaviour does not happen on macOS. This can be confirmed by setting smoothing to 0; it still lags behind.

Expected behavior

It should display behaviour consistent with macOS i.e. no lag.

To Reproduce

No response

Screenshots

No response

OS

None

OS Version

No response

Other OS

No response

Additional context

No response

[webadderall]

I don't own a Windows device so it is harder for me to troubleshoot, any help would be appreciated.
If you would like to be assigned to this issue, make a comment below

[Bingtagui404]

Hi, I'd like to help with this! I have a Windows environment (WSL2) and can investigate the cursor lag issue.

I'll start by reproducing the problem and tracing the cursor rendering path to identify the source of the delay.

[Bingtagui404]

First, I'm going to post the original video—the one where the issues can be identified. I just attempted to fix it but failed, so I'm going to give it another try.
https://www.youtube.com/watch?v=QrpbS7o8gv8

[webadderall]

Actually, looking at the footage, the delay seems to be a normal amount. The issue may have been resolved earlier, but thank you for your time spent on this.

If you hover the cursor over a button and click multiple times, can you see a delay?

[Bingtagui404]

Hi, I've been investigating this issue on Windows 11 and wanted to share my findings before submitting a fix.

What I initially tried (wrong path)

I changed Sleep(50) → Sleep(16) in electron/native/cursor-monitor/src/main.cpp, thinking it would improve cursor responsiveness. After testing, the lag was unchanged. This is because cursor-monitor only polls GetCursorInfo() for cursor type (arrow/hand/text), not position. It outputs STATE: messages and has no effect on where the cursor appears in recordings.

Actual root cause

Continuous cursor position sampling happens in electron/ipc/handlers.ts:

Line 2704: setInterval(sampleCursorPoint, CURSOR_SAMPLE_INTERVAL_MS) (currently 16ms)
Line 1590: sampleCursorPoint() calls getScreen().getCursorScreenPoint() — a synchronous polling API
This polling approach introduces inherent latency. The issue reporter noted that setting smoothing to 0 still shows lag, which confirms the problem is in sampling, not in playback rendering (cursorRenderer.ts:513 already does snapTo when smoothing ≤ 0).

Interesting finding: uiohook is already loaded on Windows but mousemove is Linux-only

The codebase already loads uiohook on all three platforms (handlers.ts:1644-1651), and it hooks mousedown/mouseup on all platforms. However, the mousemove handler at line 1713-1714 is explicitly gated to Linux only:

if (process.platform !== 'linux' || !isCursorCaptureActive) {
return
}

On Linux, this event-driven approach caches the cursor position in linuxCursorScreenPoint, which is then read by the regular sampling interval — effectively getting event-driven position updates instead of pure polling.

Proposed fix

Extend the existing mousemove handler to include win32, rather than writing a new native C++ hook. This would be a minimal change with low risk since the infrastructure already exists.

Before I submit a PR, I wanted to ask:

Was there a specific reason mousemove was limited to Linux? (e.g., coordinate quality issues on Windows?)
Would you prefer this approach, or something different?
Happy to test on Windows 11 once we agree on the direction.

[Bingtagui404]

@webadderall

[Bingtagui404]

Actually, looking at the footage, the delay seems to be a normal amount. The issue may have been resolved earlier, but thank you for your time spent on this.

If you hover the cursor over a button and click multiple times, can you see a delay?

In the video I just commented on, playback latency is indeed present—and it actually seems quite severe. You might want to watch it in slow motion to observe the cursor.

[webadderall]

I originally implemented mousemove on Linux to fix cursor-following issues (the fix didn't work) and didn't really pay much attention to Windows at the time.

In the video I just commented on, playback latency is indeed present—and it actually seems quite severe. You might want to watch it in slow motion to observe the cursor.

Some degree of cursor latency is to be expected because of smoothing, the original issue was that the cursor click animation used to fire with a delay after clicking on a button, and the cursor movement was more delayed than it is now. From what I can seee in the video, the delay is similar to macOS

[webadderall]

https://x.com/heykaran77/status/2033942024215531985

example