WDDM, DWM: pros and cons

WDDM,DWM のメリット・デメリットをちゃんと書いておいた方が良さそうなので,思い付く限りのものをリストアップしてみました.抜けがある場合はご指摘よろしくお願いします.

はじめに

  • 一般的に言って,スループットとレスポンスどちらの向上にリソースを割り当てるかは難しい問題.Windows Vista では,個人的にはレスポンスタイムの改善にフォーカスしているという印象を受ける.
  • レスポンスタイムの変化は体感しやすく,逆に 10 分の処理が 12 分かかるようになったといったスループット変化はベンチマークなどをとらないと中々気付かないため,近年はスループットを犠牲にしてでもレスポンスタイムの改善を目指す場面が増えてきているように思う.

メリット

  • GDI アプリケーション / DirectX ウィンドウモードアプリケーション共通のメリット
    • [DWM]トップレベルウィンドウ移動時の WM_PAINT が激減した (レスポンスの向上.ただし MDI の内側の合成は GDI ベースなので注意)
    • [DWM]ビデオカード (特に VRAM) への投資効果が増した
    • [DWM]Flip3D や Thumbnail API のように,他のウィンドウサーフェイスを使った軽量エフェクトが使用できるようになった (ただし,内部データを Microsoft が独占しているので,Compiz や Beryl のようにサードパーティ製のエフェクトでカスタマイズし放題,という日は当面来なさそう)
  • GDI アプリケーションのメリット
    • [WDDM]GDI がハードウェア処理されなくなったことでドライバが単純になった (信頼性の向上)
    • [DWM]レイヤードウィンドウが確実にハードウェア処理されるようになった
    • [DWM]ティアリングが無くなった (GDI の描画アルゴリズム上,従来のちらつき全てが無くなるわけではない)
  • DirectX ウィンドウモードアプリケーションのメリット
    • [DWM]ティアリングが無くなった

デメリット

  • GDI アプリケーション / DirectX ウィンドウモードアプリケーション共通のデメリット
    • [DWM]ディスプレイのリフレッシュレートを超える画面更新は破棄されるようになった (ティアリング回避のため).頑張って FPS を上げすぎても無駄になる.
    • [DWM]従来のオーバーレイ API と両立できない.
  • GDI アプリケーションでのデメリット
    • [WDDM]GDI が完全ソフトウェア実装になったことで,描画スループットが低下することがある (CPU の速度次第)
    • [DWM]ディスプレイ DC : GetDC(NULL) へのアクセスが遅くなった.特に (従来速いとされていた) XOR 描画が極端に遅くなっているので注意.
    • [DWM]非クライアント領域への描画に色々気をつける必要がでてきた.
    • [DWM]トップレベルウィンドウのクライアント領域と同じサイズの,システムメモリと VRAM を消費するようになった.
  • DirectX ウィンドウモードアプリケーションでのデメリット
    • [DWM]GPU のコンテキスト切り替えの回数が増えた.従来のように画面更新が無くても再描画,というのは避ける必要が出てきた.
    • [DWM]DWM が大量の VRAM を消費するので,使用する VRAM 量に気をつける必要が出てきた.
    • [DWM]画面表示タイミングの制御がますますややこしくなった.
    • [DWM]プライマリサーフェイスごとに,トップレベルウィンドウのクライアント領域と同じサイズの VRAM を消費するようになった.(従来プライマリサーフェイスはプロセスを越えて 1 つ)

雑感

  • DWM 自身が,フルスクリーンモードの Direct3D アプリケーションみたいなもの,という点に注意.
  • 「軽くなった」の声の裏で,スループットが落ちている例は探せばもっとあるはず.でも最近はみんな「もっさり」ばっかり気にするよね?
  • クラシックテーマや Vista Basic テーマを選べば上の [DWM] と書かれた箇所については従来通りになる.誰も褒めないけど,ちゃんとログオフ無しに変更可能を実現してくれたのは世界で一人ぐらいは褒めてあげたい.追記.重要な点を書き忘れた.dwm.exe がクラッシュしてもログオフ不要を実現してくれたのは世界で一人ぐらいは褒めてあげたい.(Remember ActiveDesktop!)
  • 従来のアプリケーションを変更することなくアーキテクチャを刷新しようとしたため,各所に大量のトリックが見られる.GDI 周りで特に,ハードウェアの挙動を仮定した高速化ノウハウなどが一気に陳腐化する.
  • GDI アプリケーションを丸々書き直せば,DWM 環境でのメインメモリ使用量は減り,パフォーマンスも改善するかもしれないが,当然誰もそのコストを払いたがらない.また,非 DWM 環境でどうするかという問題もある.
  • 現時点で DWM / WPF が「最新の GPU 機能を使って描画を高速化」と言うのは無理がある.動的頂点バッファ + 大量のテクスチャという力業で,方法論的には 10 年前のゲームで既に実現されていたこと.しかし,単なる力業でも従来より改善する点があるというのがポイントであり哀しいところ.
  • Direct3D10 はウィンドウ内を高速描画する別パラダイムと思うべき.現時点で,デスクトップ描画と D3D10 を結びつけて議論するのは無理がある.
  • WPF や Cairo のような,低レベル 3D API 上に高レベル描画 API を再構築する試みが今後改善されていけば,ハードウェアの利用効率も向上するだろう.今回 GDI がカーネルから切り離されたことだし,高レベル描画 API とドライバが一対一に対応しないというのは今後のトレンドかもしれない.
  • リモートデスクトップで,milcore.dll 経由の描画 (つまり DWM と WPF) のみ remoting 対応なのは,見方によってはアンフェア? (いわゆる非公開 API)