Do Hover Delays Feel Different on 120Hz+ Screens?

A hover dwell time that felt right on a 60 Hz monitor feels wrong on a 144 Hz monitor. The same 40 ms that registered as "instant" on 60 Hz registers as "slightly laggy" on 144 Hz, because the user's expectation of pointer responsiveness has been recalibrated by the higher refresh rate. This is not a bug in the overlay; it is a mismatch between the dwell constant and the pointer input rate. This guide explains why high-refresh displays change the perception of hover dwell, what to tune, and how to expose the right knob to the user.

For neighbouring topics, see does hardware acceleration help a tiny overlay and clipboard tools on multi-monitor Windows setups.

What dwell time actually is

A hover-activated overlay opens when the cursor enters a trigger strip and stays there for at least N milliseconds. The dwell time exists to filter out accidental passes — the user who is moving the cursor from one window to another should not open the overlay just because the shortest path crossed the trigger strip.

The dwell time is implemented as a timer that starts when the cursor enters the strip and is cancelled when the cursor leaves. If the timer expires without the cursor leaving, the overlay opens. The length of the timer is the dwell time.

The perception of dwell time depends on the rate at which the user receives visual feedback that the cursor is in the strip. On a 60 Hz monitor, the cursor's position is updated 60 times per second; on a 144 Hz monitor, 144 times per second. The user's eye sees the cursor "stop" in the strip at a higher resolution on 144 Hz, and the dwell timer that felt instant at 60 Hz feels slightly delayed at 144 Hz — because the user has been primed to expect a response after roughly 2–3 frames of stillness, and 2–3 frames at 144 Hz is 14–21 ms, not 40 ms.

Why this is not a performance issue

The first instinct when a 144 Hz user reports "the overlay feels laggy" is to look for dropped frames or input latency in the overlay's render path. That instinct is usually wrong. The overlay's render path is not what the user is perceiving — they are perceiving the dwell timer itself, which is doing exactly what it was configured to do.

A useful diagnostic: temporarily reduce the dwell time to 20 ms (or zero, if the overlay allows it) and see if the laggy feeling disappears. If it does, the dwell was the cause. If the overlay still feels laggy with dwell at zero, the cause is in the render path or the input pipeline, not the dwell.

What to tune

There are three reasonable approaches to dwell tuning on high-refresh displays, in increasing order of sophistication:

Expose dwell as a user setting

The simplest answer is to let the user adjust the dwell time themselves. A slider from 0 to 500 ms covers the useful range. Most users will leave it at the default; users on high-refresh displays will reduce it; users on shared machines who want to avoid accidental opens will increase it. The cost is one extra setting and the user education to find it.

Scale dwell by reported refresh rate

The overlay queries the monitor's refresh rate (via DXGI or the Win32 GetDeviceCaps API) and scales the dwell accordingly. A dwell of "3 frames" at 60 Hz is 50 ms; at 144 Hz it is 21 ms. This keeps the perceptual dwell constant across refresh rates. The cost is complexity: refresh rates can change at runtime (the user plugs in a new monitor, the OS changes the rate), and the overlay needs to re-query and re-scale.

Use pointer-event counting instead of time

A more sophisticated approach is to count pointer-move events rather than milliseconds. The overlay opens when the cursor has been in the strip for N consecutive pointer-move events without leaving. Because high-refresh displays generate pointer-move events at a higher rate, the overlay opens after fewer milliseconds on a high-refresh display, which is the desired behaviour. The cost is that this couples the dwell to the input rate, which is not always the same as the display rate.

The default-dwell trade-off

Whatever the approach, the overlay needs a default dwell that is correct for the common case. The common case in 2026 is increasingly a 120 Hz or 144 Hz laptop display, not a 60 Hz desktop. A default dwell of 40 ms, tuned for 60 Hz, is too long for the common case.

A default of 20 ms feels instant on both 60 Hz and 144 Hz, at the cost of more accidental opens on 60 Hz. The accidental-open rate is mitigated by hysteresis — the trigger strip is slightly wider for the open than for the close, so the cursor has to move further to close the overlay than to open it. This is the pattern well-behaved hover overlays use.

What can go wrong

• Dwell is tuned in raw milliseconds and never re-tuned. Symptom: the overlay feels laggy on high-refresh displays. Fix: reduce the dwell, or expose it as a setting.
• Dwell is set to zero. Symptom: the overlay opens on every cursor pass near the edge. Fix: restore a non-zero dwell, or add hysteresis so the close requires more cursor travel than the open.
• Dwell is implemented as a SetTimer call that fires once per second. Symptom: the overlay opens in 1-second increments, not in milliseconds. Fix: use a high-resolution timer (QueryPerformanceCounter or the multimedia timer) for sub-100 ms dwell.
• The overlay's render path is the actual bottleneck. Symptom: reducing dwell does not fix the laggy feeling. Fix: profile the render path; the cause is usually software compositing on a transparent window. See does hardware acceleration help a tiny overlay and integrated GPUs and transparent windows.

Multi-monitor with mixed refresh rates

A common 2026 configuration is a 144 Hz primary monitor for gaming and a 60 Hz secondary monitor for chat and browser. An overlay that is configured for the 144 Hz monitor but accidentally triggered on the 60 Hz monitor will feel too long; an overlay configured for 60 Hz but triggered on 144 Hz will feel too short.

The right answer is per-monitor dwell: the overlay queries the refresh rate of the monitor its trigger strip is on, and scales dwell accordingly. This is the most complex approach and the least commonly implemented; the fallback is to expose dwell as a user setting and let the user pick a value that is acceptable on both monitors.

For the multi-monitor discussion, see clipboard tools on multi-monitor Windows setups and how to pick which monitor Edge-Drop uses.

Honest positioning

Edge-Drop, the Windows hover-activated clipboard shelf, uses a dwell time tuned for a balance between responsiveness and accidental-open avoidance. The shelf exposes a configurable dwell setting (and a configurable hotkey fallback, default Alt+C), so users on high-refresh displays can reduce the dwell to match their expectation. The shelf does not currently auto-scale dwell by reported refresh rate; this is a feature gap on high-refresh multi-monitor setups, and the honest recommendation for users who notice the lag is to reduce the dwell manually. The shelf does not compete with native-Win32 overlays on raw input latency — those tools are written in C/C++ and avoid the Electron input pipeline — but the dwell setting covers most of the perceptual difference.

What to check

If your shelf feels laggy on a high-refresh display, work through these:

1. What is the monitor's actual refresh rate? (Settings → System → Display → Advanced display.)
2. What is the shelf's dwell time? (Check the shelf's settings; if it is not exposed, the dwell is hard-coded.)
3. Reduce the dwell by half and try again. If the laggy feeling disappears, dwell was the cause.
4. If reducing dwell does not help, profile the render path. The cause is likely software compositing on a transparent window.
5. If the shelf is on a multi-monitor setup with mixed refresh rates, test on each monitor separately.

A dwell of 15–25 ms is a reasonable starting point for 120–144 Hz displays. A dwell of 40–60 ms is reasonable for 60 Hz. The exact value depends on the trigger strip width and the hysteresis; both need to be tuned together.

Related reading

• Does Hardware Acceleration Help a Tiny Overlay?
• Measuring Clipboard App Idle Cost Yourself
• Clipboard Tools on Multi-Monitor Windows Setups
• Win+V Not Working on Windows 11: 9 Fixes

Sources

• Microsoft Learn — High DPI and refresh rate support — official guidance on per-monitor DPI and dynamic display changes that applications should handle
• Microsoft Learn — DXGI swap chain statistics — DXGI reference for querying refresh rate and frame timing
• Microsoft Learn — QueryPerformanceCounter — Win32 reference for the high-resolution timer used to implement sub-100 ms dwell
• Microsoft Learn — Pointer input messages — Win32 reference for pointer input events and their relationship to display refresh rate
• Microsoft Support — Change the refresh rate in Windows — official user-facing steps for changing display refresh rate, which the overlay should respond to at runtime

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support