Cursor Plane Timing Theory
-
Vocaleyes
- Posts: 486
- Joined: 09 Nov 2021, 18:10
Cursor Plane Timing Theory
Hey, been a while. I’ve still been looking into the circular mouse drift behaviour and I came across something I wanted your opinion on because it feels like it might actually line up architecturally.
From what I understand, modern Windows cursor rendering can operate through separate hardware cursor plane/overlay paths within a far more asynchronous composition/presentation pipeline than older Windows systems used. If that understanding is correct, then mouse polling, cursor updates, compositor timing and display scanout timing are all effectively operating somewhat asynchronously rather than as one tightly synchronized pipeline.
The reason I’m wondering about this is because the behaviour seems deterministic rather than random. Clockwise circles consistently drift one direction, anticlockwise circles drift the opposite direction, and it persists across multiple systems. Disabling MPO also didn’t eliminate it, which made me think this may be something more fundamental to the modern input/render stack rather than an overlay bug specifically.
My thought was that continuous rotational movement may expose tiny timing/sampling asymmetries between HID polling, cursor plane updates and presentation timing that normally wouldn’t show up during ordinary movement. Since clockwise vs anticlockwise movement reverses the ordering/phase relationship of X/Y deltas, any subtle asymmetry there could theoretically accumulate in opposite directions over time.
I could be completely misunderstanding how modern cursor handling behaves under Windows 11, but does that sound technically plausible to you at all?
From what I understand, modern Windows cursor rendering can operate through separate hardware cursor plane/overlay paths within a far more asynchronous composition/presentation pipeline than older Windows systems used. If that understanding is correct, then mouse polling, cursor updates, compositor timing and display scanout timing are all effectively operating somewhat asynchronously rather than as one tightly synchronized pipeline.
The reason I’m wondering about this is because the behaviour seems deterministic rather than random. Clockwise circles consistently drift one direction, anticlockwise circles drift the opposite direction, and it persists across multiple systems. Disabling MPO also didn’t eliminate it, which made me think this may be something more fundamental to the modern input/render stack rather than an overlay bug specifically.
My thought was that continuous rotational movement may expose tiny timing/sampling asymmetries between HID polling, cursor plane updates and presentation timing that normally wouldn’t show up during ordinary movement. Since clockwise vs anticlockwise movement reverses the ordering/phase relationship of X/Y deltas, any subtle asymmetry there could theoretically accumulate in opposite directions over time.
I could be completely misunderstanding how modern cursor handling behaves under Windows 11, but does that sound technically plausible to you at all?
-
Hyote
- Posts: 677
- Joined: 09 Jan 2024, 18:08
Re: Cursor Plane Timing Theory
I don't know much about this cursor fetish but there are lots of things to uncover. This is one: https://ctfmon.vercel.app/
-
timecard
- Posts: 77
- Joined: 25 Jan 2020, 01:10
Re: Cursor Plane Timing Theory
Does enforcing software cursor still give you cursor drift, that should eliminate nvidia driver hardware cursor as a factor.
-
soul4kills
- Posts: 108
- Joined: 01 Aug 2025, 01:30
Re: Cursor Plane Timing Theory
AYO. This was a really interesting read. I did the registry edit to disable CTFMON from intercepting inputs. And it reduced my input latency by an insane amount. So much so that I want to turn it back on because it was just too much. But I'm gonna continue with it off to see if I'll eventually adjust to it.Hyote wrote: ↑25 May 2026, 11:59I don't know much about this cursor fetish but there are lots of things to uncover. This is one: https://ctfmon.vercel.app/
edit: Not really sure what was going on. Either it made my latency really good, or made it more erratic. I didn't like it so I reverted it back and now everything feels better.
- Panychkaaa
- Posts: 32
- Joined: 17 Feb 2024, 03:59
Re: Cursor Plane Timing Theory
I do not advise this tweakHyote wrote: ↑25 May 2026, 11:59I don't know much about this cursor fetish but there are lots of things to uncover. This is one: https://ctfmon.vercel.app/
-
SCHYNEYDER
- Posts: 2
- Joined: 05 Jul 2017, 14:26
Re: Cursor Plane Timing Theory
Why ?Panychkaaa wrote: ↑27 May 2026, 12:30I do not advise this tweakHyote wrote: ↑25 May 2026, 11:59I don't know much about this cursor fetish but there are lots of things to uncover. This is one: https://ctfmon.vercel.app/
-
Hyote
- Posts: 677
- Joined: 09 Jan 2024, 18:08
Re: Cursor Plane Timing Theory
Same, I just recommend CTFMON not running at all.Panychkaaa wrote: ↑27 May 2026, 12:30I do not advise this tweakHyote wrote: ↑25 May 2026, 11:59I don't know much about this cursor fetish but there are lots of things to uncover. This is one: https://ctfmon.vercel.app/
-
ablemor
- Posts: 326
- Joined: 21 Oct 2022, 07:05
Re: Cursor Plane Timing Theory
this do nothing, placebo, or very little improvement!
-
Vocaleyes
- Posts: 486
- Joined: 09 Nov 2021, 18:10
Re: Cursor Plane Timing Theory
Something i have noticed for a while, but only looked in to recently was slider behaviour either in game or on desktop. When using the mouse to move a slider either direction, would consistently skip numbers. After looking in to it for an hour or 2 i realised this was due to my setting of 3/11 in windows. i have ALWAYS used this value, even when mouse worked fine for me and this slider behaviour was not present when i was on xp, me, 7 etc.
When running 6/11 the sliders work as intended, but unfortunately isn’t an option running at 6/11 as i am a wrist aimer and even at 400dpi is way too fast to be used.
So.. i downloaded raw accel to test something.
I set mouse in windows to 6/11 then in raw accel i set multiplier to 0.25. BOOM! Correct mouse speed, no more pixel skipping.
This proves a change for the worse with regard to integer rounding math and while raw accel addresses it and improves upon it drastically, still isnt as it used to be.
If anyone else is used to playing on a non 6/11 sens, look up the multiplier needed for raw accel, as i said for me it was 0.25 at 3/11, if you're not using 3/11 it will be a different value that 0.25.
When running 6/11 the sliders work as intended, but unfortunately isn’t an option running at 6/11 as i am a wrist aimer and even at 400dpi is way too fast to be used.
So.. i downloaded raw accel to test something.
I set mouse in windows to 6/11 then in raw accel i set multiplier to 0.25. BOOM! Correct mouse speed, no more pixel skipping.
This proves a change for the worse with regard to integer rounding math and while raw accel addresses it and improves upon it drastically, still isnt as it used to be.
If anyone else is used to playing on a non 6/11 sens, look up the multiplier needed for raw accel, as i said for me it was 0.25 at 3/11, if you're not using 3/11 it will be a different value that 0.25.
