デスクトップの裏側 (2)
前回 (id:NyaRuRu:20060925#p1) の続き．
『いまどきのデスクトップ処理系』程に体系化された話を一気にまとめるのは難しそうなので*1，ボトムアップな話題をいくつか．
Xgl を手っ取り早く試すには？
Xgl に興味はあるが環境に手を入れたくないという場合は，1 CD Linux を使うのが便利でしょう．ざっと探してみた中では，Berry Linux が Xgl に対応しているということで試してみたところ，GeForce 6800 環境で無事 Xgl の動作を確認することができました．いくつか気になっていたことを実機でテストすることができて大変助かりました．
Xgl は軽いか？
「Xgl は軽いか？」というのは難しい質問です．プログラミング経験のある方ならよくご存じでしょうが，見た目のインパクトとハードウェア負荷というのは単純には結びつきません．
「13380ポリゴンの恐竜モデルを1280×720ドット解像度で14fps〜33fpsのリアルタイム・レイトレーシングが可能*2」というのと「デスクトップを立方体に貼り付けてぐりぐり回転させたり波紋エフェクトを重ねたり」するののどっちがすごいかなんて，普通はまあ分からないわけです．
舞台裏の苦労というのは直接ユーザの評価を受ける部分ではないので，そのこと自体に問題があるわけではありません．ただ，技術的な火の粉が降りかかってきた頃になっていざ調べて見ると，予想していたのと随分違っていることが多いのこの世界の常です．
例えば私は普段 Microsoft 系の技術を中心に見ていますが，MSDN blog を中心とした開発者コミュニティ経由で得られる情報は，同じ Microsoft の広報部門を通じて発信されているものと随分ウェイトの置かれ方が異なっています．
Windows Vista の Desktop Window Manager (DWM) チームの人が「DWM 制御下で ○○ を行うのは軽いが ×× と組み合わせると重いから気をつけろ」というのに比べれば，広報の人が「Aero はこんなに軽いんですよ」の「軽い」がなんと軽薄なことか．そういう軽薄な「軽い」でよければ，「Xgl は軽い」といくらでも書こうと思います．
Xgl (+Compiz) に比べて DWM の優れている点
Microsoft という会社は「見た目のデザインとプレゼンの下手さに比べれば，コンセプトと土台の設計はかなりおもしろい(ただし仕様の網羅性は苦手なのか，肝心なところがうっかり抜けていたり)」という印象があるのですが，DWM についても Flip3D のような微妙な機能の裏でかなりマニアックで「深追イスト」的な実装がなされています．
そんなわけで，DWM が先行しているポイントについていくつか紹介してみましょう．Xgl と Compiz の優れている点については，放っておいても他の人が色々書いてくれるでしょうし．
実際に Windows Vista と Berry Linux を実機で動かしながら読んで頂けるとベストですね．
画面書き換えタイミングの制御
DWM の特徴の 1 つとして，Tearing 回避への執念が挙げられます．Tearing というのは，例えるなら画面の上と下でフィルムのコマが異なっているような現象のことです．歴史的に CRT の画面書き換え方式が電子銃が画素を順にスキャンしていくというものであったため，ディスプレイ出力信号が一画面分のデータを出力し終わる前にプログラム側の出力画像を更新してしまうと，こういった現象が起きてしまうのです．
出力ラインが画面下端から上端に戻るタイミングに同期して出力画像を切り替えることで，Tearing は回避することが出来ます．このテクニックは現在でもゲーム機では当然のように使用されていますし，PC 環境でも MS-DOS 時代では当たり前のものでした．しかし Windows 環境では，DirectX を用いたフルスクリーンゲームを除き，Tearing 問題については野放しな状況が続いていました．DWM は，10 数年ぶりにこの問題の解消に向けて取り組んでいます．
一方 Xgl でもこの問題は認識されているようですが，残念ながら解決までには時間がかかりそうな印象を受けます．Tearing どういうものか体験するには，現状の Berry Linux で Xgl を実行し，スクリーンを横スクロールさせるてみるのが手っ取り早いとも言えるでしょう．
tearing artifacts(画面の欠落部分）を除去するにはどうすればよいですか
これは別途扱うべきフクザツな問題です。
実際マルチウィンドウシステムにおいて，プログラムの互換性を保ったまま Tearing 回避を徹底するためには，いくつかの技術的な困難があります．
技術的な詳細についてはいずれ改めて解説したいと思いますが，DWM の戦略の基本について少しだけ説明しておきましょう．
DWM 環境では，プログラムが「描画 API」を呼び出してもすぐにウィンドウのコンポジション結果に反映されるわけではありません．特にウィンドウのクライアント領域全体を更新することが多い DirectX アプリケーションのウィンドウモードや，WPF アプリケーションでは，クライアント領域数枚分(と書いたけどDWM_SOURCE_FRAME_SAMPLING の要求眺めてたら余分なフレームバッファ 1 枚で数フレームキューイングしているように見せかけられるような気がしてきた．要調査．)のキューを用意し，その中から次回の画面更新で表示すべきクライアント画像を DWM が「選択」します．
これは中々微妙な問題を孕んでいます．例えばアプリケーションが毎秒 120 回ものシーンレンダリングを行っても，画面更新が毎秒 60 回であれば DWM は自動的に半分の画像を捨ててしまいます．この場合，毎秒 120 回のレンダリングは明らかに無駄になるため，場合によっては DWM の影響をプログラム側で考慮する必要があるでしょう．
また，描画 API 呼出しから画面表示までの数十ミリ秒の遅延は，特に画像と音声の同期や，ゲームでの即応性に影響を与えることがあります．Windows Vista でウィンドウモードの Media Player による動画再生よりも Media Center によるフルスクリーン動画再生の方が滑らかに感じる場合は，DWM のウィンドウ・コンポジションが影響している可能性があります．DWM をオフにして Media Player の再生が改善するかどうか確かめてみてください．
ウィンドウ・コンポジションのタイミング情報は，DwmGetCompositionTimingInfo API で得ることができます．また，DwmSetPresentParameters API や DwmSetDxFrameDuration API で，コンポジションに関するパラメータをトップレベルウィンドウごとに制御することが可能です．
Fail-safe に関する話題
DWM の頑張っている点として，もう 1 つ Fail-safe に関するものを紹介しておきましょう．
歴史を Windows 98 に遡れば，あの当時にして既に Microsoft が HTML によるアプリケーションデザインの有用性に着目していたことを示す歴史的にも興味深い技術として ActiveDesktop があるわけですが*3，いかんせんクラッシュするとシェルごとお亡くなりになるというアーキテクチャはユーザへの印象が悪すぎました．
以後 ActiveDesktop という技術は，不安定な Windows の代名詞として黒歴史化してしまうわけですが*4，これは実装を誤れば技術の先見性も何も残らないという見本と言えるでしょう．そのような視点から見れば，Windows Vista での DWM の実装はなるほど教訓が生かされているようです．
実際のところ，DWM の基盤技術である Direct3D は，ゲーム向けということもあって信頼性よりもパフォーマンスが重視されてきたのは事実です．しかし，出来の悪いドライバのせいで大事な作業中のデータがロストしてしまっても，非難はベンダではなく Microsoft に向かうという現実があります．こういったトラブルに対して，Vista では 2 つのアーキテクチャ的な工夫が見られます．
ひとつ目のポイントは，ログオフ無しに DWM のオンオフができるというアーキテクチャを採用したことです．この点は，Xgl + Compiz とも対照的なポイントなので，少し実験してみましょう．
DWM 環境と Xgl + Compiz 環境で，それぞれ 1024 x 768 程度のウィンドウサイズの Firefox を 150 プロセスほど起動するという実験を行ってみました．先ほども書きましたが，この環境の VRAM は 128 MB です．当然，全てのクライアント領域が VRAM に収まるはずがありません．
Xgl + Compiz 環境では，テクスチャがメインメモリにスワップされているのか，どうしようもないぐらいにウィンドウ処理が重くなってしまいました．一方 Vista の DWM 環境では，100 枚目あたりで VRAM 残量の低下が報告され，さらにウィンドウを開いていくと自動的に DWM がオフに切り替えられました．これは，Fail-Safe の観点では望ましい挙動です．もちろん DWM 環境ほどスムーズな描画はされませんが，少なくとも作業を継続することは可能でした．
他方，X Window System 環境で X サーバの再起動というのは一大事です．VRAM リソース不足に陥ったとき Xgl がどう振る舞うべきかについては，恐らく Xgl の開発者にとっても頭が痛い問題でしょう．しかし，この問題について何らかの回答を出さない限り，デスクトップ環境としてリリースするには問題が残ります．
しかし，いくら DWM がオフに出来てもビデオカード自体がクラッシュしてしまうとどうしようもありません．そこで，もうひとつのポイントです．DWM の必要用件である WDDM ドライバモデルでは，PC リブート無しのビデオカードの“リセット”を規定しています(ATI のGPU Recover 類似技術)．確かに，ゲームや GPU によるシミュレーションを行う一部のアプリケーションを除き，GPU がハングしてしまうような状況でもデータをロストせずに復帰する仕組みは頑張れば実現できそうですし，あって損はありません．実際，ハードウェアベンダと共同でそういった仕組みを整備していったことも，Windows Vista の成果と言えるでしょう．もちろん，こういったハードウェアが多く出回ることで今後他の OS でも同様の仕組みが整備されていく契機となるかもしれません．
とまあ，以上，Windows Vista のデスクトップの裏側に関するお話でした．
