Windows 7 のグラフィックスの変更点を整理する
(2009年2月9日追記)
『GDI アクセラレーションについて整理する - NyaRuRu の日記』にて，公開された WDK のドキュメントを元に追加の考察を行っています．
基本的にはプレビュー版のWindows 7においても、日本語を利用することは可能だった。しかし、1つだけ大きな問題がある。それはAero Glassと日本語表示が必ずしも共存しないことだ。
図5はおなじみの日本語エディタ、秀丸をWindows 7のプレビュー版で起動したところだ。見れば分かるように、メニューの表示がおかしい。「その他」のメニューの途中から日本語表示が普通なのは、まだカーソルがこのエリアまで至っていないことを意味している。カーソルを下に持って行くと、それに連れてメニュー上部のように日本語表示がおかしくなっていく。なお、この画面はBlue Badgeを適用した後のものだが、この現象はBlue Badgeの適用如何を問わない。こうした日本語表示の乱れは、メニューだけでなく、たとえばアプリケーションをインストールする際のライセンス条項等のダイアローグ、あるいはIMEでの変換中でも見られる。
さすがにこれでは、日本語が使えなくもない、と言っても使う気にはなれない。が、これを修正する手段が存在する。それはAero Glassを無効にし、Aero Basicにすることだ。図6は、図5のシステムのままAero Basicに切り替えたものだが、日本語の表示は完全に復旧している。通知領域にATOKのアイコンが見えるが、もちろんATOKの動作(この例はATOK2007だが)もほぼ問題ない。
ただ、Aero Basicにしてしまうと、起動中のアプリケーションのサムネイルが表示されなくなる(図7)など、Windows 7の魔法(新UI)が少なからず解けてしまう。これはこれで微妙な感じだが、現状ではやむを得ない。
どうして日本語の表示がうまくいかないのか。ハッキリと言えることは、フォントそのものはシステム中に存在するし、そのフォントを正しく読み出すこともできている、ということだ。そうでなくては、Aero Basicでも日本語が表示できなくなる。おそらく問題があるのはフォントのレンダリングとリフレッシュだろう。
Windows 7 の Pre-Beta はまだ触っていませんが，日本語表示が乱れるケースがあるというのは初めて聞く話でした．確かに面白い話ではあります．が，この後に続く考察はちょっと危ういように感じられました．記事中には GDI のハードウェアアクセラレーションに関しても混乱も見られます．
情報を整理する意味で，以下に私が知る範囲での Windows 7 のグラフィックスの変更点についてここでまとめておきます．
Windows Vista までのドライバモデル
まずはおさらいから．
Windows Vista では，新しいグラフィックスドライバモデルが導入されました．このドライバモデルは，WDDM (Windows Display Driver Model) と呼ばれています．と同時に，Windows XP 以前のグラフィックスドライバモデルは XPDM *1 と呼ばれるようになり，WDDM と XPDM の間の区別が行われるようになりました．
Windows Vista / Windows Server 2008 世代のカーネル (6.0 系) は，実際には WDDM と XPDM どちらとも組み合わせて使うことができます (排他利用)．ただし，Windows Vista ロゴと絡めた Microsoft のブランディング戦略から，ほとんどのベンダは事実上 WDDM の使用を強制されています．一方で，サーバ製品での XPDM の延命は続いており，後述するように Windows Server 2008 R2 世代においても XPDM は選択肢のひとつとして残るようです．
WDDM は以下のようなコンポーネント間の依存関係をもたらします．
- Direct3D 9Ex や Direct3D 10 のプログラミングモデルは WDDM に強く依存しています．これらの世代の Direct3D の機能であるプロセス間共有サーフェスや，デバイスロストの排除等は，ドライバモデルの変更によって初めて実現されています．これは，Direct3D 10 等を Windows XP にバックポート出来なくなった原因でもあります．
- Windows Vista の新しいウィンドウマネージャである DWM (Desktop Window Manager) は，Direct3D 9Ex の機能を前提に設計されています．特にプロセス間共有サーフェスとデバイスロストの排除は，DWM の設計を容易にし，また DWM の安定性と高速化に大きく寄与しています．
- 一方で，WPF (Windows Presentation Foundation) が要求するコンポーネントは，.NET Framework 3.5 SP1 の段階でも，高々 Direct3D 9 Shader Model 2.0 までとなっています．このことは，WPF がプログラマに公開している機能が Shader Model 2.0 までに限定されている原因となっています．ただし，WPF の描画エンジン自体は Direct3D 9Ex をサポートしており，Direct3D 9Ex の新機能が GPU を使ったテキストレンダリングとして活用されています．また，D3DImage 使用時にも WDDM の恩恵を受けられます(Direct3D9 および WPF の相互運用性のパフォーマンスに関する考慮事項)．
さて，GDI のハードウェアアクセラレーションについても整理しておきましょう．XPDM までのグラフィックスドライバは，Win32 GDI API とほぼ一対一に対応するドライバファンクションを公開していました (『Windows Vista での GDI/GDI+ 描画 - NyaRuRuの日記』)．これらのドライバファンクションは，必須なもの，条件付きで必須ななもの，オプショナルなものの 3 種類に大別されており，グラフィックスチップのベンダは必要なドライバファンクションを実装することで GDI 命令を受け取ることができました．
ドライバによって実装されないファンクションは，OS によってエミュレートされます．このエミュレーションは，他のドライバファンクションを組み合わせて実現したり，いったんシステムメモリに読み出して CPU でエミュレートしたりと様々です．XPDM の時代から，必ずしも全ての GDI API がハードウェア処理されていなかったことに注意してください．特に，アルファチャネルを利用した合成処理はほとんどのケースでソフトウェア処理されていたと考えられます．
この状況は Windows Vista でさらに加速します．Windows Vista で導入された WDDM (WDDM v1) には，GDI のドライバファンクションが存在しませんでした．つまり，アプリケーションからの GDI API 呼び出しがドライバに渡されるルートそのものが無くなったことになります．これが，「Windows Vista で GDI アクセラレーションが廃止された」と言われる理由です．
なお，従来の DirectDraw オーバーレイをサポートするためのファンクションは，WDDM でも残されています (CreateOverlay)．ただし フルスクリーンモードの Direct3D アプリケーションと DirectDraw 由来のオーバーレイの間に互換性がないのは変わらず，デスクトップコンポジションとオーバーレイは両立しません．WDDM v1.1 では，新しい DDI の追加という形で DWM と共存可能なオーバーレイを導入するようです．
また XPDM で動作する Windows Vista は，従来通りドライバの公開する GDI ファンクションを利用します．
Windows 7 でのドライバモデル
Windows 7 / Windows Server 2008 R2 (カーネル 6.1 系) では，WDDM のバージョンが上がり，WDDM v1.1 となります．Windows Vista 世代の WDDM は WDDM v1 と呼ばれるようになります．
OS としての Windows 7 / Windows Server 2008 R2 は，WDDM v1.1, WDDM v1, XPDM の 3 種類に対応します．ただし Windows 7 をインストールして出荷される PC は，Vista 同様ロゴプログラムによって WDDM v1.1 が強く推進されていくことでしょう．一方で，Server Logo では XPDM は依然として許される方向にあるようです．
Phasing Out XPDM
WDDM v1.1 の新機能はいくつかありますが，ここで重要なのは
- DXGI フォーマットでの BGRA フォーマットサポートの義務化したこと
- GDI ハードウェアアクセラレーションをサポート可能にしたこと
のふたつです．後者は，以前公開されていた Guidelines for Graphics in Windows 7 ではオプショナルな要求に読めますが，ロゴプログラムと絡めて恐らく事実上サポートが必須という方向になるでしょう．なお，上述のように Ultra Mobile PC (UMPCs) は依然として WDDM v1 とともに出荷が認められていることに注意してください．
さて，それでは何故 Windows 7 で GDI ハードウェアアクセラレーションが復活したのかを考えてみることにしましょう．
Windows Vista 世代の DWM の仕組み
- GDI アプリケーションでは，トップレベルウィンドウのクライアント領域サイズ × 4 bytes の共有メモリが，フレームバッファとして各アプリケーションのメモリ空間に確保される．(『DWM による描画の現場を押さえる - NyaRuRuの日記』)
- ウィンドウへの任意の GDI 描画は，ソフトウェアによって先ほどのフレームバッファに描き込まれる (GDI Redirection)．フォーマット変換も同時に行われる．(歴史的に DDB への処理が BGRA フォーマットを仮定していた一方で，Direct3D では ARGB フォーマットが主流なため，どこかでフォーマット変換が必要になる)
- Direct3D アプリケーションでは，Direct3D Runtime によって必要なサイズの隠しサーフェスが作られ，バックバッファから (フロントバッファへ) の Present は，この隠しサーフェスにリダイレクトされる (Direct3D Redirection)．これは Direct3D Runtime によって自動的に行われる．
- 共有メモリを通じて，各アプリケーションのクライアント領域イメージが dwm.exe のメモリ空間にマップされる (ARGB フォーマット)
- DWM は各アプリケーションのクライアント領域イメージから Direct3D サーフェスを作成する
- DWM はプロセス間共有サーフェスを利用して Direct3D アプリケーションの出力先に当たる隠しサーフェスを取得する．
- DWM はウィンドウの位置関係に基づいてデスクトップを描画する．(Flip を用いた画面更新を行い，ティアリングを回避する)
Windows Vista 世代の DWM の仕組みでは，GDI アプリケーションについて，システムメモリとドライバリソース (Direct3D サーフェス) に全く同じ画像が二重に保持されていることになります．
Windows 7 世代の (WDDM v1.1 フル機能サポート時の) DWM の仕組み (予想)
- GDI アプリケーションでは，トップレベルウィンドウのクライアント領域サイズと等しい BGRA フォーマットの Direct3D サーフェスが作成される．
- 何らかの形で GDI によるクライアント領域描画と BGRA サーフェスを結びつけ，それをドライバで処理させる．(例えば Direct3D サーフェスへの GetDC を利用？)
つまり，ドライバで管理されるサーフェスでありながら，GDI でも読み描きでき，かつ BGRA フォーマットの Direct3D Surface (DXGI Surface) としても使えるデュアルインターフェイスなものを可能にするのが WDDM v1.1 なんじゃないかと適当に予想しています．(Windows 7 に対応した WDK が入手できたら，もう少し状況がはっきりするでしょう → 公開されたので調べてみた『GDI アクセラレーションについて整理する - NyaRuRu の日記』)
このサーフェスはドライバによって管理されているため，GDI 描画はドライバによって処理される必要があります．(これはつまり，ドライバが処理できさえすれば良いわけで，必ずしも専用チップによる最適化は必要ないのかも知れません)
WDDM v1.1 によって (ロゴ目当ての場合に) 要求される GDI 処理には，次のようなものがあります．
WDDM v1.1 Requirement
GDI Hardware Acceleration Interfaces
- Support for common 2D operations:
- Drawing operations:
- BitBlt, ColorFill, AlphaBlend etc
- Cleartype font support
- Support for common ROPs
- Support for Linear Heaps
- Texture size of 8K X 8K
こうして，Direct3D サーフェスとシステムメモリの二重確保は不要になり，保持するデータはドライバリソースのみで良くなるというのが Windows 7 の目指す世界のようです (もちろんドライバがデータを保持しておくための領域は必要で，これには専用の VRAM または UMA によるシステムメモリが消費されます)．
WinHEC 2008 初日のキーノートスピーチで出てくる「ダブルバッファは取り除かれた」という言葉は，このことを意味しているものと考えられます．
JON DEVAAN: Right, that's great. And so we have a little over 70 windows on both systems, yet preserve the whole user experience on Windows 7, and it's basically because we're letting the video card do its job in managing the memory for those windows. We don't have to manage it double in system memory.
MIKE ANGIULO: That's right. We had some double buffering that was going on, and all of that has been eliminated. So even though we're using less memory we actually have a faster graphics system going on Win 7. So let me show you on this machine, I'm going to close down all these Windows, which is actually pretty easy now with the new Windows 7 taskbar, you can close entire groups at a time.
余談ですが，このキーノートを伝えている山田祥平氏の記事にも誤りがあります．
ステージでは引き続き、スクリプトによって大量のウィンドウを開く拷問テストのデモが行なわれた。Vistaと7で多くのウィンドウを開いた様子が比較され、クラッシュしてしまうVistaに対して、7はメモリの使い方の改良などでビクともしない堅牢性を実現している。
このテスト，公開されているキーノート動画 の 15:42 あたりから始まりますが，動画を見る限り確かにウィンドウを大量に開くことで Vista のデスクトップコンポジションはオフになっています．しかし，どのアプリケーションもクラッシュしているようには見えません．
また，デスクトップコンポジションの停止は『Windows Vista Rules for Enabling Windows Aero With Guidelines for Troubleshooting - NyaRuRuの日記』で紹介したとおりの挙動です．Vista で実装された安全装置はきちんと機能していたことになります．
各論 1 : なぜ氏の Windows 7 環境で日本語表示に問題が発生したか？
ひとつの仮説として，元麻布氏が使っていた環境が WDDM v1.1 で，かつドライバが GDI アクセラレーションに対応していて，しかもその実装に問題があった可能性があります．
上に見てきたように，WDDM v1.1 環境では GDI 命令がドライバによって処理されるケースがあります．Microsoft 提供の DIB エンジンによって常に同じ描画結果が得られていた WDDM v1 とは異なり，再び GDI 描画の結果が環境によって異なりうる時代に戻ったわけです．
もし日本語表示の問題が，ドライバの GDI 実装にまつわるものであった場合，「GDI/GDI+に対する直接的なハードウェアアクセラレーションもなくなる」と伝えてしまった記事としては二重の意味で皮肉な結果と言えるかも知れません．つまり，GDI アクセラレーションが復活したからこその不具合というわけです．
各論 2 : DirectWrite に関して
さて日本語表示の問題に話を戻すと、このWindows 7で追加されるDirectWriteが、まだ開発途上であることが原因なのではないか、という気がする。DirectWriteでは、従来のClearType技術に加え、Y軸方向のアンチエイリアスがサポートされ、フォント表示がさらに改善される見込みだ。しかし、同時にこれはフォントレンダラが変更されるということであり、このBuild 6801のDirectWriteはマルチバイト言語への対応が十分ではないのだろう。図10で示したように、DirectWriteはDirectX/DWMの上に成り立っており、Aero Glassを無効にすることで、フォントレンダラの新しい機能も無効になるのではないかと思う。
GPU を使ったフォントレンダリングについては『GPU を利用したテキストレンダリング - NyaRuRuの日記]』で紹介したように WinHEC 2004 の頃から成果が示されていて，実際 WPF では Y 方向アンチエイリアスを既に実装済みです．DirectWrite はこれらの技術の延長線上にあると考えられます．
もっとも，MUI が不安というのは確かにありますけどね (This is not yet my take on DirectWrite - Sorting it all Out)．
個人的には，そもそも Windows 7 RTM 段階で DirectWrite が既存の GDI アプリケーションの高速化に使われるという話自体が怪しいんじゃないかと思っています．
あと DirectWrite は DWM に直接の依存関係を持っていません．
各論 3 : そもそも Windows 7 でなにが高速化するの？
これは結構謎です．
WinHEC 2008 のメッセージを見る限り，GDI ハードウェアアクセラレーションは，一貫して「メモリ負荷削減のため」と言われており，「高速化のため」という表現は見つけられませんでした．GDI ハードウェアアクセラレーションの復活が，Windows XP から Vista で大幅に低下した GDI ベンチマークを元に戻すためと考えるのは，現時点ではかなり慎重になった方がよいように思います．
もちろん，サーフェスに対する GetDC がハードウェア処理されるのはありがたいと言えばありがたい話で，Direct3D と GDI の相互運用性の向上というのも恐らくこの辺りのことを言っているのではないかと想像しています．BGRA サーフェスのサポートは，ある意味で DDB の進化形かもしれません．
また，Direct2D / DirectWrite に関しても，既存アプリケーションの高速化に使われるかどうかはまだはっきりとした情報を掴んでいません．個人的には，Windows 7 RTM の段階での Direct2D / DirectWrite は単なる顔見せじゃないかと予想しているのですが，どうなんでしょうね？
おすすめ参考資料
GDI Redirection/Direct3D Redirection
- Redirecting GDI, DirectX, and WPF applications - Greg Schechter's Blog
- The role of the Windows Display Driver Model in the DWM - Greg Schechter's Blog
WinHEC 2008 のグラフィックス関連セッションより
PDC 2008 のグラフィックス関連セッションより
川西さんの PDC 2008 リポート
Direct2D 開発者 blog
修正履歴
- 2008年11月26日
- 初版
- 2008年11月27日
- DWM 環境下での Direct3D Redirection の説明を修正 (実際にはバックバッファが共有されるのではなく，その出力先の隠しサーフェスが共有される)
- Greg Schechter の記事を参考資料に追加
- 2009年2月9日
- 『GDI アクセラレーションについて整理する - NyaRuRu の日記』へのリンクを追加．
- WDK ドキュメント "GDI Hardware Acceleration" へのリンクを追加．
*1:実際には XPDM は Windows 2000 で導入されたドライバモデルなので，XPDM という呼び名は多少政治的な趣もある
