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 prefiere Desktop Duplication, la ruta predeterminada de menor sobrecarga, pero en Windows 11 puede recurrir a WGC si Desktop Duplication no puede iniciarse. También puedes seleccionar WGC de forma explícita si Desktop Duplication falla en un juego o equipo concreto. 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 y una ponderación opcional de bordes estilo viñeta. El aspecto final puede ser Fine Grain, una textura sutil y móvil de ruido azul, o Smooth, un acabado uniforme sin textura. Ambos tienen la misma atenuación media y no cambian la detección, la capacidad de respuesta ni la intensidad de protección. 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 el modo de control de preajustes Manual eliges el preajuste y la intensidad. Con Autopilot, el controlador lee 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 adapta el preajuste y la capacidad de respuesta. La Intensity global y el acabado Fine Grain/Smooth siguen bajo tu control. Puedes observar la clasificación 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.