JP5027899B2 - 遠隔の表示部へ伝送するためにフレームバッファをコピーする方法及びシステム - Google Patents

Description

関連出願の相互参照

本願は、本願と同日出願の米国特許出願、名称「遠隔の表示部へ選択的に伝送するために描画プリミティブを特定する方法及びシステム」（代理人整理番号：Ａ３３５）に関連し、当該内容は、参照することにより本願に組み込まれる。

現在のオペレーティングシステムは、通常、モニタなどの表示部に描画をレンダリングするために、アプリケーションがアクセスする画像描画インタフェース層を含んでいる。画像描画インタフェース層により、アプリケーションに描画用アプリケーションプログラミングインタフェース（ＡＰＩ）が提供され、かかるアプリケーションを用いて、その後ビデオアダプタドライバに提供する描画コマンド一式へ、描画要求を変換する。ビデオアダプタドライバは順に、描画コマンドを受信し、ビデオアダプタ固有の描画プリミティブへ変換し、ビデオアダプタ（例えば、グラフィックカード、統合ビデオチップセット）へ転送する。ビデオアダプタは、ビデオ信号を発生させ連結された外部表示部へ伝送するのに使用される、ビデオアダプタのフレームバッファを更新するために、描画プリミティブを受信し直ちに処理するか、又は代わりに、順次実行するために、先入れ先出し（ＦＩＦＯ）バッファに描画プリミティブを記憶する。かかる画像描画インタフェース層の一例には、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓオペレーティングシステム（ＯＳ）のグラフィカルデバイスインタフェース（ＧＤＩ）があり、Ｗｉｎｄｏｗｓ ＯＳを介してアクセス可能な、ユーザレベル及びカーネルレベルで動的にリンクされる多数のライブラリとして実装されている。

サーバベースコンピューティング（ＳＢＣ）や仮想デスクトップインフラストラクチャ（ＶＤＩ）などの技術向上により、組織は従来のパーソナルコンピュータ（ＰＣ）を、データセンタの遠隔のデスクトップサーバ（又はその上で稼動する仮想マシン）上でホストされるデスクトップのインスタンスと交換することができるようになる。ユーザの端末にインストールされるシンクライアントアプリケーションは、ユーザ端末の表示部上でレンダリングするために、オペレーティングシステムセッションのグラフィカルユーザインタフェースを伝送する遠隔のデスクトップサーバに接続する。かかる遠隔のデスクトップサーバシステムの一例には、遠隔のデスクトップサーバからクライアントへフレームバッファ（画面上に表示されるピクセルごとの値を含む）を伝送するために、リモートフレームバッファ（ＲＦＢ）プロトコルを利用する、バーチャルコンピューティングネットワーク（ＶＮＣ）がある。シンクライアントアプリケーションへ伝送されるグラフィカルユーザインタフェースに関連する表示データの量を減らすために、遠隔のデスクトップサーバは、フレームバッファの以前の状態を反映する、フレームバッファの第２のコピーを持ち続けてもよい。表示データの差異を特定し、符号化して（ネットワーク伝送帯域を減らして）、続いてシンクライアントアプリケーションへつながるネットワーク上へと伝送するために、この第２のコピーによって、遠隔のデスクトップサーバは、フレームバッファの以前の状態及び現在の状態を比較することが可能となる。

しかしながら、フレームバッファをかかる二次フレームバッファへコピーするコンピュータのオーバーヘッドにより、遠隔のデスクトップサーバの性能は著しく低下する可能性がある。例えば、１秒間６０回の速度で、解像度１９２０×１２００、色深度１ピクセルあたり２４ビットをサポートするフレームバッファから二次フレームバッファへ、継続的にデータをコピーするには、３．０９Ｇｂ／ｓ（ギガビット毎秒）以上をコピーすることが必要とされるであろう。

表示データは、遠隔のクライアント端末へ伝送する際に、帯域幅要件を低減するために操作される。一実施形態では、サーバは表示データを記憶する一次フレームバッファと、遠隔のクライアント端末に表示データを伝送するために二次フレームバッファを使用する表示エンコーダと、を有する。一次フレームバッファの表示データへの更新を取り囲むバウンディングボックスは特定され、データ構造のバウンディングボックスに対応する入力は印を付けられる。データ構造の各入力は、一次フレームバッファの異なる領域に対応し、印の付いた入力は更にバウンディングボックスの領域に対応する。一次フレームバッファの領域は、二次フレームバッファの対応する領域と比較され、差異を有し比較される領域のためだけに、印の付いた入力を包含する切り取られたデータ構造は、表示エンコーダへ発行される。このように、表示エンコーダは、切り取られたデータ構造内にある印の付いた入力に対応する二次フレームバッファの領域の更新される表示データを伝送することができる。

一実施形態では、その後の遠隔の端末への表示データの伝送に対して準備するために、発行するステップの後、データ構造の入力は消去される。別の実施形態では、比較するステップが差異を示すそれらの領域が、二次フレームバッファに更新される表示データを提供するために、一次フレームバッファから二次フレームバッファの対応する領域へコピーされる。

本発明の一実施形態に従う、遠隔のデスクトップサーバのブロック図を示す。 本発明の一実施形態に従う、「ｂｌｉｔｍａｐ（ブリットマップ）」データ構造を示す。 本発明の一実施形態に従う、第２のブリットマップデータ構造を示す。 本発明の一実施形態に従う、アプリケーションからの描画要求をビデオアダプタへ伝送するステップを示すフロー図。 本発明の一実施形態に従う、ビデオアダプタからのフレームバッファデータを表示エンコーダへ伝送するステップを示すフロー図。 本発明の一実施形態に従う、ブリットマップデータ構造を切り取るステップを示すフロー図。 本発明の一実施形態に従い、ブリットマップデータ構造を切り取る視覚的な例を示す。

図１は、本発明の１つ以上の実施形態に従う、遠隔のデスクトップサーバのブロック図を示す。遠隔のデスクトップサーバ１００は、デスクトップ、ノートパソコン、又はｘ８６アーキテクチャプラットフォームなどのサーバ級のハードウェアプラットフォーム１０２に構成してもよい。かかるハードウェアプラットフォームはＣＰＵ１０４、ＲＡＭ１０６、ネットワークアダプタ１０８（ＮＩＣ１０８）、ハードドライブ１１０、及び限定するものではないがマウスやキーボードなどその他Ｉ／Ｏ装置（図１には図示せず）を含んでもよい。

以下、ハイパーバイザ１２４とも称される仮想化ソフトウェア層は、ハードウェアプラットフォーム１０２の上面に設置される。ハイパーバイザ１２４は仮想マシン実行空間１２６を支え、その内部では複数の仮想マシン（ＶＭ１２８_１〜１２８_Ｎ）を同時にインスタンス化し実行してもよい。一実施形態において、各ＶＭ１２８_１〜１２８_Ｎは異なるクライアント端末から遠隔で接続される異なるユーザをサポートする。ＶＭ１２８_１〜１２８_Ｎの各々に対して、ハイパーバイザ１２４は、ＣＰＵ１３２、ＲＡＭ１３４、ハードドライブ１３６、ＮＩＣ１３８、及びビデオアダプタ１４０などのソフトウェアに実装されるエミュレートされたハードウェアを含む、対応する仮想ハードウェアプラットフォーム（即ち、仮想ハードウェアプラットフォーム１３０_１〜１３０_Ｎ）を管理する。エミュレートされたビデオアダプタ１４０は、ビデオ表示部（即ち「フレーム」）が最新情報に更新される起点となるピクセル値のバッファを留めるビデオアダプタ１４０によって使用される、メモリの一部分であるフレームバッファ１４２と、フレームバッファ１４２を更新するために使用される描画プリミティブの一覧を留めるビデオアダプタ１４０によって使用される、メモリの一部分である先入れ先出し（ＦＩＦＯ）バッファ１４４とを割り当てて保持する。一実施形態では、ＦＩＦＯバッファ１４４は、ビデオアダプタ１４０とビデオアダプタドライバ１５４との間でアクセスされ共有される共有メモリバッファである。

仮想ハードウェアプラットフォーム１３０_１は、ＶＭ１２８_１などのインスタンスを作成される仮想マシンに対し、アプリケーション１４８を実行するために、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）、Ｓｏｌａｒｉｓ（登録商標）ｘ８６、ＮｅｔＷａｒｅ、ＦｒｅｅＢＳＤなど、ｘ８６をサポートする任意のオペレーティングシステムを、ゲストオペレーティングシステム（ＯＳ）１４６としてインストールしてもよいように、標準ｘ８６ハードウェアアーキテクチャの同等品として機能する場合がある。表示部に描画を要求するアプリケーション１４８は、順に、描画要求を描画コマンドに変換し、描画コマンドをデバイスドライバ層１５２のビデオアダプタドライバ１５４へ伝送する画像描画インタフェース層１５０（例えば、一実施形態では、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ＧＤＩ）により提供されるＡＰＩを介して、描画要求を出す。図１の実施形態に示す通り、ビデオアダプタドライバ１５４は、ビデオアダプタ１４０のフレームバッファ１４２の潜在的に変更された領域を追跡し続ける、以下で「ブリットマップ」データ構造と呼ばれる空間データ構造１５６を割り当てて保持する。ブリットマップデータ構造の実装及び使用法に関しては、本発明を実施するための形態の中で後ほど詳細に説明する。デバイスドライバ層１５２は、エミュレートされたデバイスがまるでハードウェアプラットフォーム１０２の実際の物理的デバイスであるかのように、仮想ハードウェアプラットフォーム１３０_１（例えば、仮想ＮＩＣ１３８など）のかかるエミュレートされるデバイスと相互作用する、ＮＩＣドライバ１５８などの更なるデバイスドライバを含む。ハイパーバイザ１２４は概して、デバイスドライバ層１５２のデバイスドライバから、仮想プラットフォーム１３０_１のエミュレートされたデバイスによって受信される要求を受け取り、ハードウェアプラットフォーム１０２において実デバイスと通信するハイパーバイザ１２４の物理デバイスドライバ層で、実デバイスドライバに対応する形に要求を変換する役割を果たす。

グラフィカルユーザインタフェースを遠隔のクライアント端末の表示部へ伝送するために、符号化し（例えば、ネットワーク伝送帯域を減らすため）、続いてＮＩＣドライバ１５８（例えば、仮想ＮＩＣ１３８、最終的には物理ＮＩＣ１０８）を介してネットワーク上へ伝送するために、ＶＭ１２８_１は更にフレームバッファ１４２からデータを獲得するための、（例えばＡＰＩを介する）ビデオアダプタドライバ１５４と相互作用する、表示エンコーダ１６０を含む。表示エンコーダ１６０は、フレームバッファ１４２から受信したデータを記憶する二次フレームバッファ１６２と、二次フレームバッファ１６２の変更された領域を特定するための自身のブリットマップデータ構造１６４（以下、エンコーダブリットマップデータ構造１６４と呼ぶ）とを割り当て保持する。一実施形態において、表示エンコーダ１６０は、フレームバッファ１４２になされた変更を二次フレームバッファ１６２にコピーし、遠隔のクライアント端末へ伝送するために、ビデオアダプタドライバ１５４を継続的にポーリングする（例えば、１秒あたり３０回又は６０回）。

当業者は、図１の仮想化構成要素を記述するのに使用される様々な用語、層、及び分類が、それらの機能や本発明の精神から逸脱しない限り、異なる名称で称される場合があることを理解するであろう。例えば、仮想ハードウェアプラットフォーム１３０_１〜１３０_Ｎは、ハイパーバイザ１２４と対応するＶＭ１２８_１〜１２８_Ｎとの間の動作を調整するために必要とされる、仮想システムのサポートを実装する仮想マシンモニタ（ＶＭＭ）１６６_１〜１６６_Ｎの一部とみなしてもよい。或いは、仮想ハードウェアプラットフォーム１３０_１〜１３０_Ｎもまた、ＶＭＭ１６６_１〜１６６_Ｎから分離しているとみなしても、ＶＭＭ１６６_１〜１６６_Ｎがハイパーバイザ１２４から分離しているとみなしてもよい。本発明の実施形態で使用してもよいハイパーバイザ１２４の一例には、Ｃａｌｉｆｏｒｎｉａ州Ｐａｌｏ ＡｌｔｏのＶＭｗａｒｅ，Ｉｎｃ．から市販されているＶＭｗａｒｅのＥＳＸ（登録商標）製品の構成要素が含まれる。本発明の実施形態は、ハイパーバイザがオペレーティングシステムの上部に実装される、ホストされる仮想マシンシステムなど、その他の仮想化されたコンピュータシステムで実施してもよいことを更に理解されたい。

図２は、本発明の一実施形態に従う、ブリットマップデータ構造を示す。ビデオアダプタドライバ１５４及び表示エンコーダ１６０の両方は、フレームバッファ１４２及び二次フレームバッファ１６２それぞれの変更された領域を追跡するために、ブリットマップデータ構造を利用する。図２の実施形態では、ブリットマップデータ構造は２次元ビットベクトルであり、ビットベクトルの各ビット（本願では「ブリットマップ入力」とも称される）は、対応するフレームバッファのＮ×Ｎ領域を表す。ビットベクトルに置かれるビット（本願では「印付き」ブリットマップ入力とも称される）は、フレームバッファの関連するＮ×Ｎ領域内の少なくとも１つのピクセル値が、特定の時間間隔（例えば、表示エンコーダ１６０によるポーリング要求の間）に変更されていることを示す。例えば、図２はフレームバッファの６４×６４ピクセルブロック２００を示し、黒く塗りつぶされた点は、特定の時間間隔で変更されているピクセル値を表す。８×８ビットベクトル２０５は、ブリットマップデータ構造の対応するブリットマップ入力ブロックを表し、各ビット（又はブリットマップ入力）はピクセルブロック２００の８×８領域に対応する。ビットベクトル２０５の設定ビット（又は印付きブリットマップ入力）は「Ｘ」で表される。例えば、印付きブリットマップ入力２１０は、フレームバッファ領域２１５に対応する（黒い点が示すように、フレームバッファ領域２１５の全ピクセル値が指定される時間間隔で変化している）。図２は、黒く塗りつぶされた点が示す通り、変化したピクセル値を有するフレームバッファピクセルブロック２００の領域に対応する、ビットベクトル２０５における他の印付きブリットマップ入力を示す。図２の２０５に類似するブリットマップデータ構造の２次元ビットベクトル実施形態をトラバースすることで、フレームバッファのどのＮ×Ｎ領域がある時間間隔で変化しているのか、容易に特定することができる（その時間間隔で変化しなかった領域を容易に飛ばすこともできる）。

図３は、本発明の一実施形態に従う、第２のブリットマップデータ構造を示す。図３の実施形態では、ブリットマップデータ構造は領域四分木であり、ツリーの各レベルは２^Ｎ×２^Ｎピクセルブロックのより高解像度のビットベクトルを表す。図３はフレームバッファの６４×６４ピクセルブロック３００を示し、黒く塗りつぶされた点は、特定の時間間隔で変化しているピクセル値を表す。変化した各ピクセル（例えば、黒く塗りつぶされた点）が最小サブクワドラント内に含まれるまで、ピクセルブロックは連続的にますます小さなサブクワドラントへ更に分割される。例えば、ピクセルブロック３００では、最小サブクワドラントは、領域３０５、３１０、及び３１５などの８×８ピクセル領域である。より大きなサブクワドラントには、３３０などの３２×３２サブクワドラントだけでなく、３２０や３２５などの１６×１６サブクワドラントが含まれる。４レベルの領域四分木３３５は、フレームバッファの６４×６４ピクセルブロック３００に対応するブリットマップデータ構造を表す。図３に示す通り、領域四分木３３５の各レベルは、ビットベクトルのレベルにより、６４×６４から８×８の範囲で、ピクセルブロック３００内で特定のサイズのサブクワドラントに対応するビットを有するビットベクトルとして実装することができる。「Ｘ」の印が付けられる領域四分木３３５にあるノードは、ピクセルブロック３００におけるノードの対応するサブクワドラントで少なくとも１つのピクセル値が、特定の時間間隔で変更されている（黒く塗りつぶされた点で示されている）ことを示す。例えば、領域四分木３３５のレベル０（６４×６４レベル）のノード３００_Ｑは完全な６４×６４ピクセルブロックを表し、ピクセルブロック３００の少なくとも１つのピクセル値が変化しているため、「Ｘ」の印が付いている。対照的に、領域四分木３３５のレベル１（３２×３２レベル）のノード３３０_Ｑは３２×３２サブクワドラント３３０を表し、サブクワドラント３３０のピクセル値は変化していないため、印は付いていない。同様に、レベル２（１６×１６レベル）のノード３２０_Ｑ及び３２５_Ｑは１６×１６サブクワドラント３２０及び３２５をそれぞれ表し、サブクワドラント３２０及び３２５のピクセル値は変化していないため、印は付いていない。レベル３（８×８レベル）のノード３０５_Ｑ、３１０_Ｑ、及び３１５_Ｑはピクセルブロック３００の８×８領域３０５、３１０、及び３１５にそれぞれ対応し、従って印が付いている。図３の実施形態など、ブリットマップデータ構造の領域四分木実施形態では、領域四分木の最深レベルにある各ノード（即ち、８×８ピクセル領域などの最小サブクワドラントに対応）はブリットマップ入力である。ブリットマップデータ構造の領域四分木実施形態をトラバースすることで、フレームバッファのどの８×８領域（又はその他最小サイズのサブクワドラント）が、ある時間間隔で変化しているのかを容易に特定することができる。更に、そのツリー構造のため、その時間間隔で変化しなかったフレームバッファの大きなサイズのサブクワドラントを、迅速に飛ばすこともできる。ブリットマップデータ構造の領域四分木実施形態は、領域四分木の特定の実装に応じて、更にブリットマップデータ構造が使用するメモリを節約できる場合があることを理解されたい。例えば、図２のブリットマップデータ構造２０５の２次元ビットベクトル実施形態では、８×８領域がいくつ無印であっても６４ビットが消費される一方で、図３の領域四分木３３５では印の付いている８×８領域が少ないと、消費されるビットも少なくなる。図に示す通り、ブリットマップデータ構造３３５が３３ビットを利用する一方で、ブリットマップデータ構造２０５を実装することにより６４ビットが利用される。エンコーダブリットマップデータ構造１６４及びドライバブリットマップデータ構造１５６は各々、図２及び図３のデータ構造を含む種々の異なるデータ構造を使用して実装されてもよく、いずれか特定の実施形態では、エンコーダブリットマップデータ構造１６４はドライバブリットマップデータ構造１５６とは異なるデータ構造を使用してもよいことを理解されたい。

図４は、本発明の一実施形態に従う、アプリケーションからビデオアダプタへ描画要求を伝送するステップを示すフロー図である。ステップは、図１の遠隔のデスクトップサーバ１００の構成要素を参照して説明されるが、ステップを行うように構成されるいずれのシステムも、いずれの順番において本発明と一致することを理解されたい。

図４の実施形態に従い、ステップ４０５では、実行中、アプリケーション４００（即ち、ゲストＯＳ１４６上で作動しているアプリケーション１４８のうちの１つ）が、例えば、ユーザの操作に合わせてグラフィカルユーザインタフェースを更新するように、画面へ描画要求を出すために、画像描画インタフェース層１５０（例えば、Ｍｉｃｒｏｓｏｆｔ ＷｉｎｄｏｗｓのＧＤＩ）のＡＰＩにアクセスする。ステップ４１０では、ゲストＯＳ１４６を介して、画像描画インタフェース層１５０が描画要求を受信し、ビデオアダプタドライバ１５４により認識される描画コマンドへ変換する。ステップ４１５では、画像描画インタフェース層１５０が描画コマンドをビデオアダプタドライバ１５４へ伝送する。ステップ４２０では、ビデオアダプタドライバ１５４が描画コマンドを受信し、ドライバブリットマップデータ構造１５６の印付き入力に対応するフレームバッファ１４２の領域内のピクセル値の少なくとも一部分を、描画コマンドを実行した結果として更新する予定であることを示すため、ドライバブリットマップデータ構造１５６の入力に印を付ける。一実施形態では、ビデオアダプタドライバ１５４は、描画コマンド（即ち、「バウンディングボックス」とも呼ばれる）を実行した結果として更新される予定のピクセルを囲む最小サイズの長方形などの、フレームバッファ１４２内の区域を計算するか、そうでなければその区域を決定する。その後ビデオアダプタドライバ１５４は、決定された区域にピクセル値を含むフレームバッファ１５４の領域に対応するドライバブリットマップデータ構造１５６のブリットマップ入力全てを特定し印を付けることができる。ビデオアダプタドライバ１５４は、ステップ４２５では、描画コマンドをデバイス固有の描画プリミティブに変換し、ステップ４３０では、描画プリミティブをＦＩＦＯバッファ１４４に挿入する（例えば、ＦＩＦＯバッファ１４４をビデオアダプタドライバ１５４とビデオアダプタ１４０との間で共有する実施形態で）。ステップ４３５ではその後、描画プリミティブを機能させる準備ができると、ビデオアダプタ１４０が描画プリミティブに従い、フレームバッファ１４２を最終的に更新することができる（即ち、かかる描画プリミティブがＦＩＦＯバッファ１４４の端部に到達する）。

図５は、本発明の一実施形態に従い、ビデオアダプタから表示エンコーダへフレームバッファデータを伝送するステップを示したフロー図である。ステップは図１の遠隔のデスクトップサーバ１００の構成要素を参照して説明されるが、ステップを行うように構成されるいずれのシステムも、いずれの順番においても本発明と一致することを理解されたい。

図５の実施形態に従い、表示エンコーダ１６０は、ビデオアダプタ１４０のフレームバッファ１５４内にあるデータを手に入れ、符号化し、遠隔のクライアント端末に受信させるためにネットワーク上へ（例えば、ＮＩＣドライバ１５８経由で）伝送するために、継続的にビデオアダプタドライバ１５４をポーリングする（例えば、１秒あたり３０回又は６０回）、ゲストＯＳ１４６上で行われるプロセスである。ステップ５００では、表示エンコーダ１６０は、ビデオアダプタドライバ１５４によって該エンコーダに向けられたＡＰＩルーチンを介して、ビデオアダプタドライバ１５４へフレームバッファ更新要求を発行し、ビデオアダプタドライバ１５４が直接二次フレームバッファ１６２を修正することを可能とするために、二次フレームバッファ１６２へのメモリ参照（例えば、ポインタ）をビデオアダプタドライバ１５４へ受け渡す。ビデオアダプタドライバ１５４は、ステップ５０５ではフレームバッファ更新要求を受信し、ステップ５１０では、表示エンコーダ１６０からのフレームバッファ更新要求時から変化している（図４に記述した通り、アプリケーションからの描画要求による）フレームバッファ１４２の領域に対応する印付きブリットマップ入力を特定するために、そのドライバブリットマップデータ構造１５６をトラバースする。ステップ５１５で、現ブリットマップ入力に印が付いている場合、その後、ステップ５２０では、ビデオアダプタドライバ１５４はビデオアダプタ１４０からフレームバッファ１４２の対応領域（即ち、領域内のピクセル値）を要求する。ステップ５２５では、ビデオアダプタ１４０は要求を受信し、フレームバッファ１４２の要求領域をビデオアダプタドライバ１５４へ伝送する。

ビデオアダプタドライバ１５４は、ステップ５３０で、フレームバッファ１４２の要求領域を受信し、ステップ５３５で、フレームバッファ１４２の受信された要求領域のピクセル値を、二次フレームバッファ１６２にある関連領域のピクセル値と比較し、それによって、表示エンコーダ１６０からの前フレームバッファ更新要求に対するビデオアダプタドライバ１５４の返答が完了するとすぐに、フレームバッファ１４２の以前の状態が反映される。この比較ステップ５３５により、ビデオアダプタドライバ１５４は、図４で説明した通り、アプリケーションによる描画要求の視覚的冗長伝送が原因となって起こり得る非効率を特定することができる。例えば、おそらく機能性の描画に関連する態様を最適化する関心が欠如しているために、図４のステップ４０５において、実際にはグラフィカルユーザインタフェースの小領域のみがアプリケーションにより変更されている場合でも、グラフィカルユーザインタフェース全体を冗長的に再描写する描画要求を発出する場合があるアプリケーションもある。印付きブリットマップ入力の関連するフレームバッファ１４２領域が、新規ピクセル値（即ち、実際には変更されていないグラフィカルユーザインタフェースの部分に対応する領域）で更新する必要はない場合でさえも、かかる描画要求により、図４のステップ４２０にて印を付けられたドライバブリットマップデータ構造１５６に入力される。かかる印付きブリットマップ入力により、比較ステップ５３５では、ビデオアダプタドライバ１５４が表示エンコーダ１６０からの前フレームバッファ更新要求への返答を完了した後、アプリケーションから出された最適化されていない描画要求（ステップ４０５）により、かかる領域のピクセル値は変化しなかったため、印付きブリットマップ入力に関連するフレームバッファ１４２及び二次フレームバッファ１６２の領域が同一であることが明らかとなるであろう。

従って、ステップ５４０では、比較ステップ５３５によりフレームバッファ１４２及び二次フレームバッファ１６２の領域が同一であると示された場合、その後ステップ５４５で、ビデオアダプタドライバ１５４が印付きブリットマップ入力を削除することで、表示エンコーダ１６０からの前フレームバッファ更新要求にビデオアダプタドライバ１５４が返答を完了してから、実際のピクセル値がフレームバッファ１４２の関連領域で変更されていないと示すため、ドライバ ブリットマップデータ構造１５６を「切り取る」。

図６は、本発明の一実施形態に従う、ブリットマップデータ構造を切り取るステップを示すフロー図である。本ステップは、図１の遠隔のデスクトップサーバ１００を参照の上説明されるが、システムは異なる順番でステップのように行われるように構成されてもよいことは理解されたい。

ビデオアダプタ１５４は、ステップ６００では、画像描画インタフェース層１５０から描画コマンドを受信し、ステップ６０５では、描画コマンドを実行した結果もたらされたピクセル値の更新全てを取り囲むバウンディングボックスを、フレームバッファ１４２に特定する。ステップ６１０では、ビデオアダプタドライバ１５４が、バウンディングボックス内にあるフレームバッファ１４２の領域（又は領域の部分）に対応する、ドライバブリットマップデータ構造１５６のブリットマップ入力に印を付ける。ステップ６０５から６１０は、図４のステップ４２０から成るサブステップに対応することを理解されたい。ステップ６１５で、フレームバッファ更新要求が表示エンコーダから受信されると、ステップ６２０では、ビデオアダプタドライバ１５４は、バウンディングボックス（ドライバブリットマップデータ構造１５６の印付きブリットマップ入力で示される）にあるフレームバッファ１４２の領域を、二次フレームバッファ１６４（直前のフレームバッファ更新要求に対してビデオアダプタドライバ１５４が返答を完了してすぐの、フレームバッファ１４２の状態を包含する）の対応する領域と比較する。ステップ６２５では、ビデオアダプタドライバ１５４は、差異が実際に存在するステップ６２０で比較された領域に対応する印付きの入力を有する切り取られたブリットマップデータ構造を、表示エンコーダ１６０に発行する。ステップ６３０では、ビデオアダプタドライバ１５４は、印付き入力全てのうちドライバブリットマップデータ構造１５４を消去する。ステップ６１５から６３０は、概して、図５のステップ５０５、５３５、５６０、及び５６５にそれぞれ対応することを理解されたい。表示エンコーダ１６０は、ステップ６３５で、切り取られたブリットマップデータ構造を受信し、ステップ６４０で、ブリトマップデータ構造の印付き入力に対応する切り取られた領域の表示データを伝送する。

図７は、ブリットマップデータ構造を切り取る視覚的な例を示す。図７はフレームバッファ１４２の８８×７２ピクセルブロック７００を示す。７０５などの更に分割された各ブロックは、ドライバブリットマップデータ構造１５６内のブリットマップ入力に対応する８×８ピクセル領域を表す。図７に示すように、図６のステップ６００に従い、ピクセルブロック７００に示す通り、ビデオアダプタドライバ１５４は、スマイルマークを描くために、アプリケーションの描画要求に関連する描画コマンドを受信している。しかしながら、描画コマンドは、スマイルマーク自体の個別ピクセルを描く要求だけよりむしろ、ピクセルブロック７００全体を再描写するという非効率的な要求をしている。ドライバブリットマップデータ構造１５６の関連する１１×９ブリットマップブロック７１０内の各ブリットマップ入力は、図６のステップ６１０に従い、ビデオアダプタドライバ１５４により印が付けられる（印付きブリットマップ入力７１５など）。しかしながら、ステップ６１５のように、ビデオアダプタドライバ１５４が表示エンコーダ１６０からフレームバッファ更新要求を受信する際、ビデオアダプタドライバ１５４はブリットマップブロック７１０を切り取ることができ、それによって、図５のステップ５４５のように、フレームバッファ１４２の関連領域が実際には変更されていない（即ち、スマイルマーク用に変更されたピクセルを含まない）、無印のブリットマップ入力７２５などのブリットマップ入力を消去することで、ブリットマップブロック７２０を作成し、ステップ６２０及び６２５で表示エンコーダ１６０にブリットマップブロック７１０を発行する。

しかしながら、図５に戻ってステップ５４０で、比較ステップ５３５がフレームバッファ１４２及び二次フレームバッファ１６２の領域が異なる（即ち、表示エンコーダ１６０からの前フレームバッファ更新要求に返答し終えた時点から、フレームバッファ１４２の領域内にある実際のピクセル値が、ステップ４０５におけるアプリケーションの描画要求の結果変化していた）ことを示した場合、その後ステップ５５０で、ビデオアダプタドライバ１５４は、二次フレームバッファ１６２に、フレームバッファ１４２の領域内にある変更されたピクセル値を適切に反映させるために、フレームバッファ１４２の領域内にあるピクセル値を、二次フレームバッファ１６２の関連領域へコピーする。ステップ５５５では、ビデオアダプタドライバ１５４がドライバブリットマップデータ構造１５６のトラバースを完了していなかった場合には、フローはステップ５１０へ戻る。ステップ５５５で、ビデオアダプタドライバ１５４がドライバブリットマップデータ構造１５６のトラバースを完成している場合は、その後ステップ５６０で、ビデオアダプタドライバ１５４によりドライバブリットマップデータ構造１５６のコピーが表示エンコーダ１６０へ提供され、そのコピーがエンコーダブリットマップデータ構造１６４となり、本願での名称となっている。ステップ５４５で、印付きブリットマップ入力がドライバブリットマップデータ構造１５６で消去された限りにおいて、エンコーダブリットマップデータ構造１６４が、変更された実際のピクセル値を有する二次フレームバッファ１６２に、より最適化された領域表示を反映する。ステップ５６５では、ビデオアダプタドライバ１５４は、表示エンコーダ１６０から続くフレームバッファ更新要求を受信するのに備えて、ドライバブリットマップデータ構造１５６内の印付きブリットマップ入力全てを消去し、ステップ５００で発出されたフレームバッファ更新要求への返答を完了したことを表示エンコーダ１６０に示す。

ビデオアダプタドライバ１５４が、ステップ５００で表示エンコーダ１６０により発出されたフレームバッファ更新要求への返答を完了するとすぐに、二次フレームバッファ１６２は、表示エンコーダ１６０からの前フレームバッファ更新要求への返答完了以来のアプリケーションからの描画要求（図４のステップ４０５）の結果として、変更されたピクセル値全てを含み、エンコーダブリットマップデータ構造１６４は、二次フレームバッファ１６２内のどの領域がかかる変更されたピクセル値を含むかを示す、印付きブリットマップ入力を含む。かかる情報により、ステップ５７０では、表示エンコーダ１６０は印付きブリットマップ入力に対してエンコーダブリットマップデータ構造１６４をトラバースし、かかる印付きブリットマップ入力に対応する二次フレームバッファ１６２にあるその領域のみを、符号化及び遠隔のクライアント表示部への伝送のために抽出することができる。

図１は表示エンコーダ１６０が仮想マシン１２８_１内で実行する実施形態を示すが、代替の実施形態は、例えば、仮想マシンモニタ１６６_１、又はハイパーバイザ１２４の他のいずこか内で、遠隔のデスクトップサーバ１００のその他の構成要素において、表示エンコーダ１６０を実装してもよいことは理解されたい。同様に、図１は表示エンコーダ１６０及びビデオアダプタドライバ１５４が、ハイパーバイザ１２４の仮想ビデオアダプタ１４０と通信する仮想マシン１２８_１内で作動する実施形態を示すが、これらの構成要素は、非仮想マシンベースのコンピュータアーキテクチャを含む、いずれの遠隔のデスクトップサーバキテクチャに設置されてもよいことを理解されたい。更に、サーバのソフトウェア構成要素として表示エンコーダ１６０及び仮想ビデオアダプタ１４０を有するよりむしろ、代替の実施形態では、それらの一方又は両方の代わりにハードウェア構成要素を利用してもよい。同様に、代替の実施形態では、いずれの仮想ビデオアダプタを必要としない場合があることも理解されるものとする。代わりに.かかる代替の実施形態では、例えば、ビデオアダプタドライバ１５４が、フレームバッファ１４２及びＦＩＦＯバッファ１４４自体を割り当て管理してもよい。同様に、代替の実施形態では、ビデオアダプタ１４０は、ＦＩＦＯバッファ１４０などのＦＩＦＯバッファを有さずに、受信するとすぐに着信してくる描画プリミティブを即座に処理してもよい。本願に記述した他の様々なデータ構造及びバッファは、代替のシステム構成要素により割り当てられ、保持されることができることは、同様に理解されるものとする。例えば、図５のステップ５００に詳細に説明したように、表示エンコーダ１６０を有して、二次フレームバッファ１６２を割り当てて保持し、メモリ参照をビデオアダプタドライバ１５４へ受け渡すよりはむしろ、代替の実施形態では、ビデオアダプタドライバ１５４が二次フレームバッファ１６２（及びエンコーダブリットマップデータ構造１６４）を割り当てて保持し、表示エンコーダ１６０へのメモリ参照アクセスを提供してもよい。加えて、本願に記述されるビデオアダプタドライバ１５４により行われる機能性及びステップの中には、以前から存在する又は標準であるビデオアダプタドライバの別個の拡張部又は構成要素内に実装することができる（即ち、表示エンコーダ１６０は、以前から存在するビデオアダプタドライバ自体よりはむしろ、ビデオアダプタドライバのかかる別個の拡張部と通信してもよい）ことを理解されたい。同様に、代替の実施形態では、本願に記述した通り、システム構成要素間で交換されるデータの量及びタイプは様々であってよいか、又は様々な最適化技術を利用してもよいことを理解されたい。例えば、図５のステップ５６０にあるエンコーダブリットマップデータ構造１６４として、ドライバブリットマップデータ構造１５６の全てをコピーし提供するよりむしろ、代替の実施形態によって、ドライバブリットマップデータ構造１５６の関連する部分のみを、表示エンコーダ１６０に提供してもよいか、又はそうでなければドライバブリットマップデータ構造１５６のかかる関連部分を表示エンコーダ１６０に提供するために、代替のデータ構造を利用してもよい。同様に、本願の教示部分を最適化するためにキャッシュ技術を利用してもよいことを理解されたい。例えば、例として図４のステップ４２０の間、コンピュータのオーバーヘッドを減少させるために、ビデオアダプタ１５４はＦＩＦＯバッファ１４４の中間キャッシュを保持してもよい。同様に、継続的にビデオアダプタドライバ１５４をポーリングするよりはむしろ（又は、ポーリングするのに加えて）、代替の実施形態において、フレームバッファ１４２がその内容を更新する、及び／又は遠隔のクライアントから追加でフレームバッファ更新要求を追加で受信する際には、表示エンコーダ１６０は、ビデオアダプタドライバ１５４により惹起されたコールバック又は中断を受信してもよい。

本願に記載した様々な実施形態は、コンピュータシステムに記憶されるデータに関与する、コンピュータに実装される様々な動作を採用してもよい。例えば、これらの動作は、必ずではないが、電気信号又は磁気信号の形態を取り得るが、それら信号又はそれら信号形状は記憶、転送、結合、又はそれ以外の動作を行うことができ、これら動作は通常、物理量の物理的処置を必要とする場合がある。更に、かかる操作はしばしば、生成、特定、決定、又は比較などの言葉で称される。本願に記述した動作はいずれも、本発明の１つ以上の実施形態の一部を形成し、有用なマシン動作である場合がある。加えて、本発明の１つ以上の実施形態もまた、これら動作を行うためのデバイス又は装置に関する。装置は、固有の必要とされる目的のために特別に構築されてもよいか、又はコンピュータに記憶されたコンピュータプログラムにより選択的に起動又は構成される、汎用コンピュータであってもよい。特に、様々な汎用マシンを本願の教示に従って書かれたコンピュータプログラムとともに使用する場合や、又は必要な動作を行うために、より特殊な装置を構築する方がより便利な場合もある。

本願に記述した様々な実施形態は、携帯用デバイス、マイクロプロセッサシステム、マイクロプロセッサベースの家電製品又はプログラム可能な家電製品、ミニコンピュータ、メインフレームコンピュータなど、他のコンピュータシステム構成とともに実施してもよい。

本発明の１つ以上の実施形態は、１つ以上のコンピュータプログラム、又は１つ以上のコンピュータで読み取り可能な媒体に搭載される１つ以上のコンピュータプログラムモジュールとして実装されてもよい。コンピュータで読み取り可能な媒体という用語は、その後コンピュータシステムに入力することが可能なデータを記憶することができる、任意のデータ記憶デバイスを指し、媒体をコンピュータで読み取ることを可能とする様式でコンピュータプログラムを具体化する、既存又は後に開発されるいずれの技術に基づいていてもよい。コンピュータで読み取り可能な媒体の例には、ハードドライブ、ネットワーク接続ストレージ（ＮＡＳ）、読み取り専用メモリ、ランダムアクセスメモリ（例えば、フラッシュメモリデバイス）、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）、ＣＤ−ＲＯＭ 、ＣＤ−Ｒ、又はＣＤ−ＲＷ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気テープ、並びにその他光学及び非光学データ記憶装置が挙げられる。コンピュータで読み取り可能な媒体はまた、コンピュータで読み取り可能なコードが分散的に記憶され実行されるように、ネットワーク接続コンピュータシステム上に分散されることもできる。

理解を明確にするために、本発明の１つ以上の実施形態をかなり詳細に説明したが、請求項の範囲内で一定の変更及び修正が可能であることは明らかであろう。従って、記述した実施形態は限定的ではなく例示的であるとみなされるべきであり、特許請求の範囲は本明細書で提供される詳細に限定されず、特許請求の範囲及びその均等物の内で修正することができる。特許請求の範囲では、特許請求の範囲において明記されていない限り、要素及び／又はステップは動作のいずれの特定の順序をも暗示するものではない。

加えて、記述した仮想化の方法では概して、仮想マシンが特定のハードウェアシステムに合致するインタフェースを提供すると仮定しているが、当業者は、記述した方法は、いずれの特定のハードウェアシステムにも直接対応していない仮想化と合わせて使用してもよいと認識しているであろう。様々な実施形態に従う仮想化システムは、主要な実施形態、主要でない実施形態、又はその２つの間で違いが曖昧になりがちな実施形態として実装され、全てそのように想定されている。更に、様々な仮想化動作は、ハードウェアで全体的に又は部分的に実装してもよい。例えば、ハードウェアの実装には、ディスクデータでないものも保護するために、記憶アクセス要求の修正用ルックアップテーブルを採用してもよい。

仮想化の度合いに関わらず、多くの修正、変更、追加、及び改良が可能である。従って、仮想化ソフトウェアは、仮想化機能を行うホスト、コンソール、又はゲストオペレーティングシステムの構成要素を含むことができる。本願で単一例として記述した構成要素、動作、又は構造に対して、複数の例を提供することが可能である。最後に、様々な構成要素、動作、及びデータ記憶の間の境界はいくらか恣意的であり、特定の動作は個別に図示される構成との関連で示される。機能性の他の割り当ても想定され、本発明の範囲に含まれ得る。概して、例示的構成において別個の構成要素として表される構造及び機能性を、組み合わせた構造又は構成要素として実装することが可能である。同様に、単一構成要素として表される構造及び機能性を、別個の要素として実装することが可能である。これら及び他の修正、変更、追加、及び改良は、添付の特許請求の範囲内に含まれ得る。

Claims (20)

1. 表示データを記憶する一次フレームバッファと、遠隔のクライアント端末に表示データを伝送するために二次フレームバッファを使用する表示エンコーダと、を有するサーバにおいて、前記遠隔のクライアント端末に伝送される表示データを準備する方法であって、
   前記一次フレームバッファの表示データへの更新に関連するバウンディングボックスを特定するステップと、
   データ構造で入力に印を付けるステップであって、前記データ構造の各入力は前記一次フレームバッファの異なる領域に対応し、前記印の付いた入力は更に前記バウンディングボックスの領域に対応する、ステップと、
   前記一次フレームバッファの領域を、前記二次フレームバッファの対応する領域と比較するステップと、
   差異を有し比較される領域のためだけに、印の付いた入力を包含する切り取られたデータ構造を、前記表示エンコーダへ発行するステップであって、前記表示エンコーダは、前記切り取られたデータ構造内にある印の付いた入力に対応する前記二次フレームバッファの領域の更新された表示データを伝送することができるようにする、ステップと、
   を含む、方法。
2. 前記発行するステップの後に、前記データ構造の前記入力を消去するステップを更に含む、請求項１記載の方法。
3. 前記比較するステップが、前記一次フレームバッファから前記二次フレームバッファの対応する領域へ、差異を示す領域をコピーするステップを更に含む、請求項１記載の方法。
4. 前記一次フレームバッファは、仮想ビデオアダプタにより割り当てられるメモリバッファであり、前記データ構造は前記仮想ビデオアダプタと通信するビデオアダプタドライバにより割り当てられる、請求項１記載の方法。
5. 前記ビデオアダプタドライバは、前記サーバ上にインスタンスを作成した仮想マシンのゲストオペレーティングシステムの構成要素である、請求項４記載の方法。
6. 前記データ構造は二次元ビットベクトルである、請求項１記載の方法。
7. 前記データ構造は領域四分木である、請求項１記載の方法。
8. 表示データを記憶する一次フレームバッファと、遠隔のクライアント端末に表示データを伝送するために二次フレームバッファを使用する表示エンコーダと、を有するサーバの処理ユニットによって実行される際に、
   前記一次フレームバッファの表示データへの更新に関連するバウンディングボックスを特定するステップと、
   データ構造の入力に印を付けるステップであって、前記データ構造の各入力は前記一次フレームバッファの異なる領域に対応し、前記印の付いた入力は更に前記バウンディングボックスの領域に対応する、ステップと、
   前記一次フレームバッファの領域を、前記二次フレームバッファの対応する領域と比較するステップと、
   差異を有し比較される領域のためだけに、印の付いた入力を包含する切り取られたデータ構造を前記表示エンコーダへ発行するステップであって、前記表示エンコーダは、前記切り取られたデータ構造内にある印の付いた入力に対応する、前記二次フレームバッファの領域の更新された表示データを伝送することができるようにするステップと、を行うことによって、前記処理ユニットに、前記遠隔のクライアント端末に伝送される表示データを準備させる命令を含む、コンピュータで読み取り可能な媒体。
9. 前記処理ユニットは、前記発行するステップの後に、前記データ構造の前記入力を消去するステップを更に行う、請求項８記載のコンピュータで読み取り可能な媒体。
10. 前記処理ユニットは、前記比較するステップが、前記一次フレームバッファとの差異を前記二次フレームバッファの対応する領域へ示す領域をコピーするステップを更に含む、請求項８記載のコンピュータで読み取り可能な媒体。
11. 前記一次フレームバッファは、仮想ビデオアダプタにより割り当てられるメモリバッファであり、前記データ構造は前記仮想ビデオアダプタと通信するビデオアダプタドライバにより割り当てられる、請求項８記載のコンピュータで読み取り可能な媒体。
12. 前記ビデオアダプタドライバは、前記サーバ上にインスタンスを作成した仮想マシンのゲストオペレーティングシステムの構成要素である、請求項１１記載のコンピュータで読み取り可能な媒体。
13. 前記データ構造は二次元ビットベクトルである、請求項８記載のコンピュータで読み取り可能な媒体。
14. 前記データ構造は領域四分木である、請求項８記載のコンピュータで読み取り可能な媒体。
15. 表示データを記憶する一次フレームバッファと、遠隔のクライアント端末に表示データを伝送するために二次フレームバッファを使用する表示エンコーダと、を有するサーバにおいて、前記遠隔のクライアント端末に伝送される前記表示データを準備する方法であって、
    前記表示エンコーダから、前記二次フレームバッファを更新する要求を受け取るステップと、
    更新された表示データを包含する前記一次フレームバッファの領域を位置付けるために、空間データ構造において印の付いた入力を特定するステップであって、前記空間データ構造の各入力は、前記一次フレームバッファの異なる領域に対応する、ステップと、
    前記一次フレームバッファの前記位置付けられた領域に記憶される表示データを、前記二次フレームバッファの対応する領域へコピーするステップと、
    前記表示エンコーダが、前記空間データ構造の印の付いた入力に対応する、前記二次フレームバッファの領域の更新された表示データを伝送するために、前記空間データ構造における前記印の付いた入力を消去するステップと、
    を含む、方法。
16. 前記コピーするステップの前に、前記表示エンコーダからの前記二次フレームバッファを更新する先の要求に対する返答を完了するとすぐに、前記二次フレームバッファが、前記一次フレームバッファの先の状態を反映する表示データを包含する、請求項１５記載の方法。
17. 前記サーバ上で作動するアプリケーションによりなされた描画要求に対応する描画コマンドを受信するステップと、
    前記描画コマンドを実行した結果、前記一次フレームバッファの区域を更新することを決定するステップと、
    前記決定された区域に表示データを含む前記一次フレームバッファの領域に対応する、前記空間データ構造の全ての入力に印を付けるステップと、
    を更に含む、請求項１５記載の方法。
18. 前記決定された区域は、前記描画コマンドを実行した結果更新された、前記一次フレームバッファにおける全ての表示データの境界を示す長方形である、請求項１７記載の方法。
19. 前記消去するステップの前に、前記空間データ構造のコピーを前記表示エンコーダに提供するステップを更に含む方法であって、前記表示エンコーダは、前記空間データ構造の前記コピーにある印の付いた入力に対応する、前記二次フレームバッファの領域に備わっている表示データを伝送する、請求項１５記載の方法。
20. 前記コピーするステップの前に、前記一次フレームバッファの前記位置付けられた領域を、前記二次フレームバッファの合致する領域と比較するステップと、
    前記二次フレームバッファの前記対応する合致する領域と同一の表示データを包含する、前記一次フレームバッファの位置付けられた領域に対応する前記空間データ構造で、前記印の付いた入力の各々を消去するステップと、
    を更に備える、請求項１９記載の方法。

Images