エンジンの仕組み

OLED Guard Pro はスクリーンセーバーではありません。PC を使っている間、接続されたすべてのディスプレイで毎フレーム動作し続ける、GPU 常駐のリアルタイム映像パイプラインです。このページでは、その技術的な全体像を解説します。

4 段構成のパイプライン

CAPTUREWGC/DXGIMODELexposurePRESENTfieldCOMPOSITEDWM

1. キャプチャ: Windows Graphics Capture / Desktop Duplication

Windows には、DWM が各ディスプレイ向けに合成している映像の GPU テクスチャハンドルを取得できる API が 2 つ用意されています。Windows Graphics Capture (WGC) と DXGI Desktop Duplication です。OLED Guard は両方をサポートします。キャプチャ方式の設定では Auto、WGC、Desktop Duplication を選択でき、Auto は Windows 11 では WGC を、それ以外の環境では従来方式である Desktop Duplication を選択します。WGC が利用できる環境で優先されるのは、全画面ゲームの中でもフルレートでフレームを取得し続けられるためです。Desktop Duplication では、こうした場面でフレーム供給が滞ることがあります。どちらの方式でも、エンジンが前提とする次の特性は変わりません。

  • キャプチャは GPU 上で実行されます。フレームバッファーがビデオメモリの外へ出ることはありません。
  • どちらの API もボーダーレス全画面のゲーム内で動作します（現在ほとんどのゲーマーが実際にプレイしているモードです）。BitBlt や PrintWindow といった旧来の手法では不可能です。
  • HDR、マルチモニター、高リフレッシュレートのディスプレイにも、特別な処理なしで対応します。

セッション中にグラフィックスドライバーがリセットされたり、キャプチャが停止したりした場合も、エンジンはそれを検知し、黙って止まるのではなくパイプラインをクリーンに再起動します。

2. モデル: ピクセルごとの露光量シェーダー

ピクセルシェーダーが、キャプチャした各フレームをネイティブ解像度で処理します。すべてのピクセルについて、次の計算を行います。

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

これと並行して、2 つのパスも実行されます。

  • モーションエンベロープ。 軽量な時間方向のハイパスフィルターです。直近 N フレームでそのピクセルがどれだけ変化したかを測り、動きの大きいピクセルは露光量の減衰を速めます。動いているコンテンツは劣化を一点に集中させないためです。
  • 安定性検出器。 モーションエンベロープに対するローパスフィルターです。多くのフレームにわたって値が安定しているピクセルを「静止」としてフラグ付けし、保護の候補にします。

露光量ヒストグラムは GPU メモリ上でダブルバッファリングされます。ホットパスで CPU への読み戻しは発生しません。

3. 表示: リスクを連続的なフィールドに変える

露光量モデルは、パネルの劣化がどこで進んでいるかを示します。表示ステージは、そのリスクを実際に画面へどう現すかを決めます。v5 では、これは個別のオーバーレイパスの積み重ねではなく、1 つの連続的なフィールドです。これは 2 つの低解像度の時間的フィールドから構築されます。

  • 占有度（Occupancy） は「保護すべきコンテンツがここに持続的にあるか?」に答えます。これにより、一瞬の明るい閃光では減光が発動しません。
  • 強度（Intensity） は「リスクモデルはここにどれだけの保護を求めているか?」に答えます。

目に見える減光は、この 2 つのフィールドの積であり、明示的に順序付けられた調整で形づくられます。真に高リスクなピークに対する即時のセーフティコア、Game IQ が学習した HUD の保護下限、静止コンテンツの猶予期間、除外矩形、オプションの Vignette エッジ重み付け、そしてブルーノイズのパターン形成です。表示は履歴と切り離されているため、動くコンテンツは、パネルが実際に蓄積した露光量を消すことなく、古い減光を解放できます。

手動モードでは、強度と形状を「Overlay」ページで設定します。Automatic Mode では、コントローラーがライブの信号分類（作業、ゲーム、動画、アイドル）、ピクセルごとのモーションエンベロープ、ダイナミズムのトレースを参照し、知覚されやすさを許容範囲に抑えつつ、リスクを最小化できるとモデルが判断した構成を選びます。この様子は「Advanced > Live Classifier」の表示でリアルタイムに確認できます。

4. 合成: DWM の事前乗算アルファ

2 つ目のシェーダーが、選択されたオーバーレイを透過の常時最前面ウィンドウへ描画します。Desktop Window Manager は、Windows 自身のアニメーションと同じ経路である事前乗算アルファを使って、このウィンドウをデスクトップに合成します。オーバーレイが次の環境で正しく動作するのはこのためです。

  • SDR モードと HDR モード
  • ボーダーレス全画面のゲーム
  • 可変リフレッシュレートのディスプレイ（G-Sync / FreeSync）
  • マルチモニター構成
  • DPI が混在する構成

実際のブレンドを行っているのは DWM です。OLED Guard はフレームを供給しているだけです。

ディスプレイごとに並列動作

接続された各ディスプレイは、それぞれ独立したパイプラインを実行し、状態を共有しません。モニターの変更、ホットプラグ、解像度の変更が起きると、エンジンはそれを検知して該当するパイプラインだけを破棄・再構築し、ほかのディスプレイには影響を与えません。

CPU 上で動くもの

CPU が担当するのは次の処理です。

  • 起動時のシェーダーコンパイル
  • プリセット、設定、React 製 UI
  • アプリプロファイル用の前面ウィンドウ監視
  • アプリから輝度を変更したときの DDC/CI コマンド

CPU が画面の内容を見ることはありません。フレームは終始 GPU メモリ内にとどまります。

パフォーマンスバジェット

ミドルレンジ GPU、1440p / 144 Hz での代表的な計測値です。

ステージ1 フレームあたりのコスト
キャプチャ~ 0.4 ms
モデル~ 0.3 ms
合成~ 0.5 ms
合計~ 1.2 ms

これは 16.6 ms（60 Hz）のバジェットの 7% に相当しますが、ゲームの描画パスをブロックするのではなく GPU 側で並列に実行されるため、ベンチマークでの実時間への影響は通常 1% 未満です。解像度やリフレッシュレートが高いほど、また GPU が非力なほどコストは増えますが、相対的な内訳は変わりません。

あえて採用しなかったもの

何度も再検証したうえでの設計判断をいくつか挙げます。

  • セルベースのリスクモデルは不採用。 32 × 32 のタイル単位で判断する保護レイヤーを試作しましたが、廃止しました。ピクセル単位のモデリングのほうが物理に忠実であり、硬いタイルはコンテンツの境界に階段状のアーティファクトを生んでいました。v5 の表示フィールドは意図的に低解像度ですが、連続的に平滑化・クロスフェードされるため、あの硬いタイルのように階段状になることは決してなく、その下にあるリスクモデルはピクセル単位のままです。
  • CPU 側の焼き付きヒューリスティクスは不採用。 エンジンは「これは Discord のサイドバーだ」「これは YouTube のロゴだ」といった認識を試みません。認識ベースの手法は壊れやすく、時間とともに陳腐化します。露光量こそが普遍的な物理量です。
  • テレメトリーパイプラインは不採用。 ピクセルごとのヒストグラムがマシンの外へ出ることはありません。設計上、それを受け取るサーバー自体が存在しません。

エンジンが動く様子を実際に見たい場合は、デスクトップアプリのエンジンの詳細設定ページで、ライブ分類器、各パラメーターの自動コントローラーのトレース、60 Hz のライブシグナルストリップを確認できます。

インストール保護モード