■ 第239回 ■ 明らかになってきたAvalonの実装手法

　米シアトルでMicrosoftが開催中のハードウェア開発者向け会議「WinHEC 2004」では、昨年の秋に開催されたProfessinal Developers Conference 2003(ソフトウェア技術者向け会議)で明らかになったAvalonの情報に加え、より具体的な実装にまで踏み込んだ内容が紹介された。

　Avalonは次世代WindowsのLonghornで実装される、Win32に代わる新しいAPIセット「WinFX」の中で、プレゼンテーション部分を担当する。この中には2D/3Dグラフィック、アニメーション、ビデオ、オーディオなどが含まれ、Avalonではこれらのメディアを統合的に扱うことが可能になっている。

　これまでWindowsは、Windows 3.xで定義された16bitのGDIを起源に、Windows 95以降のGDI、Windows 2000以降のGDI+、さらにはWindows XPまでの間に加えられてきたDirectXなど様々な拡張APIをリセットし、全く新しいアーキテクチャへと移行する。

　ではそれによってWindowsの内部構造はどのように変化し、どのようなメリットが生まれるのだろうか。

●階層型のデスクトップ描画構造

　これまでMicrosoftは(Longhornという名前が出る以前から)、WinHECで徐々に次世代グラフィックのアーキテクチャをアナウンス、その一部はGDI+にも取り入れられている。たとえばGDIの描画を、GDI+でDirectXの描画サーフェイスに行なうように変更したものも、今から振り返ればAvalonに向けての布石だったとも言える。

　その後、Longhornの描画はDirect3Dのテクスチャバッファに書き込まれることが明らかになり、2D、動画などの描画にもGPUのシェーダプログラムが利用されることなどもアナウンスされている。

　また、Avalonの描画アーキテクチャはネットワーク透過に設計されており、Ethernetや無線LANなどのネットワークを通じて高速に実行できるとも言われている。画面解像度に対してのスケーラビリティを持ち、従来のアプリケーションを96dpiで、Longhornアプリケーションは画面の実解像度(ピクセルピッチ)に併せて描画する機能も昨年わかったことだ。ピクセルピッチはディスプレイから情報を受けなければ自動判断できないため、ディスプレイメーカーにはディスプレイ情報としてピクセルピッチを入れておくように推奨している。

　今回のWinHECでも、Avalonで実装される様々な描画、アニメーション機能は可能な限りシェーダプログラムとして書かれ、CPUに対する負荷を最小限に抑えてGPUに仕事をさせていることを強調している。従来、3Dばかりでしか利用されてこなかったGPUの機能や性能が、Avalonではあらゆる画面表示においてパフォーマンスを左右する重要な要素に格上げされるとも言えるだろう。

　なお、AvalonにはアプリケーションがCPUパワーを振り分けるシステムと似た、GPUパワーを管理する機能もある。たとえばフルスクリーン動作のゲームには、GPUの独占使用をさせてパフォーマンスの最大化を図ったり、フルスクリーンではないゲームや各アプリケーション、あるいは動画サーフェイスの描画などで、適切にGPUパワーをシェアする仕組みだ。こうしたGPUパワーの管理はLonghornのディスプレイドライバモデルで書かれてさえいれば機能する。

　では、Longhorn内部でのモジュール構造はどうなっているのか?

　Avalonの描画モジュールは、「Unified Composition Engine(UCE)」という名前が付けられている。UCEは、後述する“Visual Tree”というプレゼンテーション要素を構造化したデータを受け、それを描画バッファの中に生成したり、オーディオ出力データを生成するモジュールだ。

　UCEはアプリケーションごとにインスタンス(複製)が並行動作。デスクトップのユーザーインターフェイスを司るシェルも含め、各アプリケーションごとに独立したUCEが描画イメージを生成し、テクスチャとして描画バッファに保存される。

　最終的にデスクトップを描画するのは、「Desktop Window Manager(DWM)」だ。DWMは各アプリケーションごとのUCEインスタンスが作り出したテクスチャを元に、正しい位置、サイズ、描画パラメータ(半透明処理や影付き処理など)でVisual Treeを作り、それを再度UCEでレンダリングさせ、Direct3Dのバックバッファに出力する。

　このように階層構造でのデスクトップ描画になっているため、DWMの味付け、設定によってデスクトップ上におけるグラフィック効果の自由度は非常に高くなる。以前、WinHECにおけるデモで、ウィンドウを移動する際にウィンドウ形状が揺れたり、あるいはウィンドウサイズを縮小して置いておくといったユーザーインターフェイスが披露されたが、(実際にどのようなユーザーインターフェイスになるかは別として)Direct3Dで表現できるあらゆる手法を用いてデスクトップを作ることができる。

●複数メディア統合とネットワーク透過を実現するVisual Tree

　さて、文中にVisual Treeという耳慣れない言葉が出てきた。Visual Treeとは、いわばUCEに対する指示書のようなものである。UCEでレンダリングするオブジェクトをツリー型の構造化データで表現するデータの固まりだ。

　Avalonでは単なるグラフィック以外のプレゼンテーション要素を統合していると述べた。ビットマップ、ベクトルグラフィック、テキスト、動画、音声、それにあらゆる3Dオブジェクトタイプをサポートする。

　Visual Treeにはこれら複数の異なる要素の詳細を含むことができる。2D描画のパラメータやペンタイプ、ブラシタイプ、変形処理、ビットマップ、ビデオストリーム、3Dモデルデータ、3Dテクスチャなどなど、あらゆるプレゼンテーション要素は、Visual Treeの中に記述されている。

　UCEはVisual Treeの記述内容をベクトルグラフィック、3D、テキスト、ビットマップ、ビデオ、オーディオに分離し、それぞれに適したレンダリングを行なった後にグラフィックを合成、オーディオ要素と同期させながら出力する。

　Visual Treeはシンプルな構造化データになっているため、その更新も楽だ。Visual Treeを改変したりアニメーション指示をUCEに対して指示すると、UCEは各要素の合成時に異なる描画結果を出す。たとえばウィンドウを動かすと、DWMのUCEは同じVisual Treeを用い、動かすウィンドウの位置ジオメトリだけを変えながら再合成することでウィンドウを動かす。アニメーションの場合は、UCE内部のアニメーション処理モジュールがVisual Tree内のジオメトリを更新しながら再描画を行なう。

　また、個々のアプリケーションは描画の順番などを意識することなく、Visual Treeを改変していくことで画面の描画を行なうことが可能だ。UCEにはVisual Treeのすべてを渡すのではなく、その差分だけを引き渡してレンダリングを実行することもできる。このため、アプリケーションプログラム側は最低限の更新情報だけを、構造データで渡すだけでよい。複数の描画要素を合成する場合も、2つのVisual Treeの構造をマージするだけでよく、アプリケーションプログラム側で行なうべき処理はシンプルになる。

　Visual Treeに関してもうひとつ興味深いのは、パラメータ変更や追加オブジェクトなどの差分を与えるだけで複雑な再描画も行なえてしまう点である。最終的なデスクトップの描画イメージはDWMと共に動くUCEが行なうが、その前段階ですでにデスクトップ上に並べるテクスチャ要素は決定している。

　ここに新しいウィンドウを開いた場合、そのウィンドウテクスチャをVisual Treeに追加。動かすだけならば、ジオメトリ変更だけだ。それ以外の要素は変化しないため、UCEに送る必要はない。つまりDWMとUCEの間で使われるデータ帯域はそれほど多くない。さらには、アニメーション要素を加える場合、アニメーションの結果をUCEに送るのではなく、アニメーションの指示をUCEに送るだけで済んでしまう。

デスクトップ描画かこのような階層構造で行なわれる。Longhorn非対応アプリも、描画結果をテクスチャとして取り込んで処理する	プレゼンテーション要素を構造化データにしたVisual Treeは処理キューに入れられ、無駄な処理などを省く複合化処理を施された後、UCEに引き渡される。UCEには各オブジェクトを合成する際、アニメーションさせたりオーディオ要素との同期を図る機能もある

　そしてAvalonでは、この間をネットワークにすることも可能だ。いわゆるリモートデスクトップ(あるいはターミナルサービス)を実現するための仕組みが、ジェネリックなグラフィック描画のアーキテクチャに取り込まれているのである。

　これまで、リモートデスクトップはWindows Terminalを動かすためのRDP(Remote Desktop Protocol)で実現してきたが、RDPはGDIレベルの描画しかサポートしないため、動画ストリームを効率的にネットワーク透過で扱えなかった。この問題を解決するために、MicrosoftはRDPとは別チャネルで映像ストリームを流す手法を実装する。しかしAvalonでは、そうした応急措置的な対応ではなく、すべてのプレゼンテーション要素をネットワーク透過でレンダリング可能になる。リモートとローカルの差は、最後のUCEにVisual Tree(とそのアップデート差分)を引き渡す帯域幅の違いだけになる。

　また、必要とする帯域も大幅に少なくなり、リモート端末上で派手なアニメーションや3D要素のレンダリングを行なうことも(端末のグラフィック機能・パフォーマンスによっては)可能になる。たとえばMedia Centerの機能をリモートで利用するMedia Center Extender(MCX)という製品が今年の後半に登場する見込みだが、Longhorn世代のMCXではAvalonの機能をフルに使ったリッチユーザーインターフェイスを、PCを置かないリビングなどで実現できるようになるだろう。

□WinHEC 2004のホームページ(英文)
http://www.microsoft.com/whdc/winhec/

□バックナンバー

(2004年5月6日)

[Text by 本田雅一]