VRR a HDR: dlaczego czasem pojawia się migotanie i jak to naprawić

Skąd bierze się migotanie przy VRR i HDR – krótki obraz problemu

Typowy scenariusz: VRR + HDR + symulator = „pulsujący” obraz

Gracz odpala symulator lotu lub wyścigów, włącza HDR w systemie i w grze, aktywuje G‑Sync lub FreeSync, ustawia odświeżanie 144–165 Hz i oczekuje płynnego, pięknego obrazu. Zamiast tego pojawia się subtelne lub wyraźne migotanie:

• ciemne partie obrazu lekko „pulsują” przy zmianach FPS,
• jasność ekranu zdaje się delikatnie skakać, szczególnie w menu lub przy panoramowaniu kamerą,
• w ekstremalnych sytuacjach obraz przyciemnia się i rozjaśnia jakby monitor miał problem z podświetleniem.

Często dzieje się to tylko w wybranych tytułach, przy konkretnych ustawieniach graficznych lub tylko w scenach nocnych. U jednego znajomego na podobnej karcie graficznej wszystko działa dobrze, u innego – koszmar. Łatwo wtedy obwiniać „wadliwy egzemplarz” albo sterowniki, ale zwykle problem leży głębiej, w połączeniu kilku technologii naraz.

Współdziałanie wielu warstw: od GPU po firmware monitora

Migotanie przy VRR i HDR to wynik interakcji kilku warstw:

• GPU i silnik gry – generują klatki z zmienną liczbą FPS, czasem z dużymi skokami (np. 80 → 45 → 90 FPS).
• Sterownik GPU – próbuje nadążyć z VRR (Adaptive Sync, G‑Sync, FreeSync), ewentualnie z Low Framerate Compensation.
• Monitor – ma własne ograniczenia panelu, logikę lokalnego/globalnego wygaszania, różne reakcje na częstotliwość odświeżania.
• Firmware monitora – decyduje, jak szybko i w jaki sposób zmienia się jasność podświetlenia przy HDR i VRR.
• System operacyjny i tryb HDR – wprowadza dodatkowy tonemapping i kontrolę luminancji.

Wystarczy, że jedna z tych warstw zachowuje się agresywnie lub ma słabiej dopracowaną logikę sterowania jasnością, a obraz zaczyna zachowywać się niestabilnie. Chodzi głównie o elektroniczne zmiany jasności, a nie typowe błędy graficzne w stylu znikających tekstur.

Flicker elektroniczny vs artefakty graficzne

Zanim zacznie się eksperymentować z ustawieniami, trzeba rozróżnić VRR/HDR flicker od zwykłych artefaktów gry:

• Flicker elektroniczny:
  • dotyczy całej sceny lub dużych obszarów,
  • najczęściej objawia się jako „pompowanie” jasności lub kontrastu,
  • zmienia się przy włączaniu/wyłączaniu VRR lub HDR w ustawieniach.
• Artefakty graficzne gry:
  • pojawiają się tylko w konkretnych miejscach (np. mrugające cienie, linie na horyzoncie),
  • mogą wynikać z błędów cieniowania, antyaliasingu, streamingu tekstur,
  • zwykle nie reagują na zmianę odświeżania monitora.

Jeśli po wyłączeniu VRR migotanie prawie znika, a po wyłączeniu HDR znika całkowicie – mamy do czynienia z typowym problemem VRR + HDR, a nie z błędem samej gry.

Różne zachowanie paneli: IPS vs VA, HDR‑ready vs „prawdziwy” HDR

Nie każdy monitor reaguje na VRR i HDR tak samo. Dość wyraźnie widać różnice między typami paneli i klasami HDR:

• Matryce VA – bardzo często bardziej podatne na VRR flicker, szczególnie w ciemnych scenach; zmiana jasności przy zmianie Hz jest u nich bardziej zauważalna.
• Matryce IPS – zwykle stabilniejsze, ale zdarzają się konstrukcje z agresywnym lokalnym wygaszaniem lub słabo skalibrowanym trybem HDR, które też migoczą.
• Monitory „HDR‑ready” / HDR400 – przeważnie brak prawdziwego lokalnego wygaszania, często tylko podbity kontrast i inny tonemapping, co potrafi dramatyzować drobne wahania jasności.
• Monitory z pełnym local dimming (FALD, MiniLED) – potrafią bardzo mocno zmieniać lokalną jasność wraz z zawartością sceny, a VRR wymusza nieregularne odświeżanie tego procesu.

Dlatego ta sama konfiguracja GPU i tej samej gry na jednym ekranie jest praktycznie wolna od flickeru, a na innym robi się nie do zniesienia. Zamiast szukać uniwersalnej „magicznej” kombinacji ustawień, trzeba dobrać je do konkretnego monitora i typowych FPS w danym symulatorze.

Podstawy VRR, V‑Sync i HDR – ile trzeba, żeby nie dać się marketingowi

Co faktycznie robi VRR (G‑Sync, FreeSync, Adaptive Sync)

VRR (Variable Refresh Rate) to zbiorcze określenie technologii takich jak G‑Sync, FreeSync czy Adaptive Sync. Ich wspólny cel jest prosty: dostosować częstotliwość odświeżania monitora do aktualnego FPS, aby zmniejszyć lub wyeliminować tearing (rwanie obrazu) i zmniejszyć stutter (mikroprzycięcia).

Kluczowy punkt: VRR nie poprawia jakości obrazu jako takiej:

• nie zwiększa rozdzielczości,
• nie poprawia tekstur,
• nie naprawia błędów cieniowania.

VRR kontroluje czas wyświetlania klatek. Gdy FPS spada z 120 do 70, monitor z VRR zwalnia odświeżanie zamiast „czekać” na następną klatkę przy stałych 120 Hz. Problem w tym, że w wielu panelach zmiana częstotliwości nie jest neutralna dla jasności i to jest punkt zapalny w połączeniu z HDR.

Rola V‑Sync przy włączonym VRR

Tradycyjny V‑Sync blokuje renderowanie klatek tak, aby zsynchronizować je ze stałym odświeżaniem (np. 60 Hz). Ogranicza to tearing, ale:

• powoduje dodatkowe opóźnienie wejścia,
• w połączeniu z niestabilnymi FPS potrafi zablokować grę np. na 30 FPS przy spadku poniżej 60.

Przy VRR, V‑Sync często wciąż jest używany, ale w innej roli:

• VRR działa w określonym zakresie Hz (np. 48–144 Hz),
• powyżej górnej granicy VRR, V‑Sync lub jego warianty (Fast Sync, Enhanced Sync) decydują, jak obsłużyć „nadmiar FPS”.

Różnica między V‑Sync w panelu sterownika a V‑Sync w grze bywa kluczowa:

• V‑Sync w sterowniku NVIDIA/AMD ma priorytet globalny; może nadpisywać zachowanie gry.
• V‑Sync w grze często jest prostszy i mniej przewidywalny przy VRR.

Migotanie przy VRR i HDR potrafi nasilać się, gdy system musi „szarpać” odświeżaniem między kilkoma trybami: VRR w zakresie, brak VRR powyżej zakresu, przejścia przy LFC. Nieprawidłowo ustawiony V‑Sync tylko dokłada zmienne opóźnienia i nieregularne kroki FPS.

HDR: więcej jasności, więcej problemów z jej stabilnością

HDR (High Dynamic Range) oznacza szerszy zakres luminancji (od głębszej czerni po jaśniejsze biele) oraz i/lub szerszą paletę barw (np. Rec.2020 zamiast sRGB). Żeby to działało sensownie w grach:

• monitor musi mieć odpowiednią szczytową jasność i przyzwoity kontrast,
• potrzebny jest prawidłowy tonemapping po stronie gry i systemu,
• często wchodzi w grę lokalne lub globalne sterowanie podświetleniem.

Im większy zakres jasności, tym bardziej widoczne są nawet drobne wahania. To, co w SDR wygląda jak ledwo zauważalne przygaszenie, w HDR może sprawiać wrażenie pełnego „pulsowania” sceny. Gdy VRR wymusza zmiany częstotliwości, elektronika podświetlenia czasem modyfikuje jasność w ślad za tym – i to właśnie wzmacnia wizualny efekt migotania.

Marketingowe etykiety a rzeczywistość

Na obudowie monitora można znaleźć znaczki typu HDR400, HDR10, FreeSync Premium, G‑Sync Compatible. Dobrze wygląda to na pudełku, ale nie oznacza, że:

• HDR jest precyzyjnie zaimplementowany (HDR400 często ma niski kontrast i brak local dimmingu),
• FreeSync działa idealnie w całym deklarowanym zakresie (zdarzają się „dziury” i niestabilność przy niskich Hz),
• G‑Sync Compatible zapewnia taką samą jakość jak modułowy G‑Sync (to tylko test kompatybilności, nie pełny kontroler).

Z perspektywy migotania ważne jest, aby znać realny zakres VRR i zachowanie HDR w danym modelu, a nie sugerować się wyłącznie nadrukami marketingowymi. Często dopiero testy użytkowników w sieci pokazują, w jakich warunkach konkretny monitor zaczyna „pompować” jasność przy VRR.

Jak VRR wpływa na jasność i dlaczego w połączeniu z HDR robi się z tego bomba

Zależność jasności od częstotliwości odświeżania

Niektóre panele (często VA, ale nie tylko) mają nieliniową zależność jasności od częstotliwości odświeżania. Innymi słowy: przy 60 Hz podświetlenie świeci trochę inaczej niż przy 144 Hz, choć teoretycznie ustawiony poziom jasności jest ten sam.

Przy stałym odświeżaniu (bez VRR) użytkownik tego zwykle nie zauważa – ekran zawsze pracuje np. w 144 Hz, więc nawet jeśli jasność 60 Hz ≠ jasność 144 Hz, nie ma kiedy tego porównać. VRR zmienia sytuację:

• FPS w grze spada z 120 do 50,
• monitor z VRR obniża częstotliwość do ~50 Hz,
• panel fizycznie świeci trochę inaczej przy 50 Hz niż przy 120 Hz.

Takie wahania często mają niewielką amplitudę, ale HDR dramatyzuje różnice. Szczególnie w ciemnych scenach każdy dodatkowy procent zmiany luminancji jest nagle dobrze widoczny.

Tonemapping i automatyczna kontrola podświetlenia

HDR nie polega tylko na „dokręceniu” suwaka jasności. Potrzebne są złożone procesy:

• Tonemapping gry – przelicza jasność sceny do zakresu akceptowalnego przez monitor.
• Tonemapping systemu – w Windows tryb HDR ma dodatkową warstwę przetwarzania.
• Algorytmy sterowania podświetleniem – lokalne/globalne wygaszanie, redukcja halo, zarządzanie strefami.

Gdy FPS i częstotliwość odświeżania są stabilne, te procesy działają w przewidywalny sposób. Przy VRR sytuacja się komplikuje:

• silnik gry zmienia jasność sceny w zależności od tego, co jest w kadrze,
• VRR zmienia moment wyświetlania klatek (odświeżanie nie jest już stałe),
• algorytmy HDR mogą reagować na inne „okna czasowe” sygnału wideo.

W rezultacie przy dynamicznych zmianach FPS, np. podczas przelotu nad miastem w symulatorze lotu, punkt odniesienia dla luminancji potrafi „skakać”. Raz monitor dobiera podświetlenie pod ciemne pasma terenu, innym razem pod jasne chmury, a jeszcze dochodzi do tego zmienna częstotliwość pracy panelu.

Local dimming i VRR: logika stref nie nadąża

Monitory z lokalnym wygaszaniem (local dimming, FALD, MiniLED) sterują jasnością grup diod podświetlenia w zależności od zawartości obrazu. Dla statycznych scen filmowych to przeważnie działa rozsądnie. W grach, szczególnie z VRR, zaczynają się schody:

• każda nowa klatka może wymagać innego układu jasności stref,
• przy stałym 60 Hz strefy mają równy czas na reakcji między klatkami,
• przy VRR kolejne klatki pojawiają się po nierównych odstępach czasu.

Firmware monitora musi zdecydować, jak szybko i jak mocno zareagować na zmianę zawartości. Gdy dołożymy do tego HDR (czyli większy rozstrzał między czernią a bielą), wynik bywa taki, że:

• ciemne strefy gwałtownie przyciemniają się i rozjaśniają przy panoramowaniu,
• krawędzie jasnych obiektów mają „oddychające” halo,

Globalne sterowanie jasnością i „oddychanie” sceny

Nawet gdy monitor nie ma local dimmingu, firmware często stosuje globalne algorytmy kontroli jasności. Chodzi o:

• utrzymanie deklarowanej szczytowej luminancji w ryzach poboru mocy,
• ochronę panelu przed przegrzewaniem się,
• „upiększenie” krzywej gamma przy HDR, żeby obraz wyglądał efektowniej w recenzjach.

Tego typu logika przy stałych 60 lub 120 Hz jest względnie przewidywalna. Gdy wejdzie VRR, monitor widzi sygnał z:

• nieregularnymi odstępami między ramkami,
• zmieniającą się średnią jasnością (np. od kabiny samolotu do białych chmur),
• aktywnym mapowaniem tonów po stronie gry i/lub systemu.

W efekcie powstaje wrażenie „oddychającej” sceny – jasność nie zmienia się ostro jak błysk lampy, tylko leniwie pływa: scena rozjaśnia się o kilka–kilkanaście procent, po chwili wraca. W HDR takie wachnięcia są szczególnie widoczne w półcieniach (kokpit, wnętrza, zmierzch).

Część producentów próbuje to ugasić, dodając filtry wygładzające w firmware monitora. Działa to do momentu, gdy:

• FPS nie spadnie bardzo nisko (praktycznie „stop-klatki”),
• scena nie ma dużych kontrastów (np. HUD na tle nocnego nieba),
• nie nałożą się na siebie reakcje gry (adaptacja oka) i reakcje monitora (adaptacja podświetlenia).

Jeśli te czynniki się na siebie złożą, nawet model, który „na papierze” jest stabilny przy VRR + HDR, w realnej grze potrafi zacząć delikatnie migotać lub pompować jasność. Najczęściej wychodzi to na jaw przy dłuższych sesjach w symulatorach i tytułach z dynamiczną pogodą.

Interakcja VRR z ABL, ABL-like i innymi „niewidzialnymi” funkcjami

Oprócz dobrze znanego local dimmingu dochodzi jeszcze jedna grupa mechanizmów: ABL (Automatic Brightness Limiter) i pokrewne rozwiązania, często nieopisane w specyfikacjach. Ich zadanie:

• ograniczyć jasność przy bardzo dużym pokryciu ekranu bielą,
• zmieścić się w limitach energetycznych (zwłaszcza przy certyfikatach typu Energy Star),
• chronić diody przed przegrzaniem przy wysokim HDR-owym nasyceniu.

Typowy przypadek: w statycznym teście HDR monitor trzyma ok. stałą jasność, ale przy panoramowaniu po jasnym niebie, gdzie średnia jasność sceny rośnie i spada, ABL reaguje z opóźnieniem. VRR powoduje, że:

• zmieniają się nie tylko wartości pikseli, ale i tempo ich pojawiania się,
• algorytmy ABL próbują reagować na coś, co z punktu widzenia ich projektanta „nie powinno” być aż tak chaotyczne.

Nie wszystkie panele na to cierpią. W IPS-ach klasy wyższej (często z droższym sterowaniem zasilaniem) ABL jest łagodniejszy albo domyślnie mniej agresywny. W tanich monitorach HDR400 i część VA zdarzają się gwałtowne skoki jasności, które przy VRR zamieniają się w nieregularne migotanie – zwłaszcza przy ściemnionej ogólnej jasności i mocno kontrastowych scenach.

Low Framerate Compensation (LFC) – kiedy ratuje płynność, a kiedy psuje HDR

Na czym realnie polega LFC

LFC (Low Framerate Compensation) to mechanizm używany w ramach VRR, który ma „udawać” wyższe odświeżanie, gdy FPS spadnie poniżej dolnej granicy zakresu VRR monitora. Schemat jest prosty:

• zakres VRR monitora: np. 48–144 Hz,
• gra spada do 40 FPS – to poniżej 48 Hz,
• LFC dubluje (lub potraja) ramki: monitor przechodzi na 80 Hz (2×40) albo 120 Hz (3×40).

Na ekranie ciągle widzisz te same 40 różnych klatek na sekundę, ale monitor odświeża się częściej, dzięki czemu:

• zmniejsza się postrzegane szarpanie,
• zmiany obrazu są prezentowane w bardziej równym rytmie.

Na poziomie sygnału wygląda to jednak jak nagły skok z niskiego Hz na wysoki, tyle że bez zwiększenia faktycznego FPS gry. I tu wracamy do problemów z jasnością i HDR.

LFC a skoki jasności przy przejściach przez próg VRR

Krytyczny moment to przekroczenie dolnego progu VRR. Przykład z praktyki:

• monitor ma zakres VRR 48–144 Hz,
• latasz w MSFS w okolicach 55–60 FPS, obraz dość stabilny,
• nad dużym miastem FPS spada na chwilę do ~45 FPS.

Dla karty graficznej nic dramatycznego, ale dla monitora:

• przy 48 FPS ekran odświeża się ok. 48 razy na sekundę,
• przy 47 FPS LFC może już zdecydować o przejściu na 94 Hz (2×47),
• jasność przy 48 Hz ≠ jasność przy 94 Hz w wielu panelach.

Efekt subiektywny: krótkie mrugnięcie, jakby ktoś na ułamek sekundy ruszył suwakiem jasności. Jeśli FPS oscyluje w okolicy progu (np. 44–52), pojawia się ciągłe przełączanie trybów – czyli regularne migotanie. HDR potrafi to podbić tak, że w ciemnych scenach masz wrażenie pulsującego obrazu.

Kiedy LFC faktycznie pomaga

Są scenariusze, w których LFC jest bardziej sprzymierzeńcem niż problemem. Najczęściej wtedy, gdy:

• FPS jest wyraźnie poniżej dolnej granicy VRR (np. 30–35 FPS przy progu 48 Hz),
• monitor ma dobrze skalibrowaną jasność między np. 60 a 120 Hz,
• gra nie generuje gwałtownych skoków średniej luminancji (stabilne, powolne sceny).

W takiej sytuacji:

• monitor stabilizuje się np. w okolicach 90–100 Hz na zdublowanych ramkach,
• przejście z VRR „nisko” do VRR „wysoko z LFC” jest jednorazowe i rzadko powtarzane,
• jasność ma szansę pozostać względnie stała, a migotanie jest minimalne.

Ten scenariusz częściej zdarza się w grach mocno ograniczonych CPU, gdzie FPS „siedzi” w jednym zakresie, zamiast skakać między 40 a 90. W symulatorach lotu przy stabilnym locie na dużej wysokości z reguły jest spokojniej niż przy niskich przelotach nad terenami miejskimi.

Kiedy LFC zamienia HDR w dyskotekę

Problemy pojawiają się, gdy spełnione są jednocześnie trzy warunki:

1. Wąski lub niefortunny zakres VRR – np. 55–144 Hz zamiast 40–144 Hz.
2. Niestałe FPS – gra stale przeskakuje w górę i w dół w okolicy tego progu.
3. Nieliniowa jasność panelu – jasność 50 Hz, 80 Hz i 120 Hz różni się od siebie zauważalnie.

Gdy te trzy punkty się zejdą, scenariusz wygląda mniej więcej tak:

• FPS = 60, monitor ~60 Hz, HDR pracuje spokojnie,
• spadek do 52 FPS – monitor 52 Hz, delikatne przyciemnienie,
• spadek do 49–50 FPS – aktywuje się LFC, monitor przeskakuje np. na 100 Hz, jasność inna,
• krótkie odbicie FPS do 55–58 – LFC wyłącza się, monitor znowu 55–58 Hz.

Każde takie przejście ma ślad w postaci skoku jasności lub kontrastu postrzeganego. Jeśli dodatkowo:

• gra ma własną adaptację oka (auto exposure),
• Windows przetwarza sygnał HDR ze swoim mapowaniem tonów,
• monitor dorzuca globalny ABL lub prosty local dimming,

migotanie przestaje być „od czasu do czasu”, a zaczyna być stałym towarzyszem w scenach z dużą zmiennością FPS i jasności.

Konfiguracje sprzętowo‑programowe, które szczególnie sprzyjają migotaniu

VA + wąski zakres VRR + HDR400

Kombinacja często spotykana w tańszych i średniopółkowych monitorach gamingowych:

• panel VA z wysokim kontrastem, ale słabszą równomiernością jasności przy różnych Hz,
• zakres VRR zaczynający się np. od 48–60 Hz w górę,
• certyfikat HDR400 bez pełnoprawnego local dimmingu.

Typowy obrazek z praktyki:

• w ciemnym hangarze czy kokpicie HDR wygląda „efektownie”,
• przy wylocie na jasne niebo lub nad śnieg jasność zaczyna lekko pulsować,
• gdy FPS pływa wokół dolnej granicy VRR, pojawiają się pojedyncze błyski lub regularne pulsowanie.

W tej klasie sprzętu migotanie bywa efektem ubocznym agresywnego mapowania HDR i taniego sterowania zasilaniem. Zmiana ustawień w OSD (wyłączenie local dimmingu, zmniejszenie max brightness, przełączenie trybu HDR na „cine” zamiast „game”) potrafi ograniczyć problem, ale zwykle kosztem części efektu HDR.

IPS z G‑Sync Compatible + Windows HDR zawsze włączony

Na papierze to „bezpieczniejszy” scenariusz: IPS, brak ekstremalnej nieliniowości przy różnych Hz, certyfikat G‑Sync Compatible. W praktyce migotanie pojawia się z innych powodów:

• Windows trzyma pulpit w HDR cały czas i przeprowadza dodatkowe mapowanie SDR → HDR dla gier bez natywnego HDR,
• niektóre gry włączają pseudo‑HDR lub korzystają z własnych profili jasności nieprzystających do EDID monitora,
• sterownik GPU próbuje zgrać VRR, V‑Sync i własne funkcje typu „low latency mode”.

Efekt w realu:

• migotanie głównie przy przełączaniu się między grą a pulpitami (Alt+Tab),
• nagle wzmacniające się pulsowanie po zmianie trybu okna,
• znikające migotanie po całkowitym wyłączeniu HDR w Windows, choć HDR w grze pozostaje.

Tutaj problemem nie zawsze jest sam panel, lecz interakcja: Windows HDR + VRR + profil kolorów. Różne wersje sterowników NVIDII i AMD wprowadzają zmiany w pipeline, więc zjawisko może się nasilać lub słabnąć po aktualizacji – bez żadnej zmiany sprzętu.

MiniLED / FALD + agresywny local dimming

Monitory z MiniLED często chwali się za imponujący kontrast i wysoką jasność szczytową. Jednocześnie to właśnie one potrafią mieć najbardziej widoczne „pompowanie” jasności przy VRR:

• setki lub tysiące stref, którymi trzeba sterować w czasie rzeczywistym,
• algorytmy local dimmingu z kilkoma trybami (low/medium/high),
• spałowanie stref z uwzględnieniem sygnału luminancji i czasu trwania jasnych obszarów.

Przy VRR firmware musi reagować na:

• ruch jasnych obiektów (np. słońce, reflektory),
• zmienny czas między klatkami,