Brainstorm: Mouse poll synchronized frame rate capping?

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
Post Reply
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Brainstorm: Mouse poll synchronized frame rate capping?

Post by Chief Blur Buster » 15 Jan 2019, 19:37

Hello.

Blur Busters Idea Alert.

How about a mouse poll synchronized frame rate cap? Basically RTSS hooking into the mouse, to framepace VRR to the poll?

125fps cap for 144Hz VRR monitors for 1000Hz mice (1000/8=125)
200fps cap for 240Hz VRR monitors for 1000Hz mice
250fps cap for 1000Hz mice (some 240Hz gaming monitors may overclock to 250Hz)

This could reduce mouse microstuttering from poll rate significantly, creating even smoother VRR motion of even lower latency, potentially improving mousefeel. Capping software would hook into the mouse reports somehow -- and framepace the framecap on a VRR display in synchronous to mouse reports, reducing the pollrate-vs-refreshrate harmonics/beat-frequencies that can affect mousefeel.

Remember, at 4000 pixels/sec flickturn, even a 1ms error = 4 pixel microstutter! So milliseconds do matter for this use case.

Thoughts on this brainstorm?
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: Brainstorm: Mouse poll synchronized frame rate capping?

Post by RealNC » 15 Jan 2019, 21:43

With a 1000Hz mouse, you'd only be improving things by 0.5ms (average jitter.) So IMO it doesn't help much with 144Hz or even 240Hz displays. With a 125Hz mouse though, this would help a lot, since it would give an apparent frame pacing jitter reduction of 4ms, which is huge (clearly visible on 144Hz displays.) But... who uses 125Hz mice :P
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Brainstorm: Mouse poll synchronized frame rate capping?

Post by Chief Blur Buster » 16 Jan 2019, 05:03

RealNC wrote:With a 1000Hz mouse, you'd only be improving things by 0.5ms (average jitter.) So IMO it doesn't help much with 144Hz or even 240Hz displays.
Doesn't mean we shouldn't try. Sometimes the millisecond reveals unexpected surprises; like it does for MPRT, strobe backlights pulsewidths, GtG ghosting differences still human-visible 0.5ms GtG versus 1.0ms GtG being important for ultra-Hz (confirmed by my eyes too), and other factors.

Run this thought exercise:
+/-0.5ms (1ms microstutter vibration amplitude) is still almost a 25% blur-adder to a 4.2ms refresh cycle.

The ultrahighfrequency rapid microstutters of +/-0.5ms beat-frequencying (blending into motion blur, as explained in 1000Hz Journey Article "stutter=blur" equivalency explanation, using the guitar string metaphor.

Low frequency stutter, like guitar strings, become visible vibration (vibrating edges). While high frequency stutter simply blends to motion blur (blurry edges). This is visible at http://www.testufo.com/vrr and variable-refresh-rate framerate ramp animations -- for a see-for-yourselfer for skeptical naysayers about this "stutter=blur" blend/equivalency.

So, you see -- this may be currently turning ~4ms persistence (240Hz sample-hold = 1/240sec motion blur) into ~5ms persistence (and that's even before GtG blur is added), perhaps even degrading 240Hz quality by 25%. That's major. Throw in GtG, and you've got very roughly ~6ms persistence -- 50% worse thanks to GtG limitations and mouse microstutter limitations.

At 480Hz, this becomes a cliff. ~2ms persistence becoming ~4ms because of the 1ms GtG amd the 1ms mouse microstutter.
480Hz degrading to 240Hz due to combined weak links.
See, RealNC?

Anyway, many people keep being unable to get TestUFO-smooth mouseturns in their games (it's hard), and this is one of the many causes.

So... DO test/experiment/turn this unturned stone rather than classic assumption (that BlurBusters exists to battle!) ;)
I've got a feeling this is potentially one of the famous Blur Busters "millisecond surprises".
Maybe not, but I have long had an uncanny ability of insight here -- the same uncanny ability I use to invent TestUFO animations.

With the emergence of 0.5ms GtG monitors and my expectation of >240Hz -- I'm expecting that mouselook fluidity improvements could transition from microstuttery to VR-quality with a pollrate-synchronized VRR frame rate cap. This matters a lot less with 165Hz IPS than 240Hz TN and especially 480Hz TN, and it's time to get ready to battle weak links in the Refresh Rate Race. This is a known weak link, let's fix it.

Possible Error Factors:
That said, internally, many mouse sensors are running at ~2000Hz thru ~6000Hz now, and the 1000Hz report rate is sometimes a composition/average of the last few, so that the poll rate may be slightly decoupled from the sensor rate. In such mice, that may mean the pollrate aliasing effect may be lower, if the polls during fluctsuating-framerate situations don't need to be grid-aligned to the millisecond intervals, and then instead exhibit the sensor granularity effect instead of the poll rate granularity effect.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Vleeswolf
Posts: 37
Joined: 25 Aug 2017, 15:59

Re: Brainstorm: Mouse poll synchronized frame rate capping?

Post by Vleeswolf » 16 Jan 2019, 12:16

This is a thing with hardware such as NaturalPoint TrackIR 5, which has a 120 hz poll rate. Unless you cap a game to integer multiples/divisors of 120 hz the head tracking motion feels bad. I use either in game or RTSS capping to target 60 FPS with TrackIR games, with a 100hz gsync Monitor for a perfectly smooth and responsive tracking experience.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Brainstorm: Mouse poll synchronized frame rate capping?

Post by Chief Blur Buster » 16 Jan 2019, 13:41

Vleeswolf wrote:This is a thing with hardware such as NaturalPoint TrackIR 5, which has a 120 hz poll rate. Unless you cap a game to integer multiples/divisors of 120 hz the head tracking motion feels bad. I use either in game or RTSS capping to target 60 FPS with TrackIR games, with a 100hz gsync Monitor for a perfectly smooth and responsive tracking experience.
Excellent use case for tracker-pollrate-synchronized frame rate caps.

Some mice/devices probably need it more badly than others.

The problem with arbitrary capping is you've got sawtooth-slewing input lag effect as the Hz is not exactly same.

Image

For example, refresh rate may be 119.983Hz and the tracker may be 120.015Hz -- they are not running off the same clocks. As they slew against each other, you have saw-toothing [0ms -> 8.3ms] input latency. During those sawtooth-crossings, you get 1 tiny microstutter. Possibly 1 microstutter every few seconds, or every minute, or more, but over the whole minute you've got a gradually-increasing or gradually-decreasing input latency caused by the slewing of slightly different Hz.

Implementation Idea
The use of a pollrate-synchronized framerate cap, would fix that latency, and that occasional microstutter. (e.g. Framerate cap algorithm could even be to release the last frame's Present() call the moment a new report comes in, which causes the game to begin input-reading that).
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Slender
Posts: 573
Joined: 25 Jan 2020, 17:55

Re: Brainstorm: Mouse poll synchronized frame rate capping?

Post by Slender » 18 Sep 2023, 17:48

wow, but how realize that?

Post Reply