dermodemon wrote: ↑12 Jun 2025, 12:48
Vocaleyes wrote: ↑12 Jun 2025, 10:47
dermodemon wrote: ↑12 Jun 2025, 03:51
and how we can run these cpp files by the way? want to try it
open folder - x64 - release - open app, should do it?
so i tested it. with this app running my desktop sensitivity feels like 3200 dpi instead of my 1600 dpi.
but in games - 0 differences. absolutely does nothing. only on desktop
No problem, i've spent a lot of today working on all of this and trying to refine. I came across something interesting while doing this, which would fit the pattern of mouse on windows 7 was good, then went to s**t;
Windows 7 **did not** force vsync on mouse input at the OS level.
### Key Points:
**Windows 7**:
* Raw input, DirectInput, and standard WM\_MOUSEMOVE messages were all **decoupled from vsync**.
* Mouse input was processed **asynchronously**—meaning the cursor and input events were delivered immediately, not synced to the screen’s refresh rate.
* This is one reason why many users describe mouse movement in Windows 7 as feeling **snappier and more responsive**, especially in competitive games.
**Windows 8 and newer** (especially **Windows 10 and 11**):
* Introduced more modern input pipelines and compositor models (such as **WDDM 1.2+**, **DWM always-on**, **input injection** tied to frame presentation, etc.).
*Some input paths—especially those using `WM_MOUSEMOVE` or cursor drawing—became synced with the desktop compositor's vsync**, which introduced **input delay** (1–2 frames).
* Games using raw input or DirectInput often still avoid this delay, but the desktop and some UI frameworks now feel **slower** in cursor response compared to Windows 7.
Summary:
| Feature | Windows 7 | Windows 10/11 |
| Cursor tied to vsync | No | Yes (in many paths)|
| DWM always-on | No (can disable) | Yes (mandatory) |
| Raw Input delay | Minimal | Sometimes present |
| General cursor responsiveness | High | Often degraded |
So based on that information, I spent a lot of today trying to make it so that on windows 11 DWM vsync (which isn't disabled within nvidia control panel) doesn't affect mouse movement.
I made an app to reflect this.
Currently am boiled down to an app called "LowInputLagShell", this app;
✔ Reduce input latency
✔Bypass vsync-related delay
Does NOT change mouse movement feel in any noticeable way.
What this does:
✔ Captures raw mouse input (via RIDEV_INPUTSINK)
✔ Skips Windows’ input-to-vsync sync via PeekMessage
✔ Uses high-resolution timers (timeBeginPeriod(1))
Does not read or move the mouse cursor (no movement change)
No processing or filtering added.
Please feel free to test this and let me know (find attached) am about to test it myself. Just getting it to a place where it's NOT janking out everywhere is the real challenge it turns out.
Cheers for the feedback!
https://drive.google.com/drive/folders/ ... sp=sharing
Does NOT change mouse movement feel in any noticeable way.