The Obsolete Rule and the Window It Created
The standard advice for modern PC gaming has long been a specific triad: disable vertical synchronization, enable a frame limiter, and cap that limiter three frames below your monitor’s maximum refresh rate. This configuration is presented as the universal solution for smooth, tear-free gaming with minimal input lag. It is not. This rule was engineered for a display technology that no longer dominates the high-end market: fixed refresh rate panels. It assumes a rigid mechanical constraint where the screen updates at a single, immutable speed, such as 60Hz or 144Hz. In that static environment, the rule served a precise purpose: it kept the frame rate within a narrow band below the refresh ceiling to prevent the display from attempting to draw a frame that had not yet been fully rendered by the GPU.
When a GPU renders faster than the display can show, tearing occurs because the screen begins drawing a new frame while the previous one is still being painted. V-Sync solved this by forcing the GPU to wait for the next vertical blanking interval, but this introduced stuttering when the frame rate dropped below the refresh rate. The frame limiter was the compromise, capping the FPS to stay just under the refresh rate, thereby avoiding both tearing and the stutter caused by V-Sync’s queue. However, this logic collapses entirely on Variable Refresh Rate (VRR) displays. VRR monitors, including those supporting G-Sync and FreeSync, dynamically adjust their refresh rate to match the GPU’s output. The display does not have a fixed ceiling to breach. The concept of staying "three frames below" a limit is meaningless when the limit is fluid and determined by the content itself.
The persistence of this advice is a result of legacy knowledge being applied to new hardware without understanding the underlying mechanism change. Users who purchase VRR monitors and retain their old settings are often applying a solution to a problem that no longer exists. The frame limiter, in this context, is not optimizing performance or visual quality; it is artificially restricting the GPU’s ability to utilize the display’s full potential. By capping the frame rate, the user is preventing the monitor from refreshing at higher rates when the hardware is capable of delivering them. This results in a suboptimal experience that is worse than what the hardware can natively provide, simply because the user is following a rule designed for a different era of display technology.
The Mechanics of Variable Refresh Rate
To understand why the old advice fails, one must examine how VRR actually functions. Unlike fixed refresh rate panels, which operate on a rigid clock cycle, VRR displays contain a controller that can vary the timing of its vertical blanking intervals. When the GPU renders a frame, it signals the display. If the display is ready, it immediately begins scanning out the new frame. If the GPU is still working, the display waits. This synchronization is handled at the hardware level, between the GPU and the monitor, bypassing the operating system’s compositor in many cases. The result is a seamless integration of frame delivery and screen refresh, eliminating tearing without the latency penalties associated with traditional V-Sync.
The critical distinction here is the removal of the "ceiling." On a fixed 144Hz panel, if the GPU produces 145 frames per second, the 145th frame is discarded or causes tearing because the 144th refresh cycle has already begun. The system cannot handle the excess. On a VRR panel, if the GPU produces 145 frames, the monitor simply refreshes at 144Hz for a moment, then adjusts to 145Hz for the next frame, or varies continuously between the two. There is no penalty for exceeding the nominal refresh rate. The display adapts to the content. Therefore, any software-based cap that restricts the frame rate to a value below the maximum refresh rate is actively preventing the monitor from operating at its optimal synchronization point.
This mechanism also changes the role of the frame limiter. In the old paradigm, the limiter was a protective measure against tearing. In the VRR paradigm, the limiter becomes a throttle on performance. If a game can run at 160 FPS on a 144Hz VRR monitor, the monitor will refresh at up to 160Hz, provided the display supports that range. Capping the FPS at 141 (144 minus 3) forces the monitor to refresh at a lower rate, increasing input latency and reducing visual fluidity. The user is essentially telling the hardware to perform below its capability. The only valid reason to cap the frame rate on a VRR display is to prevent the GPU from overheating, to manage power consumption, or to ensure stability in games with erratic frame pacing. It is not a requirement for tear-free gameplay.
The Role of the DXGI Flip Model
The software stack on modern Windows systems has evolved alongside VRR hardware, introducing the DXGI flip model. This presentation model is fundamentally different from the older bit-block transfer (BitBlt) method. In the BitBlt model, the GPU copies the rendered frame into a separate surface owned by the Desktop Window Manager (DWM), which then composites it to the screen. This process involves multiple memory copies and adds latency, particularly in windowed mode. The flip model, introduced in Windows 8 and refined in subsequent updates, allows the GPU to share the back buffer directly with the DWM. This eliminates the intermediate copy operations, reducing system resource load and improving performance.
The flip model is crucial for VRR because it supports the low-latency presentation required for smooth variable refresh rates. It enables features such as "DirectFlip," where the application can bypass the DWM entirely and send frames directly to the display controller. This is most effective in fullscreen borderless mode, where the window client region matches the screen dimensions. In this configuration, the GPU can present frames with minimal overhead, ensuring that the time between frame completion and display refresh is as short as possible. This reduces input latency, which is a primary benefit of VRR.
However, the flip model also changes how tearing and synchronization are handled. With the flip model, tearing can occur if the application presents a frame while the display is in the middle of scanning out the previous one. This is where the old advice to use a frame limiter often clashes with the capabilities of the flip model. The flip model allows for unthrottled framerates in windowed mode, provided the application supports the `DXGI_PRESENT_ALLOW_TEARING` flag. This flag permits tearing, which is then managed by the VRR display. The display’s variable refresh rate smooths out the tearing, making it imperceptible or less disruptive. By forcing a frame limiter, the user prevents the flip model from operating in its most efficient state, adding unnecessary latency and reducing the frame rate without gaining any visual benefit. The flip model is designed to work with the hardware, not against it, and capping the FPS undermines this design.
When the Frame Limiter Is Actually Necessary
Despite the arguments against universal frame limiting, there are specific scenarios where capping the frame rate on a VRR display is beneficial. The key is to distinguish between performance optimization and synchronization necessity. One such scenario is when the game’s frame pacing is inconsistent. If a game produces frames at irregular intervals, such as 100 FPS for one second and 60 FPS for the next, the VRR display will adjust its refresh rate accordingly. While VRR handles this well, extreme fluctuations can still cause minor stuttering or visual artifacts, particularly if the refresh rate swings rapidly between low and high values. In such cases, a frame limiter can smooth out the pacing, providing a more consistent experience.
Another valid use case is thermal and power management. Modern GPUs can generate significant heat when running at high framerates, especially in demanding titles. If the GPU is thermally constrained, it may throttle its performance, leading to unexpected frame rate drops. By capping the FPS, the user can keep the GPU within a safe thermal envelope, ensuring stable performance. This is particularly relevant for laptops or systems with limited cooling capacity. In these instances, the frame limiter is not a synchronization tool but a stability mechanism. It prevents the hardware from self-limiting due to thermal stress, which would otherwise result in worse performance than a steady, capped framerate.
Additionally, some games have bugs or engine limitations that cause issues at very high framerates. Physics simulations, AI routines, or network synchronization may behave unpredictably if the frame rate exceeds a certain threshold. In these cases, capping the FPS is necessary to maintain game integrity. However, this is a game-specific issue, not a display-specific one. The user should cap the FPS based on the game’s requirements, not based on the monitor’s refresh rate. The "three frames below" rule is irrelevant here; the cap should be set to the highest stable framerate the game can handle, regardless of whether it is 144Hz, 165Hz, or 240Hz.
The Correct Configuration for VRR Users
For players who have invested in VRR monitors, the configuration should reflect the capabilities of the hardware. The first step is to disable vertical synchronization in the GPU driver and the game settings. V-Sync is incompatible with VRR in the traditional sense, as it forces a fixed refresh rate, negating the benefits of variable refresh. On NVIDIA systems, this means disabling V-Sync in the control panel and enabling G-Sync. On AMD systems, this means enabling FreeSync. The goal is to let the display and GPU communicate directly, without the operating system’s compositor interfering.
Next, the frame limiter should be disabled or set to a value that does not restrict the GPU’s performance. If the game can run at 144 FPS on a 144Hz monitor, the user should allow it to do so. If the game runs at 200 FPS, the monitor will refresh up to 200Hz, provided the display supports it. The only time a frame limiter is needed is if the user wants to reduce input latency further by lowering the framerate, or if they need to manage thermal output. In these cases, the cap should be set based on the user’s specific needs, not on a rigid rule. The "three frames below" guideline is obsolete and should be abandoned.
Finally, users should ensure they are using the flip model in their graphics applications. This is the default on modern Windows systems for most games, but it is worth verifying. The flip model provides the lowest latency and best performance, especially in windowed mode. By combining the flip model with VRR and no frame limiter, users can achieve the smoothest, most responsive gaming experience possible. The old rules were designed for a static world. In a dynamic one, they only serve to hold the hardware back. The correct approach is to trust the hardware, let it run at its full potential, and only intervene when there is a specific, measurable issue to solve.