JP4691037B2 - リモートなビジュアル構成のためのプロトコル - Google Patents

Description

本発明は、概して電子データ処理に関し、より詳細には、コンピュータシステムにおけるグラフィックスおよび制御情報の流れの管理に関する。

デジタル方式で作成されたマルチメディア、デジタルデバイス上で閲覧するためのデジタル形式のビデオおよびオーディオの組合せ、ならびにイメージおよびアニメーションなどのデジタル媒体は、急速に容量が増え、数も急増している。今日製造されているほぼすべての新しいパーソナルコンピュータは、何らかの形態のマルチメディアを含んでいる。カメラ、ビデオレコーダ、電話およびテレビなどのデジタル製品の売上げは、堅調に伸びている。インターネットの成長が堅調かつ急速に続いているので、マルチメディアは、インターネットの領域にもますます普及しつつある。こうしたコンピュータベースの技術における進歩の継続は、性能の向上をもたらしただけでなく、このようなコンピュータ機器ユーザの、性能への期待も高めている。コンピュータ業界は、ＣＤ ＲＯＭドライブ、通信モデムの速度向上、ならびにより高速なビデオカードおよびオーディオカードによってこうした期待に応えてきた。こうしたユーザの期待の高まりは、ハードウェアの性能だけでなく、データの処理性能にも及んでいる。

たとえば、マルチメディアおよびオーディオ圧縮などの分野において、データは、安定した連続するストリームとして処理され得るように処理される。このデータは、ＴＶ会議、ゲーム、ＤＶＤ（デジタルビデオディスク）、プロ向けのオーディオ、電話などの分野、ならびにオーディオ、ビデオ、またはオーディオおよびビデオがデジタル処理される他の分野で用いられる。

データのレンダリングは、ほとんどいつでも、システム内の様々なモジュールにおける何らかの形態の処理を必要とする。たとえば、ビデオクリップは、専用のハードウェアモジュールでのデコード、別のハードウェアモジュールでのビデオフィールドのラスタ化、ソフトウェアモジュールでのオーディオのデジタルフィルタリング、別のソフトウェアモジュールによるサブタイトルの挿入、ソフトウェアモジュールによる、無音期間をスキップするためのオーディオデータの解析などを必要とするであろう。ストリーミングを働かせるために、データは、定常ストリームとして処理され、次いで、オーディオおよび／またはビデオにレンダリングされる。ただし、データが十分に速く処理されないと、データの提示が円滑にならない。

従来のクライアント−サーバ間のレンダリングでは、データは、サーバで処理され、異なる仮想フレームに入れられてクライアントに送られ、ここでフレームがレンダリングされる。各フレームは、レンダリングされる項目に変更がない場合でも、そのフレームをレンダリングするのに必要とされる全データおよび情報を含む。たとえば、すべてのアニメーションフレームは、そのフレームが隣接フレームと同一であっても、そのフレームをレンダリングするための全部のデータおよび情報をもつ。その結果、データの伝送は、大量の利用可能帯域幅を消費する。この帯域幅消費は、サーバがサポートし得るクライアントの数を減少させる。さらに、クライアントマシン上のハードウェアは、データを処理するのに利用されることができない。たとえば、データを処理するサーバは、３Ｄグラフィックアクセラレータなど、クライアントハードウェアのハードウェア特徴を利用することができない。

本発明は、リモートデバイス上で構成物を作成し制御する方法およびプロトコルを提供する。このプロトコルは、サーバおよび他のデバイスが、リモート表示デバイス上に画像コンテンツを構成するために、リモートデバイスの処理能力を利用できるようにさせる。こうすることは、サーバが、より多くのクライアントを扱うことを可能にする。というのは、サーバは、コンポジション（composition、以下、「構成物」という場合もある）を実際にレンダリングするのに使われる機能（たとえば、ペイント、ドロー、アニメーションなど）を処理する必要がないからである。この結果、クライアントの３Ｄハードウェアアクセラレーションパイプ、およびクライアントのＣＰＵなど、クライアント側のハードウェア性能をより多く利用することができるようになる。たとえば、クライアントは、アニメーション機能を処理することができ、このことは、サーバがクライアントに、全アニメーション効果を含む個々の静的フレームを送る代わりに、アニメーション機能を記述する情報を送ることを可能にする。

本プロトコルは、アプリケーションが、クライアントデバイス上にコンポジションを作成するために、媒体を介してコマンドを伝達することを可能にする基本的な高レベルのコマンドパケットを提供する。こうしたパケットのペイロードは、コンポジションを作成するための、デバイス上のコンポーネントに対する実際のコマンドを含むことができる。要求アプリケーションは、コンポジションサービス（以下、「構成サービス」という場合もある。また、「コンポジション・・・」を「構成・・・」という場合もある）を作成し、レンダリングターゲットおよびレンダリングコンテキストを作成し、コンポジションノード（構成ノード）を作成し、コンポジションノード用のリソースを作成し、コンポジションをレンダリングするためのコマンドのパケットを送る。

要求アプリケーションからのパケットは、リソースコマンドパケットおよびコントロールパケットである。リソースコマンドパケットは、クライアント上の該当するリソースに経路指定される。コントロールパケットは、構成状態を制御し、クライアントマシン上でテキストグリフ（ｔｅｘｔ ｇｌｙｐｈ）のキャッシュを維持するのに使われる。通知パケットが、要求アプリケーションに返送される。

本発明の追加の特徴および利点が、添付の図面を参照して進められる、例示的な実施形態の以下の詳細な説明から明らかになるであろう。

添付の特許請求の範囲は本発明の特徴を具体的に定義するが、本発明、ならびにその目的および利点は、以下の詳細な説明を添付の図面と併せ読むことによって最もよく理解されることができよう。

本発明は、サーバが、構成処理の諸態様をクライアントマシンにオフロードする機能を提供する。この結果、サーバ側のスケーラビリティが向上する。通信プロトコルの高レベルの記述性によって、即時モードモデルを用いてデータを送る場合よりも、データをレンダリングするために大幅に少ない量のデータおよび情報がクライアントに送られるようになる。

本発明の詳細を述べる前に、本発明が実装され得る例示的なデバイス、および本発明が作用し得る環境の概略が述べられる。図面に移ると、同じ参照番号は同じ要素を指し、本発明は、適切なコンピューティング環境において実装されるものとして示される。そうすることが必要なわけではないが、パーソナルコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的なコンテキストにおいて、本発明が説明される。概して、プログラムモジュールは、特定のタスクを実施しまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、可搬型デバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成を用いて実施され得ることを当業者は理解するであろう。本発明は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実施される分散型コンピューティング環境でも実施されることができる。分散型コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートメモリ記憶装置両方に配置されることができる。

図１は、本発明が実施され得る、適切なコンピューティングシステム環境の例１００を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲に対するどのような限定を示唆することも意図されない。コンピューティング環境１００は、例示的な動作環境１００に示されるどのコンポーネントまたはその組合せに関するどのような依存も要件も有していると解釈されるべきでない。

本発明は、他の数多くの汎用または専用のコンピューティングシステム環境または構成と動作する。本発明とともに使用するのに適切であり得る公知のコンピューティングシステム、環境、および／または構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ型デバイス、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれをも含む分散型コンピューティング環境などを含むが、それに限定されない。

本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的なコンテキストにおいて説明されることができる。概して、プログラムモジュールは、特定のタスクを実施しまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実施される分散型コンピューティング環境でも実施されることができる。分散型コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよび／またはリモートコンピュータ記憶媒体に置かれることができる。

図１を参照すると、本発明を実施する例示的なシステムは、汎用コンピューティング装置を、コンピュータ１１０の形態で含む。コンピュータ１１０のコンポーネントは、処理ユニット１２０と、システムメモリ１３０と、システムメモリなど様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１とを含むことができるが、それに限定されない。システムバス１２１は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスなどいくつかの種類のバス構造のいずれでもよい。限定ではなく例として、このようなアーキテクチャは、ＩＳＡ（業界標準アーキテクチャ）バス、ＭＣＡ（マイクロチャネルアーキテクチャ）バス、ＥＩＳＡ（拡張ＩＳＡ）バス、ＶＥＳＡ（米国ビデオ電子装置規格化協会）ローカルバス、およびメザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られるＰＣＩ（周辺装置相互接続）バスを含む。

コンピュータ１１０は通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスされ得るとともに揮発性媒体および不揮発性媒体、着脱式媒体および固定式媒体両方を含む、利用可能などの媒体でもよい。限定ではなく例として、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するためのどの方法でも技術でも実施される揮発性媒体および不揮発性媒体、着脱式媒体および固定式媒体を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（デジタル多用途ディスク）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは、所望の情報を格納するのに使われることができるとともにコンピュータ１１０によってアクセスされることができる他のどの媒体も含むが、それに限定されない。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、変調データ信号、たとえば搬送波や他の移送機構として具体化し、どの情報配信媒体も含む。「変調データ信号」という用語は、信号に情報を符号化するように信号特性の１つまたは複数が設定されまたは変更された信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークや直接有線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体を含む。上記のどの組合せも、やはりコンピュータ可読媒体の範囲に含まれるべきである。

システムメモリ１３０は、コンピュータ記憶媒体を、ＲＯＭ（読出し専用メモリ）１３１およびＲＡＭ（ランダムアクセスメモリ）１３２など、揮発性および／または不揮発性メモリの形態で含む。ＢＩＯＳ（基本入出力システム）１３３は、たとえば起動中にコンピュータ１１０内部の要素間での情報の転送を助ける基本ルーチンを含み、通常はＲＯＭ１３１に格納される。ＲＡＭ１３２は一般に、処理ユニット１２０に対してただちにアクセス可能な、かつ／または処理ユニット１２０によって現在操作されているデータおよび／またはプログラムモジュールを含む。限定ではなく例として、図１では、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピュータ１１０は、他の着脱式／固定式、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。単なる例として、図１では、固定式不揮発性磁気媒体からの読出しまたはそこへの書込みを行うハードディスクドライブ１４１、着脱式な不揮発性磁気ディスク１５２からの読出しまたはそこへの書込みを行う磁気ディスクドライブ１５１、および、ＣＤ ＲＯＭや他の光学媒体など着脱式な不揮発性光ディスク１５６からの読出しまたはそこへの書込みを行う光ディスクドライブ１５５を示す。例示的な動作環境で使われることができる、他の着脱式／固定式、揮発性／不揮発性コンピュータ記憶媒体は、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体状態ＲＡＭ、固体状態ＲＯＭなどを含むが、それに限定されない。ハードディスクドライブ１４１は通常、インターフェース１４０などの固定式メモリインターフェースによって、システムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インターフェース１５０などの着脱式メモリインターフェースによって、システムバス１２１に接続される。

上述し、かつ図１に示されているディスクドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピュータ１１０のための他のデータの格納を可能にする。図１では、たとえば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示される。こうしたコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じでも、異なってもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、少なくとも異なるものであることを示すために、本明細書では異なる番号が与えられている。ユーザは、キーボード１６２、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１、マイクロホン１６３、およびタブレットまたは電子デジタイザ１６４を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力デバイス（図示せず）は、ジョイスティック、ゲーム用パッド、衛星パラボラアンテナ、スキャナなどを含み得る。こうしたおよび他の入力デバイスはしばしば、システムバスに結合されるユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、ＵＳＢ（ユニバーサルシリアルバス）など、他のインターフェースおよびバス構造によって接続されることもできる。モニタ１９１または他の種類の表示デバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１は、タッチスクリーンパネルなどとも統合され得る。モニタおよび／またはタッチスクリーンパネルは、タブレットタイプのパーソナルコンピュータでのように、コンピューティング装置１１０が組み込まれているハウジングに物理的に結合され得ることに留意されたい。さらに、コンピューティング装置１１０などのコンピュータは、出力周辺インターフェース１９５などを介して接続されることができるスピーカ１９７およびプリンタ１９６など、他の周辺出力デバイスも含むことができる。

コンピュータ１１０は、リモートコンピュータ１８０など、１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク接続された環境において動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードでよく、通常、コンピュータ１１０に関連して上述された要素の多くまたはすべてを含むが、図１にはメモリ記憶装置１８１のみが示されている。図１に示される論理接続は、ＬＡＮ（ローカルエリアネットワーク）１７１およびＷＡＮ（ワイドエリアネットワーク）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーク環境は、会社、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいてよく見られる。たとえば、コンピュータシステム１１０は、データがそこから移行されている発信マシンとなることができ、リモートコンピュータ１８０は、宛先マシンとなることができる。

ＬＡＮネットワーク環境において使われる場合、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーク環境において使われる場合、コンピュータ１１０は通常、モデム１７２、または、たとえばインターネットなどのＷＡＮ１７３を介して通信を確立する他の手段を含む。モデム１７２は、内部にあっても外部にあってもよく、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続されることができる。ネットワーク接続された環境では、コンピュータ１１０に関連して図示したプログラムモジュールまたはその一部は、リモートメモリ記憶装置に格納されることができる。限定ではなく例として、図１は、リモートアプリケーションプログラム１８５を、メモリ装置１８１に常駐するものとして示す。図示したネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段も使われることができることが理解されよう。

プログラミングインターフェース（またはより簡単には、インターフェース）は、コードの１つまたは複数のセグメント（群）が、コードの１つまたは複数の他のセグメント（群）によって提供される機能と通信しまたは機能にアクセスすることを可能にする、どの仕組み、処理、プロトコルとしても見なされ得ることに留意されたい。あるいは、プログラミングインターフェースは、他のコンポーネント（群）の、１つまたは複数の仕組み（群）、方法（群）、関数呼出し（群）、モジュール（群）などと通信結合することができる、システムのあるコンポーネントの、１つまたは複数の仕組み（群）、方法（群）、関数呼出し（群）、モジュール（群）、オブジェクト（群）などとして見なされ得る。上記の文における「コードのセグメント」という用語は、適用される専門範囲に関わらず、かつコードセグメントが個別にコンパイルされるかどうか、コードセグメントがソースコード、中間コード、またはオブジェクトコードとして提供されるのか、コードセグメントがランタイムシステムまたは処理において使用されるのか、コードセグメントが同じマシンもしくは異なるマシンに置かれるか、それとも複数のマシンに分散されるか、あるいはコードのセグメントによって表される機能が、完全にソフトウェアとして、完全にハードウェアとして、またはハードウェアおよびソフトウェアの組合せとして実装されるのかに関わらず、１つまたは複数の命令またはコードの行を含み、たとえば、コードモジュール、オブジェクト、サブルーチン、関数などを含むことを意図していることが留意されるべきである。

概念的に、プログラミングインターフェースは、図２ａまたは図２ｂに示すように、包括的に見られ得る。図２ａは、第１および第２のコードセグメントが通信するためのルート（ｃｏｎｄｕｉｔ）としてのインターフェース１というインターフェースを示す。図２ｂは、インターフェースを、インターフェースオブジェクトＩ１およびＩ２（第１および第２のコードセグメントの一部であってもなくてもよい）を備えるものとして示し、こうしたインターフェースオブジェクトは、システムの第１および第２のコードセグメントが、媒体Ｍを介して通信することを可能にする。図２ｂを見て、インターフェースオブジェクトＩ１およびＩ２を、同一のシステムの別個のインターフェースと見なす人、オブジェクトＩ１およびＩ２と媒体Ｍとがインターフェースを構成すると見なす人がいるかもしれない。図２ａおよび２ｂは、双方向の流れ、およびその流れの両端でのインターフェースを示すが、特定の実装形態は、一方向での情報の流れしかもたない（または後で説明されるように情報の流れをもたない）場合もあり、一端でのインターフェースオブジェクトしかもたない場合もある。限定ではなく例として、ＡＰＩ（アプリケーションプログラミングインターフェース）、エントリポイント、方法、関数、サブルーチン、リモートプロシージャコール、およびＣＯＭ（コンポーネントオブジェクトモデル）インターフェースなどの用語は、プログラミングインターフェースの定義範囲に包含される。

このようなプログラミングインターフェースの特徴は、第１のコードセグメントが、第２のコードセグメントに情報（この場合、「情報」は、広い意味で使われており、データ、コマンド、要求などを含む）を送る方法と、第２のコードセグメントが、その情報を受け取る方法と、その情報の構造、シーケンス、シンタクス、編成、スキーマ、タイミング、および内容とを含み得る。これに関して、情報が、インターフェースによって定義されたやり方で移送される限り、基礎となる移送媒体自体は、有線でも無線でも、あるいは有線および無線の組合せであっても、インターフェースの動作にとって重要でなくてよい。特定の状況では、情報は、従来の意味での一方向または両方向で渡されることができない。というのは、情報の転送は、あるコードセグメントが、第２のコードセグメントによって実施される機能に単にアクセスするときのように、別の仕組み（たとえば、コードセグメントの間の情報の流れとは別に、情報が、バッファ、ファイルなどに置かれる）を介するか、または存在しなくてもよいからである。こうした特徴のいずれかまたは全部は、所与の状況、たとえば、コードセグメントが、疎結合構成または密結合構成のシステムの一部であるかに応じて重要となる場合があり、したがって、このリストは、例示であって限定のためではないと見なされるべきである。

このプログラミングインターフェース概念は、当業者に知られており、本発明の上記の詳細な説明から明らかである。しかし、プログラミングインターフェースを実装する他の方法もあり、明示的に除外されない限り、こうした方法も、本明細書に添付され定義される特許請求の範囲に包含されることを意図している。このような他の方法は、図２ａおよび２ｂの単純化された概観より高度または複雑に見え得るが、それにもかかわらず、全体として同じ結果を達成する類似した機能を実施する。ここで、プログラミングインターフェースのいくつかの例示的な代替実装形態を簡潔に説明する。

Ａ．因数分解（ＦＡＣＴＯＲＩＮＧ）
あるコードセグメントから別のコードセグメントへの通信は、その通信を、複数の別々の通信に分けることによって、間接的に達成されることができる。このことは、図３ａおよび３ｂで概略的に示される。図に示すように、いくつかのインターフェースは、機能の分割可能な組の用語で説明されることができる。したがって、図２ａおよび２ｂのインターフェース機能は、２４または２×２×３×２を数学的にもたらすことができるように、同じ結果を達成するように因数分解されることができる。したがって、図３ａに示されるように、インターフェース１というインターフェースによって提供される機能は、インターフェースの通信をインターフェース１Ａ、インターフェース１Ｂ、インターフェース１Ｃなどの複数のインターフェースに変換するように下位分割され、同じ結果を達成することができる。図３ｂに示されるように、インターフェースＩ１によって提供される機能は、複数のインターフェースＩ１ａ、Ｉ１ｂ、Ｉ１ｃなどに下位分割され、同じ結果を達成することができる。同様に、第１のコードセグメントから情報を受け取る、第２のコードセグメントのインターフェースＩ２は、複数のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどに因数分解されることができる。因数分解するとき、第１のコードセグメントに含まれるインターフェースの数は、第２のコードセグメントに含まれるインターフェースの数と一致しなくてもよい。図３ａおよび３ｂのいずれの場合でも、インターフェース１およびＩ１というインターフェースの機能上の意図は、それぞれ図２ａおよび２ｂの場合と同じままである。インターフェースの因数分解は、因数分解が認識困難になり得るように、結合的な、可換な、および他の数学的なプロパティの後に起こることもできる。たとえば、一部のアプリケーションにおいて動作の順序は重要でなくてよく、したがって、インターフェースによって実現される機能は、インターフェースの遂行に先立って、別のコード部分またはインターフェースによって実現されても、システムの別のコンポーネントによって実施されてもよい。さらに、プログラミング分野の当業者であれば、同じ結果を達成する異なる関数呼出しを行う様々な方法があることを理解できよう。

Ｂ．再定義（ＲＥＤＥＦＩＮＩＴＩＯＮ）
いくつかの場合において、プログラミングインターフェースの特定の特徴（たとえばパラメータ）を無視し、追加し、または再定義し、意図した結果を依然として達成することが可能であり得る。このことは、図４ａおよび４ｂに示される。たとえば、図２ａのインターフェース１というインターフェースが、Ｓｑｕａｒｅ（ｉｎｐｕｔ，ｐｒｅｃｉｓｉｏｎ，ｏｕｔｐｕｔ）の関数呼出しを含み、この呼出しは、３つのパラメータ、すなわちｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎ、およびｏｕｔｐｕｔを含み、第１のコードセグメントから第２のコードセグメントに発行されると仮定する。中央のパラメータｐｒｅｃｉｓｉｏｎは、図４ａに示すように、所与のシナリオに関係しない場合、適切に無視されることも、（この状況において）ｍｅａｎｉｎｇｌｅｓｓパラメータで置き換えられることもできよう。無関係なａｄｄｉｔｉｏｎａｌパラメータを追加することもできる。いずれの場合でも、第２のコードセグメントによって入力が二乗された後で出力が返される限り、二乗機能は達成されることができる。ｐｒｅｃｉｓｉｏｎは、コンピューティングシステムの何らかの下流部分または他の部分にとって有意なパラメータでもよい。ただし、ｐｒｅｃｉｓｉｏｎは、二乗計算という狭い目的にとって必要ないと認識されると、置き換えられまたは無視されることができる。たとえば、有効なｐｒｅｃｉｓｉｏｎ値を渡すのではなく、誕生日などの無意味な値が、結果に悪影響を与えることなく渡されることができよう。同様に、図４ｂに示すように、インターフェースＩ１は、インターフェースＩ１’で置き換えられ、インターフェースへのパラメータを無視しまたは追加するように再定義される。インターフェースＩ２は、同様にインターフェースＩ２’として再定義されることができ、不必要なパラメータまたは他の所で処理されることができるパラメータを無視するように再定義される。ここでのポイントは、いくつかの場合において、プログラミングインターフェースは、何らかの目的には必要とされないパラメータなどの特徴を含む場合があるので、こうした特徴は、無視されまたは再定義され、あるいは他の目的のために他の所で処理されることができることである。

Ｃ．インラインコーディング（ＩＮＬＩＮＥ ＣＯＤＩＮＧ）
２つの別々のコードモジュールの機能の間の「インターフェース」が形態を変えるように、そうした機能の一部または全部をマージすることも可能であり得る。たとえば、図２ａおよび２ｂの機能は、それぞれ図５ａおよび５ｂの機能に変換されることができる。図５ａにおいて、図２ａの以前の第１および第２のコードセグメントは、その両方を含むモジュールにマージされる。この場合、コードセグメントは、依然として相互に通信していてもよいが、インターフェースは、単一モジュールにより適した形態に適合されることができる。したがって、たとえば、正式な呼出しおよび戻りステートメントは不必要になり得るが、インターフェース１というインターフェースに順じた同様の処理または応答（群）は依然として有効であり得る。同様に、図５ｂに示してあるが、図２ｂのインターフェースＩ２の一部（または全部）は、インターフェースＩ１にインラインに書き込まれて、インターフェースＩ１”を形成することができる。図に示すように、インターフェースＩ２は、Ｉ２ａおよびＩ２ｂに分割され、インターフェース部分Ｉ２ａは、インターフェースＩ１とインラインにコーディングされて、インターフェースＩ１”を形成している。具体的な例として、図２ｂのインターフェースＩ１が、関数呼出しｓｑｕａｒｅ（ｉｎｐｕｔ，ｏｕｔｐｕｔ）を実施し、この呼出しが、インターフェースＩ２によって受け取られ、インターフェースＩ２は、第２のコードセグメントによる、ｉｎｐｕｔとともに渡された値の（ｉｎｐｕｔを二乗するための）処理の後、二乗された結果をｏｕｔｐｕｔとともに返す場合を考える。このような場合、第２のコードセグメントによって実施される（ｉｎｐｕｔを二乗する）処理は、インターフェースへの呼出しなしで、第１のコードセグメントによって実施されることができる。

Ｄ．分離（ＤＩＶＯＲＣＥ）
一方のコードセグメントから別のコードセグメントへの通信は、その通信を複数の別々の通信に分けることによって間接的に遂行することができる。このことは、図６ａおよび６ｂに概略的に示される。図６ａに示すように、ミドルウェアの１つまたは複数の断片（群）（元のインターフェースから全機能および／またはインターフェース機能を分離するので、分離インターフェース（群））が、第１のインターフェース、すなわちインターフェース１上での通信を変換して、異なるインターフェース、この場合インターフェース２Ａ、インターフェース２Ｂ、およびインターフェース２Ｃというインターフェースに通信を準拠させるように提供される。これは、たとえば、インターフェース１のプロトコルに従ってオペレーティングシステムと通信するように設計されたアプリケーションのベースがインストールされているが、次いで、オペレーティングシステムが、異なるインターフェース、この場合インターフェース２Ａ、インターフェース２Ｂ、およびインターフェース２Ｃというインターフェースを用いるように変更される場合に行われ得るであろう。重要なのは、第２のコードセグメントに使われていた元のインターフェースは、第１のコードセグメントによって使われるインターフェースとの互換性がなくなるように変更され、したがって、古いおよび新しいインターフェースを互換可能にするのに媒介が用いられる点である。同様に、図６ｂに示すように、ＤＩ２と共同で作用するように設計し直されているが同じ機能的結果をもたらす、インターフェースＩ１からの通信を受けるための分離インターフェースＤＩ１、およびたとえばインターフェースＩ２ａおよびＩ２ｂにインターフェース機能を送るための分離インターフェースＤＩ２を有する、第３のコードセグメントが導入されることができる。同様に、ＤＩ１およびＤＩ２は、図２ｂのインターフェースＩ１およびＩ２の機能を、新しいオペレーティングシステムに翻訳するように共同作用し、同じまたは類似した機能的結果をもたらすことができる。

Ｅ．書換え（ＲＥＷＲＩＴＩＮＧ）
インターフェース機能を他のもので置き換えるが全体的に同じ結果を達成するようにコードを動的に書き換える、さらに別の変形体が可能である。たとえば、（．Ｎｅｔフレームワーク、Ｊａｖａ（登録商標）ランタイム環境、または他の同様のランタイムタイプの環境によって提供されるような）実行環境において、中間言語（たとえば、マイクロソフトＩＬ、Ｊａｖａ（登録商標）バイトコードなど）の形で示されるコードセグメントが、ＪＩＴ（ジャストインタイム）コンパイラまたはインタープリタに与えられるシステムがあり得る。ＪＩＴコンパイラは、第１のコードセグメントから第２のコードセグメントへの通信を動的に変換するように、すなわち、第２のコードセグメント（元のまたは異なる第２のコードセグメントのどちらか）によって要求され得る異なるインターフェースに通信を準拠させるように書かれることができる。このことは、図７ａおよび７ｂに示される。図７ａに見られ得るように、この手法は、上述された分離シナリオと似ている。これは、たとえば、インターフェース１のプロトコルに従ってオペレーティングシステムと通信するように設計されたインストール済のアプリケーションのベースが、次いで、オペレーティングシステムが、異なるインターフェースを用いるように変更される場合に行われ得るであろう。ＪＩＴコンパイラは、インストールベースのアプリケーションからのオンザフライでの通信を、オペレーティングシステムの新しいインターフェースに準拠させるのに用いられることができよう。図７ｂに示されるように、インターフェース（群）を動的に書き換えるこの手法は、インターフェース（群）を動的に因数分解し、あるいは作り変えるのにも適用されることができる。

代替実施形態によって、インターフェースと同じまたは類似の結果を達成する上述したシナリオは、様々な方法、すなわち直列および／または並列で、あるいは他の介在コードと組み合わされることもできることにも留意されたい。したがって、上で提示された代替実施形態は、互いに排他的でなく、図２ａおよび２ｂに示される汎用的なシナリオと同じまたは等価なシナリオを作り出すように、混合され、調和され、組み合わされることができる。ほとんどのプログラミング構成の場合のように、本明細書では説明されないであろうが、それにもかかわらず本発明の精神および範囲によって表されるインターフェースの同じまたは類似の機能を達成する他の同様の方法があることにも留意されたい。すなわち、インターフェースの価値を決定するのは、少なくとも一部は、インターフェースによって表される機能、およびインターフェースによって可能にされる有利な結果であることに留意されたい。

以下の説明において、特に指定のない限り、動作および１つまたは複数のコンピュータによって実施される操作の象徴的な表現を参照して本発明が説明される。そのようなものとして、このような動作および操作は、コンピュータで実行されるものと見なされる場合があり、構造化された形態でデータを表す電気信号を扱うコンピュータの処理装置による操作を含むことが理解されよう。この処理はデータを変換しまたはコンピュータのメモリシステム内の場所に保持し、メモリシステムは、当業者によく理解されたやり方でコンピュータの動作を再構成しまたは変更する。データが保持されるデータ構造は、データの形式によって定義される特定の特性を有するメモリの物理的な場所である。ただし、本発明は上記の状況で説明されているが、当業者であれば理解するように、限定を意図するものではなく、これ以降説明される様々な動作および操作はハードウェアでも実装され得る。

ここで図８に移ると、図８は、本発明が作用する例示的な環境２００を示す。アプリケーション２０２、２０４は、サーバ２０６に常駐している。ウィンドウマネージャ２０８は、ウィンドウと協働しウィンドウを編成することを可能にし、上記の操作をより容易にする、ウィンドウの移動、ウィンドウのサイズ変更、ウィンドウの破壊、タイトルバーおよび他の項目でのウィンドウの装飾などを実施する。アプリケーション２０２、２０４は、項目（たとえば、テキストドキュメント、グラフィック、アニメーションなど）がアプリケーションによってどのようにして表示されているかを示すためのビジュアルツリー２１０、２１２を作成する。ビジュアルツリーは、グラフィックスシステムによって媒体（たとえば、表示モニタ、プリンタ、面など）にレンダリングされるデータ構造を表す。ビジュアルツリーがレンダリングされると、ビジュアルツリー中のデータは、アプリケーションが使われているときにユーザがディスプレイのアプリケーション領域中で目にする「シーン」となる。アプリケーション２０２、２０４は、それぞれのビジュアルツリーに対する制御を保ち続けて、表示デバイス（たとえば、モニタ１９１）のアプリケーション表示領域で起こりつつあることを制御する。アプリケーション２０２、２０４は、そのビジュアルツリーの出力を、インターフェース２２８を介して処理中構成ループに提出する。この出力は、アプリケーションのビジュアルツリーのサブツリーを構築するのに用いられる。サブツリーは、面に構成され、この面は、デスクトップの構成のためにウィンドウマネージャ２０８に提出される。ウィンドウマネージャ２０８は次いで、ディスプレイでのアプリケーションの可視性に基づいて、何が表示され何が表示されないかを判断し、この判断に基づいて、構成ツリー２１４、２１６が作成される。構成ツリーは、ビジュアルツリーとは独立してレンダリングされる。構成ツリーは、ユーザが表示デバイス上で目にする、ビジュアルツリーからコンパイルされたすべての要素を含む。たとえば、ビジュアルツリーがドキュメント用に作成された場合、構成ツリーは、表示されているドキュメントのそうした部分となる。

本発明は、サーバで構成ツリーを作成する必要なく、構成ツリーがリモートに作成され操作されることを可能にする。本発明は、構成ツリーをリモートに作成し操作するという観点で説明されるが、本発明は、図８のサーバ上で構成物を作成しレンダリングするのにも利用され得ることを理解されたい。ここで、図９に移ると、サーバ２０６上のアプリケーション２０２、２０４が、クライアントデバイス２２０に表示されている。１台のクライアントデバイスのみが示されているが、任意の数のクライアントデバイスが使われ得ることを理解されたい。アプリケーション２０２、２０４およびウィンドウマネージャ２０８は、パケットを使い、通信チャネル２３２を経由し、ネットワーク２３０を介してそれぞれの構成モジュール２２２〜２２６と通信するのに、インターフェース２２８を用いる。１つのアプリケーションドメインとともに使われ得る構成モジュールの数は、要望に応じた任意の数でよい。サーバ２０６およびクライアント２２０は、ネットワークまたは他のどの手段によっても接続される必要はなく、データは、サーバプラットフォームによって書き込まれクライアントプラットフォームまたはプラットフォーム群によって読み取られるどの媒体を介しても移行され得ることに留意されたい。一実施形態では、パケットは、クライアント２２０に構成ツリー２１４、２１６を作成するための情報を送るために、リモートデータプロトコルとともにカプセル化される。どの構成モジュール２２２〜２２６がパケットの宛先であるかを識別するための識別子が、各パケット中に置かれる。コンポーネント２３４は、パケットを逆多重化し、モジュール２２２〜２２６の適切な変更キュー２４０、２４２、２４４にパケットを送る。

本発明のデバイス非依存プロトコルは、内容を構成するために通信チャネル２３２を介してサーバとインターフェースをとるためのアプリケーションおよびクライアントを提供する。内容のタイプは、リソースコマンドパケットおよびコントロールパケットを含む。リソースタイプは、ペン、ブラシ、ビットマップ、グリフ、ビデオクリップ、ジオメトリ（省略符号、矩形、ボックス、円など）、アニメーション、メモリなどを含む。構成ノードは、クライアントアプリケーションにとって使用可能な、空間的閉じ込め（ｃｏｎｔａｉｎｍｅｎｔ）の基本構成単位である。クライアントは、その構成サービスにおいて構成ノードを作成する。構成ノードは、１つまたは複数のリソースを含むことができる。画面内容またはデスクトップを表す１つのルート構成ノードが常に存在する。オフスクリーン構成を表す１つまたは複数の構成ノードが存在してもよい。

以下の説明において、デバイス非依存プロトコルは、一般的なコールシーケンスを用いて説明される。通信は非同期である。特殊な接続、再接続、および切断セマンティクスが用いられる。アプリケーション２０２、２０４、２０８は、クライアント２２０に常駐するそれぞれの構成モジュール２２２、２２４と通信する。通常、アプリケーションの存続期間に対して一度の接続が開始され維持される。というのは、接続および接続の切断はコストのかかる動作であり、クライアント上の構成モジュールへの通信は、頻繁に行われがちだからである。接続を維持するコストは、繰り返し切断し接続するコストよりも大幅に低いであろう。サーバアプリケーション２０２、２０４、２０８と構成モジュール２２２〜２２６の間の通信は、パケットの形態にある。

サーバアプリケーション２０２、２０４、２０８は、クライアント２２０へ接続し、パケットの送信を開始する。パケットは、リソースパケット、コントロールパケット、およびバッチパケットでよい。リソースパケットは、リソースを作成しリソースをアップデートするのに使われる。コントロールパケットは、構成状態を制御しクライアントマシン２２０上にテキストグリフのビットマップキャッシュを維持するのに使われる。バッチパケットは、複数の変更を自動的に適用するのに使われる。バッチ作成コマンドが、バッチの開始を指示するためにクライアント２２０に送られる。構成モジュールは、バッチが「終了される」まで要求を蓄積する。バッチは、バッチクローズ／コミットパケットを送ることによって終了される。その時点で、構成サービスは、コマンドの処理を開始する。構成サービス内部の変更キューは、変更が自動的に起こるようにするために、バッチ構成体を保持する。

ここで、図１０に移ると、構成物を作成し制御するステップが示されている。サーバアプリケーション２０２が、こうしたステップを説明するのに用いられる。コードのどのセグメント（群）も使われ得ることを当業者は理解するであろう。構成モジュールが作成される（ステップ３００）。構成モジュールは、すでに行われている接続に関する構成のレンダリングに責任がある。レンダリングターゲットリソースを作成するためのリソースコマンドを生成するレンダリングターゲットが作成され（ステップ３０２）、レンダリングターゲットリソースに関連づけられたレンダリングコンテキストが作成される（ステップ３０４）。レンダリングターゲットは、リソースをレンダリングするための宛先ターゲットである。構成ノードが作成される（ステップ３０６）。次いで、リソースが作成され（ステップ３０８）、構成物がレンダリングされる（ステップ３１０）。

構成は、ターゲットに内容をレンダリングするために、シンプルリソースおよび合成リソースの組合せを使用する。シンプルリソースとは、内蔵型であり、他のどのリソースにも直接依存しない。合成リソースは、他の依存リソースを参照する。合成リソースの一例は、「レンダリングデータ」リソースである。「レンダリングデータ」リソースは、ブラシ、ペン、またはジオメトリの記述など、他のリソースを参照することができるレンダリング命令を保持したリストからなる。レンダリングデータリソースは、他のリソースの補助によって実施されるレンダリング操作をエンコードするのに用いられる。レンダリングデータリソースは、こうしたレンダリング操作を空間的に限定させる役割をもつ構成ノードに関連づけられる。

構成物がアップデートされる必要がある場合、アップデートコマンドが送信される（ステップ３１２）。アップデートは、リソースの追加でもリソースのアップデートでもよい。ある特定の構成物が消去され、新しい構成物が作成される必要があり得る。たとえば、構成物がテキストドキュメントの場合、テキストドキュメントが閉じられるとその構成物が消去される。構成物が消去されることになると、消滅コマンドが構成サービスに送信される（ステップ３１４）。

アニメーションは、プラットフォーム全体に広がることができる。本発明は、一実施形態では、アニメーションを評価し提示する全責任をクライアントに負わせることによって、スケーラブルアニメーションを生み出す。これは多くの場合、特にアニメーションが複雑である場合、または高速化されていない１組の操作（モザイク化（ｔｅｓｓｅｌｌａｔｉｏｎ）など））が起こることをアニメーションターゲットが要求する場合において十分である。動作アニメーションなど、低コストで可視性の高い特定のユーザインターフェース効果に対して、チェーンの構成パスの間にこうした操作を起こらせることは妥当である。このような場合、アプリケーション２０２は、高レベルのアニメーション機能をサンプリングし、構成サービスへの要求として、リソースに関連づけられた一連のタイムスタンプ値をもたらすことになる。こうした値は、リソースがアニメーション化される期間、および間隔がアクティブ状態のままであるタイムラインの終点を表す。アプリケーション２０２は、リソースの値をアップデートするためのアップデートリソースパケットを送る。シーケンスは、基底の複雑さと矛盾することに留意されたい。構成モジュールは、タイムスタンプ値を構成サービスのグローバルタイムラインに正規化し、構成マネージャ（図示せず）は、レンダリングターゲットへの構成中に、アップデートブロックを適切なリソースに詰める。構成された各フレームごとに、構成モジュールは、瞬間値を導出するためにリソースの間隔を評価する。

プログラミングインターフェースの全体構造が説明されたので、次にリソースおよび制御コマンドパケットが説明される。コントロールパケットは、構成状態を制御し、クライアント２２０上の構成モジュールによって使われるテキストグリフのキャッシュを維持するのに用いられる。

コントロールパケットは、Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｎｕｌｌ、Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｒｅｌｅａｓｅ、Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｓｈｕｔｄｏｗｎ、Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｓｙｎｃｈｒｏｎｉｚｅ、Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｓｔａｔｕｓ、Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ａｄｄ＿Ｇｌｙｐｈ＿Ｂｉｔｍａｐｓ、Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｆｒｅｅ＿Ｇｌｙｐｈ＿Ｂｉｔｍａｐｓ、およびＲｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｆｌｕｓｈ＿Ｑｕｅｕｅである。Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｒｅｌｅａｓｅは、リソースを解放する。Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｓｈｕｔｄｏｗｎは、構成モジュールをシャットダウンし、構成モジュールに関連づけられたすべてのものを消去する。Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｓｙｎｃｈｒｏｎｉｚｅコマンドは、フレッシュスタートを行うために、構成ノードに関連づけられたすべてのものを消去する。Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｓｔａｔｕｓは、構成モジュールに状況メッセージを送る。Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ａｄｄ＿Ｇｌｙｐｈ＿Ｂｉｔｍａｐｓは、グリフのキャッシュにビットマップを追加する。Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｆｒｅｅ＿Ｇｌｙｐｈ＿Ｂｉｔｍａｐｓは、グリフのキャッシュからビットマップを削除する。Ｒｅｓｏｕｒｃｅ＿Ｃｏｍｍａｎｄ＿Ｆｌｕｓｈ＿Ｑｕｅｕｅは、変更キューをフラッシュする。

クライアント２２０からサーバ２０６に通知パケットを移送し戻す通知キューが維持される。こうしたキューは、次のタイプ、すなわちＮｏｔｉｆｉｃａｔｉｏｎ＿Ｒｅｓｏｕｒｃｅ＿Ｄｅｌｅｔｅｄ、Ｎｏｔｉｆｉｃａｔｉｏｎ＿Ｓｈｕｔｄｏｗｎ、Ｎｏｔｉｆｉｃａｔｉｏｎ＿Ｓｙｎｃｈｒｏｎｉｚｅ、Ｎｏｔｉｆｉｃａｔｉｏｎ＿Ｓｔａｔｕｓ、およびＮｏｔｉｆｉｃａｔｉｏｎ＿Ｅｒｒｏｒであり得る。

リソースコマンドパケットは、リソースをレンダリングするのに用いられる。リソースとは、「異なる解像度および／または物理デバイスについて異なる具現化を要求するシーンのレンダリングに必要とされる任意のオブジェクト、構成ツリーにおいて何度も使われる任意のオブジェクト、またはアニメーションを介してなど、ユーザと関わりなく変化し得る任意のオブジェクト」と定義されることができる。リソースは、それ自体をシリアル化し、アップデートを適用し、ある特定の解像度およびデバイスに対する具現化をもたらすことができる。リソースタイプは、Ｎｕｌｌ、Ｍｅｍｏｒｙ、Ｒｅｎｄｅｒｄａｔａ、Ｂｉｔｍａｐ、Ｇｌｙｐｈｒｕｎ、Ｖｅｒｔｉｃｅｓ、Ｔｉｍｅｌｉｎｅ、Ｄｏｕｂｌｅａｎｉｍａｔｉｏｎ、Ｃｏｌｏｒａｎｉｍａｔｉｏｎ、Ｐｏｉｎｔａｎｉｍａｔｉｏｎ、Ｒｅｃｔａｎｉｍａｔｉｏｎ、Ｓｉｚｅａｎｉｍａｔｉｏｎ、Ｄｏｕｂｌｅａｎｉｍａｔｉｏｎｃｏｌｌｅｃｔｉｏｎ、Ｃｏｌｏｒａｎｉｍａｔｉｏｎｃｏｌｌｅｃｔｉｏｎ、Ｐｏｉｎｔａｎｉｍａｔｉｏｎｃｏｌｌｅｃｔｉｏｎ、Ｒｅｃｔａｎｉｍａｔｉｏｎｃｏｌｌｅｃｔｉｏｎ、Ｓｉｚｅａｎｉｍａｔｉｏｎｃｏｌｌｅｃｔｉｏｎ、Ｔｒａｎｓｆｏｒｍ、Ｄｏｕｂｌｅ、Ｃｏｌｏｒ、Ｐｏｉｎｔ、Ｒｅｃｔ、Ｓｉｚｅ、Ｇｒａｄｉｅｎｔ、Ｂｒｕｓｈ、Ｆｉｇｕｒｅ、Ｇｅｏｍｅｔｒｙ、Ｐｅｎ、Ｖｉｄｅｏ、Ｃｏｍｐｏｓｉｔｉｏｎ＿Ｎｏｄｅ、Ｃｏｍｐｏｓｉｔｉｏｎ＿Ｃｏｎｔｅｘｔ、Ｉｍａｇｅ、Ｈｗｎｄ＿Ｃｏｍｐｏｓｉｔｉｏｎ＿Ｔａｒｇｅｔ、およびＩｎｔｅｒｍｅｄｉａｔｅ＿Ｃｏｍｐｏｓｉｔｉｏｎ＿Ｔａｒｇｅｔを含む。Ｈｗｎｄ＿Ｃｏｍｐｏｓｉｔｉｏｎ＿Ｔａｒｇｅｔは、ウィンドウをレンダリングするのに用いられる。中間構成ターゲットは、オフスクリーンレンダリングのために使われ得る。

構成モジュールに送られるリソースは概して、コールバックなしで、構成モジュールによって直接具現化可能である。直接具現化することができない場合、必要とされる具現化されたものが送られる。「テキスト」および「イメージ」のようなリソースは、具現化するのに（オーバーヘッドの処理という点で）コストがかかり、したがって、構成ツリーで使うための適切な「レンダリング準備完了」の形態に変換される。容易にレンダリングされ得る形態へのリソースの変換は、構成モジュールにおける構成に対するオーバーヘッドを節約する。リソースは、ユーザコードへのいずれかのコールバックを必要とする場合にも、適切な「レンダリング準備完了」の形態に変換される。構成モジュールによって、必要な場合には適正な解像度に効率的にモザイク化（ｔｅｓｓｅｌｌａｔ）され得る「ジオメトリ」のような他のリソースは、構成モジュール自体によって具現化される。

リソースは概して、描画リソース、値リソース、および構造リソースなど、いくつかのタイプに分けられる。描画リソースは、レンダリング層によって定義されるオブジェクトであり、その層によって直接消費されることができる。描画リソースの例は、ＲｅｎｄｅｒＤａｔａ、Ｂｉｔｍａｐ、Ｉｍａｇｅ、Ｇｌｙｐｈｒｕｎ、Ｇｅｏｍｅｔｒｙ、およびＢｒｕｓｈを含む。

レンダリングコストが非常に低く一定である描画リソースは、構成中に、デバイスおよび解像度非依存ソースデータから直接具現化されることができる。ジオメトリは、構成モジュールの構成ループにおいて効率的に、最終的に要求される解像度にモザイク化され得るので、シンプルな描画リソースである。対照的に、合成描画リソースは、具現物を生成するために、複雑な計算、ユーザコードへのコールバック、または入出力を必要とする。一実施形態では、合成描画リソースは、構成モジュールによって具現化されない。そうではなく、適切な具現化は、構成に先立ってアプリケーション２０２、２０４および／またはサーバ２０６によってもたらされる。「イメージ」が、合成リソースの例である。イメージは、ディスクから読み取られ、デコードされ、適切な解像度でサンプリングされ、フィルタリングされる。

値リソースは、別のリソースによって使われるシンプルな可変値または活動値を表す。値リソースの例は、Ｄｏｕｂｌｅ、Ｐｏｉｎｔ、Ｃｏｌｏｒ、およびＴｒａｎｓｆｏｒｍである。たとえば、ＲｅｎｄｅｒＤａｔａリソースは、点の１つが、アニメーションまたはアプリケーションによる強制的な指示によって変化することが期待される場合、線を引くためにＰｏｉｎｔリソースを参照することができる。値リソースは、静的でも活動的でもよい。値リソースが活動的である場合、値リソースは、値が時間とともにどのように変わるかを定義するアニメーション間隔データを含む。

構造リソースは、構成プロセスにおいて役割を担うが、直接にはレンダリングの一部ではないオブジェクトである。こうしたオブジェクトは、変更キューを介してアップデートに関与し、内部の値をアップデートするのに値リソースを使うことができるリソースとして実装される。識別されている構造リソースは、構成ノードを含む。

概して、リソースは、使われることができるようになる前に具現化されなければならない。具現化されたものは、「所与の解像度に適し、ある特定のデバイスによって使われる準備ができているリソースの表現」と呼ばれ得る。具現化の例は、ある特定の解像度および形式変換に合わせて三角形になるようにモザイク化されたジオメトリであり、ビデオカード上の頂点バッファにすでにロードされている可能性が高い。具現化は、構成モジュールにおいてオンデマンドで作成されるか、またはサーバ２０６で作成され、構成モジュールに送られる。要求されるリソースの具現化が見つけられることも作成されることもできない場合、通知が、サーバ２０６への通知キューによってキューに入れられる。通知は、用いられる具現化のどの形式変換とも一緒に、必要とされるリソースハンドル、形式変換、およびデバイスを示す。

パケットは、下に示すような構造をもつ。

ここで、Ｍｉｌ＿Ｐａｃｋｅｔ＿Ｔｙｐｅは、バッチパケット、コントロールパケット、またはリソースパケットの１つである。ＨＭＩＬ＿Ｒｅｓｏｕｒｃｅハンドルは、リソースに対して適切なタイプでなければならない。こうしたハンドルは、リソース、コンテキスト、または構成ノード（たとえばｃｏｍｐｎｏｄｅ）に対するものでなければならない。ＭＩＬ＿Ｒｅｓｏｕｒｃｅ＿Ｔｙｐｅは、上に示すようなリソースのタイプ（たとえば、ビットマップ、形式変換、ジオメトリなど）である。

パケットには、タスクを実施するよう構成サービスに命令するのに使われるコマンドが付加されている。このコマンド付加は、サードパーティベンダが、その構成サービスを動作させる独自のコードを供給することを可能にする。このような一実装形態は以下の通りである。

ステップ３００から３１４を実施する命令の例は以下の通りである。この例において、構成モジュールおよびレンダリングターゲットが作成される。次いで、バッチオープンコントロールパケットが送信される。構成ノード、レンダリングデータリソース、および構成コンテキストを作成するためのコマンドが送信される。構成コンテキストにおいてルートノードが設定され、構成コンテキストは、ｈｗｎｄターゲット上に設定される。この時点で、構成ノード、構成コンテキスト、レンダリングデータリソース、ルートノード、およびｈｗｎｄターゲットが関連づけられる。次いで、リソースが作成される。リソースは、ジオメトリリソース、立体ブラシリソース、およびペンリソースである。次いで、ペンをアップデートし、ジオメトリリソースに楕円を追加し、ジオメトリを描画するためにアップデートパケットが送られる。次いで、色塗りされた矩形が描画され、レンダリングデータが構成ノード上に設定され、構成ノードがアップデートされる。構成物を消去するために、リソースを解放するためのリソース解放コマンドが送られ、構成デバイスが消滅させられる。

上述の説明から理解され得るように、リモートデバイス上で構成物を作成し制御するための方法およびプロトコルが開示された。このプロトコルは、サーバおよび他のデバイスが、リモートデバイス上に構成物をレンダリングするために、リモートデバイスの処理能力を利用することを可能にする。こうすることは、サーバが、より多くのクライアントを扱うことを可能にする。というのは、サーバは、構成物を実際にレンダリングするのに使われる機能（たとえば、ペイント、ドロー、アニメーションなど）を処理する必要がないからである。この結果、クライアントの３Ｄハードウェアアクセラレーションパイプ、およびクライアントのＣＰＵなど、クライアント側のハードウェア性能をより多く利用することができるようになる。たとえば、クライアントは、アニメーション機能を処理することができ、このことは、サーバがクライアントに、アニメーションフレームを送る代わりに、アニメーション機能を記述する情報を送ることを可能にする。

以上、本発明の原理が適用され得る多くの可能な実施形態を検討したが、図面に関連して本明細書において説明された実施形態は、例示のみを意図しており、本発明の範囲を限定するものととられるべきではないことが理解されるべきである。たとえば、例示された実施形態の、ソフトウェアとして示した要素は、ハードウェアとして実装されることもでき、その逆も可能であり、あるいは、本発明の精神から逸脱することなく、例示された実施形態は、構成および細部において変更され得ることを当業者は理解するであろう。したがって、本明細書に記載した本発明は、このようなすべての実施形態が添付の請求項およびその均等物の範囲内であり得ることを企図している。

本発明が帰属する例示的なコンピュータシステム全体を示すブロック図である。 ２つのコードセグメントの間のプログラミングインターフェースを示す、簡略化したブロック図である。 ２つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す、簡略化したブロック図である。 因数分解の概念を示す、複数の別々の通信に分けられた通信を有する、２つのコードセグメントの間のプログラミングインターフェースを示す簡略化したブロック図である。 因数分解の概念を示す、複数の別々の通信に分けられた通信を有する、２つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。 再定義の概念を示す、特定の特徴が無視され、追加され、または再定義されている、２つのコードセグメントの間のプログラミングインターフェースを示す簡略化したブロック図である。 再定義の概念を示す、特定の特徴が無視され、追加され、または再定義されている、２つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。 インラインコーディングの概念を示す、２つのコードモジュールの間のインターフェースが形態を変えるようにそのコードモジュールの機能の一部をマージさせた、２つのコードセグメントの間のプログラミングインターフェースを示す簡略化したブロック図である。 インラインコーディングの概念を示す、２つのコードモジュールの間のインターフェースが形態を変えるようにそのコードモジュールの機能の一部をマージさせた、２つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。 分離の概念を示す、通信を複数の別々の通信に分けることによって通信が間接的に遂行される、２つのコードモジュールの間のプログラミングインターフェースを示す簡略化したブロック図である。 分離の概念を示す、通信を複数の別々の通信に分けることによって通信が間接的に遂行される、２つのコードモジュールの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。 書換えの概念を示す、同じ結果を達成する他のものでプログラミングインターフェースを置き換えるために動的に書き換えられたコードを示す簡略化したブロック図である。 書換えの概念を示す、同じ結果を達成する他のものでプログラミングインターフェースを置き換えるために動的に書き換えられたコードの代替実施形態を示す簡略化したブロック図である。 本発明が作用する例示的な環境全体を示すブロック図である。 本発明が作用する例示的な代替環境全体を示すブロック図である。 本発明の教示によって構成物を作成するためのステップを示すフローチャートである。

Claims (8)

1. デバイス上にコンポジションをレンダリングするための方法であって、
   コンピュータが、コンポジションノード作成パケットの受取りに応答してコンポジションノードを作成するステップと、
   コンピュータが、少なくとも１つのリソース作成パケットの受取りに応答して前記コンポジションをレンダリングする少なくとも１つのリソースを作成するステップであって、該ステップが、
   コンピュータが、前記少なくとも１つのリソースに関連づけられた一連のタイムスタンプ値を受取るステップであって、該一連のタイムスタンプ値が、前記少なくとも１つのリソースのアニメーションされる期間及び該期間がアクティブ状態に保持されるタイムラインの終点を表す、ステップ、
   コンピュータが、前記一連のタイムスタンプ値をグローバルタイムラインに正規化するステップ、及び、
   コンピュータが、前記期間の各々を評価し前記少なくとも１つのリソースに関する瞬間値を導出するステップを含む、ステップと、
   コンピュータが、少なくとも１つのレンダリングアップデートパケットに応答して前記コンポジションを作成するステップとを含むことを特徴とする方法。
2. レンダリングデータリソース作成パケットの受取りに応答してレンダリングデータリソースを作成するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. バッチオープンパケットの受取りに応答してバッチプロセスをオープンするステップをさらに含むことを特徴とする請求項１に記載の方法。
4. バッチクローズ／コミットパケットの受取りに応答して少なくとも１つのリソース作成パケットおよび少なくとも１つのリソースアップデートパケットの一方を処理するステップをさらに含むことを特徴とする請求項３に記載の方法。
5. 解放コマンドの受取りに応答してリソースを解放するステップをさらに含むことを特徴とする請求項１に記載の方法。
6. コマンドパケットの受取りに応答して通知を送信するステップをさらに含むことを特徴とする請求項１に記載の方法。
7. 請求項１〜６のいずれか１項に記載のステップをコンピュータに実行させるためのプログラム。
8. 請求項１〜６のいずれか１項に記載のステップをコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images