How the engine works

OLED Guard Pro is not a screensaver. It is a real-time, GPU-resident video pipeline that runs every frame, on every connected display, while you use your computer. This page is the technical tour.

The four-stage pipeline

1. Capture — Windows Graphics Capture / Desktop Duplication

Windows ships two APIs that give you a GPU texture handle to whatever DWM is composing for a given display: Windows Graphics Capture (WGC) and DXGI Desktop Duplication. OLED Guard supports both. The Capture method setting picks Auto, WGC, or Desktop Duplication; Auto selects WGC on Windows 11, with Desktop Duplication as the classic path elsewhere. WGC is preferred where available because it keeps delivering frames at full rate inside fullscreen games, where Desktop Duplication could be starved. Either way, the properties we rely on hold:

• Capture runs on the GPU. The frame buffer never leaves video memory.
• Both APIs work inside borderless fullscreen games (which is the mode most gamers actually play in). Older approaches like BitBlt or PrintWindow do not.
• HDR, multi-monitor, and high-refresh displays are supported without us doing anything special.

If the graphics driver resets mid-session or capture dies, the engine notices and restarts the pipeline cleanly instead of silently stopping.

2. Model — per-pixel exposure shader

A pixel shader processes each captured frame at native resolution. For every pixel it computes:

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

Two parallel passes also run:

• Motion envelope. A cheap temporal high-pass: how much has this pixel changed in the last N frames? Pixels with high motion get their exposure decayed faster, because moving content does not concentrate aging.
• Stability detector. A low-pass on the motion envelope: pixels whose value has been stable for many frames are flagged as “static” and become candidates for protection.

The exposure histogram is double-buffered in GPU memory. There is no readback to the CPU on the hot path.

3. Present: turn risk into a continuous field

The exposure model says where panel wear is building. The presentation stage decides how that risk actually appears on screen. In v5 this is a single continuous field rather than a stack of separate overlay passes. It is built from two low-resolution temporal fields:

• Occupancy answers "is protectable content persistently here?", so a brief bright flash does not trigger dimming.
• Intensity answers "how much protection does the risk model want here?".

The visible dim is the product of those two fields, shaped by explicitly ordered modifiers: an immediate safety core for true high-risk peaks, the Game IQ learned-HUD floor, a static grace period, exclude rectangles, optional vignette edge-weighting, and blue-noise pattern shaping. Because presentation is kept separate from history, moving content can release stale dimming without erasing the exposure the panel actually accumulated.

In manual mode you set strength and shaping from the Overlay page. In Automatic Mode the controller reads the live signal classification (work, gaming, video, idle), the per-pixel motion envelope, and the dynamism trace, and picks a configuration that the model says minimises risk subject to a perceptibility budget. You can watch this happen in the Advanced > Live Classifier readout.

4. Composite — DWM premultiplied alpha

A second shader renders the chosen overlay into a transparent always-on-top window. The Desktop Window Manager composites that window onto your desktop using premultiplied alpha — the same path it uses for Windows’ own animations. That is why the overlay works correctly in:

• SDR and HDR modes,
• borderless fullscreen games,
• variable-refresh displays (G-Sync / FreeSync),
• multi-monitor setups,
• mixed-DPI configurations.

DWM is doing the actual blending. We are just supplying a frame.

Per-display, in parallel

Each connected display runs its own copy of the pipeline. They do not share state. A monitor change, a hot-plug, a resolution change — the engine notices, drops the affected pipeline, and rebuilds it without disturbing the others.

What runs on the CPU

The CPU does:

• Shader compilation at startup,
• presets, configuration, and the React UI,
• foreground-window monitoring for app profiles,
• DDC/CI commands when you change brightness through the app.

The CPU does not see your screen contents. The frames stay in GPU memory the entire time.

Performance budget

A representative measurement at 1440p / 144 Hz on a mid-range GPU:

That is 7% of a 16.6 ms / 60 Hz budget, but it runs on the GPU side rather than blocking your game’s render path, so wall-clock impact in benchmarks is typically below 1%. Higher resolutions, higher refresh rates, and weaker GPUs scale the cost; the relative shape stays the same.

What was deliberately left out

A few design choices we re-validated more than once:

• No cell-based risk model. A protection layer that reasoned over 32 × 32 tiles was prototyped and abandoned. Per-pixel modelling is more honest about the physics; hard tiles produced staircase artifacts at content boundaries. The v5 presentation field is intentionally low-resolution, but it is continuously smoothed and crossfaded, so it never staircases the way those hard tiles did, and the underlying risk model stays per-pixel.
• No CPU-side burn-in heuristics. The engine does not try to recognise “this is a Discord sidebar” or “this is a YouTube logo.” Recognition is fragile and ages badly. Exposure is the universal physical quantity.
• No telemetry pipeline. Per-pixel histograms never leave your machine. We have no servers that receive them, by design.

If you want to see the engine in motion, the Advanced engine page in the desktop app exposes the live classifier, the per-knob auto-controller traces, and the live signals strip at 60 Hz.