Why does an 8000 Hz mouse drop FPS or stutter?
Because some software tries to handle every one of up to 8000 mouse messages a second, one at a time. The documented culprits are programs reading the mouse in the background, which Windows 11 throttled in July 2023, and game engines that process the old cursor messages alongside raw input. When Godot fixed its engine, the same mouse on the same PC went from under 1 fps to 477 fps.
An 8000 Hz mouse drops frames when software has to handle up to 8000 separate mouse messages a second, one at a time. It is not, on the evidence, the CPU drowning in interrupts. Two causes are documented. The first is programs running behind the game that also read the mouse, which Microsoft throttled in a Windows 11 update in July 2023. The second is game engines that process every message, including old-style cursor messages Windows sends alongside the raw ones. When Godot fixed that second cause, the same 8000 Hz mouse on the same PC went from under 1 fps to 477 fps. If a game still stutters at 8000 Hz, step down to 4000 Hz, then 2000 Hz.
What is actually being flooded
Polling rate is how often the mouse sends a report of its movement to the PC. At 8000 Hz that is one report every 0.125 ms. Windows turns each report into messages for every program that asked for them. Two kinds of message matter here.
- Raw input (WM_INPUT). The unprocessed movement a game reads for aiming. Godot describes it as a way to read the mouse "in a way that ignores OS processing", such as mouse acceleration.
- Legacy mouse messages (WM_MOUSEMOVE). The older cursor messages that desktop apps use. Godot calls this "the usual kind of mouse motion event, designed for applications rather than games".
Asking for raw input does not switch the legacy messages off. A program "will still receive legacy input events at the same time", Godot writes, even with the cursor hidden. A raw input listener is any program that has signed up for raw mouse input. The game is one. Programs in the background can be others, and each one gets its own copy.
One frame at 8000 Hz, walked through
Take a game running at 240 fps, with an 8000 Hz mouse moving fast. Godot notes that small, slow movements do not send an update on every poll, so this is the busy case.
So up to 33 raw input messages wait for each frame, with up to 33 legacy messages beside them. An engine that takes them one at a time pays the handling cost about 66 times a frame. Now suppose the engine collects the raw messages in one buffered read and lets one legacy message through per frame. That is the fix Godot shipped, and the work per frame falls to one batch read and one cursor update. The mouse, the USB link and the polling rate are unchanged. Only the way the program empties its queue has changed.
What that fix did in Godot's benchmark
Godot measured it on a Ryzen 9 9950X3D and RTX 5090, running Windows 11 24H2, with the mouse moved quickly in circles. Version 4.7.1 has the old input code. 4.8.dev3 has the fix, which also ships in 4.7.2. With the mouse still, both ran at about 4,100 fps.
| Polling rate | Cursor visible, before | Cursor visible, after | Captured, before | Captured, after |
|---|---|---|---|---|
| 1000 Hz | 2,641 | 2,560 | 2,583 | 2,669 |
| 2000 Hz | 1,751 | 1,848 | 1,979 | 2,110 |
| 4000 Hz | 973 | 1,546 | 1,778 | 1,962 |
| 8000 Hz | 173 | 1,103 | under 1 | 1,703 |
With V-Sync on at 480 Hz, the old engine fell to 151 fps with the cursor visible and under 1 fps with it captured. The fixed engine held 477 in both. At 4000 Hz the old engine still held 469 to 472. Moving the mouse still costs frames after the fix, 1,103 against about 4,100 uncapped. It just no longer costs the frames you can see on a 480 Hz screen.
Note the operating system. Windows 11 24H2 already includes Microsoft's 2023 change, so this collapse happened on an up-to-date Windows. Godot puts the point where drops begin, on most CPUs and recent Windows 11, "generally somewhere between 1 kHz and 2 kHz". It depends on mouse speed and single-core performance. That is why the step down from 8000 Hz goes to 4000 Hz first, the rate that held at 480 Hz, and to 2000 Hz if a slower PC still stutters.
Why the interrupt story persists
Evetech's August 2026 explainer says polling at 8000 Hz "makes the CPU service interrupts far more often than at 1000Hz". Attack Shark's Japanese blog says an 8K mouse causes 8,000 hardware interrupts a second, and that in older games these steal cycles from the main thread. The story sticks because half of it is true. 8000 reports a second is eight times the traffic, and frames really do drop.
But Godot's fix touched nothing below Windows. Same mouse, same polling rate, same CPU, same reports arriving. Captured-cursor fps went from under 1 to 1,703 by changing only how the engine reads its queue. Whatever interrupts cost, they were not what took those frames. Godot also says Linux "is generally not affected by this issue, regardless of the game". We found no published test that isolates interrupt cost, so we do not claim it is zero. It is not the documented cause.
What Microsoft fixed in 2023
Microsoft's Windows Developer blog of 26 May 2023 found the input stack "being pushed to its limits with high report rate mice". Their input was going "to not just the game, but also multiple background processes". The fix was "throttling and coalescing background raw mouse listeners and capping their message rate". Coalescing means merging several reports into one message. On a Surface Laptop Studio with a 1000 Hz mouse and a set of background listeners, Microsoft saw "significant stutter" before the change and smooth play after.
The change reached Windows 11 22H2 in update KB5028185 in July 2023, The FPS Review reported. The blog does not give the rate background programs are capped to, and it does not name the programs. We found no Microsoft statement that Windows 10 got the same change. So on Windows 10, close background programs you do not need before you test 8000 Hz against 1000 Hz.
The game-side fix
Microsoft's GetRawInputBuffer reference says it "performs a buffered read of the raw input messages data" and removes the matching WM_INPUT messages from the queue. That is the batch read in the walkthrough. Valorant's Raw Input Buffer matches that description, though Riot never names the function. Riot's 2021 notes said 8000 Hz mice "are supported with this feature enabled", and it has been always on since patch 11.06, as our Raw Input Buffer page explains.
Buffering raw input alone is not enough, though. Peter Thoman of PH3 showed a game that already used batched raw input. Shaking an 8 kHz mouse still dropped it from about 360 fps to about 133. The legacy messages "will still clutter your message queue", he wrote. His fix keeps batched raw input for aiming but processes at most five queued messages per frame.
What to do
| Your situation | Why | Do this |
|---|---|---|
| Windows 11 without the July 2023 update (KB5028185) | Background raw input listeners are not throttled (Microsoft, The FPS Review) | Install current Windows updates |
| Windows 10 | No Microsoft statement that the cap reached it | Close background programs you do not need, then test 8000 Hz against 1000 Hz |
| Updated Windows 11, one game still drops frames at 8000 Hz | The engine likely handles every message (Godot, PH3) | Step down to 4000 Hz. If it still stutters, 2000 Hz |
| Game reads input in batches (Valorant, Godot 4.7.2 and later) and 1% lows hold | Buffered reads (Riot, Godot) | Keep 8000 Hz if you want it |
Judge every row by your 1% lows in a frame time graph, not the average, as explained in frame time vs fps. What you give up by stepping down is small. 1000 to 8000 Hz shortens the mean polling delay by 0.44 ms, as our polling rate guide works out.
The short version
- 8000 Hz frame drops come from software handling mouse messages one at a time. That is the documented cause, not CPU interrupts.
- Windows 11 has throttled background raw input listeners since update KB5028185 (July 2023).
- Games must fix their own side. Godot's fix took 8000 Hz from under 1 fps to 477 at 480 Hz V-Sync.
- Batching raw input is not enough. Legacy cursor messages must be limited too.
- If a game still stutters, drop to 4000 Hz, then 2000 Hz. You lose well under half a millisecond.
Where this stops applying
Everything here is Windows. Godot's figures come from one very fast PC and one test project, and Godot says the threshold depends on single-core performance, so a slower CPU reaches it sooner. We cannot tell you which commercial games are still affected. PH3 says "several extremely popular AAA games" are, without naming them, and we have not tested any. Microsoft gives no figure for the background cap and no list of programs it affects. And this covers frame drops, not wireless dropouts at 8000 Hz, which are a radio problem covered in the polling rate guide.
Sources
- Microsoft Windows Developer blog, "Delivering Delightful Performance for More Than One Billion Users Worldwide", 26 May 2023.
- The FPS Review, "Windows 11 Update Reduces Game Stutter with High-Report-Rate Mice", 14 July 2023.
- Godot, "Fixing high polling rate mice on Windows in Godot", 24 August 2026.
- PH3 Blog, "Things you really should know about Windows Input, but would rather not: Raw Mouse edition", 16 September 2024.
- Microsoft Learn, GetRawInputBuffer function.
- Evetech, "Does 8000Hz Polling Hurt Your FPS?", 14 August 2026.
- Attack Shark Japan, high polling rates and frame drops in older games.
Frequently asked questions
Does an 8000 Hz polling rate lower FPS?
In some games, yes, and badly. In Godot's benchmark an 8000 Hz mouse dragged the old engine to under 1 fps with the cursor captured and V-Sync at 480 Hz. After the engine changed how it reads mouse messages, the same setup held 477 fps. In games that read input in batches, such as Valorant, the cost is much smaller.
Is the FPS drop caused by CPU interrupts?
That is the common explanation, but it is not the documented one. Godot's fix changed nothing below Windows: same mouse, same polling rate, same CPU. Only the engine's message handling changed, and captured-cursor fps went from under 1 to 1,703 uncapped. Microsoft's 2023 fix also targeted message delivery to background programs, not interrupts.
Did Windows fix high polling rate stutter?
Partly. Update KB5028185 for Windows 11 22H2 (July 2023) throttles and coalesces raw mouse input for programs running in the background and caps their message rate. It does not fix a game that mishandles its own messages: Godot's collapse was measured on Windows 11 24H2.
Should I use 4000 Hz instead of 8000 Hz?
If a game drops frames at 8000 Hz on an up-to-date Windows, yes, try it. In Godot's unfixed engine at 480 Hz V-Sync, 4000 Hz held 469 to 472 fps while 8000 Hz fell to 151 or under 1. If 4000 Hz still stutters, try 2000 Hz.