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

1. Erfassung: Windows Graphics Capture / Desktop Duplication

Windows stellt zwei APIs bereit, die dir ein GPU-Texture-Handle auf das liefern, was DWM für ein bestimmtes Display zusammensetzt: Windows Graphics Capture (WGC) und DXGI Desktop Duplication. OLED Guard unterstützt beide. Die Einstellung Erfassungsmethode wählt zwischen Auto, WGC und Desktop Duplication; Auto wählt unter Windows 11 WGC, mit Desktop Duplication als klassischem Pfad auf anderen Systemen. Wo verfügbar, wird WGC bevorzugt, weil es auch in Vollbildspielen weiter Frames mit voller Rate liefert, wo Desktop Duplication ausgehungert werden konnte. In beiden Fällen gelten die Eigenschaften, auf die wir uns verlassen:

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

Wenn der Grafiktreiber mitten in der Sitzung zurückgesetzt wird oder die Erfassung abbricht, bemerkt die Engine das und startet die Pipeline sauber neu, statt stillschweigend stehen zu bleiben.

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. Präsentation: Risiko in ein kontinuierliches Feld verwandeln

Das Belichtungsmodell sagt, wo sich Panel-Verschleiß aufbaut. Die Präsentationsstufe entscheidet, wie dieses Risiko tatsächlich auf dem Bildschirm erscheint. In v5 ist das ein einziges kontinuierliches Feld statt eines Stapels separater Overlay-Durchläufe. Es wird aus zwei zeitlichen Feldern niedriger Auflösung aufgebaut:

• Belegung beantwortet „ist hier dauerhaft schützbarer Inhalt?“, sodass ein kurzes helles Aufblitzen kein Dimmen auslöst.
• Intensität beantwortet „wie viel Schutz möchte das Risikomodell hier?“.

Die sichtbare Abdunklung ist das Produkt dieser beiden Felder, geformt durch ausdrücklich geordnete Modifikatoren: ein unmittelbarer Sicherheitskern für echte Hochrisiko-Spitzen, die von Game IQ gelernte HUD-Untergrenze, eine statische Gnadenfrist, Ausschlussrechtecke, optionale Vignetten-Randgewichtung und Blue-Noise-Musterformung. Weil die Präsentation vom Verlauf getrennt bleibt, können bewegte Inhalte veraltetes Dimmen loslassen, ohne die Belichtung zu löschen, die das Panel tatsächlich angesammelt hat.

Im manuellen Modus stellst du Stärke und Formung auf der Overlay-Seite ein. 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:

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:

• Kein zellenbasiertes Risikomodell. Eine Schutzschicht, die über Kacheln von 32 × 32 argumentierte, wurde prototypisiert und verworfen. Die Modellierung pro Pixel ist ehrlicher zur Physik; harte Kacheln erzeugten Treppenartefakte an Inhaltsgrenzen. Das Präsentationsfeld von v5 ist bewusst niedrig aufgelöst, wird aber kontinuierlich geglättet und übergeblendet, sodass es nie so Treppenstufen bildet wie diese harten Kacheln, und das zugrunde liegende Risikomodell bleibt pro Pixel.
• 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.