Cursor Plane Timing Theory
Posted: 24 May 2026, 05:02
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?
