Como o motor funciona

O OLED Guard Pro não é um protetor de tela. É um pipeline de vídeo em tempo real, residente na GPU, que roda a cada frame, em cada tela conectada, enquanto você usa o seu computador. Esta página é o tour técnico.

O pipeline de quatro estágios

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

1. Captura — DXGI Desktop Duplication

O Windows inclui uma API chamada Desktop Duplication que entrega um handle de textura na GPU daquilo que o DWM está compondo para uma determinada tela, toda vez que isso muda. Nós a usamos porque:

Ela roda na GPU. O frame buffer nunca sai da memória de vídeo.
É a única API pública do Windows que funciona dentro de jogos em tela cheia sem bordas (que é o modo no qual a maioria dos jogadores de fato joga). Abordagens mais antigas como BitBlt ou PrintWindow não funcionam.
Ela suporta HDR, múltiplos monitores e telas de alta taxa de atualização sem que precisemos fazer nada de especial.

2. Modelo — shader de exposição por pixel

Um pixel shader processa cada frame capturado em resolução nativa. Para cada pixel, ele calcula:

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

Duas passagens paralelas também rodam:

Envelope de movimento. Um filtro temporal passa-alta de baixo custo: o quanto este pixel mudou nos últimos N frames? Pixels com muito movimento têm sua exposição decaída mais rápido, porque conteúdo em movimento não concentra o envelhecimento.
Detector de estabilidade. Um filtro passa-baixa sobre o envelope de movimento: pixels cujo valor permaneceu estável por muitos frames são marcados como “estáticos” e se tornam candidatos à proteção.

O histograma de exposição fica com buffer duplo na memória da GPU. Não há leitura de volta para a CPU no caminho crítico.

3. Política — o que fazer a respeito

O estágio de política decide três coisas, por pixel, a cada frame:

Quanta proteção aplicar.
Que tipo de camada de proteção renderizar — ruído (padrão), escurecimento estático, deslocamento de pixels ou dithering, com uma ponderação de borda estilo vinheta opcional sobreposta por cima.
Onde o campo é moldado — uniforme, ponderado em vinheta na direção das bordas, ou guiado pela geometria do perfil do aplicativo.

No modo manual, esses valores vêm dos controles deslizantes da página Camada de proteção. No Modo automático, o controlador observa a classificação ao vivo do sinal (trabalho, jogo, vídeo, ocioso), o envelope de movimento por pixel e o traço de dinamismo, e escolhe uma configuração que, segundo o modelo, minimiza o risco sujeito a um orçamento de perceptibilidade. Você pode acompanhar isso acontecendo no indicador Avançado > Live Classifier.

4. Composição — alfa pré-multiplicado do DWM

Um segundo shader renderiza a camada de proteção escolhida em uma janela transparente sempre no topo. O Desktop Window Manager compõe essa janela sobre a sua área de trabalho usando alfa pré-multiplicado — o mesmo caminho que ele usa para as próprias animações do Windows’. É por isso que a camada de proteção funciona corretamente em:

modos SDR e HDR,
jogos em tela cheia sem bordas,
telas de taxa de atualização variável (G-Sync / FreeSync),
configurações com múltiplos monitores,
configurações de DPI misto.

O DWM é quem faz a mesclagem de verdade. Nós apenas fornecemos um frame.

Por tela, em paralelo

Cada tela conectada roda a sua própria cópia do pipeline. Elas não compartilham estado. Uma troca de monitor, uma conexão a quente, uma mudança de resolução — o motor percebe, descarta o pipeline afetado e o reconstrói sem perturbar os demais.

O que roda na CPU

A CPU faz:

A compilação dos shaders na inicialização,
as predefinições, a configuração e a interface em React,
o monitoramento da janela em primeiro plano para os perfis de aplicativo,
os comandos DDC/CI quando você muda o brilho pelo aplicativo.

A CPU não vê o conteúdo da sua tela. Os frames permanecem na memória da GPU o tempo todo.

Orçamento de desempenho

Uma medição representativa a 1440p / 144 Hz em uma GPU de médio porte:

Estágio	Custo por frame
Captura	~ 0,4 ms
Modelo	~ 0,3 ms
Composição	~ 0,5 ms
Total	~ 1,2 ms

Isso é 7% de um orçamento de 16,6 ms / 60 Hz, mas roda do lado da GPU em vez de bloquear o caminho de renderização do seu jogo, então o impacto em tempo real nos benchmarks costuma ficar abaixo de 1%. Resoluções mais altas, taxas de atualização mais altas e GPUs mais fracas escalam o custo; o formato relativo permanece o mesmo.

O que foi deliberadamente deixado de fora

Algumas decisões de projeto que revalidamos mais de uma vez:

Sem camada de inteligência baseada em células. Uma camada de proteção baseada em células que raciocinava sobre blocos de 32 × 32 foi prototipada e abandonada. A modelagem por pixel é mais honesta quanto à física; os blocos produziam artefatos em escada nos limites do conteúdo.
Sem heurísticas de burn-in do lado da CPU. O motor não tenta reconhecer “isto é uma barra lateral do Discord” ou “isto é um logotipo do YouTube”. O reconhecimento é frágil e envelhece mal. A exposição é a grandeza física universal.
Sem pipeline de telemetria. Os histogramas por pixel nunca saem da sua máquina. Não temos servidores que os recebam, por design.

Se você quiser ver o motor em ação, a página do Motor avançado no aplicativo de desktop expõe o classificador ao vivo, os traços do autocontrolador por parâmetro e a faixa de sinais ao vivo a 60 Hz.

Instalação Modos de Proteção