Jak działa silnik

OLED Guard Pro to nie wygaszacz ekranu. To działający w czasie rzeczywistym, rezydujący na GPU potok wideo, który przetwarza każdą klatkę, na każdym podłączonym ekranie, podczas gdy korzystasz z komputera. Ta strona to techniczny przegląd.

Czteroetapowy potok

   ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
   │ CAPTURE  │ ──▶ │  MODEL   │ ──▶ │  POLICY  │ ──▶ │COMPOSITE │
   │  DXGI    │     │ exposure │     │ Auto/man │     │   DWM    │
   └──────────┘     └──────────┘     └──────────┘     └──────────┘

1. Przechwytywanie — DXGI Desktop Duplication

Windows udostępnia API o nazwie Desktop Duplication, które daje Ci uchwyt do tekstury GPU z tym, co DWM komponuje dla danego ekranu, za każdym razem, gdy obraz się zmienia. Używamy go, bo:

  • Działa na GPU. Bufor klatki nigdy nie opuszcza pamięci wideo.
  • To jedyne publiczne API Windows, które działa wewnątrz gier w trybie bezramkowego pełnego ekranu (a to tryb, w którym większość graczy faktycznie gra). Starsze podejścia, jak BitBlt czy PrintWindow, nie działają.
  • Obsługuje HDR, wiele monitorów oraz ekrany o wysokiej częstotliwości odświeżania bez żadnych dodatkowych zabiegów z naszej strony.

2. Modelowanie — shader ekspozycji dla każdego piksela

Pixel shader przetwarza każdą przechwyconą klatkę w natywnej rozdzielczości. Dla każdego piksela oblicza:

luminance     = dot(pixelRGB, vec3(0.2126, 0.7152, 0.0722));
delta         = luminance * frameTime;
exposure[p]   = exposure[p] + delta;

Działają też dwa równoległe przejścia:

  • Obwiednia ruchu. Tani filtr górnoprzepustowy w dziedzinie czasu: jak bardzo zmienił się ten piksel w ciągu ostatnich N klatek? Piksele o wysokim ruchu mają szybciej wygaszaną ekspozycję, bo poruszająca się treść nie koncentruje starzenia.
  • Detektor stabilności. Filtr dolnoprzepustowy na obwiedni ruchu: piksele, których wartość była stabilna przez wiele klatek, są oznaczane jako “statyczne” i stają się kandydatami do ochrony.

Histogram ekspozycji jest podwójnie buforowany w pamięci GPU. Na gorącej ścieżce nie ma odczytu z powrotem do CPU.

3. Polityka — co z tym zrobić

Etap polityki decyduje o trzech rzeczach, dla każdego piksela, w każdej klatce:

  • Jak dużą ochronę zastosować.
  • Jakiego rodzaju nakładkę wyrenderować — szum (domyślnie), statyczne przyciemnienie, przesuwanie pikseli lub ditheringu, z opcjonalnym ważeniem krawędzi w stylu winiety nałożonym na wierzch.
  • Gdzie ukształtować pole — jednolicie, z ważeniem winietowym ku krawędziom lub sterowane geometrią profilu aplikacji.

W trybie ręcznym te wartości pochodzą z suwaków na stronie Overlay. W Automatic Mode kontroler patrzy na klasyfikację sygnału na żywo (praca, granie, wideo, bezczynność), obwiednię ruchu dla każdego piksela oraz ślad dynamizmu i wybiera konfigurację, która według modelu minimalizuje ryzyko w ramach budżetu zauważalności. Możesz to obserwować w odczycie Advanced > Live Classifier.

4. Składanie — DWM z premnożoną alfą

Drugi shader renderuje wybraną nakładkę do przezroczystego okna zawsze na wierzchu. Desktop Window Manager komponuje to okno na Twoim pulpicie, używając premnożonej alfy — tej samej ścieżki, której używa do własnych animacji Windows. Dlatego właśnie nakładka działa poprawnie w:

  • trybach SDR i HDR,
  • grach w trybie bezramkowego pełnego ekranu,
  • ekranach o zmiennej częstotliwości odświeżania (G-Sync / FreeSync),
  • konfiguracjach wielomonitorowych,
  • konfiguracjach o mieszanym DPI.

To DWM wykonuje faktyczne mieszanie. My tylko dostarczamy klatkę.

Osobno dla każdego ekranu, równolegle

Każdy podłączony ekran uruchamia własną kopię potoku. Nie współdzielą stanu. Zmiana monitora, podłączenie na gorąco, zmiana rozdzielczości — silnik to zauważa, zrzuca dotknięty potok i odbudowuje go bez zakłócania pozostałych.

Co działa na CPU

CPU zajmuje się:

  • kompilacją shaderów przy starcie,
  • presetami, konfiguracją oraz interfejsem w React,
  • monitorowaniem aktywnego okna na potrzeby profili aplikacji,
  • poleceniami DDC/CI, gdy zmieniasz jasność z poziomu aplikacji.

CPU nie widzi zawartości Twojego ekranu. Klatki przez cały czas pozostają w pamięci GPU.

Budżet wydajności

Reprezentatywny pomiar przy 1440p / 144 Hz na GPU ze średniej półki:

EtapKoszt na klatkę
Capture~ 0,4 ms
Model~ 0,3 ms
Composite~ 0,5 ms
Razem~ 1,2 ms

To 7% budżetu 16,6 ms / 60 Hz, ale wykonuje się po stronie GPU, zamiast blokować ścieżkę renderowania Twojej gry, więc wpływ na rzeczywisty czas w benchmarkach jest zazwyczaj poniżej 1%. Wyższe rozdzielczości, wyższe częstotliwości odświeżania oraz słabsze GPU skalują ten koszt; względny kształt pozostaje taki sam.

Co celowo pominęliśmy

Kilka decyzji projektowych, które ponownie zweryfikowaliśmy więcej niż raz:

  • Brak warstwy inteligencji opartej na komórkach. Warstwa ochrony oparta na komórkach, która rozumowała na kafelkach 32 × 32, została zaprototypowana i porzucona. Modelowanie dla każdego piksela jest bardziej uczciwe wobec fizyki; kafelki dawały artefakty schodkowe na granicach treści.
  • Brak heurystyk wypalania po stronie CPU. Silnik nie próbuje rozpoznawać “to jest pasek boczny Discorda” czy “to jest logo YouTube”. Rozpoznawanie jest kruche i źle się starzeje. Ekspozycja to uniwersalna wielkość fizyczna.
  • Brak potoku telemetrii. Histogramy dla poszczególnych pikseli nigdy nie opuszczają Twojego komputera. Z założenia nie mamy żadnych serwerów, które by je odbierały.

Jeśli chcesz zobaczyć silnik w akcji, strona Zaawansowany silnik w aplikacji desktopowej udostępnia klasyfikator na żywo, ślady automatycznego kontrolera dla każdego pokrętła oraz pasek sygnałów na żywo z częstotliwością 60 Hz.

InstalacjaTryby ochrony