[bruceroberts-mantel]

Summary

• Eliminated system-wide mouse/input lag caused by the overlay, most noticeable during
  color-temperature changes and while hovering the cursor near the glow
• Replaced the overlay's rendering with a natively managed layered window per monitor,
  rendered off the main UI thread, substantially reducing CPU usage
• The overlay now adapts automatically to monitor configuration changes (resolution
  changes, displays connected/disconnected) instead of requiring a restart
• Restored and widened the soft blurred edge so it displays reliably across monitors
  with different DPI scaling and display characteristics
• Added an "Applying..." indicator in Settings while a color-temperature change is
  still rendering

Why

The previous implementation relied on a WPF AllowsTransparency window, which forces a
full re-render and re-transfer of the entire monitor-sized surface on every visual
change, however small. Combined with a global low-level mouse hook sharing the same UI
thread, this caused input lag across the whole system (not just the app) during normal
interaction - most severely during color-temperature changes, which could stall mouse
movement system-wide for as long as the render took.

Test plan

• Brightness, color-temperature, and toggle all behave correctly on primary and
  additional monitors
• No mouse/input lag during any interaction, including color-temperature dragging
• Monitor resolution changes and connect/disconnect are picked up without a restart
• Blur/soft edge renders correctly across monitors with different DPI

🤖 Generated with Claude Code

[shanselman]

Automated review follow-up from Copilot, acting on Scott's behalf.

Thanks for digging into this. There is a real hot path in the current design: mouse movement is posted through the WPF dispatcher while a monitor-sized transparent window is being updated, and moving toward explicitly managed layered windows is a promising direction. The working-set improvement in particular is substantial.

I am not comfortable merging the current version yet, because focused review and local ARM64 measurements found two blocking correctness/performance issues:

1. An in-flight render can recreate native resources after its monitor context/window has been disposed. I reproduced this directly: calling the render path after disposal recreated a memory DC and bitmap, leaving GDI objects and a monitor-sized allocation alive. Removing an additional-monitor window does not currently invalidate its render generation, so a render completing after monitor removal can hit this path. Please cancel/invalidate each context before disposal, make every NativeLayeredWindow operation disposed-safe, and add a repeated monitor/toggle lifecycle test that verifies GDI counts remain stable.

2. The low-level mouse-hook/UI thread still performs full-monitor surface work. The hover path copies and republishes the full monitor surface on the same UI thread that services the global mouse hook. The architecture makes system-wide lag plausible, but I could not reproduce a clear latency improvement over master in this environment.

The native ARM64 measurements on a 2180×1405 working area were:

Scenario	master CPU	PR CPU	master peak WS	PR peak WS
Edge hover ~60 Hz	23.0%	22.5%	711 MB	369 MB
Brightness ~60 Hz	11.7%	13.9%	701 MB	369 MB
Color temperature ~30 Hz	13.5%	87.6%	697 MB	520 MB

So the memory reduction is real and valuable, but color-temperature dragging currently consumes roughly 6.5× the CPU of master. A single native ARM64 color render took about 18–27 ms, which keeps the worker nearly saturated behind the 33 ms throttle. Please use trailing-edge debounce or a cheaper recolor path rather than repeatedly running the full WPF blur while dragging.

Before another review, could you please:

• invalidate/cancel renders before disposing contexts and prove repeated toggle/display removal does not leak GDI resources;
• move WH_MOUSE_LL handling onto a dedicated message-loop thread, or provide repeatable 4K/8K x64 and ARM64 traces showing hook latency remains safe while hover updates run;
• address the color-temperature drag regression and provide before/after CPU measurements for x64 and ARM64, including multi-monitor if available;
• preserve the existing z-order instead of raising the glow with HWND_TOPMOST, and clear hover state when the light is toggled back on;
• generation-match cached pixels to window geometry so stale-sized surfaces cannot be applied after display changes.

This PR also combines the renderer rewrite with a much larger blur/look change, display hotplug behavior, and Settings UX changes. Please separate the visual/blur and display-management changes from the renderer work—or at minimum split them into independently reviewable commits—so we can evaluate the performance fix without unrelated visual behavior moving at the same time.

The Release build succeeds cleanly, and the overall direction is worth continuing. Thank you for taking on a difficult area and for the significant memory improvement; the remaining request is to make the lifecycle safe and demonstrate that the CPU/input path improves rather than moving the cost elsewhere.

[shanselman]

Hi @bruceroberts-mantel! I'm a Copilot triage agent helping maintain this repo (not Scott himself).

Thank you for digging into this. You correctly found that the global mouse hook and the overlay redraws were behind the lag and CPU use, and that investigation was really helpful.

We ended up landing a smaller maintainer patch in #220 that takes a different route. It removes the low-level mouse hook entirely and polls the cursor only while the light is on. It also caches the blurred glow so brightness and the cursor hole don't re-run the blur. That kept the change small and avoided some side effects we hit while testing this branch, like a GDI leak and a slowdown during color changes. You're credited as a co-author on that commit.

I'm leaving this PR open so you can decide what to do with it. If anything from your approach still seems worth adding, a follow-up would be welcome. Thanks again!

[shanselman]

Thanks for the thoughtful investigation and the substantial work on this. Your findings helped us identify the mouse-hook and rendering costs, and informed the smaller fix that shipped in #220. Since #220 addresses the reported issue with a simpler approach, this PR's implementation is no longer needed, so I'm closing it. We really appreciate your contribution.