Cómo funciona el motor

OLED Guard Pro no es un salvapantallas. Es una canalización de vídeo en tiempo real, residente en la GPU, que se ejecuta en cada frame, en cada pantalla conectada, mientras usas tu ordenador. Esta página es el recorrido técnico.

La canalización de cuatro etapas

1. Captura — Windows Graphics Capture / Desktop Duplication

Windows incluye dos APIs que te dan un handle de textura en la GPU de lo que DWM esté componiendo para una pantalla determinada: Windows Graphics Capture (WGC) y DXGI Desktop Duplication. OLED Guard admite ambas. El ajuste Método de captura permite elegir Auto, WGC o Desktop Duplication; Auto selecciona WGC en Windows 11, con Desktop Duplication como la ruta clásica en el resto. WGC es la opción preferida donde está disponible porque sigue entregando frames a ritmo completo dentro de los juegos en pantalla completa, donde Desktop Duplication podía quedarse sin frames. En cualquier caso, las propiedades en las que nos apoyamos se mantienen:

• La captura se ejecuta en la GPU. El frame buffer nunca sale de la memoria de vídeo.
• Ambas APIs funcionan dentro de los juegos en pantalla completa sin bordes (que es el modo en el que la mayoría de los jugadores realmente juega). Los enfoques más antiguos como BitBlt o PrintWindow no lo hacen.
• Admiten HDR, multimonitor y pantallas de alta frecuencia de actualización sin que tengamos que hacer nada especial.

Si el controlador gráfico se reinicia a mitad de sesión o la captura muere, el motor lo detecta y reinicia la canalización de forma limpia en lugar de detenerse silenciosamente.

2. Modelo — shader de exposición por píxel

Un pixel shader procesa cada frame capturado a resolución nativa. Para cada píxel calcula:

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

También se ejecutan dos pasadas paralelas:

• Envolvente de movimiento. Un filtro temporal de paso alto poco costoso: ¿cuánto ha cambiado este píxel en los últimos N frames? Los píxeles con mucho movimiento ven su exposición decaer más rápido, porque el contenido en movimiento no concentra el envejecimiento.
• Detector de estabilidad. Un filtro de paso bajo sobre la envolvente de movimiento: los píxeles cuyo valor ha permanecido estable durante muchos frames se marcan como “estáticos” y pasan a ser candidatos a protección.

El histograma de exposición está en doble búfer en la memoria de la GPU. No hay lectura de vuelta a la CPU en la ruta crítica.

3. Presentación: convertir el riesgo en un campo continuo

El modelo de exposición dice dónde se está acumulando el desgaste del panel. La etapa de presentación decide cómo aparece realmente ese riesgo en la pantalla. En la v5 esto es un único campo continuo en lugar de una pila de pasadas de capa separadas. Se construye a partir de dos campos temporales de baja resolución:

• La ocupación responde a "¿hay contenido protegible de forma persistente aquí?", de modo que un breve destello brillante no dispara la atenuación.
• La intensidad responde a "¿cuánta protección quiere aquí el modelo de riesgo?".

La atenuación visible es el producto de esos dos campos, moldeada por modificadores ordenados de forma explícita: un núcleo de seguridad inmediato para los verdaderos picos de alto riesgo, el suelo de HUD aprendido de Game IQ, un periodo de gracia para el contenido estático, rectángulos de exclusión, una ponderación opcional de bordes estilo viñeta y el moldeado del patrón de ruido azul. Como la presentación se mantiene separada del historial, el contenido en movimiento puede liberar la atenuación obsoleta sin borrar la exposición que el panel realmente acumuló.

En modo manual ajustas la intensidad y el moldeado desde la página Overlay. En el Modo automático el controlador observa la clasificación de la señal en vivo (trabajo, juego, vídeo, inactivo), la envolvente de movimiento por píxel y la traza de dinamismo, y elige una configuración que, según el modelo, minimiza el riesgo sujeto a un presupuesto de perceptibilidad. Puedes ver cómo ocurre esto en el indicador Advanced > Live Classifier.

4. Composición — alfa premultiplicado de DWM

Un segundo shader renderiza la capa elegida en una ventana transparente siempre visible. El Desktop Window Manager compone esa ventana sobre tu escritorio usando alfa premultiplicado — la misma ruta que usa para las propias animaciones de Windows’. Por eso la capa funciona correctamente en:

• modos SDR y HDR,
• juegos en pantalla completa sin bordes,
• pantallas de frecuencia de actualización variable (G-Sync / FreeSync),
• configuraciones multimonitor,
• configuraciones de DPI mixto.

DWM es quien hace la mezcla real. Nosotros solo aportamos un frame.

Por pantalla, en paralelo

Cada pantalla conectada ejecuta su propia copia de la canalización. No comparten estado. Un cambio de monitor, una conexión en caliente, un cambio de resolución — el motor lo detecta, descarta la canalización afectada y la reconstruye sin perturbar las demás.

Qué se ejecuta en la CPU

La CPU se encarga de:

• la compilación de shaders al arrancar,
• los preajustes, la configuración y la interfaz de React,
• la monitorización de la ventana en primer plano para los perfiles de app,
• los comandos DDC/CI cuando cambias el brillo a través de la app.

La CPU no ve el contenido de tu pantalla. Los frames permanecen en la memoria de la GPU todo el tiempo.

Presupuesto de rendimiento

Una medición representativa a 1440p / 144 Hz en una GPU de gama media:

Eso es el 7% de un presupuesto de 16,6 ms / 60 Hz, pero se ejecuta del lado de la GPU en lugar de bloquear la ruta de renderizado de tu juego, así que el impacto en tiempo real en los benchmarks suele estar por debajo del 1%. Las resoluciones más altas, las frecuencias de actualización más altas y las GPU más débiles escalan el coste; la forma relativa se mantiene igual.

Qué se dejó fuera deliberadamente

Algunas decisiones de diseño que revalidamos más de una vez:

• Sin modelo de riesgo basado en celdas. Se prototipó y se abandonó una capa de protección que razonaba sobre teselas de 32 × 32. El modelado por píxel es más honesto con la física; las teselas rígidas producían artefactos en escalera en los límites del contenido. El campo de presentación de la v5 es intencionadamente de baja resolución, pero se suaviza y se funde de forma continua, así que nunca produce escalones como aquellas teselas rígidas, y el modelo de riesgo subyacente sigue siendo por píxel.
• Sin heurísticas de burn-in del lado de la CPU. El motor no intenta reconocer “esto es una barra lateral de Discord” o “esto es un logotipo de YouTube”. El reconocimiento es frágil y envejece mal. La exposición es la magnitud física universal.
• Sin canalización de telemetría. Los histogramas por píxel nunca salen de tu máquina. No tenemos servidores que los reciban, por diseño.

Si quieres ver el motor en acción, la página del Motor avanzado de la app de escritorio expone el clasificador en vivo, las trazas del autocontrolador por parámetro y la franja de señales en vivo a 60 Hz.