JP5080554B2 - 代替的グラフィック・セットの効率的な符号化 - Google Patents

Description

本発明は、代替的グラフィック・セットの効率的な符号化の方法に関する。

コンピュータ化されたシステムが一般化するのと同時に、大規模および小規模両方のネットワークにおいてコンピュータシステムのファイルおよび処理リソースを分散する必要も高まった。一般に、コンピュータシステムおよび関連するデバイスは、多くの理由で、例えば、個人的な電子メッセージの交換、商品の販売、口座情報の提供などのためにネットワークを介して情報を伝達する。しかし、人は、コンピュータシステムおよびその関連するアプリケーションが次第にさらに高度化されたのにつれて、ネットワーク上でデータおよびリソースを共有することに関連する困難も大きくなったことを認識するであろう。

組織のネットワーク内でリソースを分散するための一部の現在のやり方は、１つまたは複数のクライアント（またはリモートデバイス）とリソースを共有する集中サーバ（またはローカルデバイス）を含む可能性がある。クライアントはそのようなリソースをローカルにインストールしない。通常、そのようなシステムは、リモート・デスクトップ・プロトコル（ＲＤＰ：Remote Desktop Protocol）、インデペンデント・コンピューティング・アーキテクチャ（ＩＣＡ：Independent Computing Architecture）などの専用プロトコルを使用してリモート・クライアントと様々なアプリケーションを共有する。そのようなプロトコルを用いて、クライアント・コンピュータ・システムは、興味のあるネットワークリソースをホストする集中ネットワークサーバにアクセスし、まるでそれらのリソースがローカルにインストールされているかのようにそれらのリソースと対話（例えば、マウスイベントおよびキーボードイベントを送るなど）することができる。

そして今度は、ネットワークサーバが、それらの対話（interaction）を処理し、データの対応するレンダリング情報を作成し、処理されたデータおよび作成されたレンダリング情報の両方をクライアントに返送する。次に、クライアント・コンピュータ・システムは、データおよびレンダリング情報を受信し、クライアント側のビデオドライバを使用して受信データをローカルでレンダリングおよび表示する。理想的には、クライアント・コンピュータ・システムとネットワークサーバとの間のこの対話は、クライアント・コンピュータ・システムが、そのクライアント・コンピュータ・システム自体のインストールされたリソースを用いてデータを実際に処理したかのようにシームレスに行われる。残念なことに、そのようなシステムは、ネットワーク・スループットの制約を受ける可能性があり、ネットワーク・スループットの制約は、負荷がかけられた場合に、対話および処理の観点でローカルのクライアント・コンピュータ・システムが見るものの間に「ラグ（lag）」をもたらす可能性がある。

上述の集中的な共有モデルとほとんどの点で類似している別の種類のシステムは、ネットワーク上のその他の受信クライアント・コンピュータ・システムにウィンドウデータ情報を送信するように構成されたブロードキャスティング（または「送信」）クライアント・コンピュータ・システムを含む。この特徴は、「デスクトップ共有」と呼ばれることもある。この例において、ブロードキャスティングコンピュータ（例えば、学習環境における「インストラクタ」）および受信コンピュータシステム（例えば、「生徒」）は、インストラクタのコンピュータのデスクトップ画面およびローカルにインストールされたアプリケーションの共有を可能にする共通してインストールされたアプリケーションプログラムを使用して接続する。集中コンピューティングシステムのシナリオと同様に、クライアント・コンピュータ・システムは、インストラクタのコンピュータに表示されたウィンドウと、当該ウィンドウが生徒のコンピュータ自体のウィンドウであるかのように対話することができる可能性がある。

ビットマップはネットワーク接続（例えばインターネット）を介して送信されるときに帯域幅の消費の観点でコストが高いので、ビットマップ全体を送信するのではなく、（上述のシステムなどの）今日のほとんどのシステムは、何を描画するか、および何らかのものをどのように描画するかをクライアント側のサブルーチンに指示するグラフィックプリミティブ（graphic primitive）およびその他の操作を送信する。例えば、クライアントは、長方形がどこに描画されるべきか、どのぐらいの大きさか、何色かなどについての情報と共に、長方形を描画するように指示される可能性がある。例えば、長方形は、ユーザインターフェースのためのボタン、ドキュメントの周囲の境界、または長方形の形状が有用である可能性がある任意のその他の目的を描画するために使用されることができる。もちろん、より高度であり、リモートのクライアントに操作を転送し、リモートのクライアント上で操作を実行するために行われなくてはならないより多くの処理を必要とする可能性があるプリミティブとして使用されることができる多くのその他の形状および操作が存在する。

プリミティブの上述の使用はネットワーキングシステムをよりシームレスにしたが、アプリケーションがより高度なグラフィカルインターフェースおよびその他の表示を獲得し続けるにつれて、上述のプリミティブの使用は処理の負担がより大きくなる。さらに、クライアントのディスプレイ上にグラフィックをレンダリングするためにローカルからリモートデバイスに送信される情報は、概して、タイル表示されたウィンドウがグラフィック情報の損失をもたらす即時表示モード（immediate presentation mode）で使用される。例えば、即時表示モードを使用すると、ウィンドウの見える部分を描画するために必要とされる情報のみが利用可能である。換言すれば、その他のウィンドウに覆われたバックグラウンドのウィンドウの部分に関して保持されるグラフィック情報はなく、すなわち、グラフィック情報は、最もトップのレベルのウィンドウに関してのみ保持される。したがって、ウィンドウがフォアグラウンドに移動されるとき、新しい情報が、当該ウィンドウを描画するために必要とされる。上述のグラフィックの高度化の進行のために、この情報の頻繁な送信は、頻繁な更新が必要とされるとき、例えば、ウィンドウがシャッフルされ、ローテーションされ、再配列されるときに、システムに過負荷をかける可能性がある。また、このことは、それがより高度なアニメーションに関連するときに様々な困難をもたらす。

上記で特定した現在のネットワークの難点および欠点は、本発明の例示的実施形態を通じて克服される。例えば、本明細書において説明される実施形態は、ローカルデバイス上で実行され、リモートデバイス上に表示されるアプリケーションに関するリソースを使用し効率的に符号化するために使用されるメカニズムを提供する。この要約は、「発明を実施するための最良の形態」において以下でさらに説明される概念の選択を簡素化された形態で導入するために提供されることに留意されたい。この要約は、特許請求の範囲に記載された対象の重要な特徴または必須の特徴を特定するように意図されておらず、特許請求の範囲に記載された対象の範囲を決定する助けとして使用されるように意図されてもいない。

１つの例示的実施形態は、使用されるグラフィック言語の種類にかかわらず、適切な符号化メカニズムを判定することによって、ローカルデバイス上で実行されるアプリケーションに関してリモートデバイス上に表示するためのグラフィックオブジェクトを効率的に符号化するメカニズムを提供する。メカニズムはローカルデバイス上でアプリケーションを実行することを提供し、それらのアプリケーションのそれぞれは、リモートデバイスにおける表示のために特定のグラフィック言語に基づいてグラフィック表示を生成する。さらに、特定のグラフィック言語に関するグラフィック・セットが受信され、そのグラフィック・セットは、アプリケーションに関するグラフィック表示の少なくとも一部をレンダリングする際に使用されるリソースおよび／または命令を含む。同様に受信されるのは、以下に関する情報を含む符号化データである。すなわち、（１）データ圧縮モジュールが、グラフィック・セットが通常の形態であるときよりも効率的にグラフィック・セットを圧縮するのを助けるために使用される、グラフィック・セット内のフィールドの内容を記述するメタデータ、および／または（２）グラフィック・セットに対して効率的な圧縮の種類を選択するための、リモートデバイスによってサポートされるデータ圧縮メカニズムを記述する符号化種類データである。受信した符号化データに基づいて、適切な符号化メカニズムが、グラフィック・セットの様々な部分に対して決定される。

その他の例示的実施形態は、アプリケーションに関する（もしあれば）どのリソースがリモートデバイスに送信されるべきかを判定することによって、ローカルデバイス上で実行されるアプリケーションに関してリモート・ディスプレイ・デバイス上にグラフィックオブジェクトを効率的にレンダリングすることを提供する。この実施形態において、アプリケーションもまたローカルデバイス上で実行され、それらのアプリケーションのそれぞれは、リモートデバイスに送信するためのグラフィック表示を生成する。次に、リソースおよび／または表示命令を含むグラフィック・セットが受信され、そのグラフィック・セットは、アプリケーションに関するグラフィック表示の少なくとも一部をレンダリングするために使用されることができる。同様に受信されるのは、以下に関する情報を含むリソースデータである。すなわち、（１）記憶されるリソースの種類にかかわらず、グラフィック・セットに対応するリソースがリモートデバイスに送信され、再利用の目的で集中キャッシュに記憶されたかどうかを判定するための配信状態情報、（２）ローカルデバイスからリソースを転送することなしにアプリケーションに関してリモートデバイス上にリソースを表示するためにリモートデバイス上で現在利用可能な専用のリソースを判定するための、サポートされるアプリケーションの情報、（３）帯域幅もしくはその他のシステム制約を節約するために、完全なリソースの質を落としたバージョンが最初に送信され、質を落としたバージョンを改善するアップデートがその後送信されるようにリソースの部分が漸進的にリモートデバイスに送信されるべきであるかどうかを判定するためのシステム制約データ、および／または（４）グラフィック・セットに対応するリソースがリモートデバイスにおいてユーザによって現在見られることができるか否かを記述する可視性情報である。受信したリソース情報に基づいて、グラフィック・セットの部分が、符号化のために選択される。

別の例示的実施形態は、ローカルデバイス上で実行されるアプリケーションに関してリモートデバイス上でグラフィック表示を生成する際に使用されるレンダリングデータ構造を効率的に同期することを提供する。この実施形態において、その他の実施形態と同様に、アプリケーションがローカルデバイス上で実行され、それらのアプリケーションのそれぞれは特定のグラフィック言語のレンダリングデータ構造を生成し、それらのレンダリングデータ構造は、リソースに関する状態を保有し、リモートデバイス上でアプリケーションに関するグラフィック表示を構成するために使用される保持モードデータ構造（retain mode data structure）である。その後、特定のグラフィック言語に対応するリソースおよび／または表示命令を含むグラフィック・セットが受信され、レンダリングデータ構造を修正することに使用される。さらに、データ圧縮モジュールがより容易に認識し、適切に符号化することができる異なるグラフィック言語に関するグラフィック・セットの間で共通のフィールドに対する構造の種類をデータ圧縮モジュールが特定することを助けるために、グラフィック・セットに関するフィールドの記述を含むメタデータが受信される。受信されたメタデータに基づいて、グラフィック・セットのフィールドが、リモートデバイスに送信し、アプリケーションに関してリモートデバイスにおいてグラフィック表示を構成するために使用されるレンダリングデータ構造をローカルデバイスとリモートデバイスの間で同期するために符号化される。

本発明のさらなる特徴および利点が以下に続く説明において述べられ、その説明からある程度明らかになるか、または本発明の実施によって学習されることができる。本発明の特徴および利点は、添付の特許請求の範囲において具体的に示された機器および組合せを用いて実現および獲得されることができる。本発明のこれらのおよびその他の特徴は、以下の説明および添付の特許請求の範囲からより完全に明らかになり、以降で説明される本発明の実施によって学習されることができる。

本発明の上述のおよびその他の有利な特徴が獲得されることができるやり方を説明するために、上で簡潔に記載された本発明のより具体的な説明が、添付の図面に図示される本発明の具体的な実施形態に対する参照によって行われる。これらの図面は本発明の典型的な実施形態のみを示し、したがって本発明の範囲の限定とみなされてはならないという理解の下で、本発明が添付の図面の使用を通じてより具体的で詳細に示され、説明される。

本発明は、リモートデバイスにおいてローカル・アプリケーションの表示をレンダリングする際に使用されるグラフィック・セットを効率的にリモートで送信するための方法、システム、およびコンピュータプログラム製品にまで及ぶ。本発明の実施形態は、以下でより詳細に検討されるように種々のコンピュータハードウェアまたはモジュールを含む専用または汎用コンピュータを含むことができる。

前置きとして、本明細書における例および説明は、様々な実装において便宜的に本件特許出願人の用語を参照することが認識および理解される。しかし、そのような特定の用語の参照は、本明細書の実施形態を特定のオペレーションシステムまたはその他の種類のシステムに限定するものと解釈されるべきではない。むしろ、本明細書において説明される基本的な機能は、本明細書において説明される機能が望まれる任意のコンピューティング環境またはオペレーションシステムにおいて実施されることができる。

上述のように、現在のネットワークのグラフィック表示をリモートで送信することの先に特定された難点および欠点は、本明細書において提供される例示的実施形態を通じて克服される。例えば、一実施形態は、異なるグラフィック言語にまたがる様々なフィールドの共通性が特定されるように特定のグラフィック言語に関するグラフィック・セットのフィールドを特定するために使用されるメカニズムであるフィールド符号化（field encoding）を提供する。特定されると、グラフィック・セットのフィールド内の様々なデータの種類にまたがって関連付けられた冗長性または特定された共通性が、効率的に符号化されることができる。例えば、フィールドの間の冗長性または共通性は、以下の技術のうちの１つまたは複数を適用することによって削除されるか、または効率的に圧縮されることができる。すなわち、（１）フィールドに対して提供されたメタデータまたはその他の情報に基づく、マシンフォーマットとネットワークフォーマットの間のフィールドの変換、（２）可変長のフィールドの符号化（例えば、２／３／４バイト符号化）、（３）点が配列内の前の点に対する差分として符号化されることができ、差分が絶対座標よりも少ないバイト数で表されることができる、概して座標の配列を符号化するために使用される差分符号化、（４）特定の種類の構造を、同じ種類の前に符号化された構造に基づいて符号化するために使用されるインターオーダ圧縮（inter-order compression）である。上記のメカニズムは、現在、その他のプロトコル（例えば、リモート・デスクトップ・プロトコル（ＲＤＰ：Remote Desktop Protocol））において適用されることができるが、本明細書において提供される実施形態は、フィールド符号化をグラフィック・デザイン・インターフェース（ＧＤＩ：Graphics Design Interface）以外のその他のグラフィック言語、例えば、ウィンドウズ（登録商標）プレゼンテーション・ファンデーション（ＷＰＦ：Windows（登録商標） Presentation Foundation）情報に拡張することに留意されたい。

別の実施形態において、異種のリソースは、それらのリソースを記憶するときに同種の方法で扱われるようにリソースのキャッシュが提供される。現在のメカニズム（ＲＤＰなど）は、後の操作または命令でリソースを再利用することによって帯域幅を節約するためにクライアント上のリソースを記憶することを可能にするが、本発明は、（例えば、ＷＰＦのようなＧＤＩ以外の）その他のグラフィック言語において使用するためにキャッシュメカニズムを拡張する。例えば、現在のメカニズムは、リソースの種類（例えば、グリフ、ビットマップ、スプライトなど）を別個のキャッシュに記憶し、それによって、リソースを再利用することに対する拡張不可能なアプローチを提供する。したがって、実施形態は、全てのリソースに対してそれらのリソースの種類にかかわらず集中キャッシュを提供する、より包括的で拡張可能なメカニズムを提供する。したがって、リソースは、レンダリングデータ構造内で、または異なるアプリケーションに関するデータ構造にまたがってさえ複数回使用されることができ、したがって、リソースは、リモートデバイスに１回送信され、様々な構成のサブ構造（例えば、サブツリー）にまたがって使用されることのみを必要とする。

さらに別の実施形態において、グラフィック・セット内のリソースまたはその他のアイテムをリモートで送信するための符号化または圧縮の種類が、リモートデバイスによってサポートされる圧縮メカニズムの種類に基づいて決定されることができる。そのような場合、利用可能な圧縮メカニズムが、接続時にクライアント（すなわちリモートデバイス）とサーバ（すなわちローカルデバイス）との間でネゴシエーションされることができるが、リソースを圧縮するためにサーバによって使用される厳密な圧縮メカニズムは、ローカルデバイスによって圧縮時に決定される。したがって、ローカルデバイスは、各フォーマットが所与のデータをどれだけよく圧縮するかに基づいて、ネゴシエーションされたフォーマットのうちの１つを選択する。例えば、様々な圧縮技術から選択されることができる１つの圧縮の種類が、単一のリソースに対して使用されることができる。次に、データ量を最も効率的に削減する結果として得られる圧縮メカニズムが、リモートデバイスにリソース（またはその他のデータ）を送信するために使用されることができる。ローカルサーバは、圧縮する様々なリソースまたはその他のデータに基づいて可逆圧縮フォーマットまたは不可逆圧縮フォーマットのいずれかを選択することができる。

さらにその他の例示的実施形態は、部分的に送信されたリソースを用いてレンダリングすることによって応答性を向上することを提供する。したがって、帯域幅またはディスプレイデバイスの制約などの様々なシステム制約に基づいて、リソースの一部が、アプリケーションによって何らかの意味のあるものをレンダリングするためのフルレンダリング命令と共に送信されることができる。例えば、ビットマップまたはその他のリソースは、そのような漸進的な技術を用いて圧縮された画像を含むことができる。そのような場合、カラー画像は、完全な画像を解凍するために必要な全てのデータがクライアントデバイスに到着している訳ではないので最初は不正確である可能性がある。しかし、リモートデバイスは、最初のレンダリングのために不鮮明な画像またはその他の質を落とした画像を使用することができる。

例として、アプリケーションに関するボタンは、非常に不正確な色を有する可能性があるが、しかし、ユーザがボタンの最終バージョンを待つことなしにボタンと対話することを可能にするのに十分なだけ優れたやり方でボタンをやはり表示することができる。画像からのさらなるデータがネットワークから到着するにつれて、リモートデバイスは画像をアップデートすることができ、画像を含むデータ構造の一部を再レンダリングすることができる。このように、単に、ほとんどの場合、ユーザが画像データの全てがアップデートされることなしにアプリケーションを使用することができるので、ユーザの知覚される応答性が劇的に向上する。色の質を落とすメカニズムの使用が使用されたが、任意の種類の漸進的な符号化またはインターレース技術も使用されることができることに留意されたい。さらに、そのような漸進的またはインターレースメカニズムはビットマップまたはその他の同様のリソースに適用される可能性があるだけでなく、曲線または格子などの様々な配列を有する画像に対しても良好に機能することに留意されたい。

さらに別の例示的実施形態において、（もしあれば）グラフィック・セットのどの部分がリモートデバイスに送信されるべきか、およびどのような順序で送信されるべきかを判定するためのメカニズムが提供される。例えば、グラフィック表示またはリソースの一部はユーザに見えない可能性があることが多い。したがって、Ｚオーダ、透明度、最小化／最大化状態などが、アプリケーションまたはアプリケーションのリソースがユーザに見える出力を生成するかどうかを判定することに効果的な役割を果たす。アプリケーションまたはアプリケーションのリソースが見えない限り、そのアプリケーションのコンテンツまたはリソースをリモートで送信することは後になるまで必要ない可能性がある。したがって、アップデートは、帯域幅が許すまで遅らされることができる。さらに、ローカルサーバは、そのような可視性の情報に基づいて、レンダリングデータ構造または表示のどの部分がリモートデバイスに送信されるかを優先順位付けすることができる。

さらにその他の実施形態は、リモートデバイス上での専用のリソースをレンダリングするときにローカルデバイスとリモートデバイスの間のリソースの転送を排除するために、リモートデバイス上での専用のリソースの使用を提供する。例えば、グラフィックデータがリモートで送信されるほとんどの場合、境界、タイトルバー、および／またはその他のアイコンのようなリソースは、サーバおよびリモートコンピュータの両方に存在する。例えば、リモートおよびローカルサーバの両方が同じ（または同様の）アプリケーションをインストールする場合、おそらく、ローカル・アプリケーションに関するアイコンは、リモート側のアプリケーションに関するバイナリのリソースの部分に存在する。そのような場合、ローカルデバイスは、サーバまたはローカルデバイスがリモートデバイスのためにリソースのバイトを送信する必要なしに、これらの様々なリソースを使用するようにリモートデバイスに命令することができる可能性がある。

有利な特徴に関するより具体的な言及が図に関して以下でより詳細に記載されるが、本発明の範囲内の実施形態は、コンピュータ可読媒体上に記憶されたコンピュータが実行可能な命令またはデータ構造を搬送または保有するためのコンピュータ可読媒体も含む。そのようなコンピュータ可読媒体は、汎用または専用コンピュータによってアクセスされることができる任意の利用可能な媒体であることができる。限定ではなく例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくはその他の光ディスク記憶装置、磁気ディスク記憶装置もしくはその他の磁気記憶装置、またはコンピュータが実行可能な命令もしくはデータ構造の形態で所望のプログラムコード手段を搬送もしくは記憶するために使用されることができ、汎用もしくは専用コンピュータによってアクセスされることができる任意のその他の媒体を含むことができる。情報がネットワークあるいは（有線、無線、または有線もしくは無線の組合せのいずれかである）別の通信接続を介してコンピュータに転送または提供されるとき、当然、コンピュータは当該接続をコンピュータ可読媒体として見る。したがって、当然、任意のそのような接続はコンピュータ可読媒体と呼ばれる。上記の媒体の組合せもコンピュータ可読媒体の範囲に含まれるべきである。

コンピュータが実行可能な命令は、例えば、多目的コンピュータ、専用コンピュータ、または専用処理デバイスに特定の機能もしくは一群の機能を実行させる命令およびデータを含む。発明の対象が構造的特徴および／または方法の動作に特有の言語で説明されたが、添付の特許請求の範囲で定義された発明の対象は上述の特定の特徴または動作に必ずしも限定されないことを理解されたい。むしろ、上述の特定の特徴および動作は、特許請求の範囲を実施する例示的な形態として開示される。

本明細書において使用される用語「モジュール」または「コンポーネント」は、コンピューティングシステム上で実行されるソフトウェアオブジェクトまたはルーチンを指すことができる。本明細書において説明される様々なコンポーネント、モジュール、エンジン、およびサービスは、コンピューティングシステム上で実行されるオブジェクトまたはプロセスとして（例えば、別個のスレッドとして）実装されることができる。本明細書において説明されるシステムおよび方法はソフトウェアで実装されることが好ましいが、ハードウェア、またはソフトウェアおよびハードウェアの組合せでの実装も可能であり、考えられる。この説明において、「コンピューティングエンティティ」は、本明細書において既に定義された任意のコンピューティングシステム、またはコンピューティングシステム上で実行される任意のモジュールもしくはモジュールの組合せである可能性がある。

図１Ａは、ローカルデバイス上のアプリケーションに関するグラフィック情報をリモートで表示することに使用される分散システムを示す。示されるように、アプリケーション１１５がローカルデバイス１０５上で実行されることができ、そのアプリケーションの表示はリモートデバイス１１０を対象とする。アプリケーション１１５は、テキストエディタ、表計算アプリケーション、または任意のその他のよく知られているアプリケーションなどの多数のアプリケーションのうちのいずれかのアプリケーションであってよいことに留意されたい。さらに、リモートデバイス１１０およびローカルデバイス１０５のための環境は、リモートデバイス１１０が、ローカルデバイス１０５のアプリケーション１１５を実行し、さらに、ローカルデバイス１０５のネットワークの外のリモートデバイス１１０からアプリケーションを見て、制御したいと望むプレゼンテーションタイプの環境（例えば、上述のデスクトップ共有）またはネットワーキングシステムであってよい。したがって、ローカルデバイス１０５とリモートデバイス１１０の間の通信は、任意のよく知られているローカルおよび分散の両方のネットワーク、例えば、ＬＡＮ、インターネットなどをまたがる可能性がある。

ローカルデバイス１０５とリモートデバイス１１０の間の通信チャネルを確立するために使用されるアプリケーションまたはネットワークの種類によらず、アプリケーション１１５は、リモートデバイス１１０から受信されたユーザ入力に従ってアプリケーションプログラムインターフェース（ＡＰＩ）コール１２０を行うことができる。そのようなＡＰＩコール１２０は、様々なアプリケーション１１５のグラフィック表示に影響を与える。例えば、ＡＰＩコール１２０は、アプリケーション１１５の表示を最小化／最大化すること、表示内のアイコンもしくはその他のリソースを移動すること、または１つまたは複数のアプリケーション１１５に関するグラフィックの表示と対話し、グラフィックの表示を変更する任意の数のよく知られているやり方である可能性がある。言うまでもなく、認識されるであろうように、様々なアプリケーション１１５のグラフィック表示が変わるために、入力がＡＰＩコール１２０の形態で届くことは必須ではない。したがって、様々なアプリケーション１１５のグラフィック表示に影響を与えるためのＡＰＩコール１２０の使用は、本明細書においては例示のみを目的として使用され、本明細書の実施形態の範囲を限定するか、またはそうでなければ狭めるように意図されない。

しかしながら、そのようなコール１２０を使用するとき、ＡＰＩコール１２０は、表示命令１６０および／または様々なリソース１６５を含むことができるグラフィック・セット１５５を生成する合成エンジン１３０を呼び出すことができる。表示命令１６０は、リソース１６５の種類、表示内の位置付け（すなわち、ｘｙ座標）、リソース１６５のサイズおよび／もしくは形状、または様々なリソース１６５を表示するために使用される任意のその他のよく知られているプロパティもしくは操作などの情報を含むことができる。リソース１６５は、任意の数のよく知られているアイコン、テキスト、グリフ、スプライト、ビットマップ、およびその他の画像の種類を表すこともできる。したがって、本明細書において説明される表示命令１６０およびリソース１６５は、リソース上で実行される任意の数の様々な操作、およびアプリケーション１１５のグラフィックの表示のために使用される任意の数の画像データを包含するように広く解釈されるべきである。

概して、グラフィック・セット１５５は、様々なアプリケーション１１５に関するレンダリングデータ構造１７８を生成するために使用される。そして今度は、レンダリングデータ構造１７８は、アプリケーション１１５の表示を記述するために使用され、各ノードがリソース、プロパティ、またはそれらの関係を示す記述を表すツリー状構造であることができる。例えば、データツリー内のあるノードはボタンを表すことができ、一方、その他のノードはボタンの色、サイズ、形状、またはその他のプロパティを記述し、一方、さらにその他のノードはアプリケーション１１４の表示内のその他のコンポーネントまたはリソースとの関係および対話を表す。したがって、認識されるであろうように、グラフィック・セット１５５は、レンダリングデータ構造１７８を修正、生成、またはそうでなければアップデートするために使用される可能性があり、そのとき、レンダリングデータ構造１７８は、アプリケーション１１５に対応する１つまたは複数の表示を構成するために使用されることができる。上述のその他のグラフィック言語の即時表示モード（immediate presentation mode）とは異なり、レンダリングデータ構造１７８、１８５の使用は、リソースに関する状態が保有される保持モードを可能にすることに留意されたい。以下でより詳細に説明されるように、これは、本明細書において説明されるその他の実施形態と共に、多くの有利な特徴を可能にする。

一実施形態において、ローカルデバイス１０５上のレンダリングデータ構造１７８と、リモートデバイス１１０側の同様のレンダリングデータ構造１８５とを同期することが望ましいことに留意されたい。そのような場合、本明細書において提供される例示的実施形態は、リモートデバイス１１０上のレンダリングデータ構造１８５のアップデートまたは修正のために様々なグラフィック・セット１５５を効率的に符号化することができる。しかし、本明細書において提供される一部のメカニズムは、レンダリングデータ構造１７８、１８５をサポートするグラフィック言語に対して使用されるが、その他の実施形態は、そのようなレンダリングデータ構造１７８、１８５をサポートしないグラフィック言語に同様に適用可能であることに留意されたい。実際、本明細書において説明される実施形態のうちの多くは、ＧＤＩ、ＷＰＦ、ならびにその他の知られている（および知られていない可能性がある）グラフィック言語を含むがこれらに限定されない多種多様なグラフィック言語に対して使用される。したがって、様々な実施形態の以下の検討は、幅広い数のグラフィック言語にまたがって適用可能であるように広く解釈されるべきである。

グラフィック・セット１５５を生成するために使用されるグラフィック言語にかかわらず、概して、符号化決定モジュール１５０は、レンダリングデータ構造１７８（すなわち、保有モード合成データ構造（retained mode composition data）またはツリー）に対して直接動作することに留意されたい。符号化決定モジュール１５０は、アプリケーション１１５が合成エンジン１３０を呼び出す１２０ときに直ちにレンダリングデータ１７８を送信する可能性があるか、またはネットワークが認めるときに後でデータ１７８を送信する可能性がある。例えば、アプリケーション１１５は、円を生成するためにエンジン１３０を呼び出す１２０可能性がある。命令１２０は符号化決定モジュール１５０に対する直接呼び出しに変換される可能性があり、後者は、即座に円命令を符号化し、それを回線で送信する。代替的なモデルは、符号化決定モジュール１５０が、円がレンダリングデータ構造１７８（例えば、合成ツリー）に追加されたことを知らされる可能性があり、データ１７８がいつ送信されるべきかを符号決定モジュール１５０に決定させる可能性がある。第１のモデルは「プッシュ」モデルとみなされることができる一方、第２のモデルは「プル」モデルである可能性がある。２つの間の相違は、単に、符号化決定モジュール１５０がレンダリングデータ構造１７８からアップデートを取得する時期である。両方のモデルとも機能するが、プッシュモデルはプルモデルよりも制限される可能性がある。したがって、最も効率的なアップデートメカニズムは、２つの間の複合である可能性がある（すなわち、データ１７８は帯域幅が許すだけ速くネットワークにプッシュされるが、何らかのネットワークの輻輳が存在する場合、システムは、ネットワークの利用可能性のイベントによって駆動されるプルモデルを採用する）。

データ１７８を転送するために使用されるモデルにかかわらず、一実施形態において、符号化決定モジュール１５０は、グラフィック・セット１５５内の様々な種類のフィールドを特定するために、グラフィック・セット・メタデータ１４０（本明細書においては単に「メタデータ」とも呼ばれる）を有する符号化テーブル１３５を使用することができる。例えば、メタデータ１４０は、グラフィック・セット１６０内の様々な種類のフィールドを記述することができ、符号化決定モジュール１５０が、表示命令１６０およびリソース１６５のリモートデバイス１１０への効率的な転送のために様々なフィールドをどのようにして最も上手く符号化するかを適切に判断するために使用することができる。より具体的には、メタデータ１４０は、異なるグラフィック言語に関する複数のグラフィック・セット１５５の間に共通するフィールドに関する異なる種類のデータ構造を特定するために使用されることができる。そのとき、そのような情報は、データ圧縮モジュール１７５がグラフィック・セット１５５の異なるフィールドをより容易に認識し、適切に符号化するのを助けるために使用されることができる。

例えば、表示命令１６０は、従来、マシンフォーマットで記憶されるかまたはシリアル化されるリソースの種類、位置付け（例えば、ｘｙ座標）、色、またはその他の情報を含む文字列またはその他のバイナリ表現を有する可能性がある。したがって、メタデータ１４０は、これらのフィールドをマシンフォーマットで記憶されている文字列として認識するために使用されることでき、それらのフィールドは、次に、ネットワークフォーマットに変換されることができる。例えば、通常、座標（またはその他の文字列もしくはバイナリフィールド）は、レンダリングのために使用されるローカルデバイス１０５上のグラフィック・セット１５５内にマシンサイズワード（machine size word）として保有されるが、マシンワードは、ほとんどの場合、そのような座標を記憶するために必要な実際のバイトサイズの２倍から４倍大きい。そのような場合、マシンワードは、より小さいサイズに変換され、ネットワークパケット内に置かれるべきであり、それによって、データ圧縮モジュール１７５がリモートデバイス１１０への伝送の前にこれらのフィールドをより効率的に符号化することを可能にする。

その他の実施形態は、圧縮のための最も効率的なメカニズムを特定するためにグラフィック・セット１５５内のその他のフィールドまたはリソースを記述するためにグラフィック・セット・メタデータ１４０を使用する。例えば、符号化決定モジュール１５０は、そのような情報を最も効果的に圧縮することができるデータ圧縮モジュール１７５を選択するためにリソース１６５の種類を判定するメタデータ１４０を使用することができる。例えば、一部のビットマップは、ランレングス符号化（ＲＬＥ）メカニズムを使用して最もよく符号化される。したがって、メタデータ１４０が、リソース１６５をビットマップとして特定するために使用されることができ、適切なＲＬＥが、そのようなリソースを適切に符号化するために選択されることができる。

もちろん、提供されたグラフィック・セット・メタデータ１４０に基づいて特定され、適切に符号化されることができる、表示命令１６０に関する多くのその他の種類のリソース１６５およびフィールドが存在する。例えば、１つのフィールドが可変長フォーマットで最もよく符号化されると特定される可能性がある一方、別のフィールドは差分符号化により適する可能性がある（例えば、ある点が配列内の前の点に対する差分として符号化されることができ、差分が絶対座標よりも少ないバイト数で表されることができる座標）。その他の例は、通常、特定の種類の構造を同じ種類の前に符号化された構造に基づいて符号化するために使用されるインターオーダ圧縮を含む可能性がある。もちろん、認識されるであろうように、メタデータ１４０は、多数の圧縮モジュール１７５が必要に応じて符号化決定モジュール１５０によって適切に選択されることができるように、任意の数の様々な表示命令１６０およびリソース１６５を記述するために使用されることができる。したがって、符号化のための特定の種類のデータの上記の使用、または本明細書において説明される任意の特定の種類の符号化は、例示のみを目的とし、本明細書の実施形態を限定するか、またはそうでなければ狭めるように意図されない。

メタデータ１４０はグラフィック・セット１５５とは別の符号化テーブル１３５に示されるが、その他の実施形態は、やはりメタデータ１４０をグラフィック・セット１５５の一部とみなす。さらに、本明細書において説明される様々なモジュールの配置は、その他の構成および／もしくは概略的レイアウトと組み合わされることができ、ならびに／またはその他の構成および／もしくは概略的レイアウトに分けられることができることに留意されたい。したがって、様々な図に示される概略的レイアウト、および本明細書において説明されるモジュールまたはコンポーネントは例示のみを目的として使用され、明示的に特許請求の範囲に記載されない限り、様々な実施形態の範囲を限定するか、またはそうでなければ狭めるように意図されない。

また、メタデータ１６５は、実行時情報またはコンパイル時情報であることができることに留意されたい。例えば、拡張可能マークアップ言語（（ＸＭＬ）またはその他の好適なバイナリフォーマット）ドキュメントが、実行時に交換されるメタデータ１６５を含むことができる。２つの間の相違は、概して、実行時情報が、メタデータファイル（例えばＸＭＬドキュメント）が符号化決定モジュール１５０に渡されることを可能にする特定の関数呼び出しを通じて合成エンジン１３０によってプッシュされるという事実である。通常、実行時メタデータ１６５は、初期化のときに一度だけプッシュされる。その時点以降、合成またはレンダリングエンジン１３０は、符号化決定モジュール１５０が符号器を呼び出す度にグラフィック・セット１５５を符号化決定モジュール１５０に全て示す必要はない。その代わりに、合成エンジン１３０は、最初のメタデータ１６５の交換において定義された明確に定義された種類をストリーム内の各オーダ（ｏｒｄｅｒ）（すなわち、表示命令および／またはリソース）の初めに付ける（または特定する）必要があるだけである。以下の例が助けとなるであろう。

例えば、メタデータ１６５が実行時に交換されると仮定すると、メタデータ１６５は以下のＸＭＬファイルのようになる可能性がある。

上のＧＦＸＭＥＴＡＤＡＴＡ構造において、２つのオーダの種類が宣言される。第１のオーダの種類は、２つの浮動小数点数を含むオーダの種類である。第２のオーダの種類は、１つの符号付き整数、１つの符号なし整数、および座標の１つの配列を含む配列である。このメタデータは、初期化のときに符号化決定モジュール１５０に伝達されるべきである。初期化の後、第２の構造（ＯＲＤＥＲ）が、オーダを符号器１５０に送信するために使用されることができる。どのようにして第２の構造が種類を記述せず、値だけを記述するかに留意されたい。ＸＭＬの表現においてさえ、第２のデータ構造（ＯＲＤＥＲ）からメタデータを分けることによって、より少ない情報が、オーダに関する内容を符号化決定モジュール１５０に伝達するために必要とされることが理解される。メタデータ１４０は非常に静的であり、したがって、一度だけ送信されることは理に適っている。一方、オーダデータは、動的なデータであり、概して、いかなる静的な情報もそのオーダデータに付加しなかったはずである。そのような利点は、（以下で説明される）バイナリフォーマットがＸＭＬの代わりにデータおよびメタデータの両方に関して使用されるときによりはっきりと分かる。符号器または符号化決定モジュール１５０はオーダの種類だけを見る可能性があり、メタデータの記述に基づいて、値をどのように符号化するかを知ることになる。

例えば、その他のファイル（例えば、インターフェース定義または記述言語（ＩＤＬ）ファイル）が、符号器１７５または符号化決定モジュール１５０と合成エンジン１３０との間のコンパイル時コントラクトを表す。コントラクトが変化している場合、２つのコンポーネントは、共通の（例えばＩＤＬ）ファイルを使用して再コンパイルされる必要がある。共通のファイルを使用することは、デバイスが同じバイナリデータ構造フォーマットに対して動作することを保証する。しかし、コンパイル時にデータを記述することは、符号化コード自体がグラフィックデータの記述から直接生成されるので、おそらく（上述の）符号化決定モジュール１５０のより高速な動作をもたらすことに留意されたい。しかしながら、コンパイル時の記述は、使用される言語に大きく依存する。例えば、ＣおよびＣ＋＋においては、マクロの集合が、グラフィックプリミティブを定義するために使用されることができる。マクロを使用することによって、人は、マシンフォーマット構造および符号化またはネットワークコード自体の両方を定義することができる。

適切なデータ圧縮１７５がグラフィック・セット１５５内の１つまたは複数のフィールドを符号化してしまうと、これらのフィールド（またはグラフィック・セット１５５）はリモートデバイス１１０に送信され、そこで、これらのフィールド（またはグラフィック・セット１５５）はモジュール１８０を使用して解凍され、グラフィック・セット１９０に示されるように再生成される。したがって、合成エンジン１９５は、これらを使用して、ローカルデバイス１０５上のレンダリングデータ構造１７８と同期しているレンダリングデータ構造１８５を生成することができる。さらに、そのとき、このレンダリングデータ構造１８５は、ディスプレイドライバ１０４が、ローカルデバイス１０５からのアプリケーション１１５の表示を表す適切なディスプレイ１０２を生成することができるように構成されることができる。したがって、リモートデバイス１１０上のユーザがディスプレイ１０２と対話するとき、異なるグラフィック・セット１５５が生成されることができ、レンダリングデータ構造１７８、１８５を同期するために上述のように符号化する。

別の例示的実施形態において、選択される符号化の種類またはデータ圧縮モジュール１７５は、リモートデバイス１１０上のそれらのサポートされる符号化の種類に基づくことができる。例えば、接続の初期化中に（または、その後の何らかのその他の時点で）、データ圧縮の種類が、ローカルデバイスとリモートデバイス１１０との間でネゴシエーションされることができる。したがって、図示するように、リモートデバイス１１０はサポートされる符号化の種類１８４を送信し、次に、そのサポートされる符号化の種類１８４は利用可能な符号化メカニズムのリスト１４５に含まれることができる。そのとき、利用可能な符号化メカニズムのこのリスト１４５は、符号化決定モジュール１５０によって、上述のようにグラフィック・セット１５５内のフィールドを圧縮するために適切なデータ圧縮モジュール１７５を選択することに使用されることができる。

利用可能な符号化メカニズム１４５は概して接続時にリモートデバイス１１０とローカルデバイス１０５との間でネゴシエーションされるが、グラフィック・セット１５５の一部を圧縮するためにローカルデバイス１０５によって使用される厳密な圧縮メカニズムは、圧縮時にオンザフライ（on-the-fly）で決定されることに留意されたい。したがって、リモートデバイス１１０は、使用されることになるデータ圧縮１７５の厳密な種類について事前の知識を持たない。しかしながら、サポートされる符号化の種類１８４が前もって判定されるので、ローカルデバイス１０５は、任意のそのようなサポートされる符号化の種類１８４の使用がリモートデバイス１１０によって処理されることができることを保証されることができる。また、利用可能な符号化メカニズムのリスト１４５は、ローカルデバイス１０５上で利用可能な符号化メカニズムにも基づくことができることにさらに留意されたい。換言すると、データ圧縮モジュール１７５およびデータ解凍モジュール１８０は、それらの間で共通の種類を有する必要がある。

また、本明細書において検討されるように、任意のよく知られている種類の符号化メカニズムが使用されることができる（例えば、ＲＬＥ、ＭＰＥＧベース、ＪＰＥＧ、ＧＩＦ、ＺＩＰ、ＬＺベース、ＪＢＩＧ、ＤｅｊａＶｕ、または可逆圧縮フォーマットまたは不可逆圧縮フォーマットのいずれかであるその他のよく知られているパターンまたは統計に基づく圧縮メカニズム）ことに留意されたい。また、グラフィック・セット１５５内のフィールドのうちの１つまたは複数は、リモートデバイス１１０にネットワークを介して送信するためにデータを最も効率的に圧縮するために様々な符号化またはデータ圧縮モジュール１７５の階層関係を使用して符号化されることができることに留意されたい。

図１Ｂは、ローカル１０５およびリモートデバイス１１０の両方を有する上述と同様の分散システムを示す。図１Ｂは上述のシステムの簡素化されたバージョンであり、したがって、概略図を簡素化するためにコンポーネントまたはモジュールを省略して示されることに留意されたい。しかし、その図に示された実施形態においては、どの符号化の種類がグラフィック・セット１５５を符号化するために使用されるべきかを判定するのではなく、様々なメカニズムが、リモートデバイス１１０に送信するリソース（もしあれば）を選択するために使用される。１つのそのような実施形態において、異種のリソースがそれらのリソースを記憶するときに同種のやり方で扱われるアプリケーションのリソースのキャッシュが提供される。

例えば、第１のアプリケーション（例えば、アプリケーション１）１１５は、リソース「Ａ」１０６の要求を行うことができる。リソースがネットワークを介してリモートデバイス１１０に送信されるとき、そのようなリソースの配信の状態がリソーステーブル１１２に記憶されることができる（この場合、リソース「Ａ」１１４の配信の状態を転送済みと示す）。リモートデバイス１１０上で、リソース「Ａ」１０６は、集中キャッシュ１２８内のリソースのリスト１１８に示されるように集中キャッシュ１２８に記憶される。したがって、次にアプリケーション１１５がリソース「Ａ」１０６を使用したいと望むとき、リモートデバイス１１０に当該リソースを送信するのではなく、リソースマネージャ１０８は、リソースが既に送信されたことを特定し、単に、リソースデバイス１１０への送信のためのリソースＩＤ１６１を有する表示命令１６０を提供する。換言すれば、リソース（この場合、リソース「Ａ」１０６）は、ローカル１０５デバイスとリモート１１０デバイスとの間の接続中に一度送信されることだけを必要とし、様々な異なるアプリケーション（例えば、同様にリソース「Ａ」１０６を呼び出すアプリケーション２）にまたがって繰り返し使用されることができる。

特定のプロトコル（例えば、ＲＤＰ）によって使用される一部のキャッシュメカニズムはリソースのキャッシュを可能にするが、概して、そのようなキャッシュは、使用されるリソースの種類（例えば、グリフ、ビットマップ、スプライトなど）に基づいて分けられることに留意されたい。そのようなメカニズムは本明細書において提供される、より包括的な集中キャッシュメカニズムと同程度に効率的である可能性があるが、これらのアプローチは拡張不可能である。全てのリソース１８０を記憶するための集中キャッシュ１２８を提供することによって、本発明は、様々なアプリケーション１１５にまたがって、および使用されることができる異なるレンダリングデータ構造１７８、１８５にまたがってそのようなリソース１０６を使用する能力を拡張する。例えば、本明細書において提供される包括的なキャッシュメカニズム（例えばＲＤＰを使用する）は、リソースが一度だけ送信され、合成構造またはツリー内の複数のノードによって使用されるというさらなる利点を有する。例えば、アイコンが複数のアプリケーション１１５によって使用される場合、そのアイコンは、それらのアプリケーション１１５に対応する合成サブツリー（またはレンダリングデータ構造１７８、１８５）のそれぞれに存在する。

そのようなキャッシュメカニズムがない場合、リソースは、そのリソースを使用する各ノードのためにリモートデバイス１１０に送信される必要がある。しかし、本明細書において提供される集中記憶メカニズムを用いる場合、リソース１６５は、リソース１６５がノードに初めて追加されるときに一度だけ送信され、合成データ構造内の複数のノードによって使用される。また、ローカルデバイス１０５およびリモートデバイス１１０は、大きく異なるサイズのリソースをキャッシュすることによって引き起こされるメモリのフラグメンテーションを制限するメカニズムを使用してもしなくてもよいことに留意されたい。さらに、拡張不可能なアプローチはリソースにアクセスするための効率的なメカニズムを依然として提供することができるので、そのようなアプローチが、本明細書において提供される包括的なキャッシュと併せて使用されることができることに留意されたい。

さらに別の例示的実施形態において、部分的に送信されたリソースを用いてレンダリングすることによって応答性を向上するためのメカニズムが提供される。そのような場合、帯域幅などのシステム制約１１６、またはリモートデバイス１１０上のディスプレイの制約が、リソースマネージャ１０８を含む符号化決定モジュール１５０によって特定されることができる。そのようなシステム制約１１６に基づいて、リソースマネージャ１０８は、部分的なリソース１６３だけが、上述のようにグラフィック・セット１５５に関する表示命令１６０で送信されるべきであることを判定することができる。より具体的には、概して、グラフィック・セット１５５をレンダリングするために必要な２つの情報が存在する。本明細書において表示命令１６０として示される第１の部分は、リソース１６５に関する実際のレンダリング操作を記述する。概して、それらは、リソース１６５がレンダリングのためにどのように使用されるべきか、およびどのリソース１６５がレンダリングのために使用されるべきかについての命令を含む。第２の部分は、レンダリングのために使用されるリソース１６８を表す。

理解されることができるように、概して、レンダリングまたは表示命令１６０は、レンダリングが開始することができる前にクライアントまたはリモートデバイス１１０に全て送信される必要がある。しかし、これはリソース１６５には当てはまらない。リソース１６５は、レンダリングが、アプリケーション１１５によってレンダリングされる意味がある何らかのもののために開始するとき、常に１００％利用可能でなければならない訳ではない。例えば、最初のビットマップリソース１６５は、漸進的な技術を用いて圧縮された画像を含むことができる。例えば、画像の色は、様々な帯域幅の制約、またはその他の考慮すべき事項のために初めは不正確である可能性がある。しかしながら、リモートデバイスは、リモートデバイス上でのレンダリングのためにこの不鮮明な、色のおかしい、またはその他の点で質を落とした画像を使用することができる。

例えば、リソース１６５がボタンである可能性がある場合を取り上げると、色が非常に不正確である可能性があるか、または何らかのその他の質の低下が見られる可能性があるが、ボタンの表示は、ユーザがボタンの最終バージョンを待つことなしにボタンと対話することを可能にするのに十分であることができる。しかしながら、画像からのさらなるデータがネットワークから到着するにつれて、リモートデバイス１１０は画像またはレンダリングデータ構造１８５をアップデートすることができる。したがって、ほとんどのユーザがリソース１６５の全てが存在することなしにアプリケーションを使用することができる場合に、ユーザによる知覚される応答性が劇的に向上される。例は色の質を落とす技術を使用するが、任意の種類の漸進的な符号化またはインターレースメカニズムが同様に使用される可能性があることに留意されたい。

また、この部分的レンダリングメカニズムは、保持モードのシステムに対して上手く機能することができるが、その他のモデル（例えばＧＤＩ）に対してはそれほど上手く機能しない可能性があることに留意されたい。理由は、保有モードにおいては、レンダリングデータ構造１８５（例えば合成ツリー）が、改善されたリソース１６５を用いてアップデートされると、全ての情報が、再描画を引き起こすためにリモート側１１０にあるからである。しかし、その他の非保持モデル（例えばＧＤＩモデル）においては、リモート１１０側に再構成するためのメカニズムが存在しない可能性があり、したがって、描画が不正確なリソースを用いて行われる場合、概して、ローカル１０５またはサーバ側が描画操作において再びそのリソース１６５を使用するまで描画をリフレッシュするメカニズムが存在しない。しかしながら、非保持モデルにおいてさえ、何かをレンダリングする前にリソース１６５全体を待つのではなく不正確なリソース１６５を使用してレンダリングすることが好ましい場合が存在する可能性がある。

図１Ｄは、曲線１４２において表示される座標の配列を使用する上記の実施形態を示す。図示するように、完全なリソースセット１４４は、曲線１４２に沿った多数の点を含む。しかし、実施形態は、システム制約１１６を使用して、部分的なリソースセット１４８のみが送信されるべきであることを判断する可能性がある。例えば、この例においては、曲線１４２を正確に表さないが、依然として画像全体の妥当な描画を可能にする曲線１４６に沿った点の一部だけが送信される。換言すると、正確な曲線１４２は、各点がその曲線に関するデジタルサンプルを表す多数の点から近似され、より多くのサンプルが存在するほど、曲線はより正確に見える。しかし、曲線１４２によっては、十分に近い表現１４６が、サンプルの数の一部のみを使用してレンダリングされることができる。点の残りは後でアップデートされることができる。アップデートがローカルデバイス１０５から到着するにつれて、リモートデバイス１１０は、その曲線１４２に関する点の集合をアップデートし、その曲線１４２を使用するデータ構造１８５を再レンダリングする。各アップデートによって、レンダリング曲線１４６は、最終的な意図される形状１４２に次第に近付いていく。

上記の例はグラフィカルな曲線または格子、および単純なボタンを使用するが、より高度なリソース１６５もこの特徴を使用することができることに留意されたい。例えば、最終形態が３Ｄオブジェクトである画像が、最初に、２Ｄオブジェクトの中間形態で示されることができる。帯域幅が利用可能になるにつれて、益々多くの情報が、画像をその画像の最終的な３Ｄ形態にアップデートするために送信されることができる。言うまでもなく、認識されるであろうように、この特徴を利用することができる多くの様々なリソース１６５およびメカニズム（すなわち、リソースの一部をどのように送信するか、およびリソースのどの部分を送信するか）が存在する。したがって、上記の例は、本明細書において例示のみを目的として使用され、これらのおよびその他の実施形態の範囲を限定するように意図されない。

さらに別の例示的実施形態において、リソースマネージャ１０８は、ローカルデバイス１０５およびリモートデバイス１１０の両方で専用のリソースを判定または特定することができる。したがって、サポートされるアプリケーションの情報１２２が、接続が初期化されると（またはその後のいずれかのときに）ローカルデバイス１０５に転送されることができる。概して、この情報は、リモートデバイス１１０上でサポートされ、リソースストア１２６に記憶されるアプリケーションのリソース１２４を含む。そのとき、このサポートされるアプリケーションの情報１２２は、リソースマネージャ１０８によって、どの種類のリソースがリモートデバイス１１０に送信されるべきかを決定することに使用されることができる。

例えば、リモート１１０およびローカルデバイス１０５の両方が、特定のアプリケーション（例えば、特定の種類のテキストエディタ）をインストールする可能性がある。したがって、アイコンまたはそれに関連するその他のアプリケーションのリソース１２４も、両方のデバイス１０５、１１０上に配置される。これらの場合、ローカルデバイス１０５は、ローカルデバイス１０５が適切なアイコンに関するリソース１２４を実際に送信する必要なしに、単に表示命令１６０およびリソースＩＤ１６１を使用して、リモートデバイス１１０に適切なアイコンを使用するように命令することができる。しかし、そのようなモデルはリソース１２４がシリアル化された形態で記憶されると仮定することに留意されたい。それらのリソース１２４は必要に応じて変換されることができるが、概して、変換はハードウェアレイヤで行われる。したがって、リソースを変換しないプロトコルまたはグラフィック言語に関して、ローカルデバイス１０５が、回線を介してリソース１２４に関するデータを送信する代わりに、よく知られているリソースＩＤ１６１をクライアントに伝達することができる。リモートデバイス１１０上での専用のアプリケーションのリソース１２４のそのような使用は、リソース１２４のサイズが大きい場合に特に有利である。

厳密なリソース１２４がローカル１０５およびリモート１１０デバイスの両方に存在する必要はないことにも留意されたい。例えば、一部のアプリケーション１１５は、いくつかのアプリケーション１１５の間に共通するリソース１２４を有する。例えば、ほとんどのアプリケーション１１５は、境界と、タイトルバーと、最小化／最大化、全／部分画面、および／または閉じるアイコンに関するウィンドウ命令とを有する。したがって、概して、リモートデバイス１１０上で使用されるアプリケーションのリソース１２４はローカルマシン１０５上の厳密なアプリケーション１１５に対応することになるが、それらのアプリケーションのリソース１２４は、必ずしもローカルマシン１０５上の厳密なアプリケーション１１５に対応する必要はない。

図１Ｃは、ローカルデバイス１０５およびリモートデバイス１１０の両方で使用されることができるか、または専用の様々なリソースの使用を示す。この例において、境界１３２リソースは、アプリケーション画面のウィンドウを縁取るために使用されることができる。さらに、タイトルバー１３５およびウィンドウ操作アイコン１３６も、リモートデバイス１１０上でアクセスされ、使用されることができるアプリケーションのリソース１２４である可能性がある。同様に、様々なコンポーネントまたはアイコンを有するツールバー１３８も利用されることができる。しかしながら、ローカルマシン１０５上で操作されるか、またはそうでなければ変更される情報は、上述の実施形態によって回線を介して送信される必要がある。

さらにその他の例示的実施形態において、上記の符号化およびその他のリソース選択メカニズムが、単一のコンポーネントの一部として実装されることができる。このコンポーネントとアプリケーションまたは合成エンジンとの間のインターフェース（またはコントラクト（contract））は、ＩＤＬまたはＸＭＬのようなインターフェース定義言語によって定義されることができる。しかしながら、コントラクトは、リソース１６５データと、リソース１６５を効率的に符号化するために必要なメタデータ１４０との両方を符号化決定モジュール１５０に提供すべきである。このようにして、リソース１６５のレイアウトまたは編成の変更は、符号化決定モジュール１５０に対するアップデートを必要としない。メタデータ１４０に対するアップデートだけが必要とされ、このアップデートは、インターフェースまたはコントラクトを変更することによって遂行されることができる。

本発明は、機能的ステップおよび／または非機能的動作を含む方法の観点で説明されることもできる。以下は、本発明を実施することにおいて実行されることができるステップおよび／または動作の説明である。通常、機能的ステップは達成される結果の観点で本発明を説明し、一方、非機能的動作は特定の結果を達成するためのより具体的な動作を説明する。機能的ステップおよび／または非機能的動作が特定の順序で説明されるかまたは特許請求の範囲に記載される可能性があるが、本発明はステップおよび／または動作の任意の特定の順序または組合せに必ずしも限定されない。さらに、特許請求の範囲の詳述におけるステップおよび／または動作の使用（のみ）が、そのような用語の所望の特定の使用を示すために使用される。

上述のように、図２〜４は、本発明の様々な例示的実施形態に関する流れ図を示す。図１〜４の以下の説明は、場合によって図１Ａ〜Ｄからの対応する要素を参照する。これらの図からの特定の要素に対する言及がなされる可能性があるが、そのような言及は例示のみを目的として使用され、明示的に特許請求の範囲に記載されない限り、記載の実施形態の範囲を限定するか、またはそうでなければ狭めるように意図されない。

図２は、使用されるグラフィック言語の種類にかかわらず、適切な符号化メカニズムを判定することによって、ローカルデバイス上で実行されるアプリケーションに関してリモートデバイス上に表示するためのグラフィックオブジェクトを効率的に符号化する方法２００に関する流れ図を示す。方法２００は、ローカルデバイス上で（１つまたは複数の）アプリケーションを実行する動作２０５を含む。例えば、アプリケーション１１５はローカルデバイス上１０５で実行されることができ、アプリケーション１１５は、リモートデバイス１１０における表示のために特定のグラフィック言語に基づいてグラフィック表示を生成する。そのようなグラフィック言語は、ＧＤＩ、ＷＰＦ、またはその他の種類の現在知られているかまたは将来のグラフィック言語を含むことができる。

方法２００は、特定のグラフィック言語に関するグラフィック・セットを受信する動作２１０も含む。例えば、符号化決定モジュール１５０が、特定のグラフィック言語に関するグラフィック・セット１５５を受信することができ、グラフィック・セット１５５は、（１つまたは複数の）表示命令１６０および／または（１つまたは複数の）リソース１６５を含む。そのようなグラフィック・セット１５５は、リモートデバイス１１０上でアプリケーション１１５に関するグラフィック表示の少なくとも一部をレンダリングするために使用される。これらの表示命令は、ディスプレイ上の位置、サイズ、色、形状などの観点でリソースを記述するプロパティを含むことができる。リソースは、グリフ、アイコン、スプライト、ビットマップ、または任意のその他の画像などのよく知られているリソースのうちのいずれかのリソースであってよいことにさらに留意されたい。

さらに、メソッド２００は、（１）グラフィック・セットの内容を記述するメタデータ、（２）リモートデバイスによってサポートされるデータ圧縮メカニズムを記述する符号化種類データに関する符号化データを受信する動作２２０を含む。例えば、符号化決定モジュール１５０は、データ圧縮モジュール１７５が、グラフィック・セット１５５が通常の形態であるときよりも効率的にグラフィック・セット１５５を圧縮することを助けるために使用される、グラフィック・セット１５５内のフィールドの内容を記述するグラフィック・セット・メタデータ１４０を受信することができる。この通常の形態は、シリアル化されたまたはシリアル化されていない形態であってよいことに留意されたい。あるいは、または併せて、符号化決定モジュール１５０は、リモートデバイス１１０によってサポートされる利用可能な符号化メカニズムのリスト１４５を受信することができる。この符号化種類データは、上述のようにグラフィック・セット１５５に対して効率的な圧縮の種類を選択するためにリモートデバイス１１０によってサポートされるデータ圧縮メカニズムを記述する。

受信された符号化データに基づいて、方法２００は、グラフィック・セットの一部に対する適切な符号化メカニズムを決定する動作２２５も含む。例えば、メタデータ１４０と利用可能な符号化メカニズムのリスト１４５とに基づいて、符号化決定モジュール１５０は、どのデータ圧縮モジュール１７５が最も効率的にグラフィック・セット１５５の様々な部分を符号化するかを判定することができる。

図３は、アプリケーションに関する（もしあれば）どのリソースがリモートデバイスに送信されるべきかを判定することによって、ローカルデバイス上で実行するアプリケーションに関してリモート・ディスプレイ・デバイス上にグラフィックオブジェクトを効率的にレンダリングする方法３００を示す。方法３００は、ローカルデバイス上で（１つまたは複数の）アプリケーションを実行する動作３０５を含む。例えば、アプリケーション１１５がローカルデバイス１０５上で実行されることができ、それらのアプリケーションのそれぞれは、リモートデバイス１１０に送信するためのグラフィック表示を生成する。方法３００はまた、（１つまたは複数の）表示命令および／または（１つまたは複数の）リソースを含むグラフィック・セットを受信する動作３１０を含む。例えば、符号化決定モジュール１５０は、リソースマネージャ１０８と連携して、リモートデバイス１１０上のアプリケーション１１５に関するグラフィック表示の少なくとも一部をレンダリングすることに使用されるべきであるリソース１６５および／または表示命令１６０を含むグラフィック・セット１５５を受信することができる。

方法３００は、（１）配信状態情報、（２）サポートされるアプリケーションの情報、（３）システム制約データ、および／または（４）可視性情報に関するリソースデータを受信する動作３１５も含む。より具体的には、リソースマネージャ１０８は、リソース１６５の配信状態を判定するためのリソースデータを受信することができる。例えば、リソース状態テーブル１１２が、記憶されるリソースの種類にかかわらず、対応するリソース（例えばリソースＡ １１４）がリモートデバイス１１０に送信され、再利用の目的で集中キャッシュ１２８に記憶されたかどうかを判定するために、グラフィック・セット１５５に対応するリソースの配信状態を判定するためにリソースマネージャ１０８によって使用されることができる。換言すれば、異種のリソースがそれらのリソースを記憶するときに同種のやり方で扱われるように、様々な種類のリソースが集中キャッシュ１２８内に記憶される。ローカルデバイス１０５およびリモートデバイス１１０は、大きく異なるサイズのリソースをキャッシュすることによって引き起こされるメモリのフラグメンテーションを制限するメカニズムを使用してもしなくてもよいことに留意されたい。

さらに、符号化決定モジュール１５０またはリソースマネージャ１０８は、ローカルデバイス１０５からリソースを転送することなしにそのようなリソースを表示するためにリモートデバイス１１０上で現在利用可能な専用のリソース１２４を判定するために、サポートされるアプリケーションの情報１２２を受信することができる。換言すると、リモートデバイス１１０およびローカルデバイス１０５の両方が同様のまたは同じアプリケーションをインストールする場合、リモートデバイス１１０上で確保されているリソースまたはアイコンが特定され、表示されることができ、したがって、それらのリソースはローカルデバイス１０５からリモートデバイスに送信される必要がない。そのような専用のリソースは、境界、タイトルバー、ツールバー、または両方のアプリケーションにまたがって標準的であるアイコンまたはリソースの何らかのその他の形態を含むことができる。

さらに、符号化決定モジュール１５０またはリソースマネージャ１０８は、帯域幅またはその他のシステム制約を節約するために完全なリソースの質を落としたバージョンが最初に送信され、質を落としたバージョンを改善するアップデートがその後送信されるように、リソースの一部がリモートデバイス１１０に漸進的に送信されるべきであるかどうかを判定するためのシステム制約情報１１６も受信することができる。例えば、図１Ｄに示されるように、高サンプリングで曲線１４２を示す完全なリソースセット１４４は、曲線１４６から示されるように総サンプリングセットの一部だけを含む部分的なリソースセット１４８として最初に送信されることができる。リモートデバイスに漸進的に送信される部分的なリソースは、ビットマップ、曲線、格子、またはその他の画像の形態を含む可能性があることに留意されたい。また、質を落としたバージョンは、色、詳細、サンプルの点の数、またはその他の画像の質の低下の不正確性を含むが、リソースの質を落としたバージョンは、リモートデバイス１１０のユーザがリソースを認識することを可能にするのに十分な情報を含むべきであることに留意されたい。リソースは、ボタン、チェックボックス、またはその他のインタラクティブなアイテムである可能性があり、ユーザは、完全なリソースを受信することなしに依然としてアイテムと対話することができるべきであることにさらに留意されたい。

さらに、符号化決定モジュール１５０またはリソースマネージャ１０８は、グラフィック・セット１５５に対応する１つまたは複数のリソース１６５がユーザによって現在見られることができるか否かを記述するリソース状態テーブル１１２からの可視性情報１１３を受信することができる。そのような可視性情報は、リソースのＺオーダ、透明度、最小化／最大化状態などについての情報を含むことができる。したがって、見えない可能性があるリソースは、帯域幅が許すまで、または見るために必要とされるまでリモートデバイス１１０への送信を遅らされることができる。

受信されたリソース情報に基づいて、方法３００は、符号化のためにグラフィック・セットの一部を選択する動作３２０を含む。換言すれば、上記の配信状態、サポートされるアプリケーションの情報、システム制約データ、および／または可視性情報に基づいて、グラフィック・セット１５５の一部（すなわち、表示命令のフィールド、またはリソースの一部）が、データ圧縮モジュール１７５を使用して符号化するために選択される。

図４は、ローカルデバイスで実行されるアプリケーションに関してリモートデバイス上でグラフィック表示を生成することに使用されるレンダリングデータ構造を効率的に同期する方法４００を示す。方法４００は、ローカルデバイス上で（１つまたは複数の）アプリケーションを実行する動作４０５を含む。例えば、上述のように、アプリケーション１１５がローカルデバイス１０５上で実行されることができ、それらのアプリケーションのそれぞれは特定のグラフィック言語のレンダリングデータ構造１７８を生成し、それらのレンダリングデータ構造１７８は、リソース１６５に関する状態を保有し、リモートデバイス１１０上でアプリケーション１１５に関するグラフィック表示を構成するために使用される保持モードデータ構造である。

方法４００は、（１つまたは複数の）リソースおよび／または（１つまたは複数の）表示命令を含むグラフィック・セットを受信する動作４１０も含む。例えば、符号化決定モジュール１５０は、表示命令１６０および／またはリソース１６５を含むグラフィック・セット１５５を受信することができる。表示命令１６０は、ディスプレイ上の位置付け、サイズ、色、形状などの観点でリソース１６５を記述するプロパティを含むことができる。

方法４００は、グラフィック・セットの記述を含むメタデータを受信する動作１１４も含む。例えば、符号化決定モジュール１５０は、データ圧縮モジュール１７５がより容易に認識し、適切に符号化することができる異なるグラフィック言語に関する複数のグラフィック・セット１５５の間で共通のフィールドに対する構造の種類を圧縮モジュール１７５が特定することを助けるために、グラフィック・セット１５５のフィールドの記述を含むグラフィック・セット・メタデータ１４０を受信することができる。例えば、メタデータ１４０に基づいて、フィールドは、マシンフォーマットからネットワークフォーマットに変換されることができ、この変換は、マシン形態であるときよりも優れた圧縮比のためにフィールドのビット長を削減する。さらに、メタデータ１４０は、可変長の形態の符号化のために、またはリソースの変化だけがリモートデバイスに送信されるように使用される差分符号化のために使用されることができ、リソースの変化は、グラフィック・セット１５５全体を送信するよりも少ないバイトを使用して符号化されることができる。さらに、メタデータ１４０は、特定の種類のフィールドを同じ種類の前に符号化された構造に基づいて符号化するために使用されるインターオーダ圧縮メカニズムのために使用されることができる。

メタデータ１４０はグラフィック・セット１５５に添付されてもされなくてもよいことに留意されたい。例えば、概して、メタデータ１５５の交換は、使用されるグラフィック・セット１５５の種類（例えば、オーダ／命令またはリソース）を示す１回限りのイベントである。そのとき、各グラフィック・セット１５５は、種類（または識別子）を初めに付けられることができる。符号化決定モジュール１５０は、そのとき、この識別子を見ることができ、最初に交換されたメタデータ１５５に基づいて適切なデータ圧縮モジュール１７５、適切な符号化の順序などを選択することができる。

受信されたメタデータに基づいて、方法４００は、グラフィック・セットのフィールドを符号化する動作４２０を含む。例えば、グラフィック・セット１５５内のフィールドを記述するグラフィック・セット・メタデータ１４０に基づいて、符号化決定モジュール１５０は、リモートデバイス１０５に送信するためのフィールドを符号化し、ローカル１０５とリモート１１０デバイスとの間でレンダリングデータ構造１７８、１８５を同期するためにそのようなデータを使用することができ、レンダリングデータ構造１７８、１８５は、アプリケーション１１５に関してリモートデバイス１１０においてグラフィック表示を構成するために使用される。

本発明は、本発明の精神または本質的特徴から逸脱することなしにその他の特定の形態で実施されることができる。説明された実施形態は全ての点において例示的とだけみなされるべきであり、限定的とみなされるべきではない。したがって、本発明の範囲は、上記の説明によってではなく添付の特許請求の範囲によって示される。特許請求の範囲と均等な意味および範囲内に入る全ての変更は特許請求の範囲に包含されるべきである。

例示的実施形態による、リモートデバイスにおいて表示をレンダリングする際に使用されるグラフィック・セットを効率的に符号化するために様々な情報を使用する分散システムを示す図である。 例示的実施形態による、（もしあれば）リソースのどの部分がリモートデバイスへの送信のために符号化されるべきかを判定するために様々なリソースについての情報を利用する分散システムを示す図である。 例示的実施形態による、リモートデバイス上で利用可能であり、ローカルデバイスからのリソースの転送が存在しないように使用されることができる専用のリソースまたはアイコンの一部を示す図である。 例示的実施形態による、部分的に送信されたリソースを用いてレンダリングすることによって応答性を向上するためのメカニズムを示す図である。 例示的実施形態による、リモートデバイス上の表示のためのグラフィックオブジェクトを効率的に符号化するための方法に関する流れ図である。 例示的実施形態による、リモート・ディスプレイ・デバイス上でグラフィックオブジェクトを効率的にレンダリングする方法に関する流れ図である。 例示的実施形態による、リモートデバイス上でグラフィック表示を生成する際に使用されるレンダリングデータ構造を効率的に同期する方法に関する流れ図である。

Claims (22)

1. 分散コンピューティングシステムにおいて、使用されるグラフィック言語の種類にかかわらず、符号化メカニズムを決定することによって、ローカルデバイス上で実行される１つまたは複数のアプリケーションに関する、リモートデバイス上で表示させるグラフィック・セットを符号化するコンピュータ実行方法であって、
   ローカルデバイス上で１つまたは複数のアプリケーションを実行し、グラフィック・セットを生成するステップであって、前記グラフィック・セットは、前記１つまたは複数のアプリケーションに関するグラフィック表示の少なくとも一部をレンダリングする際に使用される、１つもしくは複数のリソース、１つもしくは複数の表示命令、または前記リソースおよび前記表示命令の両方を含む、ステップと、
   前記アプリケーションが、１つまたは複数のデータ圧縮モジュールが前記グラフィック・セットを圧縮することを助けるために使用される、前記グラフィック・セット内の１つまたは複数のフィールドの内容を記述するメタデータを抽出するステップと、
   前記アプリケーションが、前記グラフィック・セットに対して圧縮の種類を選択する、前記リモートデバイスによってサポートされる１つまたは複数のデータ圧縮メカニズムを記述する符号化種類データを、前記リモートデバイスから受信するステップと、
   前記アプリケーションが、前記抽出されたメタデータおよび前記受信された符号化種類データに基づいて、前記グラフィック・セットの１つまたは複数の部分に対して符号化メカニズムを決定するステップと、
   前記アプリケーションが、前記決定された符号化メカニズムに基づいて、前記グラフィック・セットの１つまたは複数の部分を符号化するステップと
   を含むことを特徴とするコンピュータ実行方法。
2. 前記１つまたは複数の表示命令は、ディスプレイ上の位置付け、サイズ、色、または形状のうちの１つまたは複数の観点でリソースを記述する１つまたは複数のプロパティを含むことを特徴とする請求項１に記載のコンピュータ実行方法。
3. 前記メタデータに基づいて、前記フィールドのうちの１つまたは複数を、マシンフォーマットからネットワークフォーマットに変換し、前記１つまたは複数のフィールドのビット長を削減することを特徴とする請求項１に記載のコンピュータ実行方法。
4. 前記メタデータに基づいて、前記フィールドのうちの１つまたは複数を、可変長の形態で符号化することを特徴とする請求項１に記載のコンピュータ実行方法。
5. 前記メタデータに基づいて、差分符号化を使用し、リソースの変化だけを前記リモートデバイスに送信するように、前記グラフィック・セット全体よりも少ないバイト数を使用して符号化することを特徴とする請求項１に記載のコンピュータ実行方法。
6. 前記メタデータに基づいて、インターオーダ圧縮メカニズムを使用し、特定の種類の前記フィールドのうちの１つまたは複数を、以前に符号化された同じ種類の構造に基づいて符号化することを特徴とする請求項１に記載のコンピュータ実行方法。
7. 前記リモートデバイスによってサポートされる前記１つまたは複数のデータ圧縮メカニズムを、接続時にローカルデバイスとリモートデバイスとの間でネゴシエーションし、選択される前記符号化メカニズムは、前記データ圧縮メカニズムのそれぞれの、所与のグラフィック・セットに対する圧縮比にさらに基づくことを特徴とする請求項１に記載のコンピュータ実行方法。
8. 前記１つまたは複数のデータ圧縮モジュールは、ＲＬＥ、ＭＰＥＧベース、ＪＰＥＧ、ＧＩＦ、ＺＩＰ、ＬＺベース、ＪＢＩＧ、ＤｅｊａＶｕに基づく圧縮メカニズムのうちの１つまたは複数を含むことを特徴とする請求項７に記載のコンピュータ実行方法。
9. 分散コンピューティングシステムにおいて、１つまたは複数のアプリケーションに関するどのリソースをリモートデバイスに送信するべきかを判定することによって、ローカルデバイス上で実行中の前記アプリケーションに関するグラフィック表示を前記リモートデバイスのディスプレイ上にレンダリングさせるために前記リモートデバイスに送信するコンピュータ実行方法であって、
   前記ローカルデバイス上で、前記アプリケーションを実行して、１つもしくは複数のリソース、１つもしくは複数の表示命令、または前記リソースおよび前記表示命令の両方を含むグラフィック・セットを生成するステップであって、前記グラフィック・セットは、前記アプリケーションに関するグラフィック表示の少なくとも一部をレンダリングする際に使用される、生成するステップと、
   前記アプリケーションが、（１）記憶されるリソースの種類にかかわらず、前記グラフィック・セットに対応する１つもしくは複数のリソースが前記リモートデバイスに送信され、再利用の目的で集中キャッシュに記憶されたかどうかを判定する配信状態情報、（２）前記ローカルデバイスから少なくとも１つのリソースを転送することなしに前記アプリケーションに関する前記少なくとも１つのリソースを前記リモートデバイス上に表示するために前記リモートデバイス上で現在利用可能な専用のリソースを判定する、サポートされるアプリケーションの情報、（３）帯域幅もしくはシステム制約を節約するために、画質を落としたリソースを最初に送信し、前記画質を落としたリソースを改善するアップデートをその後送信するように、リソースの一部を前記リモートデバイスに漸進的に送信するべきであるかどうかを判定するシステム制約データ、または（４）前記グラフィック・セットに対応する１つまたは複数のリソースがユーザによって現在見られることができるか否かを記述する可視性情報、のうちの１つまたは複数に関する情報を含む、前記ローカルデバイス上にあらかじめ記憶されたリソース情報に基づいて、前記リモートデバイスに送信するべきリソースを判定し、前記グラフィック・セットの一部を選択し、符号化するステップと、
   前記アプリケーションが、前記符号化されたグラフィック・セットを、前記リモートデバイスに送信するステップと
   を含むことを特徴とするコンピュータ実行方法。
10. 前記ローカルデバイス、前記リモートデバイス、または前記ローカルデバイスおよび前記リモートデバイスの両方は、前記集中キャッシュ内にサイズの異なるリソースをキャッシュすることによって引き起こされるメモリのフラグメンテーションを制限するメカニズムを使用することを特徴とする請求項９に記載のコンピュータ実行方法。
11. 前記専用のリソースは、前記アプリケーションに関する境界、タイトルバー、ツールバー、またはウィンドウ操作アイコンの１つまたは複数を含むことを特徴とする請求項９に記載のコンピュータ実行方法。
12. 前記可視性情報は、前記１つまたは複数のリソースのＺオーダ、透明度、または最小化／最大化状態についての情報を含むことを特徴とする請求項９に記載のコンピュータ実行方法。
13. 前記画質を落としたリソースを改善するアップデートに関するリソースは、ビットマップ、曲線、または格子のうちの１つまたは複数を含み、前記画質を落としたリソースの画質の低下は、色、詳細、サンプルの点の数のうちの１つまたは複数によるものであることを特徴とする請求項９に記載のコンピュータ実行方法。
14. 前記画質を落としたリソースは、フォームコントロールであり、前記ユーザは、前記画質を落としたリソースを改善するアップデートを受信することなしに前記フォームコントロールを操作することができることを特徴とする請求項１３に記載のコンピュータ実行方法。
15. 分散コンピューティングシステムにおいて、ローカルデバイス上で実行される１つまたは複数のアプリケーションに関してリモートデバイス上でグラフィック表示を生成する際に使用される１つまたは複数のレンダリングデータ構造を同期するコンピュータ実行方法であって、
    前記ローカルデバイス上で前記アプリケーションを実行し、特定のグラフィック言語に対応し、前記レンダリングデータ構造を修正する際に使用される１つもしくは複数のリソース、１つもしくは複数の表示命令、または前記リソースおよび前記表示命令の両方を含むグラフィック・セットを生成するステップであって、前記アプリケーションのそれぞれは前記特定のグラフィック言語の前記レンダリングデータ構造を生成し、前記レンダリングデータ構造は、前記リソースに関する状態を保有し、かつ前記リモートデバイス上で前記アプリケーションに関する前記グラフィック表示を構成するために使用される保持モードデータ構造である、生成するステップと、
    前記アプリケーションが、１つまたは複数のデータ圧縮モジュールが認識し、符号化することができる１つまたは複数の異なるグラフィック言語に関する複数の前記グラフィック・セットの間で共通の１つまたは複数のフィールドに対する構造の種類を前記データ圧縮モジュールが特定することを助けるために、前記フィールドの記述を含むメタデータを抽出するステップと、
    前記アプリケーションが、前記抽出したメタデータに基づいて、前記フィールドを符号化するステップと、
    前記アプリケーションが、前記符号化されたフィールドを含むグラフィック・セットを前記リモートデバイスに送信するステップと、
    前記アプリケーションが、前記レンダリングデータ構造を、前記ローカルデバイスと前記リモートデバイスの間で同期するステップと
    を含むことを特徴とするコンピュータ実行方法。
16. 前記表示命令は、ディスプレイ上の位置付け、サイズ、色、または形状のうちの１つまたは複数の観点でリソースを記述する１つまたは複数のプロパティを含むことを特徴とする請求項１５に記載のコンピュータ実行方法。
17. 前記メタデータに基づいて、前記フィールドのうちの１つまたは複数を、マシンフォーマットからネットワークフォーマットに変換し、前記フィールドのビット長を削減することを特徴とする請求項１５に記載のコンピュータ実行方法。
18. 前記メタデータに基づいて、前記フィールドのうちの１つまたは複数を、可変長の形態で符号化することを特徴とする請求項１５に記載のコンピュータ実行方法。
19. 前記メタデータに基づいて、差分符号化を使用し、リソースの変化だけを前記リモートデバイスに送信するように、前記グラフィック・セット全体よりも少ないバイト数を使用して符号化することを特徴とする請求項１５に記載のコンピュータ実行方法。
20. 前記メタデータに基づいて、インターオーダ圧縮メカニズムを使用し、特定の種類の前記フィールドのうちの１つまたは複数を、以前に符号化した同じ種類の構造に基づいて符号化することを特徴とする請求項１５に記載のコンピュータ実行方法。
21. 前記符号化されたグラフィック・セットを送信するステップと
    前記アプリケーションが、前記符号化されたグラフィック・セットのＺオーダ、透明度、および最小化／最大化状態の少なくとも１つに基づき、前記符号化されたグラフィック・セットの可視性を判定するステップと、
    前記アプリケーションが、前記ローカルデバイスと前記リモートデバイス間の帯域幅判定するステップと、
    前記アプリケーションが、前記判定された可視性および帯域幅に基づき、前記符号化されたグラフィック・セットの可視部分を先に、前記リモートデバイスに送信するステップと、
    前記アプリケーションが、前記判定された可視性および帯域幅に基づき、前記符号化されたグラフィック・セットの不可視部分を後から、前記リモートデバイスに送信するステップと
    を含むことを特徴とする請求項１に記載のコンピュータ実行方法。
22. 前記符号化されたグラフィック・セットを送信するステップと
    前記アプリケーションが、前記符号化されたグラフィック・セットのＺオーダ、透明度、および最小化／最大化状態の少なくとも１つに基づき、前記符号化されたグラフィック・セットの可視性を判定するステップと、
    前記アプリケーションが、前記ローカルデバイスと前記リモートデバイス間の帯域幅判定するステップと、
    前記アプリケーションが、前記判定された可視性および帯域幅に基づき、前記符号化されたグラフィック・セットの可視部分を先に、前記リモートデバイスに送信するステップと、
    前記アプリケーションが、前記判定された可視性および帯域幅に基づき、前記符号化されたグラフィック・セットの不可視部分を後から、前記リモートデバイスに送信するステップと
    を含むことを特徴とする請求項９に記載のコンピュータ実行方法。

Images