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

   ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
   │ CAPTURE  │ ──▶ │  MODEL   │ ──▶ │  POLICY  │ ──▶ │COMPOSITE │
   │  DXGI    │     │ exposure │     │ Auto/man │     │   DWM    │
   └──────────┘     └──────────┘     └──────────┘     └──────────┘

1. Captura — DXGI Desktop Duplication

Windows incluye una API llamada Desktop Duplication que te da un handle de textura en la GPU de lo que DWM esté componiendo para una pantalla determinada, cada vez que cambia. La usamos porque:

• Se ejecuta en la GPU. El frame buffer nunca sale de la memoria de vídeo.
• Es la única API pública de Windows que funciona 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.
• Admite HDR, multimonitor y pantallas de alta frecuencia de actualización sin que tengamos que hacer nada especial.

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. Política — qué hacer al respecto

La etapa de política decide tres cosas, por píxel, en cada frame:

• Cuánta protección aplicar.
• Qué tipo de capa renderizar — ruido (predeterminado), atenuación estática, desplazamiento de píxeles o dithering, con un peso opcional de bordes estilo viñeta superpuesto encima.
• Dónde se conforma el campo — uniforme, ponderado en viñeta hacia los bordes, o guiado por la geometría del perfil de la app.

En modo manual estos valores provienen de los controles deslizantes de 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 capa de inteligencia basada en celdas. Se prototipó y se abandonó una capa de protección basada en celdas que razonaba sobre teselas de 32 × 32. El modelado por píxel es más honesto con la física; las teselas producían artefactos en escalera en los límites del contenido.
• 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.