“Just track each pixel and dim it.” We started there too.
The core idea really is that simple, and OLED Guard is built on it: measure how much each pixel lights up over time, then push back where the wear is building. A prototype that does exactly that is a weekend’s work. The hard part is everything the weekend prototype does to your screen the moment it meets a real desktop, a real game, and months of uptime.
You’re right about the idea. It’s the details that bite.
“Track each pixel’s brightness and dim the static ones” is genuinely the right instinct, and it is where the engine begins. But a protector is not a demo that runs for a minute in a screenshot. It has to be correct, invisible, and safe, on every display you own, without a single frame dropped, without you ever noticing it, and without the fix quietly creating new uneven wear of its own. And no, measuring every pixel is not the expensive part: the whole pass runs on the GPU in a fraction of each frame, typically under 1% overhead. The cost is in the correctness. Here are the six walls a naive version hits, and how OLED Guard gets past each.
Every one sounds simple until you ship it
None of these is gold-plating. Each layer exists because the simpler version was built, met reality, and either annoyed people into turning it off or aged the panel in a new way.
Getting the pixels at all
Sounds simple: Read the screen's framebuffer every frame.
Why it isn’t: The classic ways of grabbing the screen (BitBlt, PrintWindow) go black inside the borderless-fullscreen games where HUD burn-in is worst. You need GPU-resident capture (Windows Graphics Capture or Desktop Duplication), with zero copy back to the CPU on the hot path, running at 144 Hz and above without stealing frames from the game, and recovering cleanly every time the graphics driver resets.
When "bright and static" is ambiguous
Sounds simple: Dim the pixels that are bright and don't change.
Why it isn’t: A loading screen, a paused cutscene, a bright sky, an open menu: all bright, all static, and none of them should be treated like a taskbar. Telling durable UI from a momentary still means separating persistence (is content really always here?) from intensity (how much risk?), tracking a per-pixel motion envelope, and rejecting false positives. Get it wrong and you either strobe the whole screen or protect nothing.
How you dim can age the panel too
Sounds simple: Just lower the brightness in that region.
Why it isn’t: A hard per-pixel dim mask leaves visible staircase edges at content boundaries. Naive random dithering clumps, so some subpixels get hammered while their neighbours idle, which is its own kind of uneven aging: the fix creates the problem. Doing it right needs true blue noise, spatially decorrelated so the protective texture spreads load evenly and reads as a flat, quiet film to your eye.
If people can see it, they turn it off
Sounds simple: When in doubt, dim harder to be safe.
Why it isn’t: Protection you can notice is protection people disable, and a tool that is switched off protects nothing. So every intervention runs against a perceptibility budget: the most risk reduction for the least visible change. That constraint, not the dimming itself, is what turns this from a brightness slider into an engineering problem.
Never erase the history
Sounds simple: Recompute the dimming fresh every frame.
Why it isn’t: The wear that actually ages an OLED built up over hours; it does not reset because you scrolled. v5 keeps two things deliberately apart: the risk model (what each pixel has physically absorbed, integrated over time) and the presentation (what to dim right now). That split lets moving content release stale dimming cleanly without wiping the exposure history underneath it.
Games are the hard case, not the easy one
Sounds simple: Find the HUD and dim it.
Why it isn’t: A game HUD is the brightest, most static, most session-to-session identical thing on screen (the worst case for burn-in) sitting over fast, latency-sensitive motion. It vanishes and returns every goal, menu and respawn, and a scene cut wipes the engine's temporal state, so a naive motion check drops every HUD at once and then makes you wait about 30 seconds to re-earn protection. Solving that took a whole subsystem: Game IQ, a loop-free, reset-immune, per-game learned floor.
We tried the shortcuts first
The complexity in OLED Guard is the problem’s, not decoration we added. The tempting simplifications were built, tested against real panels, and abandoned when they made things worse.
A tile-based risk grid
A model that reasoned over 32 by 32 tiles was prototyped and dropped: hard tiles produced staircase artifacts at content boundaries. Per-pixel modelling is more honest about the physics, and the v5 presentation field stays continuously smoothed instead.
Recognising "that is a Discord sidebar"
Teaching the engine to name specific apps and logos is fragile and ages badly the moment a UI changes. Exposure, the luminance a pixel accumulates over time, is the one universal physical quantity, so that is what the engine measures instead.
And here is the honest part
The hardest constraint of all is that there is no guarantee to hide behind. OLED Guard reduces the statistical risk of burn-in; it cannot regrow degraded emitters, and no overlay beats the physics of leaving the same bright image on screen for eighteen hours a day. That is precisely why every layer is built to be conservative: one-way floors that can only add protection, a fallback to the base engine whenever a smarter layer is unsure, and a perceptibility budget on every pixel it touches. Doing less would be easy. Doing this much, safely, and invisibly, is the work.
Simple to say.
Hard to get right.
That gap, between the one-line idea and a protector you can actually leave running, is the whole product. If you want to go deeper, the engine is documented in full.