We have one now in Armagetron Advanced!

Here is the list of why you may want to enable it, I will elaborate below:

• It can reduce latency
• It can improve motion clarity
• You get more consistent responses
• It conserves energy and thus…
• It increases battery life on mobile devices

First, Recommendations

If you have a variable refresh monitor, do

* Wait for VSYNC on
* Framerate Limit a bit below your refresh rate

This lowers your latency relative to just VSYNC on, without hurting your frame rate too much.

If you also use backlight strobing/black frame insertion (marketing terms vary) and the refresh rate is 180 Hz or above, do

* Wait for VSYNC on
* Framerate Limit at 1/2 to 2/3 of your refresh rate

This lowers your latency relative to just VSYNC on, plus it can increase motion clarity.

Without variable refresh rate, pick between:

* Wait for VSYNC on
* No Framerate Limit (or above your refresh rate)

to conserve energy and get a smooth picture and

* Wait for VSYNC off
* Framerate Limit at 360-720

to minimize latency while not having your PC explode or make strange, high-pitched, noises. Of course, these settings also apply if you have a variable refresh monitor and don’t like VSYNC.

If you want to conserve energy

* Framerate Limit to 40-120 FPS

Z-Man’s personal settings

on a 240 Hz variable refresh screen with strobing backlight support (off most of the time, it has side effects), for anyone interested:

* Wait for VSYNC on
* Framerate Limit at 120 FPS

Rationale

Latency, or Why Even VSYNC Haters Should Consider a Framerate Limit

The usual game processing loop goes like this:

• collect input and network data
• process input, update world state
• send world state to graphics card
• wait for graphics card to receive it all
• maybe also wait for graphics card to process it all and send it to the screen
• repeat

Latency is the time between collecting the input and seeing the effect on the screen. The part of that we can influence is the time between collecting the input and having everything sent to the graphics card. As you see above, without a frame rate limit, that time includes waiting for the graphics card or monitor, which at that point may still be busy dealing with the last update we sent it. A frame rate limit can cut that out; with a frame rate limit, the loop goes

• wait for minimal frame time to have passed since the last loop
• collect input and network data
• process input, update world state
• send world state to graphics card
• wait(*) for graphics card to receive it all
• maybe also wait(*) for graphics card to process it all and send it to the screen
• repeat

How does adding the additional wait decrease latency? Simple. The additional wait is between the update to the screen and collecting the next input, where they do not cause latency. Until the point where the limit actually decreases the frame rate, every millisecond spent waiting there is a millisecond less latency.

Or, put differently; If you set your frame rate limit to a bit below what you typically get for unbound frame rate, you give your hardware a chance to catch a breath between frames and process whatever comes next with lower latency.

Caveat

The latency considered above is the minimal latency. The practical latency you care about is of course the time between you PRESSING a button and the result appearing on the screen. Obviously, that will go up if you reduce the frame rate limit further. The sweet spot for lowest latency is just below the frame rate you would get without limit.

Consistency

In addition to avoidable latency, varying frame rates will also lead to inconsistent latency or other erratic reactions to player input. By capping your frame rate, your game will behave and react the same way every time, which will aid with precision turns.

Motion Clarity

This applies for setups where you have a variable refresh rate screen with also variable strobing backlight.

When you have a moving object on a typical modern sample-and-hold screen, such as an LCD, and you follow the motion with your eye, that object will appear blurry even at 60 FPS. There is no better explanation than just seeing it in action. Higher refresh rates reduce that blur, or expressed another way, they increase motion clarity. To increase clarity further, some screens have a strobing backlight, which only flashes for a fraction of the frame time, reducing the time each frame sends light to your eye. Unfortunately, for LCD screens, the timing of that flash usually cannot be correct for the entire screen, as the frame update comes rolling from the top to the bottom, and you either have the top of the screen already flipping to the next frame or the bottom in the middle of the switch to the current frame. There are of course solutions, for example OLED screens, but they typically come at a higher cost.

What is quite common, though, are monitors that allow you to combine variable refresh rate and backlight strobing. Now the frame rate limit comes in: If you limit the frame rate to, for example, half your monitor’s maximal refresh rate, the transfer of the image data and thus the update of the LCD matrix still happens at a rate that would allow the full refresh rate, so the update finishes early and there is a good finite time between the bottom of the screen updating and the top going to the next frame. Which means there likely is a time when the image at a consistent state across the entire display, which is, ideally, when the backlight flash will be triggered. Whether that all works out depends very much on implementation details, though.

Energy Savings and Battery Live

Should be obvious. Fewer frames per second means less work means less energy used means more time on a battery charge.