windows-internals

MenuShowDelay and friends: the timing values behind “snappy”

Menus wait before opening, hovering delays accelerate, and window drag behavior redraws — all under documented HKCU values with known defaults. The complete timing cheat-sheet.

ProofTune Project··5 min read
Windows internals illustration Windows internals

User feel is often just a few timers. The documented per-user values all sit under HKCU\Control Panel\Desktop (and one Panel\Menus cousin) with plain defaults:

MenuShowDelay
ms before a menu opens on hover — default 400; 0 = immediate
MouseHoverTime
hover timer used by listviews/menus — default 400
DragFullWindows
1 shows contents while dragging; 0 shows only a frame — big difference on slow GPUs
MinAnimate
1 = animate minimize/maximize; 0 instant

Why defaults are high

Defaults balance discoverability against input noise: a 400 ms menu delay prevents menus from popping when you sweep past heading toward a dialog. Lowering the delay trades that anti-noise for speed — measurable in any repeated-task session, imperceptible on machines where Remoting conditions made it higher.

The reversibility angle

Each value documents its stock default, which is why restore is a write, not a guess: put 400 back and the delay is exactly stock. That's the separating line between tuning and hacking: you can name what's normal before you deviate from it.

ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.
ProofTune logo

See these exact settings inside the real tool

The browser replica runs the same strings and states as the installed app — click around before you ever install anything.