VRR Flicker on OLED Monitors: Causes and Fixes

Part of the gaming monitor guide. The underlying display physics is covered in how display panels actually work.

What is actually changing when the screen flickers?

An OLED pixel is a light emitter driven by a thin-film transistor circuit that holds a charge for the duration of one refresh interval. The panel's gamma response, the mapping from input signal value to output luminance, is calibrated at one refresh rate, normally the panel's native maximum. TFTCentral's testing describes this directly: gamma on OLED panels is optimised for a fixed refresh rate, and when the display runs outside that rate the subpixels receive an effectively incorrect charge level for the intended brightness.

Variable refresh rate deliberately breaks the fixed interval. When the game renders at 90fps the panel refreshes every 11.1 milliseconds; at 45fps it refreshes every 22.2 milliseconds. The pixel drive circuit holds its charge across a window twice as long, and the average light output over that window is not identical to the calibrated value. The result is a luminance error that tracks frame rate.

This is why the effect is called VRR flicker rather than VRR tearing or stutter. Nothing is wrong with the image content. The same signal value is simply being rendered at a slightly different brightness from one moment to the next, and the eye interprets a rapid sequence of those small brightness differences as flashing.

Why dark scenes flicker and bright scenes do not

Two things stack up near black, and neither is what people usually assume. The first is the shape of the gamma curve. Near black the curve is compressed, so a very small absolute change in luminance spans a large number of code values; the identical absolute change higher up the curve spans a fraction of one. The second is OLED's black floor, which is genuinely black. On an LCD, a backlight sits under every dark scene and raises the floor enough to bury small luminance errors. On OLED there is nothing underneath to hide behind.

It is worth being precise about the eye's part in this, because it is often overstated. Weber's law, the rule that we resolve brightness differences proportionally rather than absolutely, holds well across mid photopic levels. It does not hold all the way down: at low luminance the eye moves into the DeVries-Rose regime and proportional sensitivity actually gets worse. Near-black VRR flicker is conspicuous because of the display, not because vision peaks there. What the eye does contribute is dark adaptation, which is why the same artefact is obvious in a dark room and easy to miss in a lit one.

TFTCentral's measurements on a WOLED panel, the Asus ROG Swift PG27AQDP, show the code-value compression clearly. Sweeping the frame rate from 480fps down to 10fps, the bottom of which sits below the panel's 40Hz VRR floor where LFC is multiplying frames, moved the darkest test patch from RGB 5 to RGB 16, a span of eleven values. The same sweep moved a bright RGB 200 patch by only about two values. The eleven-step figure measures how many code values the error covers, not how large the luminance change is; that same luminance shift at mid-grey would amount to a fraction of a single step and pass unnoticed.

Why menus, loading screens and cutscenes are the worst offenders

In-game frame rate usually varies within a band. Walking through a level might swing between 90 and 120fps, a modest change in refresh interval producing a modest gamma error. Menus, pause screens, loading screens and inventory overlays are different: they contain almost no geometry, so the GPU renders them at whatever the engine allows, often several hundred frames per second, and then drops back to gameplay frame rate the instant the scene loads.

That produces the largest possible refresh interval swing, repeated, and it very often happens over a dark or black background. A loading screen is close to the worst-case test pattern for this artefact: huge frame rate range, near-black content, and a static image that gives the eye nothing else to look at.

Cutscenes trigger it for the opposite reason. Many are locked to 30fps while gameplay runs uncapped, so entering and leaving a cutscene forces an abrupt refresh transition. If a monitor flickers only in menus and cutscenes and looks clean during gameplay, that pattern is the expected signature of VRR flicker, not evidence of a fault.

Is the monitor defective?

Almost never. RTINGS tested six popular gaming OLEDs for their comparative research on the artefact and found VRR flicker on all six, differing in severity rather than in kind. No OLED gaming monitor has been shown to be free of it. It is a property of how self-emissive pixels are driven, not a manufacturing escape.

The artefact is not exclusive to OLED, though the evidence across panel types is uneven. TFTCentral found no visible or measurable flicker on the IPS monitors it tested, and expects VA panels to show the effect without having validated it directly. OLED is singled out because its near-perfect black floor makes dark scenes genuinely dark, which is precisely the condition under which small luminance errors become visible.

A defect looks different: flicker that persists with VRR disabled entirely, flicker that is confined to one region of the panel, visible banding or lines, or brightness pulsing at a fixed rhythm regardless of what is on screen. Any of those warrants a warranty claim. Brightness that shifts in step with frame rate changes does not.

WOLED and QD-OLED flicker in different patterns

The two OLED panel constructions misbehave in distinguishable ways, which is useful when diagnosing what a display is doing. On WOLED panels, gamma appears to track frame rate more or less continuously and proportionally: a small frame rate swing produces a small luminance shift, a large swing produces a large one. Reducing the size of the swing therefore reduces the artefact roughly in proportion.

QD-OLED panels behave less predictably. Rather than a continuous drift, TFTCentral found short spikes and flashes of flicker occurring at scattered frame rate points rather than as a linear gamma shift, with spikes becoming more frequent at lower frame rates. Practically, that means a QD-OLED can flicker sharply even when frame rate variation is fairly narrow, if that narrow band happens to cross one of the trigger points.

The consequence for tuning is real. On WOLED, tightening the frame rate cap tends to yield steady improvement. On QD-OLED, the useful move is often shifting the cap to a different value entirely rather than merely tightening it, so the operating range sits away from a spike point.

For the underlying differences between these panel constructions, including why one filters white light and the other converts blue, see the display physics explainer on this site.

Fix one: cap the frame rate, and cap it correctly

The single most effective user-side fix is a frame rate cap set below the level the system reliably sustains. The goal is not a high number, it is a stable one. A cap that the GPU meets almost all of the time holds the refresh interval nearly constant, and a nearly constant refresh interval produces nearly constant gamma. A cap set at the average frame rate is a common mistake, because by definition the system falls below the average roughly half the time, and every one of those dips is a refresh transition.

Measure a demanding section of the game, note the low point, and cap somewhat beneath it. If a game runs between 95 and 160fps with dips to 88, a cap at 80 or 85 will look dramatically steadier than an uncapped 160.

Which limiter you use matters, and the two things people want from a limiter pull in opposite directions. External limiters such as RTSS hold the most consistent frame pacing, because they wait at the frame-presentation call itself. In-engine caps give up a little of that consistency in exchange for lower latency, typically around half a frame to a frame less. For flicker specifically, consistency is what matters, so an external limiter is usually the better choice unless input lag is the priority. Driver-level caps sit between the two and work fine.

Per-game caps matter more than a single global setting. A competitive shooter that holds 200fps needs no cap; a heavy single-player title that swings between 60 and 130fps needs an aggressive one. Setting one global cap forces a compromise that is wrong for both.

Fix two: keep the refresh rate away from the LFC boundary

Low Framerate Compensation exists to keep adaptive sync working when frame rate falls below the monitor's minimum VRR rate. That floor varies by model, typically somewhere between 40Hz and 48Hz on current gaming OLEDs, and it is worth looking up the figure for the specific panel rather than assuming. LFC works by repeating frames, so a 40fps output might be displayed at 80Hz. That doubling is an instantaneous, large change in refresh interval, and TFTCentral observed a significant and jarring shift in RGB shade right at that boundary.

The practical implication is that frame rates hovering around a panel's own LFC threshold produce the harshest flicker of all, because the display repeatedly crosses in and out of frame doubling. The fix is to pick a side. Cap clearly below the floor, so LFC stays continuously engaged, or lift settings until frame rate stays comfortably above it. Note that this makes the advice model-dependent: an average of 45 to 55fps is a bad place to sit on a 48Hz-floor panel and perfectly fine on a 40Hz-floor one, where it never approaches the boundary at all.

This also explains the counterintuitive advice that lowering a frame rate cap can improve the picture. On a panel whose floor sits just under 50Hz, moving from an unstable 50fps to a locked cap well beneath the floor reduces raw performance but removes the boundary crossings, and the image looks calmer.

Fix three: anti-flicker modes, and what they cost

Several manufacturers now ship OSD settings that restrict the active VRR range, on the reasoning that a narrower refresh range permits a smaller gamma deviation. Asus implements this as an OLED Anti-Flicker control with multiple levels. On the ROG Strix XG27AQDMG the setting moves the range from 40-240Hz with LFC when off, to 160-240Hz without LFC on the middle setting, to 200-240Hz without LFC on high. On the ROG Swift PG27UCDM the equivalent steps are 48-240Hz with LFC, 80-240Hz with LFC, and 140-240Hz with no LFC.

TFTCentral's measurements confirm the approach works in the intended direction: on a WOLED panel, narrowing the range from 480-40Hz to 480-165Hz reduced the peak near-black RGB deviation from eleven values to about 8.5, and the tighter 480-210Hz setting brought it down to seven. It reduces the artefact rather than eliminating it.

The cost depends entirely on whether the mode keeps LFC, which is the detail most summaries skip. Where LFC stays enabled, as on the PG27UCDM's 80-240Hz middle setting, adaptive sync still functions below the floor via frame multiplication; the trade there is that boundary crossings become more likely, not that sync disappears. Where LFC is disabled, as on the PG27UCDM's 140-240Hz high setting and on both restricted XG27AQDMG modes, adaptive sync genuinely stops below the floor and tearing or v-sync latency returns for anything slower. That makes the aggressive settings a good fit for high-frame-rate competitive play and a poor one for slower single-player games. On Asus displays the control also requires DisplayPort or USB-C and is unavailable over HDMI, which accounts for a good share of reports that the option is greyed out.

Manufacturer claims about generational improvement should be read carefully. Asus describes ROG OLED Anti-Flicker 2.0 as minimising onscreen flicker by up to 20 percent compared to previous-generation panels, which is a vendor figure rather than an independently verified one, and a 20 percent reduction is a mitigation rather than a cure.

Related

• 1440p vs 4K Gaming Monitor: 27in and 32in Compared
• IPS vs VA vs OLED for Gaming: Which Panel Wins?
• Mini-LED vs OLED Monitor: Zones, Blooming, Brightness
• Is a Higher Refresh Rate Worth It? 144Hz to 480Hz Explained