JP5279754B2 - 遠隔の表示部へ選択的に伝送するために描画プリミティブを特定する方法及びシステム - 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