ネットワークがどんな場所でも使えるようになってくると、自分の使っているコンピュータを直接利用する必要はないんじゃないか? という疑問が出てくるものだ。同じような疑問は、遙か昔のエンジニアも同じように持っていた。初期のコンピュータは高価すぎて、ユーザーが1人で独占することなど許されなかったからだ。

　ユーザーインターフェイスを含むI/Oの部分と、コンピュータプログラムが動作するハードウェアは、必ずしも同じ箱の中に入っている必要はない。昔からコンピュータに慣れ親しんでいる人なら、むしろその考え方の方が、ずっと一般的だと思うだろう。

　しかしリッチなグラフィック表示だけでなく、動画や3Dといった表現手法が一般的になってくると、ネットワークを通じてコンピュータを快適に利用する事が難しくなってきた。

　WindowsのリモートデスクトップやTerminal Service、VNCプロジェクトやVNCをベースにしたMac OS Xのリモート操作機能などは、いずれもかなり高速に動いてはくれるが、とても“手元にある端末の中でプログラムが動いているように”などとは紹介できないパフォーマンスしか出ない。

　それでも充分という用途は、もちろんいくつも存在するが、ユーザーがリモートであることを気にせずに使えるようになるには、もっと多くの改良が必要だった。しかし、Windows 7ではその問題が解決されている。リモートデスクトップのパフォーマンスが大きく改善されており、それによってこの機能を活用する場面が大幅に増えるはずだ。

　パフォーマンスが充分に改善され、機能制限も少なくなれば、家庭内を移動しながら、あるいはWiMAXやWiFiスポット、3Gネットワークを通じてリモートで1つのデスクトップPCを使うといった使い方ができないものだろうか? とは誰もが考えることだろう。では、実際の使い勝手は? ということで、試してみることにした。

　マウス操作やキーボード操作に関してはネットワーク経由で利用していても、パフォーマンスに大きな問題を感じることはない。問題は画面表示にある。

　ネットワークを通じた画面表示を高速に行なうソフトウェアの開発は、これまでにも実験的なものをいくつか見たことがある。たとえばIntelはWindowsのディスプレイドライバに仮想ドライバを挟み、ネットワークを通じてGPUへの通信を行なう技術のデモを行なったことがある。GPUに与える指示やデータを圧縮してネットワークで搬送すれば、最低限のデータ転送量で結果を得ることが可能だ。

　Intelが見せていたのはドライバレベルでのテクニックだが、Microsoftは同様の仕組みをOSがサポートするリモート操作のプロトコルに導入した。これが2008年秋にMicrosoftが開催したソフトウェア開発者向け会議のProfessional Developers Conference 2008で詳細が紹介された「RDP 7.0」というプロトコルだった。

　RDPはRemote Desktop Protocolの略で、国際標準のT.128というプロトコルをベースにしたインタラクション(操作指示などの交換)に、Windowsのアプリケーション向けのグラフィック描画や音声再生機能などを拡張したものだ。その7.0はWindows 7やWindows 7とほぼ同時期にリリースが予定されているWindows Server 2008 R2に搭載されるRDPの最新バージョンだ。

　RDP 7.0の最大の特徴は、ウィンドウのクライアント領域(各プログラムが描画するエリア。ウィンドウ枠などはOS自身が重なりなどを考慮して描画する)を含め、すべての描画指示をネットワークを通じて行ない、実際の描画は端末側のGPUやCPUで行なう事だ。

　従来のRDPは一部描画指示のコマンド以外、基本的にサーバーとなる側(ソフトウェアが実際に実行されているコンピュータ)が描画を行ない、その結果を端末側に送る仕組みだった。差分更新や圧縮などを巧妙に行なうことで、かなり高速に動作はするが動画再生は遅く、また3Dグラフィックス処理をサーバー側でソフトウェアレンダリングして結果を画像で転送する必要があるなど、不得手なアプリケーションもある。

　下の図はMicrosoftがPDCにおいてRDP 7.0の説明に用いたブロック図を日本語化したものだ。RDP 7.0ではDirect3DやDirectDraw、動画や音声の再生などの操作をコマンドストリームへと変換する。音声や動画、グラフィック描画などを統合し、1つのメディアストリームにする仕組みというのは、実はWindows Vistaから導入されているWindows Presentation Foundation(WPF)のアーキテクチャと同じだ。

RDP 7.0の動作アーキテクチャ

　MicrosoftはWPFとRDPのコマンドストリームが同じだとは言っていないが、考え方としては同様のものだと考えられる。さらに、伝統的なGDI(Windowsのグラフィック描画ライブラリ)操作は一部をサーバー側でレンダリング、一部を描画コマンドに変換し、前述のコマンドストリームと重畳して1つのストリームとし、それをTCP/IPネットワークを通じてRDP 7.0クライアントに送る。

　こうすることで動画をはじめとするメディアストリームやDirectXを用いたアプリケーションなども、クライアントプログラムを動かすコンピュータの能力次第で高速に実行できるようになる上、一般的なグラフィック操作の速度も高速化するとMicrosoftは主張している。Windows Vistaのリモートデスクトップ比で15%、Windows XP比では40%の性能アップだ。

　論より証拠で、現在配布されているWindows 7でも、RDP 7.0の効果を試してみた。読者の皆さんも、もし手元でWindows 7のβ版を動かしているならば、実験してみるといいだろう。

　Microsoftは昨年のPDCにおいて、RDP 7.0を用いて3Dゲームもある程度は動作したり、動画再生が行なえるところを見せた(もちろん、それは高速なLANで接続された環境である)。デモ映像だけを見ると既存のリモート操作環境とは一線を画していると感じたが、実際にβ版でどこまで動くかは判らない。

　まず、一般的なアプリケーション、WebブラウザやOffice、メーラーなどから。これらのアプリケーションはRDPによる接続はVNCよりも実用性は高く、LAN環境やWi-Fiスポットからのアクセスならば充分に使い物になっていた。

　よって、当然ながらRDP 7.0でも良好な結果が得られると思ったのだが、バグなのかWindows 7に付属するディスプレイドライバのパフォーマンスが悪いのかは判らないが、Aeroをオンにした時の作業性が悪い。

　Aeroの表示は完璧に行なわれる。前出の図にあるようにDWMが直接コマンドストリームを生成してネットワークを通じてデスクトップの描画を行なわせることもあって、描画の更新そのものは高速でストレスはない。Aeroの設定そのものは、Windows Vista同士でリモートデスクトップ接続をさせた場合にも可能だったが、パフォーマンス的にはRDP 7.0の方が上だ。

Aeroによるデスクトップ描画

　ところがマウスカーソルのレスポンスが悪い(マウスカーソル描画のフレームレートが極端に低い)という問題にぶち当たった。マウスカーソルのレスポンスはGPUコマンドによるデスクトップ描画を行なわない(Aeroではないデスクトップテーマ)を選択すると、全く問題なく反応する。この時のデスクトップ描画はRDPDD(RDPディスプレイドライバ)を通じて行なうので、問題はメディアレンダリングのためのコマンドストリーム生成か、あるいはRDPクライアント側にあると思われる。

　ということで、最初から躓いてしまったが、マウスカーソルの描画以外に問題は無いため、正式版では改善されている可能性が高いだろう。Aeroによるデスクトップの動きそのものは、とてもリモートとは思えないもので、802.11n無線LANの端末で普通に使うことができた。マウスカーソルの件は、念のためフィードバックフォームからMicrosoftに報告を入れてある。

　次に動画再生。再度、RDP 7.0のブロック図を見て欲しい。RDP 7.0で改善される動画再生は、Windowsの動画再生システムを通る場合のみ高速化される。Windows Media Playerでの再生はDirectShowを通じて行なわれるのできちんと再生できる。

　試しにWindows Mediaに変換した動画を480p、720p、1080pと順に再生させてみたが、1080pで若干のコマ落ちを確認できたものの、ほぼローカルで再生させる場合と変わらない表示となった。480pをフルスクリーンに引き延ばしてもコマ落ちは起きない。メディアストリームを受け、クライアント側で引き延ばして表示するからだ。

　このまま順調に進むと思われたが、Windows Media Video以外のコーデックで圧縮された動画(MP4拡張子)をWindows Media Playerで再生したところ、今度は盛大なコマ落ちが発生した。もちろん、DirectShowを用いないFlashムービーも同様にコマ落ちが起きる。

　歓び半分、残念さ半分といったところか。いや、ビジネスクライアントとしてならともかく、コンシューマユーザーからすると落胆の方が大きいかもしれない。とはいえ、こちらも出荷直前版や製品版では治っている可能性もある。アップデートが行なわれた際に再検証してみることにしよう。

　Direct3Dアプリケーションについても情報を知りたいという読者もいるだろう。本格的なゲームとなるとリモートでゲームを遊ぶのは難しい上、通常はクライアントとなる側の方がパフォーマンスが低いため、あまり大規模な3Dアプリケーションを動かしても意味がないと思うが、一応、いくつかのゲームやベンチマーク機能付きデモを動かしてみた。

　しかし、DirectX 9世代のアプリケーションは初期化に失敗し、うまく動作させることができなかった。DirectX 10世代のアプリケーションは動いたのだが、どうもネットワーク経由でDirect3Dのコマンドストリームを送っているようには見えない。ローカルで動かした場合も遅いのだが、それでも毎秒10～15フレームぐらいは出ているが、リモートでは2～3フレームしか出ない。

Direct3Dによる3D描画

　RDP 7.0のアーキテクチャでは、DWMとDirectXではコマンドストリームの生成場所が異なるので、Direct3DのコマンドストリームをRDPでディスパッチする部分に問題があるのか、あるいは何らかの原因でコマンドではなくソフトウェアレンダリングの結果をグラフィックで送信しているか、あるいはまだサポートされていないものと思われる。

　とはいえ、リモートデスクトップの目的を考えれば、3D描画はAeroのデスクトップがリモートで完璧に動くだけでも、個人的には充分な手応えを感じた。

　次にWAN経由での操作性についても試した。

　Windows 7をインストールしたThinkPad X300で、WiFiスポット、WiMAX、3Gネットワーク(ドコモのネットワークを使ったb-mobile 3G)と環境を変えながら自宅のデスクトップPCに接続。なお、筆者宅はNTT東日本フレッツ光マンションタイプ(VDSL)で、ISPは@nifty、上り65Mbps/下り28Mbps(スピードテストでの実測値)という環境で使っている。

　結論から言えば、Webブラウザ、メールクライアントなどの操作に関しては、WANにおいて確実にスピードアップしている。前述したようにAeroを有効にした際のマウスカーソルの動きがぎこちないものの、それを除けばWiFiスポットでは32bitカラーの壁紙付きでも、充分に実用になる。

　WiMAXの場合、若干、操作に対するレスポンスが鈍ることはあったものの、こちらも画面書き換えにぎこちなさはない。壁紙をオフにすれば、さらに快適性が増す。3Gネットワーク時には、ネットワークの混み具合でレスポンスが低下することはあるものの、こちらも壁紙オフで実用的になった。

　さらに動画再生に関しても、RDP 7.0で高速化される動画タイプで、なおかつ480p以下の解像度ならば、ネットワークの混み具合でスムーズさを失うことはあっても、決定的に使い物にならない状況には陥らない。従来のリモートデスクトップに比べると、明らかに“普通に使える”感覚で操作できる。

　これだけ改善されていれば、これまでとは違う使い方をしたくなるというものだ。モバイル環境でのインターネット接続が高速化していることを考えれば、必要最低限のアプリケーションはローカルで動かしつつ、積極的にリモートで自宅のコンピュータを活用するといったこともできるだろう。“β”が取れたWindows 7で、どこまでβ版での問題が解決しているのか興味深い。

　なお、RDP 7.0に対応するサーバーとなるのはWindows 7、Windows Server 2008 R2のみで、クライアントプログラムもこの2つのOSにしか提供されていない。しかし、Windows XPとVistaに対してはRDP 7.0に対応するクライアントを提供することを検討している、とMicrosoftは話している(必ず提供すると約束しているわけではない)。

　また、現在はRDP 6.1対応版をMac OS X用に配布しているMicrosoftだが、そのRDP 7.0対応版を開発するかどうかに関しては、まだ議論されていない段階とのことだ。Mac OS XとWindows 7では描画エンジンのアーキテクチャが異なるため、メディアコマンドのストリーム処理による高速化は期待できないかもしれないが、GDI描画の高速化(RDP 7.0では圧縮率の向上などが図られているとのこと)のために対応版がリリースされる可能性はある。

　オープンソースのプロジェクトには、RDPクライアントを開発するものがあり、その一部は機能を整備して市販もされているが、Mac OS X用RDPクライアントと同様にメディアコマンドストリームの処理が問題となるかもしれない。