A fixed-refresh display updates on a regular clock. At 60 Hz, a new scan begins about every 16.7 milliseconds whether the graphics processor has completed a fresh frame or not. That regular schedule is simple, but rendered frames rarely arrive with perfectly regular timing.
Variable refresh rate, commonly shortened to VRR, changes that relationship. Instead of forcing every display refresh to begin at one fixed interval, a compatible display can wait within an allowed timing range and start the next refresh when a completed frame is ready. The result can make changing frame rates look smoother while reducing visible tearing.
VRR does not make a graphics processor render more frames. It changes when completed frames are presented.
Fixed refresh creates a timing boundary
A display normally scans an image from its frame buffer in a defined sequence. With a fixed refresh rate, those scans begin at predictable intervals. The graphics system must decide how to place newly rendered frames onto that schedule.
Without synchronization, the graphics processor can replace the displayed buffer while a scan is already in progress. The upper part of the screen may contain one frame while the lower part contains a newer one. The boundary between them appears as screen tearing, especially during horizontal camera movement.
Traditional vertical synchronization, or V-Sync, avoids that split by coordinating buffer presentation with the display refresh cycle. A completed frame waits for an appropriate refresh boundary rather than replacing the visible buffer mid-scan.
That removes tearing, but fixed timing creates another tradeoff. If a frame misses the next refresh boundary, it may have to wait for a later one. The previous image remains visible longer, producing uneven frame pacing and potentially adding presentation latency.
VRR lets the refresh interval move
A VRR-capable display has a supported refresh window rather than one mandatory interval. A panel advertised with a range such as 48 to 144 Hz can vary the time between refreshes within limits defined by the display, link, and implementation.
Suppose a game alternates between frames that take 8, 10, and 12 milliseconds to render. A fixed 120 Hz display starts a scan every 8.33 milliseconds, so those frame completions do not line up neatly with the refresh clock. With VRR active and operating inside its range, the display can adjust refresh timing around those completed frames instead of forcing them onto fixed 8.33-millisecond slots.
This synchronization reduces the mismatch between rendering cadence and display cadence. Motion can remain visually consistent even as the instantaneous frame rate moves up and down.
The key point is timing, not interpolation. VRR does not invent intermediate images between rendered frames. Each refresh still presents a frame produced by the graphics pipeline.
The supported range sets practical limits
Every VRR implementation has boundaries. A display cannot wait indefinitely for a frame, and it cannot refresh faster than its maximum supported rate.
If rendering exceeds the upper VRR limit, another synchronization policy becomes necessary. Depending on driver, application, and system settings, behavior can include tearing, frame-rate limiting, or conventional synchronization near the ceiling.
Low frame rates create a different problem. If a display has a minimum VRR rate of 48 Hz and a game falls to 35 frames per second, each rendered frame arrives too slowly for a simple one-refresh-per-frame relationship inside that range.
Many systems address this with low frame rate compensation. Instead of presenting each rendered frame once, the system can repeat frames at a multiple that remains inside the display’s VRR window. A 35 fps stream, for example, can be displayed with each frame refreshed twice at an effective 70 Hz timing. No extra rendered motion is created, but the link and panel remain in a valid variable-refresh operating range.
Low frame rate compensation depends on the available range and implementation. A narrow VRR window leaves less room for suitable multiples than a wide one.
Frame rate and refresh rate remain separate measurements
Frames per second describes how frequently the rendering system completes images. Hertz describes how frequently the display refreshes. VRR coordinates these rates, but it does not make them identical concepts.
A game running at 90 fps on a VRR display may cause refreshes to occur near 90 Hz for that period. If rendering later drops to 73 fps, refresh timing can move accordingly. The panel still retains its own electrical and timing constraints throughout those changes.
A high maximum refresh rate remains useful with VRR because a 240 Hz panel offers a shorter minimum refresh interval than a 120 Hz panel, giving the system room to present higher frame rates with lower scanout intervals when the GPU can supply them.
VRR mainly improves behavior when frame delivery varies below that ceiling.
VRR cannot repair irregular rendering itself
A display can align refresh timing with completed frames, but it cannot remove stalls that happen earlier in the pipeline.
If a game produces several frames quickly and then pauses for 80 milliseconds while compiling a shader, loading an asset, waiting on storage, or handling a CPU bottleneck, VRR can present the frames without forcing them onto a rigid refresh schedule. The long gap still exists. The same image must remain visible until another frame arrives.
This is an important limit when diagnosing stutter. Smooth VRR operation can hide small timing variation effectively, but large frame-time spikes remain visible because there is no new visual information to present.
Average frame rate can also conceal this issue. Two games can both average 100 fps while one delivers frames at nearly even intervals and the other alternates between rapid frames and long stalls. The second case can feel much less smooth even on a capable VRR display.
Connection standards and product labels are only part of compatibility
Variable refresh behavior can be carried through technologies associated with DisplayPort Adaptive-Sync, HDMI VRR, and vendor ecosystems such as AMD FreeSync and NVIDIA G-SYNC. These names overlap in purpose but do not guarantee identical ranges, validation criteria, processing paths, or feature support on every product.
The complete chain matters: graphics hardware, driver, operating system, application mode, cable or link, display input, and display firmware all participate. A monitor may support VRR on one input but offer a different range or feature set on another. Televisions can also combine VRR with game modes that change image processing and latency.
Compatibility badges are useful starting points, but the supported refresh range and behavior of the specific device pair provide more practical information than a logo alone.
Rapid refresh changes can expose panel behavior
Changing refresh timing can interact with the physical characteristics of a display panel. Pixel response, overdrive tuning, backlight behavior, and brightness control may have been optimized around particular refresh conditions.
Some displays can show brightness fluctuations or flicker when frame rate changes sharply, especially near the lower end of their VRR range. This does not mean VRR is inserting damaged frames. The visible change can come from the panel’s electrical or luminance response as refresh intervals vary.
Overdrive can also be sensitive to refresh rate. A setting tuned aggressively for a high fixed rate may create overshoot artifacts at lower rates. Displays with effective variable overdrive can adjust response tuning as refresh timing changes, while other models may require a compromise setting across the range.
These panel-level differences help explain how two monitors with similar advertised VRR ranges can look different during the same workload.
Frame caps can keep rendering inside the useful window
A system running very close to a display’s maximum refresh rate can repeatedly cross the upper VRR boundary as rendering speed fluctuates. Some configurations use a frame-rate cap slightly below the maximum to keep presentation inside the variable-refresh range more consistently.
The exact useful cap depends on the display, synchronization settings, game, driver, and latency goals. There is no universal offset that fits every setup.
A cap also cannot raise low performance. It only limits the upper rendering rate. Its value is in controlling presentation behavior when the GPU would otherwise produce frames faster than the chosen display path can present them under the desired synchronization policy.
VRR makes variable performance easier to present
Graphics workloads change from scene to scene. A quiet corridor, dense city, particle-heavy battle, and complex menu can place very different demands on the CPU and GPU. Fixed-refresh presentation forces all of those changing render times onto a rigid display clock.
VRR gives the display clock controlled flexibility. Inside the supported range, a completed frame can trigger a refresh at a more suitable moment, reducing tearing and the pacing penalties created by missed fixed-refresh boundaries.
That flexibility has clear limits. VRR cannot create missing frames, eliminate long rendering stalls, exceed the panel’s maximum rate, or erase panel-specific artifacts. Its practical benefit comes from coordinating two systems that naturally operate on different schedules: a renderer with variable completion times and a display that can vary when its next scan begins.