Improve stream pointer responsiveness under load.

[Jayian1890]

Reduce mouse input hot-path overhead with residual delta accumulation, adaptive flush scheduling, cached scale conversion, and tuned raw-input filtering while adding diagnostics and targeted tests.

---

Note

Medium Risk
Touches the mouse input hot-path and DataChannel send semantics, which could impact pointer feel or input reliability under different browsers/servers. Changes are localized but timing-sensitive (adaptive scheduling, quantization, scaling), so regressions may be subtle without broad device testing.

Overview
Improves stream mouse responsiveness under load by switching mouse movement accumulation to float + residual quantization, preventing small deltas from being lost after scaling/rounding and reducing per-event work.

Adds adaptive mouse flush scheduling (replacing the fixed setInterval with a self-adjusting setTimeout loop) that tightens or relaxes the flush cadence based on reliable-channel backpressure and scheduling delay, plus cached pointer scaling to avoid repeated DOM/resolution recomputation.

Extends stream diagnostics/UI overlay to surface mouse flush interval, packet rate, residual magnitude, and whether adaptive mode is active, and adds targeted unit tests for the new quantization/adaptive-interval logic; updates package.json test script to run the new test file.

^{Reviewed by Cursor Bugbot for commit 9ac7553. Bugbot is set up for automated code reviews on this repo. Configure here.}

[capy-ai]

Added 1 comment

[capy-ai]

[🟡 Medium] [🔵 Bug]

The scheduleNextFlush callback unconditionally calls itself at line 2665 without checking whether the client has been torn down. If clearTimers() executes after the timer fires but before the callback runs (a valid event-loop interleaving — e.g. a WebSocket close handler triggers cleanupPeerConnection in the same tick that the flush timer fires), clearTimeout has no effect on an already-fired timer, and this.mouseFlushTimer is set to null. The callback then calls scheduleNextFlush(), which sets a new timer, creating a zombie loop that re-fires every 2–20 ms indefinitely. Each iteration calls flushMouse() (which early-returns because inputReady is false), but the loop never terminates, wasting CPU and preventing GC of the client instance.

The old setInterval approach didn't have this issue because clearInterval prevents future ticks. Adding a guard inside the callback stops the zombie:

// opennow-stable/src/renderer/src/gfn/webrtcClient.ts
this.mouseFlushTimer = window.setTimeout(() => {
  flushMouse();
  // clearTimers() nulls mouseFlushTimer — stop if cleanup happened
  if (this.mouseFlushTimer === null) return;
  // ... adaptive calc ...
  scheduleNextFlush();
}, this.mouseFlushIntervalMs);

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 9ac7553. Configure here.}

[cursor]

You have used all of your free Bugbot PR reviews.

To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.