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,
• żądania HDR co do maksymalnej jasności i krzywej PQ/HLG.

W grach z dynamiczną kamerą pojawia się wtedy zjawisko:

• lokalne strefy rozjaśniają się z lekkim opóźnieniem,
• ciemne tło „pływa”, gdy jasny obiekt przelatuje przez różne strefy,
• cała scena wydaje się „pulsować” przy panoramowaniu, szczególnie na granicy bardzo jasnych i ciemnych obszarów.

Zmniejszenie agresywności local dimmingu (tryb „low”, a czasem nawet całkowite wyłączenie) często redukuje migotanie kosztem kontrastu. Tu nie ma uniwersalnej reguły – w niektórych modelach najbardziej akceptowalny kompromis to średni poziom wygaszania przy nieco niższej docelowej jasności HDR w OSD.

GPU niemieszczące się w zakresie VRR przez większość czasu

Jeszcze jeden, dość przyziemny przypadek: karta graficzna jest zbyt słaba do danego monitora i gry. Przykład:

• monitor 1440p 165 Hz, zakres VRR 48–165 Hz,
• gra w 1440p Ultra, średnio 30–45 FPS, z częstymi dropami do okolic 25 FPS.

Co się dzieje:

• czasami LFC wchodzi, czasami nie, ale przez większość czasu monitor operuje pod dolnym progiem VRR,
• HDR cały czas próbuje utrzymać bilans jasności, ale dostaje bardzo nieregularny strumień ramek,

Konsole z VRR + systemowy HDR na telewizorach

Konfiguracja, która zrobiła się powszechna po wprowadzeniu VRR do PS5 i Xbox Series:

• telewizor z HDMI 2.1, VRR (często 48–120 Hz) i systemowym HDR (gry + aplikacje),
• konsola z włączonym VRR „globalnie”,
• gry o bardzo różnym poziomie optymalizacji i implementacji HDR.

Telewizor zakłada, że ma do czynienia z w miarę stabilnym sygnałem wideo. Dostaje jednak:

• niestabilny framerate, często oscylujący w okolicy dolnego progu VRR,
• skalowanie obrazu (np. gry 1440p lub dynamiczne rozdzielczości do 4K),
• różne metadane HDR (statyczne, brak, pseudo‑HDR).

Mnóstwo osób raportuje wtedy:

• migotanie głównie w ciemnych scenach, gdy kamera wykonuje szybkie ruchy,
• chwilowe błyski przy przełączaniu trybów obrazu lub po wyjściu z menu gry,
• zachowanie zależne od konkretnego modelu TV i wersji firmware’u.

Częsty punkt zapalny to połączenie: tryb gry (Game Mode) + globalny systemowy HDR TV + VRR. Niektóre telewizory w trybie gry upraszczają mapowanie tonów albo agresywniej kontrolują ABL, przez co każda zmiana częstotliwości odświeżania jest subtelnie „przeliczana” na inną jasność. W połączeniu ze spadkami FPS w okolicy 40–60 efektem bywa pulsująca poświata w całej scenie.

PC + TV 120 Hz z „inteligentnymi” ulepszaczami obrazu

Inna problematyczna kombinacja to podłączony komputer do telewizora, który ma komplet bajerów:

• dynamiczny kontrast,
• automatyczną regulację jasności pod światło w pokoju,
• filtry redukcji szumu, ostrości, żywych kolorów itp.

W teorii tryb PC lub Game powinien większość z nich wyłączyć, ale:

• część TV zostawia działające niektóre algorytmy nawet w Game Mode,
• firmware aktualizowany OTA potrafi zmienić zachowanie bez zapowiedzi,
• opcje typu „Eco”, „Light Sensor” czy „Dynamic Tone Mapping” bywają poukrywane w innych zakładkach.

Jeżeli:

• VRR jest włączony w sterowniku GPU,
• HDR jest globalnie aktywny w Windows,
• telewizor dodatkowo koryguje jasność według własnych algorytmów,

migotanie potrafi pojawiać się nawet przy pozornie stabilnym FPS. Najczęściej widać to na dużych, ciemnych powierzchniach z drobnymi jasnymi elementami (HUD, biały celownik na nocnym niebie). TV podbija jasność przy szybszym odświeżaniu, Windows mapuje SDR do HDR, GPU dostosowuje VRR – trzy różne „sterowniki jasności” działające jednocześnie.

Diagnostyka migotania VRR + HDR krok po kroku

Odróżnienie migotania VRR od innych problemów

Na początek trzeba upewnić się, że faktycznie chodzi o interakcję VRR i HDR, a nie o:

• klasyczne PWM (migotanie podświetlenia przy niskiej jasności),
• uszkodzony przewód lub złącze (artefakty, krótkie zaniki obrazu),
• błędy samej gry (szarpanie animacji bez zmian jasności).

Kilka prostych obserwacji mocno zawęża pole poszukiwań:

• jeżeli migotanie znika po wyłączeniu HDR, przy pozostawionym VRR, problem najpewniej dotyczy mapowania tonów albo ABL,
• jeżeli migotanie znika po wyłączeniu VRR, przy włączonym HDR, winny jest albo LFC, albo nieliniowość jasności przy różnych Hz,
• jeżeli migotanie występuje tylko przy bardzo niskiej jasności w OSD, możliwe, że to PWM, a nie VRR.

Dla osób wrażliwych na PWM użyteczne jest też szybkie sprawdzenie:

• czy monitor oferuje tryb „DC dimming” lub podobny opis (czasem ukryty pod „Eye Care”, „Flicker Free” itp.),
• czy migotanie nasila się przy obniżaniu jasności w OSD, ale przy stałym FPS i wyłączonym VRR.

Jeżeli zjawisko jest ściśle powiązane ze zmianami FPS (np. skoki jasności tylko wtedy, gdy gra przechodzi z zatłoczonego miasta na otwarte pola), praktycznie zawsze w tle działa VRR + HDR + LFC.

Test 1: wyłączenie HDR w systemie i w grze

Najprostszy test to całkowite wyłączenie HDR. W praktyce:

• w Windows – dezaktywacja „Użyj HDR” w ustawieniach ekranu,
• w konsoli – wyłączenie HDR w ustawieniach wyjścia wideo (nie tylko w samej grze),
• w grach na PC – upewnienie się, że opcja HDR w menu gry jest ustawiona na OFF.

Jeżeli po tej zmianie:

• obraz nadal minimalnie „pulsuje”, ale bez zauważalnych zmian jasności, to raczej kwestia samego VRR i ewentualnego LFC,
• migotanie praktycznie znika, a pozostają tylko sporadyczne mikro‑przycięcia, wtedy HDR jest głównym wzmacniaczem problemu.

Przy takim teście trzeba zaakceptować, że porównujemy obraz SDR i HDR – kontrast, gama i kolory będą inne. Chodzi tylko o obserwację zmian jasności w czasie, a nie o ogólną jakość.

Test 2: wymuszenie stałego odświeżania (wyłączenie VRR)

Kolejny krok to wyłączenie VRR:

• na PC – odznaczenie G‑Sync/FreeSync w sterowniku GPU i/lub w OSD monitora,
• na konsoli – dezaktywacja VRR w ustawieniach systemowych,
• na TV – wyłączenie FreeSync/VRR w menu obrazu.

Po tej zmianie monitor pracuje w stałym odświeżaniu (np. 60, 120 lub 144 Hz). Efekt:

• jeżeli migotanie znika przy włączonym HDR, główny podejrzany to LFC lub nieliniowa odpowiedź jasności przy zmiennym Hz,
• jeżeli migotanie pozostaje podobne, trzeba szukać winy raczej w algorytmach HDR (tonemapping, ABL, local dimming).

Wiele osób jest zaskoczonych, jak „gładka” staje się luminancja przy stałym 120 Hz i HDR, nawet kosztem sporadycznego tearingu lub mikro‑stutteru. To w praktyce bardzo dobry wskaźnik, że VRR nie jest darmową poprawą, tylko kompromisem.

Test 3: ograniczanie FPS poniżej górnego limitu VRR

Przy aktywnym VRR i HDR część migotania pojawia się przy dobijaniu do górnej granicy zakresu VRR (np. 143–144 Hz przy monitorze 144 Hz). System przeskakuje wtedy między „pełnym VRR” a „prawie stałym odświeżaniem”. Dobrym testem jest:

• ustawienie limitu FPS w grze lub sterowniku (RTSS, NVIDIA Frame Limiter, AMD FRTC) na kilka Hz poniżej maksymalnego odświeżania – np. 138 na 144 Hz lub 116 na 120 Hz,
• sprawdzenie, czy przy takim ustawieniu pulsowanie jasności się zmniejsza.

Jeżeli:

• migotanie występowało głównie w okolicach maksymalnego FPS, a po ustawieniu limitu wyraźnie słabnie,
• HDR zachowuje się stabilniej w ruchu kamery,

problem leży raczej w przechodzeniu między różnymi trybami synchronizacji niż w LFC. Dotyczy to zwłaszcza konfiguracji, w których włączone są jednocześnie:

• V‑Sync w grze,
• VRR w sterowniku,
• limit FPS w narzędziu typu RTSS.

Taki „potrójny nadzór” nad klatkami to przepis na niestabilne timingi, a więc także na niestabilną jasność przy HDR.

Test 4: zachowanie przy przejściu przez dolny próg VRR

Żeby sprawdzić, czy winny jest głównie próg VRR + LFC, trzeba sprowokować sytuację, w której FPS przechodzi przez dolną granicę. Najprościej:

• odczytać zakres VRR z OSD monitora lub specyfikacji (np. 48–144 Hz),
• uruchomić grę, która ma spore wahania FPS (otwarty świat, gęste miasta),
• wyświetlić overlay ze statusem FPS (Steam, MSI Afterburner, Xbox Game Bar itp.).

Następnie dobrze jest:

• zacząć w miejscu, gdzie FPS jest powyżej dolnego progu,
• przejść do sceny, gdzie FPS spada poniżej tego progu,
• kilkakrotnie wykonać „wahadło” między tymi scenami i obserwować jasność.

Jeżeli przy każdym przekroczeniu progu 45–50 FPS:

• pojawia się wyczuwalne mrugnięcie lub krótkie rozjaśnienie/ściemnienie,
• pulsowanie jest tym silniejsze, im częściej FPS „stuka” w dolną granicę,

to klasyczny objaw aktywującego się LFC w połączeniu z nieliniowym HDR. W takim przypadku użyteczne bywają:

• obniżenie detali lub rozdzielczości, tak aby typowy FPS był albo wyraźnie powyżej dolnego progu,
• albo świadome zejście na niższe odświeżanie (np. 60 Hz zamiast 144 Hz) i trzymanie FPS w jego okolicach.

Test 5: różne tryby HDR w monitorze lub TV

Większość monitorów/telewizorów ma więcej niż jeden tryb HDR:

• „Game”, „Cinema”, „Desktop”, „HDR Standard”, „HGIG” i podobne.

Różnią się one:

• kształtem krzywej tonemappingu,
• agresywnością ABL,
• priorytetem między detalami w światłach a ogólną jasnością sceny.

Dobrą praktyką jest przełączenie się kolejno między tymi trybami przy tej samej scenie w grze (najlepiej jednocześnie z włączonym overlayem FPS). Jeżeli:

• jeden tryb ma wyraźnie mniejsze „pompowanie” jasności przy ruchu kamery,
• różnica pojawia się zwłaszcza w okolicach ciemnych scen z pojedynczymi jasnymi punktami,

oznacza to, że algorytm HDR danego trybu gorzej reaguje na nieregularne timingi VRR. Tryby opisane jako „HGIG” lub „Game HDR” często dążą do minimalizacji przetwarzania i bywają stabilniejsze od mocno „kinowych” presetów.

Test 6: inny kabel / inne złącze / inna ścieżka sygnału

Zaskakująco często migotanie brane za efekt VRR + HDR jest po prostu skutkiem marginalnego połączenia:

• stary kabel HDMI/DisplayPort na granicy specyfikacji,
• przejściówki, adaptery, tanie stacje dokujące USB‑C,
• gniazda z lekko obluzowanymi pinami.

Zmiana:

• kabla na certyfikowany (Ultra High Speed HDMI, DP 1.4 HBR3),
• portu w karcie (np. z HDMI na DisplayPort lub odwrotnie),
• bezpośrednie połączenie bez przejściówek i splitterów,

pozwala odsiać problemy z sygnałem fizycznym. Jeżeli:

• przy tej samej konfiguracji VRR + HDR migotanie ustaje po zmianie kabla lub portu,

nie ma sensu dalej grzebać w ustawieniach LFC – winny był warunek brzegowy na jakości połączenia.

Test 7: różne wersje sterownika GPU i firmware monitora/TV

Aktualizacje sterowników NVIDII/AMD/Intela i firmware monitorów/TV realnie potrafią zmienać pipeline HDR i sposób obsługi VRR. Objawia się to nagłą zmianą:

• intensywności migotania,
• progu, przy którym pojawiają się błyski,
• zachowania przy Alt+Tab i zmianie trybu okna.

Jeżeli migotanie:

• pojawiło się bez zmiany sprzętu, jedynie po aktualizacji sterownika,
• albo zniknęło na krótko po update, a wróciło po kolejnym,

dobrym testem jest:

• powrót do poprzedniej stabilnej wersji sterownika GPU,
• sprawdzenie changelogów firmware monitora/TV pod kątem VRR/HDR,
• porównanie zachowania na predefiniowanych profilach kolorów (sRGB vs. wide gamut).

Najczęściej zadawane pytania (FAQ)

Dlaczego mój monitor migocze przy włączonym VRR (G‑Sync/FreeSync) i HDR?

Najczęściej powodem jest to, że monitor zmienia jasność razem ze zmianą częstotliwości odświeżania. VRR dostosowuje Hz do aktualnego FPS, a w wielu panelach (zwłaszcza VA i tańszych „HDR‑ready”) każda zmiana Hz lekko przesuwa poziom jasności lub kontrastu. W HDR te różnice są wyraźniejsze niż w SDR, dlatego widać „pompowanie” podświetlenia.

Do tego dochodzi firmware monitora i logika HDR: lokalne lub globalne wygaszanie, tonemapping systemu, LFC w sterownikach GPU. Gdy kilka z tych elementów reaguje zbyt agresywnie na wahania FPS, pojawia się efekt pulsowania obrazu, szczególnie w ciemnych scenach i menu.

Jak sprawdzić, czy migotanie wynika z VRR + HDR, a nie z błędów gry?

Najprostszy test to zmiana ustawień krok po kroku. Najpierw wyłącz VRR (G‑Sync/FreeSync/Adaptive Sync) przy zachowaniu HDR. Jeśli migotanie prawie znika, VRR jest jednym z czynników. Następnie wyłącz HDR i zostaw VRR włączony. Jeżeli przy SDR obraz jest stabilny, źródłem problemu jest głównie kombinacja VRR + HDR, a nie sam silnik gry.

Typowy „flicker elektroniczny” dotyczy całego ekranu lub dużych obszarów i reaguje na włączanie/wyłączanie VRR/HDR. Błędy gry (mrugające cienie, linie na horyzoncie) zwykle pojawiają się tylko w konkretnych miejscach sceny i nie znikają po wyłączeniu VRR.

Czy matryca VA naprawdę częściej migocze przy VRR i HDR niż IPS?

W praktyce tak, choć nie jest to żelazna reguła. Matryce VA często mocniej zmieniają jasność przy zmianie częstotliwości odświeżania, a ich zachowanie w ciemnych scenach bywa bardziej problematyczne. Gdy dochodzi do tego HDR z rozciągniętą skalą jasności, każde drobne wahanie robi się widoczne jako pulsowanie czerni i ciemnych tonów.

IPS zwykle zachowuje się stabilniej, ale nie każdy model jest „bezpieczny”. Agresywne lokalne wygaszanie czy słabo skalibrowany tryb HDR w niektórych IPS‑ach potrafią dać efekt bardzo podobny do VA. Różnice między konkretnymi modelami są większe niż sama etykieta „VA vs IPS”, dlatego warto szukać testów dokładnie swojego monitora.

Jakie ustawienia VRR, V‑Sync i limit FPS pomagają zmniejszyć migotanie?

Najczęściej pomaga ograniczenie wahań FPS i unikanie wyjścia poza zakres VRR monitora. W praktyce stosuje się np. limit FPS o kilka klatek poniżej górnej granicy VRR (np. przy 144 Hz – limit 138–140 FPS), aby nie skakać między trybem VRR a klasycznym V‑Sync lub jego wariantami. Mniejsze skoki FPS to mniej gwałtownych zmian odświeżania i stabilniejsze podświetlenie.

Dodatkowo wielu użytkowników uzyskuje lepszy efekt, gdy V‑Sync jest wyłączony w grze, a kontrolowany w panelu sterownika (NVIDIA/AMD) razem z VRR. To nie jest uniwersalna recepta, bo różne gry i sterowniki reagują inaczej, ale warto przetestować kilka kombinacji: V‑Sync OFF/ON w grze vs w sterowniku przy włączonym VRR oraz różne limity FPS (wbudowany w grę vs limiter sterownika.

Czy wyłączenie HDR lub VRR to jedyne skuteczne rozwiązanie migotania?

To najprostszy sposób na „brutalne” wyeliminowanie problemu, ale nie jedyny. Często da się znaleźć kompromis, w którym VRR i HDR są włączone, a migotanie staje się minimalne lub akceptowalne. Pomagają m.in. stabilniejszy FPS (przez obniżenie detali), zmiana trybu HDR w grze, korekta ustawień lokalnego wygaszania lub wybór innego profilu obrazu w monitorze.

Bywają jednak konfiguracje, w których konkretna gra + dany monitor + HDR przy VRR zawsze będzie sprawiać kłopot w określonych scenach. Wtedy realnym wyborem jest: albo HDR bez VRR, albo VRR w SDR, albo pogodzenie się z lekkim flickerem. W symulatorach część osób świadomie rezygnuje z HDR na rzecz precyzyjniejszego i stabilniejszego obrazu.

Dlaczego HDR400 i „HDR‑ready” częściej sprawiają problemy z VRR niż „prawdziwy” HDR?

Monitory HDR400 i różne „HDR‑ready” zwykle nie mają pełnoprawnego lokalnego wygaszania i często korzystają z prostszych algorytmów sterowania jasnością. Zamiast faktycznie zwiększać możliwości panelu, wprowadzają agresywny tonemapping i podbijanie kontrastu, co uwydatnia każde wahanie luminancji. W połączeniu z VRR, gdzie Hz ciągle się zmienia, taki monitor może łatwo zacząć „pompować” jasność całej sceny.

Bardziej zaawansowane konstrukcje (FALD, MiniLED) potrafią kontrolować jasność precyzyjniej, ale ich lokalne wygaszanie też bywa źródłem artefaktów, zwłaszcza przy niskich FPS i nieregularnym odświeżaniu. To nie jest tak, że wyższa plakietka HDR automatycznie oznacza brak flickeru – jednak w klasie HDR400 uproszczeń i kompromisów jest zwykle najwięcej.

Czy migotanie przy VRR + HDR oznacza, że mój monitor jest wadliwy?

Niekoniecznie. W większości przypadków to zachowanie typowe dla danej konstrukcji: konkretnej matrycy, firmware’u i implementacji HDR. Jeżeli migotanie pojawia się wyłącznie przy połączeniu VRR + HDR i znika po wyłączeniu jednego z nich, raporty innych użytkowników tego modelu zwykle potwierdzą podobne doświadczenia.

O egzemplarzu faktycznie wadliwym można myśleć wtedy, gdy:

• flicker jest ekstremalny i widoczny także w SDR przy stałym odświeżaniu,
• problem występuje w całym systemie (pulpit, filmy, inne gry) przy tych samych ustawieniach,
• porównanie z innym egzemplarzem tego samego modelu pokazuje wyraźną różnicę.

W praktyce jednak najczęściej mamy do czynienia z ograniczeniem projektu monitora, a nie z jednostkową usterką.

Najważniejsze punkty

• Migotanie przy połączeniu VRR i HDR to zwykle efekt nakładania się kilku warstw naraz (GPU, sterownik, logika VRR, firmware i tryb HDR monitora), a nie „zepsutej gry” czy pojedynczego ustawienia.
• Jeśli wyłączenie VRR znacząco ogranicza migotanie, a wyłączenie HDR usuwa je praktycznie całkowicie, problem dotyczy interakcji VRR + HDR, a nie typowych artefaktów graficznych (np. błędów cieniowania czy mrugających cieni).
• Elektroniczny flicker przy VRR/HDR obejmuje zwykle całą scenę lub duże obszary i objawia się „pompowaniem” jasności/kontrastu; artefakty gry są lokalne, powtarzalne w konkretnych miejscach i zwykle nie reagują na zmianę odświeżania.
• Typ panelu i klasa HDR mocno wpływają na skalę problemu: matryce VA i tańsze ekrany „HDR‑ready” (HDR400) częściej eksponują flicker, natomiast IPS i lepiej zaprojektowane konstrukcje z local dimmingiem potrafią zachowywać się stabilniej.
• VRR sam w sobie nie poprawia jakości obrazu (rozdzielczości, tekstur, błędów shaderów) – jedynie synchronizuje czas wyświetlania klatek z FPS, a przy HDR każdy skok częstotliwości może powodować widoczne zmiany jasności.
• V‑Sync nadal odgrywa rolę przy VRR, głównie poza zakresem działania VRR; istotne jest, czy jest włączony w sterowniku czy w grze, bo to może zmieniać sposób, w jaki monitor reaguje na skoki FPS i częstotliwości.