Blur Busters Forums

Maybe a stupid question but...
I assume (never actually checked) the numbers 120 and 144 were chosen for refresh rates because they have a large number of factors.
A lot of people cap their frames below the monitor refresh. How much does it matter what you cap it to?
Does a prime number such as 137 cause a lot more stuttering than a more divisible number such as 120?
If so, what are the most important factors in order to minimise stuttering? 2,3,4,5?
Would a cap of 140 for a 144hz monitor make more sense than any other near number because it has a high number of factors?

This is important for video playback. 120Hz can play all common video frame rates 1:1 (24FPS, 30FPS, 60FPS), except 50FPS PAL video (you need 100Hz for that,) but that's a very uncommon video frame rate on the internet (it's only used for TV in PAL regions, like Europe.)

144Hz was chosen because it's close to the upper limit of DL-DVI. It can only play 24FPS perfectly (and 48FPS, but that's a very uncommon video frame rate.)

So for the desktop, 120Hz is generally the best refresh rate as it allows video to play without judder.

Content that has arbitrary frame rates (like games) is not affected. You can cap to whatever you like. However, in blur reduction modes (like ULMB, LightBoost, etc.) there can be microstutter for mouse movements in some cases (depends on how the game translates mouse input into animation.) In such cases, a divider of your mouse polling rate produces the least amount of this kind of micro stutter. The effect is tiny (I personally can't see it), but some people can. Without blur reduction, virtually no one can see it (because the motion blur hides it.)

RealNC wrote: Content that has arbitrary frame rates (like games) is not affected. You can cap to whatever you like.

Note that this is only true for freesync/gsync.
Otherwise, the cap you choose will have a significant impact on stuttering and tearing visibility.

e.g:
- cap close to refresh rate with vsync off = tear lines "roll" more slowly across the screen. => more visible tearing
- cap close to refresh rate with vsync on = repeated frames are further apart => longer "periods" in periodic microstuttering

Thanks for the comments guys.

Sorry I wasn't clear in my original post, I tend to use VSYNC and used to cap FPS at 142 (on a 144hz) monitor. I do use ULMB and I was noticing stutter, which seems to be largely improved at 140 cap.

When you cap under your refresh rate, the refresh rate and frame rate go in and out of sync. How frequently this happens depends on how different the framerate is from framerate(or half the framerate, 1/3, etc.) If you were to graph latency you get a sawtooth pattern like this:


If you cap 2fps below your refresh rate, then you get two of those sawtooth waves per second. If you cap farther below refresh rate, you're making the smooth parts of the stutter less smooth, so it's harder to notice the difference between the smooth and stuttery bits.

Bishi wrote:Thanks for the comments guys.

Sorry I wasn't clear in my original post, I tend to use VSYNC and used to cap FPS at 142 (on a 144hz) monitor. I do use ULMB and I was noticing stutter, which seems to be largely improved at 140 cap.

To remove stutter, you need to cap very close to your refresh rate. First, find out what your EXACT refresh rate is:

https://www.vsynctester.com

Then, cap to 0.007FPS below that.

I have a post over here:

http://forums.guru3d.com/showthread.php ... ost5380262

on how to do that. This gives you low latency vsync without stutter.

Ah you clever guy This looks like what I am after. Thank you!

Yes, sawtooth input lag behavior is often a problem when trying to cap with a fixed-Hz display. Slight differentials cause the slewing behaviour between framebuffer time and refresh cycle time, and the sawtooth is the beat-frequency between the two -- with an accompanying visible microstutter at the sharps.

One needs to match -- extremely close -- extremely precisely -- so that it's within the noise, to avoid the sawtooth input lag behavior.

Ideally, you want just-in-time rendering (predictive vsync waiting) to put the sawtooth lag in the valleys continuously. This is done by GeDoSaTo -- and I really think RTSS needs to adopt this too.

This may have been answered elsewhere but how does Fast-Sync and G-Sync compare to this? Is there also a sawtooth pattern of input lag?

And which has more lag, V-Sync ON with no G-Sync and FPS capped -2 under refresh rate, or Fast-Sync with uncapped FPS or FPS capped to double refresh rate?

drmcninja wrote:This may have been answered elsewhere but how does Fast-Sync and G-Sync compare to this? Is there also a sawtooth pattern of input lag?

With fast sync there is, with g-sync there isn't.

And which has more lag, V-Sync ON with no G-Sync and FPS capped -2 under refresh rate, or Fast-Sync with uncapped FPS or FPS capped to double refresh rate?

Fast sync at infinite framerate would have same input lag as g-sync. Fast sync with framerate at double refresh rate would be halfway between g-sync and capped v-sync.