# 8,000 Mouse Refreshes per Second: How High Polling Rate Mice Break Games and How Engines Fix It
Gaming mice have quietly been shipping faster and faster reporting hardware, and a body of developer-facing material suggests that this speed can outrun the assumptions built into game engines. The evidence for the specific figures and failure modes below comes largely from individual engine articles and community fix projects rather than from independent, cross-checked measurement, so the claims are presented here as reported rather than settled. What that material describes, taken together, is a recurring pattern: input hardware got dramatically faster, and some engines were not ready for it.
## How mice talk to your PC as USB HID devices
A mouse is generally understood to communicate with a computer as a USB Human Interface Device — a member of the USB HID device class, [the standard part of the USB specification](https://en.wikipedia.org/wiki/USB_human_interface_device_class) that covers keyboards, mice, game controllers, and similar input peripherals. The premise of the HID class is that these devices describe their own data format to the host, so the operating system can interpret their input without a vendor-specific driver.
In practice this means a mouse periodically sends the host a small report describing movement and button state, and the host delivers those reports to whatever software is listening. The rate at which those reports arrive is not fixed by the HID class itself; it depends on how the device is configured. That configurability is where the trouble described below begins. (Note that the mechanics here are drawn from general documentation of the HID class rather than from an independently verified account of any specific mouse, so exact behavior can vary by device.)
## What a high polling rate is: up to 8,000 mouse refreshes per second
Polling rate refers to how often, per second, a mouse reports its state to the host — measured in hertz. For years a rate of 125 Hz to 1,000 Hz was typical, with 1,000 Hz (one report per millisecond) treated as a high-end ceiling.
More recent gaming mice are reported to push well beyond that. Several developer accounts describe hardware capable of on the order of 8,000 reports — sometimes called “refreshes” — per second, roughly eight times the older 1,000 Hz ceiling. This 8,000-per-second figure is not independently corroborated here and should be read as the claim these sources make about current hardware, not as an established specification. What matters for the sections that follow is the direction: the volume of input events an engine may receive per second has, by these accounts, risen sharply.
## Why polling rates above 1000 Hz cause stuttering in game engines
The reported failure mode is not that fast input is inaccurate, but that there is simply much more of it. Where an engine’s input loop was written assuming perhaps a few input events per frame, a mouse reporting thousands of times per second can deliver an event volume the loop was never sized for.
Multiple engine and community projects describe rates above 1,000 Hz producing stuttering — that is, a mouse that reports too often correlating with dropped or uneven frame pacing rather than smoother tracking. A [Godot Engine article on high polling rate mice on Windows](https://godotengine.org/article/fixing-high-polling-rate-mice-on-windows/) is presented as addressing exactly this kind of problem, and separate community fixes exist for [Unity](https://github.com/ILiveInUrFridge/Unity-Mouse-Polling-Rate-Fix) and [WebGL](https://github.com/NIR3X/WebGL-Mouse-Input-Fix). The existence of independent fixes across several engines is consistent with a shared root cause, though the precise mechanism is not verified here and the causal link between “above 1,000 Hz” specifically and stuttering remains uncorroborated. The plausible reading of these sources is that per-event processing cost, multiplied by a much larger event count, is what degrades frame timing.
## The worst case: multi-second freezes during mouse movement
Beyond ordinary stutter, some accounts describe a far more severe symptom: multi-second freezes that occur specifically while the mouse is being moved. In this description, a game does not merely hitch — it stalls for a noticeable stretch, and the stall is tied to mouse motion, which is the moment a high polling rate mouse would emit the most events.
This is among the least independently corroborated claims here, and the sources do not confirm a precise threshold, hardware list, or reproduction case for it. If accurate, it would be the extreme end of the same event-flooding story: when input events arrive faster than the engine drains them, a backlog could grow until the main loop is starved. That mechanism is a reasonable inference from the reported symptom rather than a documented finding, and it should be treated as such.
## Inside Godot’s fix: “Handling 8 thousand mouse refreshes per second in Godot Engine” on Windows
According to the material provided, the Godot Engine team published an article about handling very high polling rate mice on Windows — described with a title on the order of “Handling 8 thousand mouse refreshes per second in Godot Engine.” The exact title, authorship, and contents are not independently verified here; what is available is [the Godot Engine article on fixing high polling rate mice on Windows](https://godotengine.org/article/fixing-high-polling-rate-mice-on-windows/), which is presented as the engine’s own account of the problem and its remedy.
Because the specifics have not been cross-checked, this section does not restate a fix in technical detail. The claim that can be responsibly made is narrow: an official Godot article on this topic is reported to exist and to concern Windows specifically. Readers wanting the actual implementation should treat the linked article as the primary source and read it directly, since the summary claims around it are flagged as uncorroborated.
## The same problem across engines and platforms: Unity, WebGL, and Linux/LWJGL
If this were a Godot-only quirk, it would likely not have generated fixes elsewhere. The provided sources instead point to a spread of independent projects:
– A [Unity mouse polling rate fix](https://github.com/ILiveInUrFridge/Unity-Mouse-Polling-Rate-Fix) targeting the same class of problem in Unity projects.
– A [WebGL mouse input fix](https://github.com/NIR3X/WebGL-Mouse-Input-Fix), indicating the issue is reported in the browser/WebGL context as well.
– A [sledding-mouse-fix project](https://github.com/mitchellcairns/sledding-mouse-fix), one more community effort in the same space.
– A [Linux-oriented fix, Scherso/MouseFix](https://github.com/Scherso/MouseFix), discussed below.
The pattern across engines and platforms is suggestive of a hardware-driven problem rather than a single engine’s bug. That said, these are separate projects by different authors, and this article does not independently verify that they all share one identical root cause; the shared symptom vocabulary is the connective tissue, not confirmed shared internals.
## The Linux workaround: Scherso/MouseFix for LWJGL 2.9.x
On Linux, the [Scherso/MouseFix project](https://github.com/Scherso/MouseFix) is presented as a workaround aimed at users on a specific input stack. The provided material describes it as targeting LWJGL — the Lightweight Java Game Library — at version 2.9.x in particular, a lineage associated with Java games such as older Minecraft versions.
The version specificity (2.9.x rather than LWJGL broadly) is part of the reported claim and has not been independently confirmed here; the repository link is the source to consult for exact scope, supported configurations, and installation. What this entry adds to the overall picture is platform breadth: the high polling rate problem is described not only across engines but across operating systems, with Linux getting its own targeted remedy.
## Beyond mice: how high polling rates cause ghosting-type issues on mechanical keyboards
The provided material extends the concern past mice to keyboards, where a related but distinct symptom — commonly called ghosting — is raised. A [keyboard ghosting troubleshooting resource](https://github.com/aston89/KEYBOARD-GHOSTING-TROUBLESHOOTING) is offered as reference for that class of problem on mechanical keyboards.
The suggested link between high polling rates and keyboard ghosting is uncorroborated and should be read cautiously. Ghosting on keyboards is traditionally attributed to matrix-scanning limitations — certain key combinations that a keyboard’s wiring cannot report simultaneously — which is a different mechanism from an engine being flooded by too many input events. Whether high polling rates cause, worsen, or merely coincide with ghosting-type symptoms is not established by the sources here. The responsible takeaway is that keyboards have their own input-integrity failure modes worth troubleshooting separately, and the linked resource is a starting point rather than confirmation of a polling-rate cause.
—
Across these accounts, the through-line is consistent even where the individual figures are not confirmed: input hardware appears to have gotten fast enough to expose assumptions baked into game engines years ago, and engines and communities have responded with platform-specific fixes. The specific numbers — 8,000 reports per second, the 1,000 Hz threshold, multi-second freezes — come from developer and community sources that have not been independently cross-checked here, so they are best treated as reported behavior pointing to a real and recurring problem, with the linked projects and articles as the primary sources to verify against.
A related engine-side case appears in Game Animation Sample Project Updated for Unreal Engine 5.8: New Physics, Motion Matching, Pose Searching, and Look-At.