Как работает движок

OLED Guard Pro - это не заставка. Это работающий в реальном времени и размещённый в памяти GPU видеоконвейер, который обрабатывает каждый кадр на каждом подключённом дисплее, пока ты пользуешься компьютером. Эта страница - технический обзор.

Четырёхэтапный конвейер

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

1. Захват: DXGI Desktop Duplication

Windows предоставляет API под названием Desktop Duplication, который при каждом изменении даёт тебе дескриптор текстуры GPU на то, что DWM компонует для конкретного дисплея. Мы используем его, потому что:

  • Он работает на GPU. Буфер кадра никогда не покидает видеопамять.
  • Это единственный публичный API Windows, который работает внутри безрамочных полноэкранных игр (а это режим, в котором большинство геймеров и играют на самом деле). Более старые подходы вроде BitBlt или PrintWindow так не умеют.
  • Он поддерживает HDR, несколько мониторов и дисплеи с высокой частотой обновления без каких-либо особых действий с нашей стороны.

2. Модель: пиксельный шейдер экспозиции

Пиксельный шейдер обрабатывает каждый захваченный кадр в нативном разрешении. Для каждого пикселя он вычисляет:

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

Параллельно выполняются ещё два прохода:

  • Огибающая движения. Дешёвый временной фильтр высоких частот: насколько сильно этот пиксель изменился за последние N кадров? У пикселей с большим движением экспозиция затухает быстрее, потому что движущийся контент не концентрирует старение.
  • Детектор стабильности. Фильтр низких частот по огибающей движения: пиксели, значение которых остаётся стабильным на протяжении многих кадров, помечаются как «статичные» и становятся кандидатами на защиту.

Гистограмма экспозиции хранится с двойной буферизацией в памяти GPU. На горячем пути нет обратного чтения в CPU.

3. Политика: что с этим делать

Этап политики решает три вещи, для каждого пикселя и в каждом кадре:

  • Сколько защиты применить.
  • Какой тип оверлея рендерить: шум (по умолчанию), статичное затемнение, сдвиг пикселей или дизеринг, с опциональным весом краёв в стиле виньетки поверх.
  • Где формируется поле: равномерно, с весом виньетки к краям или под управлением геометрии профиля приложения.

В ручном режиме эти значения берутся из ползунков на странице оверлея. В Auto Mode контроллер смотрит на живую классификацию сигнала (работа, игры, видео, простой), пиксельную огибающую движения и трассировку динамичности и выбирает конфигурацию, которая, по мнению модели, минимизирует риск в рамках бюджета заметности. Ты можешь наблюдать это в разделе Дополнительно > Живой классификатор.

4. Композитинг: DWM с предумноженной альфой

Второй шейдер рендерит выбранный оверлей в прозрачное окно, которое всегда поверх остальных. Desktop Window Manager компонует это окно на твой рабочий стол, используя предумноженную альфу: тот же путь, что он использует для собственных анимаций Windows. Вот почему оверлей корректно работает в:

  • режимах SDR и HDR,
  • безрамочных полноэкранных играх,
  • дисплеях с переменной частотой обновления (G-Sync / FreeSync),
  • конфигурациях с несколькими мониторами,
  • конфигурациях со смешанным DPI.

Фактическим смешиванием занимается DWM. Мы лишь поставляем кадр.

Для каждого дисплея, параллельно

Каждый подключённый дисплей запускает собственную копию конвейера. Они не делят состояние между собой. Смена монитора, горячее подключение, изменение разрешения - движок это замечает, отбрасывает затронутый конвейер и пересобирает его, не мешая остальным.

Что выполняется на CPU

CPU делает:

  • компиляцию шейдеров при запуске,
  • пресеты, конфигурацию и интерфейс на React,
  • мониторинг окна переднего плана для профилей приложений,
  • команды DDC/CI, когда ты меняешь яркость через приложение.

CPU не видит содержимое твоего экрана. Кадры всё это время остаются в памяти GPU.

Бюджет производительности

Репрезентативное измерение при 1440p / 144 Hz на GPU среднего уровня:

ЭтапСтоимость на кадр
Захват~ 0,4 ms
Модель~ 0,3 ms
Композитинг~ 0,5 ms
Итого~ 1,2 ms

Это 7 % от бюджета 16,6 ms / 60 Hz, но работа выполняется на стороне GPU, а не блокирует путь рендеринга твоей игры, поэтому реальное влияние по времени в бенчмарках обычно ниже 1 %. Более высокие разрешения, более высокие частоты обновления и более слабые GPU увеличивают стоимость; относительная картина остаётся той же.

Что было намеренно опущено

Несколько проектных решений, которые мы перепроверяли не один раз:

  • Никакого ячеечного слоя интеллекта. Ячеечный слой защиты, который рассуждал поверх плиток 32 × 32, был прототипирован и заброшен. Пиксельное моделирование честнее по отношению к физике; плитки давали лестничные артефакты на границах контента.
  • Никаких эвристик выгорания на стороне CPU. Движок не пытается распознать «это боковая панель Discord» или «это логотип YouTube». Распознавание хрупко и плохо устаревает. Экспозиция - это универсальная физическая величина.
  • Никакого конвейера телеметрии. Пиксельные гистограммы никогда не покидают твою машину. У нас по замыслу нет серверов, которые бы их получали.

Если ты хочешь увидеть движок в действии, страница Дополнительный движок в десктоп-приложении показывает живой классификатор, трассировки авто-контроллера по каждой ручке и полосу живых сигналов на 60 Hz.

УстановкаРежимы защиты