So funktioniert die Engine

OLED Guard Pro ist kein Bildschirmschoner. Es ist eine GPU-residente Echtzeit-Video-Pipeline, die jeden Frame auf jedem angeschlossenen Display verarbeitet, während du deinen Computer nutzt. Diese Seite ist der technische Rundgang.

Die vierstufige Pipeline

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

1. Erfassung: DXGI Desktop Duplication

Windows stellt eine API namens Desktop Duplication bereit, die dir bei jeder Änderung ein GPU-Texture-Handle auf das liefert, was DWM für ein bestimmtes Display zusammensetzt. Wir nutzen sie, weil:

  • Sie läuft auf der GPU. Der Frame-Buffer verlässt nie den Videospeicher.
  • Sie ist die einzige öffentliche Windows-API, die auch in randlosen Vollbildspielen funktioniert (dem Modus, in dem die meisten Gamer tatsächlich spielen). Ältere Ansätze wie BitBlt oder PrintWindow tun das nicht.
  • Sie unterstützt HDR, mehrere Monitore und Displays mit hoher Bildwiederholrate, ohne dass wir etwas Besonderes tun müssen.

2. Modell: Belichtungs-Shader pro Pixel

Ein Pixel-Shader verarbeitet jeden erfassten Frame in nativer Auflösung. Für jeden Pixel berechnet er:

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

Zwei parallele Durchläufe laufen ebenfalls:

  • Bewegungshüllkurve. Ein günstiger zeitlicher Hochpass: Wie stark hat sich dieser Pixel in den letzten N Frames verändert? Bei Pixeln mit viel Bewegung klingt die Belichtung schneller ab, weil bewegte Inhalte die Alterung nicht an einer Stelle bündeln.
  • Stabilitätsdetektor. Ein Tiefpass auf der Bewegungshüllkurve: Pixel, deren Wert über viele Frames stabil war, werden als „statisch“ markiert und zu Kandidaten für den Schutz.

Das Belichtungs-Histogramm liegt doppelt gepuffert im GPU-Speicher. Auf dem Hot-Path gibt es keinen Rückkanal zur CPU.

3. Policy: was damit zu tun ist

Die Policy-Stufe entscheidet pro Pixel und pro Frame über drei Dinge:

  • Wie viel Schutz angewendet wird.
  • Welche Art von Overlay gerendert wird: Rauschen (Standard), statisches Dimmen, Pixel Shift oder Dithering, optional mit einer vignettenartigen Randgewichtung darüber.
  • Wo das Feld geformt wird: gleichmäßig, vignettengewichtet zu den Rändern hin oder von der App-Profil-Geometrie gesteuert.

Im manuellen Modus stammen diese Werte von den Reglern auf der Overlay-Seite. Im Automatik-Modus betrachtet der Controller die Live-Signalklassifizierung (Arbeit, Gaming, Video, Leerlauf), die Bewegungshüllkurve pro Pixel und die Dynamik-Spur und wählt eine Konfiguration, die laut Modell das Risiko unter Einhaltung eines Wahrnehmbarkeitsbudgets minimiert. Du kannst das in der Anzeige Erweitert > Live-Klassifizierer beobachten.

4. Compositing: DWM mit vormultipliziertem Alpha

Ein zweiter Shader rendert das gewählte Overlay in ein transparentes, stets im Vordergrund liegendes Fenster. Der Desktop Window Manager setzt dieses Fenster mit vormultipliziertem Alpha auf deinen Desktop: derselbe Pfad, den er für die eigenen Animationen von Windows verwendet. Deshalb funktioniert das Overlay korrekt in:

  • SDR- und HDR-Modi,
  • randlosen Vollbildspielen,
  • Displays mit variabler Bildwiederholrate (G-Sync / FreeSync),
  • Multi-Monitor-Setups,
  • Konfigurationen mit gemischter DPI.

DWM übernimmt das eigentliche Blending. Wir liefern lediglich einen Frame.

Pro Display, parallel

Jedes angeschlossene Display führt seine eigene Kopie der Pipeline aus. Sie teilen keinen Zustand. Bei einem Monitorwechsel, einem Hot-Plug oder einer Auflösungsänderung bemerkt die Engine das, verwirft die betroffene Pipeline und baut sie neu auf, ohne die anderen zu stören.

Was auf der CPU läuft

Die CPU erledigt:

  • die Shader-Kompilierung beim Start,
  • Voreinstellungen, Konfiguration und die React-Oberfläche,
  • die Überwachung des Vordergrundfensters für App-Profile,
  • DDC/CI-Befehle, wenn du die Helligkeit über die App änderst.

Die CPU sieht deine Bildschirminhalte nicht. Die Frames bleiben die gesamte Zeit im GPU-Speicher.

Leistungsbudget

Eine repräsentative Messung bei 1440p / 144 Hz auf einer Mittelklasse-GPU:

StufeKosten pro Frame
Erfassung~ 0,4 ms
Modell~ 0,3 ms
Compositing~ 0,5 ms
Gesamt~ 1,2 ms

Das sind 7 % eines Budgets von 16,6 ms / 60 Hz, aber die Arbeit läuft auf der GPU-Seite, statt den Render-Pfad deines Spiels zu blockieren, sodass die spürbare Auswirkung in Benchmarks typischerweise unter 1 % liegt. Höhere Auflösungen, höhere Bildwiederholraten und schwächere GPUs erhöhen die Kosten; die relative Form bleibt gleich.

Was bewusst weggelassen wurde

Ein paar Designentscheidungen, die wir mehr als einmal erneut geprüft haben:

  • Keine zellenbasierte Intelligenzschicht. Eine zellenbasierte Schutzschicht, die über Kacheln von 32 × 32 argumentierte, wurde prototypisiert und verworfen. Die Modellierung pro Pixel ist ehrlicher zur Physik; Kacheln erzeugten Treppenartefakte an Inhaltsgrenzen.
  • Keine Burn-in-Heuristiken auf der CPU. Die Engine versucht nicht zu erkennen, „das ist eine Discord-Seitenleiste“ oder „das ist ein YouTube-Logo“. Erkennung ist fragil und altert schlecht. Belichtung ist die universelle physikalische Größe.
  • Keine Telemetrie-Pipeline. Histogramme pro Pixel verlassen nie deinen Rechner. Wir haben bewusst keine Server, die sie empfangen.

Wenn du die Engine in Aktion sehen möchtest, zeigt die Seite Erweiterte Engine in der Desktop-App den Live-Klassifizierer, die Auto-Controller-Spuren pro Regler und den Live-Signalstreifen mit 60 Hz.

InstallationSchutzmodi