Blur Busters Forums

Mouse input on every major platform, including Windows, Mac, Linux, and consoles, has a directional drift bug rooted in floating point coordinate transformation in the compositing layer.

Modern operating systems route mouse input through a compositor before delivering it to applications. The compositor applies a floating point transformation to integer mouse deltas — scaling for DPI, logical-to-physical coordinate mapping, and other adjustments. The result of this transformation is a float which must be truncated back to an integer screen coordinate before delivery. That truncation is not neutral. It produces a directional error that accumulates rather than cancels out.

This can be demonstrated by drawing slow circles with the mouse. Clockwise rotation produces drift in one direction. Anticlockwise produces drift in the opposite direction. The pattern is deterministic and reproducible across every platform because every modern platform routes input through a compositing layer that applies floating point transformation.

This was confirmed in the nut-tree/libnut-core library on GitHub, where a developer reported that repeatedly setting the cursor to its own current position caused it to drift. The maintainer identified the bug as a rounding error in coordinate translation and fixed it in v2.5.1 by correcting the rounding.

On Windows, Desktop Window Manager was introduced with Vista and performs logical-to-physical coordinate transformation using floating point scaling, documented in Microsoft’s own Win32 API documentation. Microsoft’s mouse_event function in winuser.h uses floor rather than round when mapping absolute coordinates to screen positions, compounding the error for synthetic input.

Prior to compositing, applications received mouse deltas with minimal transformation. The drift was not present. The compositor is the common denominator across every platform and the point at which the directional truncation error is introduced.

No current consumer platform delivers mathematically correct mouse input by default.

Vocaleyes wrote: ↑

31 May 2026, 22:47

Mouse input on every major platform, including Windows, Mac, Linux, and consoles, has a directional drift bug rooted in integer rounding during coordinate translation.

The HID standard defines mouse coordinates in a normalised range of 0 to 65,535. When translating those values to screen pixels, the correct approach is proper rounding. All platforms instead use truncation, a Floor operation, which produces a directional error rather than a neutral one. The remainder accumulates in the direction of movement over time rather than cancelling out.

This can be demonstrated by drawing slow circles with the mouse. Clockwise rotation produces drift toward the bottom right. Anticlockwise produces drift toward the top left. The pattern is deterministic and reproducible.

This was confirmed in the nut-tree/libnut-core library on GitHub, where a developer reported that repeatedly setting the cursor to its own current position caused it to drift upward until the Y coordinate hit a multiple of 135. The maintainer identified the bug in the CalculateAbsoluteCoordinates function and fixed it in v2.5.1 by correcting the rounding and sign handling.

Ubuntu acknowledged and fixed the same issue at the OS level.

Microsoft’s own mouse_event function in winuser.h uses Floor rather than Round when mapping absolute coordinates to screen positions. This is documented in the AutoHotkey community and confirmed against Microsoft’s own API documentation. The formula used is Floor(x times screen_width divided by 65535) rather than the correct Round(x times (screen_width minus 1) divided by 65535). The bug exists in the Windows API itself and remains unpatched as of 2026.

No current consumer platform delivers mathematically correct mouse input.

This information is inconsequential. Why? Because you adapt to the drift without realizing it.

Send me your Discord and I'll provide a system level mouse fix that will stop your cursor fetish.

Hyote wrote: ↑

01 Jun 2026, 23:50

Send me your Discord and I'll provide a system level mouse fix that will stop your cursor fetish.

Send me a solution for Windows 11. My mouse gets faster when I change the DPI or polling rate.
Please send me a solution.
Discord: f1zus

nonesense block of text because of two wards “RAW INPUT”

nickchraj wrote: ↑

02 Jun 2026, 18:11

nonesense block of text because of two wards “RAW INPUT”

"nonesense wards" is amusingly ironic.

Anyway;
Raw input does not bypass the desktop cursor system or remove the need to convert mouse movement into screen movement. It only bypasses pointer acceleration and some OS-level smoothing, meaning the movement data you get is closer to what the mouse sensor reports.

Even with raw input, the OS still has to apply that movement to a cursor position or a process reading it. That means the data is still handled in discrete updates, accumulated over time, and converted into screen space using finite precision math. Tiny rounding differences and timing variation in how those updates are applied can introduce small errors.

Raw input removes one specific layer of processing, not all possible sources of behaviour in cursor movement or measurement.

In simple terms, raw input makes the mouse data more direct, but it does not make cursor movement perfectly continuous or mathematically exact. The system still has to step the movement forward in chunks, and those small imperfections can slowly add up during repeated precise motions.

And for the record, I've already seen logical flaws in my initial post. You can disregard while I continue working to solve.

ok smartahh, there are ways to kill DWM have you tried it?

also do you have any explanation for this? my input lag gets worse on higher polling rate. 500 being sweet spot but still faar away from playable. 1000 and beyond is just crazy delay