Rustcast causes severe macOS mouse lag and WindowServer CPU spike

[cmolina]

Problem

After running Rustcast for several hours, macOS mouse responsiveness degrades significantly. The mouse becomes noticeably slow and unresponsive, with input events appearing to have 50-200ms delays. The issue is reproducible and occurs even if the laptop goes to sleep during the Rustcast session.

Root Cause Analysis

System Diagnostics (captured 2026-06-12 14:07:33):

WindowServer CPU Utilization

• With Rustcast running: WindowServer at 38.0% CPU
• After killing Rustcast: WindowServer dropped to 1.4% CPU (96.3% reduction ✓)

This is the critical finding: Rustcast is causing macOS's display compositing and input event processor (WindowServer) to become severely overloaded.

System State When Rustcast Active

• Memory Used: 15 GB / 16 GB (93.75%)
• Memory Compressor: 409,262 pages compressed
• Physical Free Memory: 306 MB
• System Uptime: 21 hours
• Laptop: Had gone to sleep during Rustcast session

Memory Improvement Post-Fix

• Pages in compressor: 409,262 → 182,726 (-55%)
• Memory free %: 69% → 71%

Technical Details

The Problem

When Rustcast has been running for several hours, it causes macOS's WindowServer (the display compositing and input event processor) to spike to 38% CPU usage, creating a bottleneck that delays mouse input processing.

Why This Matters

• macOS WindowServer is a single-threaded process that:
  • Receives input events (mouse, keyboard, trackpad)
  • Composites all windows/layers
  • Manages GPU command buffers
• When Rustcast causes excessive rendering work, WindowServer CPU maxes out
• Input events get queued behind rendering operations
• Result: Laggy, unresponsive mouse

System Information

• Device: MacBook Air (Mac14,2) with Apple M2
• OS: macOS 26.3 (25D125)
• RAM: 16 GB LPDDR5
• Display: 2560 x 1664 Retina

Reproduction Steps

1. Launch Rustcast
2. Let it run for several hours (laptop may sleep during this time)
3. Observe mouse responsiveness - should become sluggish
4. Monitor Activity Monitor: Check WindowServer CPU usage (should be ~38%)
5. Kill Rustcast: pkill -9 rustcast
6. Observe: Mouse responsiveness returns to normal immediately, WindowServer CPU drops to <2%

Evidence

Before/After comparison:

WindowServer CPU: 38.0% → 1.4% ✓
Memory in Compressor: 409K pages → 182K pages ✓
System Idle CPU: 78.32% → 82.92% ✓

Recommended Investigation

1. Check if Rustcast is creating excessive GPU draw calls
2. Review rendering loop - may be redrawing more frequently than necessary
3. Profile Metal GPU utilization with XCode Instruments
4. Check if Rustcast is maintaining large memory buffers
5. Verify GPU command buffer submission rates
6. Test behavior after system sleep/wake cycles

Impact

• Severity: High - Makes system unusable during extended Rustcast sessions
• Frequency: Consistent and reproducible after several hours
• Timing: Appears to accumulate over time, may worsen if laptop sleeps during session
• Affected Users: Any macOS user running Rustcast for extended periods

[awesomo4000]

You beat me to it !! i just got this problem too. Had to reboot multiple times today. I'm on Tahoe 26.5.1 / M4 Pro 24G . Exact same symptoms.

[MateuszKubuszok]

I just had the same problem. Only after I told AI to analyze the spindump it was clear it was rustcast - before I suspected DisplayLink (on my setup issue only appeared when: external monitor was enabled, DisplayLink was on, mouse was moving) or Logi Option+ (after I disabled it, Mac crashed, and after reboot it seem to work again).

I am not sure if it will help find the root cause - AI sometimes hallucinate - but the report from the AI was as following (and it does make sense):

Root cause
The spindump showed WindowServer's main thread spending 94% of its time (4.73s of 5s) inside add_event_vector_to_tap, recursing 400+ frames deep through the event-tap delivery chain — and copying the whole event vector at every level. So I enumerated installed CGEventTaps via CGGetEventTapList:

Rustcast had leaked 3,225 event taps (a normal system has 5–20; everything else on your machine accounted for 8).
Its taps listen for keyDown + flagsChanged — a global-hotkey listener. It leaked ~10 taps/minute over its 5.5h uptime. The classic bug: when macOS auto-disables a slow filtering tap (kCGEventTapDisabledByTimeout), the app creates a new tap instead of re-enabling the old one, leaving the dead tap in WindowServer's chain forever.
WindowServer walks that chain per input event on its main thread — the same thread that drives compositing. Mouse movement produces by far the highest event rate (~90–125+ events/sec), so moving the mouse saturated the thread and stuttered all displays, while video playback and scrolling stayed smooth.
This also explains every red herring you chased:

"Disabling Logi Options+ fixed it" — it didn't; the reboot did, by resetting the tap count to normal. Same reason restarts give you a grace period before it degrades again.
"Turning the display off/on brought it back" — display sleep/wake stalls app runloops, triggering tap timeouts, which is exactly when Rustcast leaks fastest.
Refresh rate, glossy UI, DisplayLink version — all irrelevant to event-tap delivery.

What I did
Rustcast was idle (no recording in progress), so I quit it and re-checked: tap count dropped from 3,233 → 8, and WindowServer is back to ~31% CPU, which is normal for DisplayLink's software compositing. Mouse movement should be smooth now and stay smooth.

It makes sense to me: if rustcast register new event listener of sort every once in a while, instead of reusing the ones it already created, after a while system has thousands event listeners to call on every action - and mouse is just the most visible event spammer.

[awesomo4000]

Claude suggested I post this here:

• check_event_tap (src/app/tile.rs, ~807) tears down and rebuilds the global CGEventTap every 5 seconds, forever.
• The Drop for EventTapHandle (src/platform/macos/launching.rs, ~28) disables the tap and removes the run loop source, but never calls CFMachPortInvalidate on the port.

Each cycle leaks a mach port and leaves a dead-but-still-registered tap behind in WindowServer. A few hours of that is thousands of stale entries WindowServer has to walk on its single thread, and mouse-move is the highest-frequency event so it's the first thing you feel. The "kill it and it's instantly fine" part fits too — when the process exits the kernel reclaims all its mach ports at once, so all the leaked taps vanish together.

I just measured this for 18 minutes and the app leaks one mach port every five seconds. I sampled using lsmp -p and the samples showed one leak every 5s. That's ~720 ports per hour when just idle.

I did some more testing with a small C program that simply creates event taps without invalidating them, then kills itself after a few seconds. At ~1500 taps, the entire MacOS UI is laggy, windows can't be dragged easily, mouse stutters. At 1700 taps, the WindowServer crashes completely. This is in line with the initial observation that this builds over time and corresponds to the couple hours ramp up of a couple hours (5/sec -> 720/hour).

[unsecretised]

Yeah I started encountering this today and was confused.

I was just restarting mac.
Give me about 24-48 hours I'll fix it and put out a release.

[ashugg]

"Me too"

Very sluggish mouse and my Mac was dropping keystrokes whenever I was typing - had to press a key, wait for the character to be printed and the cursor to blink, then press the next key 😄

I hope it's not too hard to work out what's causing this, and banishing it!

[albinsantiagojr]

same, uninstalled for now, bin had the same