リモートなビジュアル構成のためのプロトコル
リモートデバイス上で構成物を作成し制御する方法およびプロトコルが開示される。本プロトコルは、サーバおよび他のデバイスが、リモートデバイス上に構成物をレンダリングするために、リモートデバイスの処理能力を利用することを可能にし、そうすることによって、サーバのスケーラビリティ、およびリモートデバイスの処理能力の利用を高める。本プロトコルは、リモートデバイスにリソースコマンドパケットおよびコントロールパケットを伝達するための高レベルのコマンドパケットを提供し、パケットは、コマンドを処理するのに必要とされる情報をもつペイロードを有する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概して電子データ処理に関し、より詳細には、コンピュータシステムにおけるグラフィックスおよび制御情報の流れの管理に関する。
【背景技術】
【0002】
デジタル方式で作成されたマルチメディア、デジタルデバイス上で閲覧するためのデジタル形式のビデオおよびオーディオの組合せ、ならびにイメージおよびアニメーションなどのデジタル媒体は、急速に容量が増え、数も急増している。今日製造されているほぼすべての新しいパーソナルコンピュータは、何らかの形態のマルチメディアを含んでいる。カメラ、ビデオレコーダ、電話およびテレビなどのデジタル製品の売上げは、堅調に伸びている。インターネットの成長が堅調かつ急速に続いているので、マルチメディアは、インターネットの領域にもますます普及しつつある。こうしたコンピュータベースの技術における進歩の継続は、性能の向上をもたらしただけでなく、このようなコンピュータ機器ユーザの、性能への期待も高めている。コンピュータ業界は、CD ROMドライブ、通信モデムの速度向上、ならびにより高速なビデオカードおよびオーディオカードによってこうした期待に応えてきた。こうしたユーザの期待の高まりは、ハードウェアの性能だけでなく、データの処理性能にも及んでいる。
【0003】
たとえば、マルチメディアおよびオーディオ圧縮などの分野において、データは、安定した連続するストリームとして処理され得るように処理される。このデータは、TV会議、ゲーム、DVD(デジタルビデオディスク)、プロ向けのオーディオ、電話などの分野、ならびにオーディオ、ビデオ、またはオーディオおよびビデオがデジタル処理される他の分野で用いられる。
【発明の開示】
【発明が解決しようとする課題】
【0004】
データのレンダリングは、ほとんどいつでも、システム内の様々なモジュールにおける何らかの形態の処理を必要とする。たとえば、ビデオクリップは、専用のハードウェアモジュールでのデコード、別のハードウェアモジュールでのビデオフィールドのラスタ化、ソフトウェアモジュールでのオーディオのデジタルフィルタリング、別のソフトウェアモジュールによるサブタイトルの挿入、ソフトウェアモジュールによる、無音期間をスキップするためのオーディオデータの解析などを必要とするであろう。ストリーミングを働かせるために、データは、定常ストリームとして処理され、次いで、オーディオおよび/またはビデオにレンダリングされる。ただし、データが十分に速く処理されないと、データの提示が円滑にならない。
【0005】
従来のクライアント−サーバ間のレンダリングでは、データは、サーバで処理され、異なる仮想フレームに入れられてクライアントに送られ、ここでフレームがレンダリングされる。各フレームは、レンダリングされる項目に変更がない場合でも、そのフレームをレンダリングするのに必要とされる全データおよび情報を含む。たとえば、すべてのアニメーションフレームは、そのフレームが隣接フレームと同一であっても、そのフレームをレンダリングするための全部のデータおよび情報をもつ。その結果、データの伝送は、大量の利用可能帯域幅を消費する。この帯域幅消費は、サーバがサポートし得るクライアントの数を減少させる。さらに、クライアントマシン上のハードウェアは、データを処理するのに利用されることができない。たとえば、データを処理するサーバは、3Dグラフィックアクセラレータなど、クライアントハードウェアのハードウェア特徴を利用することができない。
【課題を解決するための手段】
【0006】
本発明は、リモートデバイス上で構成物を作成し制御する方法およびプロトコルを提供する。このプロトコルは、サーバおよび他のデバイスが、リモート表示デバイス上に画像コンテンツを構成するために、リモートデバイスの処理能力を利用できるようにさせる。こうすることは、サーバが、より多くのクライアントを扱うことを可能にする。というのは、サーバは、構成物を実際にレンダリングするのに使われる機能(たとえば、ペイント、ドロー、アニメーションなど)を処理する必要がないからである。この結果、クライアントの3Dハードウェアアクセラレーションパイプ、およびクライアントのCPUなど、クライアント側のハードウェア性能をより多く利用することができるようになる。たとえば、クライアントは、アニメーション機能を処理することができ、このことは、サーバがクライアントに、全アニメーション効果を含む個々の静的フレームを送る代わりに、アニメーション機能を記述する情報を送ることを可能にする。
【0007】
本プロトコルは、アプリケーションが、クライアントデバイス上に構成物を作成するために、媒体を介してコマンドを伝達することを可能にする基本的な高レベルのコマンドパケットを提供する。こうしたパケットのペイロードは、構成物を作成するための、デバイス上のコンポーネントに対する実際のコマンドを含むことができる。要求アプリケーションは、構成サービスを作成し、レンダリングターゲットおよびレンダリングコンテキストを作成し、構成ノードを作成し、構成ノード用のリソースを作成し、構成物をレンダリングするためのコマンドのパケットを送る。
【0008】
要求アプリケーションからのパケットは、リソースコマンドパケットおよびコントロールパケットである。リソースコマンドパケットは、クライアント上の該当するリソースに経路指定される。コントロールパケットは、構成状態を制御し、クライアントマシン上でテキストグリフ(text glyph)のキャッシュを維持するのに使われる。通知パケットが、要求アプリケーションに返送される。
【0009】
本発明の追加の特徴および利点が、添付の図面を参照して進められる、例示的な実施形態の以下の詳細な説明から明らかになるであろう。
【0010】
添付の特許請求の範囲は本発明の特徴を具体的に定義するが、本発明、ならびにその目的および利点は、以下の詳細な説明を添付の図面と併せ読むことによって最もよく理解されることができよう。
【発明を実施するための最良の形態】
【0011】
本発明は、サーバが、構成処理の諸態様をクライアントマシンにオフロードする機能を提供する。この結果、サーバ側のスケーラビリティが向上する。通信プロトコルの高レベルの記述性によって、即時モードモデルを用いてデータを送る場合よりも、データをレンダリングするために大幅に少ない量のデータおよび情報がクライアントに送られるようになる。
【0012】
本発明の詳細を述べる前に、本発明が実装され得る例示的なデバイス、および本発明が作用し得る環境の概略が述べられる。図面に移ると、同じ参照番号は同じ要素を指し、本発明は、適切なコンピューティング環境において実装されるものとして示される。そうすることが必要なわけではないが、パーソナルコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的なコンテキストにおいて、本発明が説明される。概して、プログラムモジュールは、特定のタスクを実施しまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、可搬型デバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ネットワークPC、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成を用いて実施され得ることを当業者は理解するであろう。本発明は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実施される分散型コンピューティング環境でも実施されることができる。分散型コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートメモリ記憶装置両方に配置されることができる。
【0013】
図1は、本発明が実施され得る、適切なコンピューティングシステム環境の例100を示す。コンピューティングシステム環境100は、適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲に対するどのような限定を示唆することも意図されない。コンピューティング環境100は、例示的な動作環境100に示されるどのコンポーネントまたはその組合せに関するどのような依存も要件も有していると解釈されるべきでない。
【0014】
本発明は、他の数多くの汎用または専用のコンピューティングシステム環境または構成と動作する。本発明とともに使用するのに適切であり得る公知のコンピューティングシステム、環境、および/または構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ型デバイス、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークPC、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれをも含む分散型コンピューティング環境などを含むが、それに限定されない。
【0015】
本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的なコンテキストにおいて説明されることができる。概して、プログラムモジュールは、特定のタスクを実施しまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実施される分散型コンピューティング環境でも実施されることができる。分散型コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよび/またはリモートコンピュータ記憶媒体に置かれることができる。
【0016】
図1を参照すると、本発明を実施する例示的なシステムは、汎用コンピューティング装置を、コンピュータ110の形態で含む。コンピュータ110のコンポーネントは、処理ユニット120と、システムメモリ130と、システムメモリなど様々なシステムコンポーネントを処理ユニット120に結合するシステムバス121とを含むことができるが、それに限定されない。システムバス121は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスなどいくつかの種類のバス構造のいずれでもよい。限定ではなく例として、このようなアーキテクチャは、ISA(業界標準アーキテクチャ)バス、MCA(マイクロチャネルアーキテクチャ)バス、EISA(拡張ISA)バス、VESA(米国ビデオ電子装置規格化協会)ローカルバス、およびメザニン(Mezzanine)バスとしても知られるPCI(周辺装置相互接続)バスを含む。
【0017】
コンピュータ110は通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ110によってアクセスされ得るとともに揮発性媒体および不揮発性媒体、着脱式媒体および固定式媒体両方を含む、利用可能などの媒体でもよい。限定ではなく例として、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するためのどの方法でも技術でも実施される揮発性媒体および不揮発性媒体、着脱式媒体および固定式媒体を含む。コンピュータ記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD−ROM、DVD(デジタル多用途ディスク)または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは、所望の情報を格納するのに使われることができるとともにコンピュータ110によってアクセスされることができる他のどの媒体も含むが、それに限定されない。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、変調データ信号、たとえば搬送波や他の移送機構として具体化し、どの情報配信媒体も含む。「変調データ信号」という用語は、信号に情報を符号化するように信号特性の1つまたは複数が設定されまたは変更された信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークや直接有線接続などの有線媒体、ならびに音響、RF、赤外線、および他の無線媒体などの無線媒体を含む。上記のどの組合せも、やはりコンピュータ可読媒体の範囲に含まれるべきである。
【0018】
システムメモリ130は、コンピュータ記憶媒体を、ROM(読出し専用メモリ)131およびRAM(ランダムアクセスメモリ)132など、揮発性および/または不揮発性メモリの形態で含む。BIOS(基本入出力システム)133は、たとえば起動中にコンピュータ110内部の要素間での情報の転送を助ける基本ルーチンを含み、通常はROM131に格納される。RAM132は一般に、処理ユニット120に対してただちにアクセス可能な、かつ/または処理ユニット120によって現在操作されているデータおよび/またはプログラムモジュールを含む。限定ではなく例として、図1では、オペレーティングシステム134、アプリケーションプログラム135、他のプログラムモジュール136、およびプログラムデータ137を示す。
【0019】
コンピュータ110は、他の着脱式/固定式、揮発性/不揮発性コンピュータ記憶媒体を含むこともできる。単なる例として、図1では、固定式不揮発性磁気媒体からの読出しまたはそこへの書込みを行うハードディスクドライブ141、着脱式な不揮発性磁気ディスク152からの読出しまたはそこへの書込みを行う磁気ディスクドライブ151、および、CD ROMや他の光学媒体など着脱式な不揮発性光ディスク156からの読出しまたはそこへの書込みを行う光ディスクドライブ155を示す。例示的な動作環境で使われることができる、他の着脱式/固定式、揮発性/不揮発性コンピュータ記憶媒体は、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体状態RAM、固体状態ROMなどを含むが、それに限定されない。ハードディスクドライブ141は通常、インターフェース140などの固定式メモリインターフェースによって、システムバス121に接続され、磁気ディスクドライブ151および光ディスクドライブ155は通常、インターフェース150などの着脱式メモリインターフェースによって、システムバス121に接続される。
【0020】
上述し、かつ図1に示されているディスクドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピュータ110のための他のデータの格納を可能にする。図1では、たとえば、ハードディスクドライブ141は、オペレーティングシステム144、アプリケーションプログラム145、他のプログラムモジュール146、およびプログラムデータ147を格納するものとして示される。こうしたコンポーネントは、オペレーティングシステム134、アプリケーションプログラム135、他のプログラムモジュール136、およびプログラムデータ137と同じでも、異なってもよいことに留意されたい。オペレーティングシステム144、アプリケーションプログラム145、他のプログラムモジュール146、およびプログラムデータ147は、少なくとも異なるものであることを示すために、本明細書では異なる番号が与えられている。ユーザは、キーボード162、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス161、マイクロホン163、およびタブレットまたは電子デジタイザ164を介して、コマンドおよび情報をコンピュータ110に入力することができる。他の入力デバイス(図示せず)は、ジョイスティック、ゲーム用パッド、衛星パラボラアンテナ、スキャナなどを含み得る。こうしたおよび他の入力デバイスはしばしば、システムバスに結合されるユーザ入力インターフェース160を介して処理ユニット120に接続されるが、パラレルポート、ゲームポート、USB(ユニバーサルシリアルバス)など、他のインターフェースおよびバス構造によって接続されることもできる。モニタ191または他の種類の表示デバイスも、ビデオインターフェース190などのインターフェースを介してシステムバス121に接続される。モニタ191は、タッチスクリーンパネルなどとも統合され得る。モニタおよび/またはタッチスクリーンパネルは、タブレットタイプのパーソナルコンピュータでのように、コンピューティング装置110が組み込まれているハウジングに物理的に結合され得ることに留意されたい。さらに、コンピューティング装置110などのコンピュータは、出力周辺インターフェース195などを介して接続されることができるスピーカ197およびプリンタ196など、他の周辺出力デバイスも含むことができる。
【0021】
コンピュータ110は、リモートコンピュータ180など、1つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク接続された環境において動作することができる。リモートコンピュータ180は、パーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピアデバイス、または他の共通ネットワークノードでよく、通常、コンピュータ110に関連して上述された要素の多くまたはすべてを含むが、図1にはメモリ記憶装置181のみが示されている。図1に示される論理接続は、LAN(ローカルエリアネットワーク)171およびWAN(ワイドエリアネットワーク)173を含むが、他のネットワークを含むこともできる。このようなネットワーク環境は、会社、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいてよく見られる。たとえば、コンピュータシステム110は、データがそこから移行されている発信マシンとなることができ、リモートコンピュータ180は、宛先マシンとなることができる。
【0022】
LANネットワーク環境において使われる場合、コンピュータ110は、ネットワークインターフェースまたはアダプタ170を介してLAN171に接続される。WANネットワーク環境において使われる場合、コンピュータ110は通常、モデム172、または、たとえばインターネットなどのWAN173を介して通信を確立する他の手段を含む。モデム172は、内部にあっても外部にあってもよく、ユーザ入力インターフェース160または他の適切な機構を介してシステムバス121に接続されることができる。ネットワーク接続された環境では、コンピュータ110に関連して図示したプログラムモジュールまたはその一部は、リモートメモリ記憶装置に格納されることができる。限定ではなく例として、図1は、リモートアプリケーションプログラム185を、メモリ装置181に常駐するものとして示す。図示したネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段も使われることができることが理解されよう。
【0023】
プログラミングインターフェース(またはより簡単には、インターフェース)は、コードの1つまたは複数のセグメント(群)が、コードの1つまたは複数の他のセグメント(群)によって提供される機能と通信しまたは機能にアクセスすることを可能にする、どの仕組み、処理、プロトコルとしても見なされ得ることに留意されたい。あるいは、プログラミングインターフェースは、他のコンポーネント(群)の、1つまたは複数の仕組み(群)、方法(群)、関数呼出し(群)、モジュール(群)などと通信結合することができる、システムのあるコンポーネントの、1つまたは複数の仕組み(群)、方法(群)、関数呼出し(群)、モジュール(群)、オブジェクト(群)などとして見なされ得る。上記の文における「コードのセグメント」という用語は、適用される専門範囲に関わらず、かつコードセグメントが個別にコンパイルされるかどうか、コードセグメントがソースコード、中間コード、またはオブジェクトコードとして提供されるのか、コードセグメントがランタイムシステムまたは処理において使用されるのか、コードセグメントが同じマシンもしくは異なるマシンに置かれるか、それとも複数のマシンに分散されるか、あるいはコードのセグメントによって表される機能が、完全にソフトウェアとして、完全にハードウェアとして、またはハードウェアおよびソフトウェアの組合せとして実装されるのかに関わらず、1つまたは複数の命令またはコードの行を含み、たとえば、コードモジュール、オブジェクト、サブルーチン、関数などを含むことを意図していることが留意されるべきである。
【0024】
概念的に、プログラミングインターフェースは、図2aまたは図2bに示すように、包括的に見られ得る。図2aは、第1および第2のコードセグメントが通信するためのルート(conduit)としてのインターフェース1というインターフェースを示す。図2bは、インターフェースを、インターフェースオブジェクトI1およびI2(第1および第2のコードセグメントの一部であってもなくてもよい)を備えるものとして示し、こうしたインターフェースオブジェクトは、システムの第1および第2のコードセグメントが、媒体Mを介して通信することを可能にする。図2bを見て、インターフェースオブジェクトI1およびI2を、同一のシステムの別個のインターフェースと見なす人、オブジェクトI1およびI2と媒体Mとがインターフェースを構成すると見なす人がいるかもしれない。図2aおよび2bは、双方向の流れ、およびその流れの両端でのインターフェースを示すが、特定の実装形態は、一方向での情報の流れしかもたない(または後で説明されるように情報の流れをもたない)場合もあり、一端でのインターフェースオブジェクトしかもたない場合もある。限定ではなく例として、API(アプリケーションプログラミングインターフェース)、エントリポイント、方法、関数、サブルーチン、リモートプロシージャコール、およびCOM(コンポーネントオブジェクトモデル)インターフェースなどの用語は、プログラミングインターフェースの定義範囲に包含される。
【0025】
このようなプログラミングインターフェースの特徴は、第1のコードセグメントが、第2のコードセグメントに情報(この場合、「情報」は、広い意味で使われており、データ、コマンド、要求などを含む)を送る方法と、第2のコードセグメントが、その情報を受け取る方法と、その情報の構造、シーケンス、シンタクス、編成、スキーマ、タイミング、および内容とを含み得る。これに関して、情報が、インターフェースによって定義されたやり方で移送される限り、基礎となる移送媒体自体は、有線でも無線でも、あるいは有線および無線の組合せであっても、インターフェースの動作にとって重要でなくてよい。特定の状況では、情報は、従来の意味での一方向または両方向で渡されることができない。というのは、情報の転送は、あるコードセグメントが、第2のコードセグメントによって実施される機能に単にアクセスするときのように、別の仕組み(たとえば、コードセグメントの間の情報の流れとは別に、情報が、バッファ、ファイルなどに置かれる)を介するか、または存在しなくてもよいからである。こうした特徴のいずれかまたは全部は、所与の状況、たとえば、コードセグメントが、疎結合構成または密結合構成のシステムの一部であるかに応じて重要となる場合があり、したがって、このリストは、例示であって限定のためではないと見なされるべきである。
【0026】
このプログラミングインターフェース概念は、当業者に知られており、本発明の上記の詳細な説明から明らかである。しかし、プログラミングインターフェースを実装する他の方法もあり、明示的に除外されない限り、こうした方法も、本明細書に添付され定義される特許請求の範囲に包含されることを意図している。このような他の方法は、図2aおよび2bの単純化された概観より高度または複雑に見え得るが、それにもかかわらず、全体として同じ結果を達成する類似した機能を実施する。ここで、プログラミングインターフェースのいくつかの例示的な代替実装形態を簡潔に説明する。
【0027】
A.因数分解(FACTORING)
あるコードセグメントから別のコードセグメントへの通信は、その通信を、複数の別々の通信に分けることによって、間接的に達成されることができる。このことは、図3aおよび3bで概略的に示される。図に示すように、いくつかのインターフェースは、機能の分割可能な組の用語で説明されることができる。したがって、図2aおよび2bのインターフェース機能は、24または2×2×3×2を数学的にもたらすことができるように、同じ結果を達成するように因数分解されることができる。したがって、図3aに示されるように、インターフェース1というインターフェースによって提供される機能は、インターフェースの通信をインターフェース1A、インターフェース1B、インターフェース1Cなどの複数のインターフェースに変換するように下位分割され、同じ結果を達成することができる。図3bに示されるように、インターフェースI1によって提供される機能は、複数のインターフェースI1a、I1b、I1cなどに下位分割され、同じ結果を達成することができる。同様に、第1のコードセグメントから情報を受け取る、第2のコードセグメントのインターフェースI2は、複数のインターフェースI2a、I2b、I2cなどに因数分解されることができる。因数分解するとき、第1のコードセグメントに含まれるインターフェースの数は、第2のコードセグメントに含まれるインターフェースの数と一致しなくてもよい。図3aおよび3bのいずれの場合でも、インターフェース1およびI1というインターフェースの機能上の意図は、それぞれ図2aおよび2bの場合と同じままである。インターフェースの因数分解は、因数分解が認識困難になり得るように、結合的な、可換な、および他の数学的なプロパティの後に起こることもできる。たとえば、一部のアプリケーションにおいて動作の順序は重要でなくてよく、したがって、インターフェースによって実現される機能は、インターフェースの遂行に先立って、別のコード部分またはインターフェースによって実現されても、システムの別のコンポーネントによって実施されてもよい。さらに、プログラミング分野の当業者であれば、同じ結果を達成する異なる関数呼出しを行う様々な方法があることを理解できよう。
【0028】
B.再定義(REDEFINITION)
いくつかの場合において、プログラミングインターフェースの特定の特徴(たとえばパラメータ)を無視し、追加し、または再定義し、意図した結果を依然として達成することが可能であり得る。このことは、図4aおよび4bに示される。たとえば、図2aのインターフェース1というインターフェースが、Square(input,precision,output)の関数呼出しを含み、この呼出しは、3つのパラメータ、すなわちinput、precision、およびoutputを含み、第1のコードセグメントから第2のコードセグメントに発行されると仮定する。中央のパラメータprecisionは、図4aに示すように、所与のシナリオに関係しない場合、適切に無視されることも、(この状況において)meaninglessパラメータで置き換えられることもできよう。無関係なadditionalパラメータを追加することもできる。いずれの場合でも、第2のコードセグメントによって入力が二乗された後で出力が返される限り、二乗機能は達成されることができる。precisionは、コンピューティングシステムの何らかの下流部分または他の部分にとって有意なパラメータでもよい。ただし、precisionは、二乗計算という狭い目的にとって必要ないと認識されると、置き換えられまたは無視されることができる。たとえば、有効なprecision値を渡すのではなく、誕生日などの無意味な値が、結果に悪影響を与えることなく渡されることができよう。同様に、図4bに示すように、インターフェースI1は、インターフェースI1’で置き換えられ、インターフェースへのパラメータを無視しまたは追加するように再定義される。インターフェースI2は、同様にインターフェースI2’として再定義されることができ、不必要なパラメータまたは他の所で処理されることができるパラメータを無視するように再定義される。ここでのポイントは、いくつかの場合において、プログラミングインターフェースは、何らかの目的には必要とされないパラメータなどの特徴を含む場合があるので、こうした特徴は、無視されまたは再定義され、あるいは他の目的のために他の所で処理されることができることである。
【0029】
C.インラインコーディング(INLINE CODING)
2つの別々のコードモジュールの機能の間の「インターフェース」が形態を変えるように、そうした機能の一部または全部をマージすることも可能であり得る。たとえば、図2aおよび2bの機能は、それぞれ図5aおよび5bの機能に変換されることができる。図5aにおいて、図2aの以前の第1および第2のコードセグメントは、その両方を含むモジュールにマージされる。この場合、コードセグメントは、依然として相互に通信していてもよいが、インターフェースは、単一モジュールにより適した形態に適合されることができる。したがって、たとえば、正式な呼出しおよび戻りステートメントは不必要になり得るが、インターフェース1というインターフェースに順じた同様の処理または応答(群)は依然として有効であり得る。同様に、図5bに示してあるが、図2bのインターフェースI2の一部(または全部)は、インターフェースI1にインラインに書き込まれて、インターフェースI1”を形成することができる。図に示すように、インターフェースI2は、I2aおよびI2bに分割され、インターフェース部分I2aは、インターフェースI1とインラインにコーディングされて、インターフェースI1”を形成している。具体的な例として、図2bのインターフェースI1が、関数呼出しsquare(input,output)を実施し、この呼出しが、インターフェースI2によって受け取られ、インターフェースI2は、第2のコードセグメントによる、inputとともに渡された値の(inputを二乗するための)処理の後、二乗された結果をoutputとともに返す場合を考える。このような場合、第2のコードセグメントによって実施される(inputを二乗する)処理は、インターフェースへの呼出しなしで、第1のコードセグメントによって実施されることができる。
【0030】
D.分離(DIVORCE)
一方のコードセグメントから別のコードセグメントへの通信は、その通信を複数の別々の通信に分けることによって間接的に遂行することができる。このことは、図6aおよび6bに概略的に示される。図6aに示すように、ミドルウェアの1つまたは複数の断片(群)(元のインターフェースから全機能および/またはインターフェース機能を分離するので、分離インターフェース(群))が、第1のインターフェース、すなわちインターフェース1上での通信を変換して、異なるインターフェース、この場合インターフェース2A、インターフェース2B、およびインターフェース2Cというインターフェースに通信を準拠させるように提供される。これは、たとえば、インターフェース1のプロトコルに従ってオペレーティングシステムと通信するように設計されたアプリケーションのベースがインストールされているが、次いで、オペレーティングシステムが、異なるインターフェース、この場合インターフェース2A、インターフェース2B、およびインターフェース2Cというインターフェースを用いるように変更される場合に行われ得るであろう。重要なのは、第2のコードセグメントに使われていた元のインターフェースは、第1のコードセグメントによって使われるインターフェースとの互換性がなくなるように変更され、したがって、古いおよび新しいインターフェースを互換可能にするのに媒介が用いられる点である。同様に、図6bに示すように、DI2と共同で作用するように設計し直されているが同じ機能的結果をもたらす、インターフェースI1からの通信を受けるための分離インターフェースDI1、およびたとえばインターフェースI2aおよびI2bにインターフェース機能を送るための分離インターフェースDI2を有する、第3のコードセグメントが導入されることができる。同様に、DI1およびDI2は、図2bのインターフェースI1およびI2の機能を、新しいオペレーティングシステムに翻訳するように共同作用し、同じまたは類似した機能的結果をもたらすことができる。
【0031】
E.書換え(REWRITING)
インターフェース機能を他のもので置き換えるが全体的に同じ結果を達成するようにコードを動的に書き換える、さらに別の変形体が可能である。たとえば、(.Netフレームワーク、Java(登録商標)ランタイム環境、または他の同様のランタイムタイプの環境によって提供されるような)実行環境において、中間言語(たとえば、マイクロソフトIL、Java(登録商標)バイトコードなど)の形で示されるコードセグメントが、JIT(ジャストインタイム)コンパイラまたはインタープリタに与えられるシステムがあり得る。JITコンパイラは、第1のコードセグメントから第2のコードセグメントへの通信を動的に変換するように、すなわち、第2のコードセグメント(元のまたは異なる第2のコードセグメントのどちらか)によって要求され得る異なるインターフェースに通信を準拠させるように書かれることができる。このことは、図7aおよび7bに示される。図7aに見られ得るように、この手法は、上述された分離シナリオと似ている。これは、たとえば、インターフェース1のプロトコルに従ってオペレーティングシステムと通信するように設計されたインストール済のアプリケーションのベースが、次いで、オペレーティングシステムが、異なるインターフェースを用いるように変更される場合に行われ得るであろう。JITコンパイラは、インストールベースのアプリケーションからのオンザフライでの通信を、オペレーティングシステムの新しいインターフェースに準拠させるのに用いられることができよう。図7bに示されるように、インターフェース(群)を動的に書き換えるこの手法は、インターフェース(群)を動的に因数分解し、あるいは作り変えるのにも適用されることができる。
【0032】
代替実施形態によって、インターフェースと同じまたは類似の結果を達成する上述したシナリオは、様々な方法、すなわち直列および/または並列で、あるいは他の介在コードと組み合わされることもできることにも留意されたい。したがって、上で提示された代替実施形態は、互いに排他的でなく、図2aおよび2bに示される汎用的なシナリオと同じまたは等価なシナリオを作り出すように、混合され、調和され、組み合わされることができる。ほとんどのプログラミング構成の場合のように、本明細書では説明されないであろうが、それにもかかわらず本発明の精神および範囲によって表されるインターフェースの同じまたは類似の機能を達成する他の同様の方法があることにも留意されたい。すなわち、インターフェースの価値を決定するのは、少なくとも一部は、インターフェースによって表される機能、およびインターフェースによって可能にされる有利な結果であることに留意されたい。
【0033】
以下の説明において、特に指定のない限り、動作および1つまたは複数のコンピュータによって実施される操作の象徴的な表現を参照して本発明が説明される。そのようなものとして、このような動作および操作は、コンピュータで実行されるものと見なされる場合があり、構造化された形態でデータを表す電気信号を扱うコンピュータの処理装置による操作を含むことが理解されよう。この処理はデータを変換しまたはコンピュータのメモリシステム内の場所に保持し、メモリシステムは、当業者によく理解されたやり方でコンピュータの動作を再構成しまたは変更する。データが保持されるデータ構造は、データの形式によって定義される特定の特性を有するメモリの物理的な場所である。ただし、本発明は上記の状況で説明されているが、当業者であれば理解するように、限定を意図するものではなく、これ以降説明される様々な動作および操作はハードウェアでも実装され得る。
【0034】
ここで図8に移ると、図8は、本発明が作用する例示的な環境200を示す。アプリケーション202、204は、サーバ206に常駐している。ウィンドウマネージャ208は、ウィンドウと協働しウィンドウを編成することを可能にし、上記の操作をより容易にする、ウィンドウの移動、ウィンドウのサイズ変更、ウィンドウの破壊、タイトルバーおよび他の項目でのウィンドウの装飾などを実施する。アプリケーション202、204は、項目(たとえば、テキストドキュメント、グラフィック、アニメーションなど)がアプリケーションによってどのようにして表示されているかを示すためのビジュアルツリー210、212を作成する。ビジュアルツリーは、グラフィックスシステムによって媒体(たとえば、表示モニタ、プリンタ、面など)にレンダリングされるデータ構造を表す。ビジュアルツリーがレンダリングされると、ビジュアルツリー中のデータは、アプリケーションが使われているときにユーザがディスプレイのアプリケーション領域中で目にする「シーン」となる。アプリケーション202、204は、それぞれのビジュアルツリーに対する制御を保ち続けて、表示デバイス(たとえば、モニタ191)のアプリケーション表示領域で起こりつつあることを制御する。アプリケーション202、204は、そのビジュアルツリーの出力を、インターフェース228を介して処理中構成ループに提出する。この出力は、アプリケーションのビジュアルツリーのサブツリーを構築するのに用いられる。サブツリーは、面に構成され、この面は、デスクトップの構成のためにウィンドウマネージャ208に提出される。ウィンドウマネージャ208は次いで、ディスプレイでのアプリケーションの可視性に基づいて、何が表示され何が表示されないかを判断し、この判断に基づいて、構成ツリー214、216が作成される。構成ツリーは、ビジュアルツリーとは独立してレンダリングされる。構成ツリーは、ユーザが表示デバイス上で目にする、ビジュアルツリーからコンパイルされたすべての要素を含む。たとえば、ビジュアルツリーがドキュメント用に作成された場合、構成ツリーは、表示されているドキュメントのそうした部分となる。
【0035】
本発明は、サーバで構成ツリーを作成する必要なく、構成ツリーがリモートに作成され操作されることを可能にする。本発明は、構成ツリーをリモートに作成し操作するという観点で説明されるが、本発明は、図8のサーバ上で構成物を作成しレンダリングするのにも利用され得ることを理解されたい。ここで、図9に移ると、サーバ206上のアプリケーション202、204が、クライアントデバイス220に表示されている。1台のクライアントデバイスのみが示されているが、任意の数のクライアントデバイスが使われ得ることを理解されたい。アプリケーション202、204およびウィンドウマネージャ208は、パケットを使い、通信チャネル232を経由し、ネットワーク230を介してそれぞれの構成モジュール222〜226と通信するのに、インターフェース228を用いる。1つのアプリケーションドメインとともに使われ得る構成モジュールの数は、要望に応じた任意の数でよい。サーバ206およびクライアント220は、ネットワークまたは他のどの手段によっても接続される必要はなく、データは、サーバプラットフォームによって書き込まれクライアントプラットフォームまたはプラットフォーム群によって読み取られるどの媒体を介しても移行され得ることに留意されたい。一実施形態では、パケットは、クライアント220に構成ツリー214、216を作成するための情報を送るために、リモートデータプロトコルとともにカプセル化される。どの構成モジュール222〜226がパケットの宛先であるかを識別するための識別子が、各パケット中に置かれる。コンポーネント234は、パケットを逆多重化し、モジュール222〜226の適切な変更キュー240、242、244にパケットを送る。
【0036】
本発明のデバイス非依存プロトコルは、内容を構成するために通信チャネル232を介してサーバとインターフェースをとるためのアプリケーションおよびクライアントを提供する。内容のタイプは、リソースコマンドパケットおよびコントロールパケットを含む。リソースタイプは、ペン、ブラシ、ビットマップ、グリフ、ビデオクリップ、ジオメトリ(省略符号、矩形、ボックス、円など)、アニメーション、メモリなどを含む。構成ノードは、クライアントアプリケーションにとって使用可能な、空間的閉じ込め(containment)の基本構成単位である。クライアントは、その構成サービスにおいて構成ノードを作成する。構成ノードは、1つまたは複数のリソースを含むことができる。画面内容またはデスクトップを表す1つのルート構成ノードが常に存在する。オフスクリーン構成を表す1つまたは複数の構成ノードが存在してもよい。
【0037】
以下の説明において、デバイス非依存プロトコルは、一般的なコールシーケンスを用いて説明される。通信は非同期である。特殊な接続、再接続、および切断セマンティクスが用いられる。アプリケーション202、204、208は、クライアント220に常駐するそれぞれの構成モジュール222、224と通信する。通常、アプリケーションの存続期間に対して一度の接続が開始され維持される。というのは、接続および接続の切断はコストのかかる動作であり、クライアント上の構成モジュールへの通信は、頻繁に行われがちだからである。接続を維持するコストは、繰り返し切断し接続するコストよりも大幅に低いであろう。サーバアプリケーション202、204、208と構成モジュール222〜226の間の通信は、パケットの形態にある。
【0038】
サーバアプリケーション202、204、208は、クライアント220へ接続し、パケットの送信を開始する。パケットは、リソースパケット、コントロールパケット、およびバッチパケットでよい。リソースパケットは、リソースを作成しリソースをアップデートするのに使われる。コントロールパケットは、構成状態を制御しクライアントマシン220上にテキストグリフのビットマップキャッシュを維持するのに使われる。バッチパケットは、複数の変更を自動的に適用するのに使われる。バッチ作成コマンドが、バッチの開始を指示するためにクライアント220に送られる。構成モジュールは、バッチが「終了される」まで要求を蓄積する。バッチは、バッチクローズ/コミットパケットを送ることによって終了される。その時点で、構成サービスは、コマンドの処理を開始する。構成サービス内部の変更キューは、変更が自動的に起こるようにするために、バッチ構成体を保持する。
【0039】
ここで、図10に移ると、構成物を作成し制御するステップが示されている。サーバアプリケーション202が、こうしたステップを説明するのに用いられる。コードのどのセグメント(群)も使われ得ることを当業者は理解するであろう。構成モジュールが作成される(ステップ300)。構成モジュールは、すでに行われている接続に関する構成のレンダリングに責任がある。レンダリングターゲットリソースを作成するためのリソースコマンドを生成するレンダリングターゲットが作成され(ステップ302)、レンダリングターゲットリソースに関連づけられたレンダリングコンテキストが作成される(ステップ304)。レンダリングターゲットは、リソースをレンダリングするための宛先ターゲットである。構成ノードが作成される(ステップ306)。次いで、リソースが作成され(ステップ308)、構成物がレンダリングされる(ステップ310)。
【0040】
構成は、ターゲットに内容をレンダリングするために、シンプルリソースおよび合成リソースの組合せを使用する。シンプルリソースとは、内蔵型であり、他のどのリソースにも直接依存しない。合成リソースは、他の依存リソースを参照する。合成リソースの一例は、「レンダリングデータ」リソースである。「レンダリングデータ」リソースは、ブラシ、ペン、またはジオメトリの記述など、他のリソースを参照することができるレンダリング命令を保持したリストからなる。レンダリングデータリソースは、他のリソースの補助によって実施されるレンダリング操作をエンコードするのに用いられる。レンダリングデータリソースは、こうしたレンダリング操作を空間的に限定させる役割をもつ構成ノードに関連づけられる。
【0041】
構成物がアップデートされる必要がある場合、アップデートコマンドが送信される(ステップ312)。アップデートは、リソースの追加でもリソースのアップデートでもよい。ある特定の構成物が消去され、新しい構成物が作成される必要があり得る。たとえば、構成物がテキストドキュメントの場合、テキストドキュメントが閉じられるとその構成物が消去される。構成物が消去されることになると、消滅コマンドが構成サービスに送信される(ステップ314)。
【0042】
アニメーションは、プラットフォーム全体に広がることができる。本発明は、一実施形態では、アニメーションを評価し提示する全責任をクライアントに負わせることによって、スケーラブルアニメーションを生み出す。これは多くの場合、特にアニメーションが複雑である場合、または高速化されていない1組の操作(モザイク化(tessellation)など))が起こることをアニメーションターゲットが要求する場合において十分である。動作アニメーションなど、低コストで可視性の高い特定のユーザインターフェース効果に対して、チェーンの構成パスの間にこうした操作を起こらせることは妥当である。このような場合、アプリケーション202は、高レベルのアニメーション機能をサンプリングし、構成サービスへの要求として、リソースに関連づけられた一連のタイムスタンプ値をもたらすことになる。こうした値は、リソースがアニメーション化される期間、および間隔がアクティブ状態のままであるタイムラインの終点を表す。アプリケーション202は、リソースの値をアップデートするためのアップデートリソースパケットを送る。シーケンスは、基底の複雑さと矛盾することに留意されたい。構成モジュールは、タイムスタンプ値を構成サービスのグローバルタイムラインに正規化し、構成マネージャ(図示せず)は、レンダリングターゲットへの構成中に、アップデートブロックを適切なリソースに詰める。構成された各フレームごとに、構成モジュールは、瞬間値を導出するためにリソースの間隔を評価する。
【0043】
プログラミングインターフェースの全体構造が説明されたので、次にリソースおよび制御コマンドパケットが説明される。コントロールパケットは、構成状態を制御し、クライアント220上の構成モジュールによって使われるテキストグリフのキャッシュを維持するのに用いられる。
【0044】
コントロールパケットは、Resource_Command_Null、Resource_Command_Release、Resource_Command_Shutdown、Resource_Command_Synchronize、Resource_Command_Status、Resource_Command_Add_Glyph_Bitmaps、Resource_Command_Free_Glyph_Bitmaps、およびResource_Command_Flush_Queueである。Resource_Command_Releaseは、リソースを解放する。Resource_Command_Shutdownは、構成モジュールをシャットダウンし、構成モジュールに関連づけられたすべてのものを消去する。Resource_Command_Synchronizeコマンドは、フレッシュスタートを行うために、構成ノードに関連づけられたすべてのものを消去する。Resource_Command_Statusは、構成モジュールに状況メッセージを送る。Resource_Command_Add_Glyph_Bitmapsは、グリフのキャッシュにビットマップを追加する。Resource_Command_Free_Glyph_Bitmapsは、グリフのキャッシュからビットマップを削除する。Resource_Command_Flush_Queueは、変更キューをフラッシュする。
【0045】
クライアント220からサーバ206に通知パケットを移送し戻す通知キューが維持される。こうしたキューは、次のタイプ、すなわちNotification_Resource_Deleted、Notification_Shutdown、Notification_Synchronize、Notification_Status、およびNotification_Errorであり得る。
【0046】
リソースコマンドパケットは、リソースをレンダリングするのに用いられる。リソースとは、「異なる解像度および/または物理デバイスについて異なる具現化を要求するシーンのレンダリングに必要とされる任意のオブジェクト、構成ツリーにおいて何度も使われる任意のオブジェクト、またはアニメーションを介してなど、ユーザと関わりなく変化し得る任意のオブジェクト」と定義されることができる。リソースは、それ自体をシリアル化し、アップデートを適用し、ある特定の解像度およびデバイスに対する具現化をもたらすことができる。リソースタイプは、Null、Memory、Renderdata、Bitmap、Glyphrun、Vertices、Timeline、Doubleanimation、Coloranimation、Pointanimation、Rectanimation、Sizeanimation、Doubleanimationcollection、Coloranimationcollection、Pointanimationcollection、Rectanimationcollection、Sizeanimationcollection、Transform、Double、Color、Point、Rect、Size、Gradient、Brush、Figure、Geometry、Pen、Video、Composition_Node、Composition_Context、Image、Hwnd_Composition_Target、およびIntermediate_Composition_Targetを含む。Hwnd_Composition_Targetは、ウィンドウをレンダリングするのに用いられる。中間構成ターゲットは、オフスクリーンレンダリングのために使われ得る。
【0047】
構成モジュールに送られるリソースは概して、コールバックなしで、構成モジュールによって直接具現化可能である。直接具現化することができない場合、必要とされる具現化されたものが送られる。「テキスト」および「イメージ」のようなリソースは、具現化するのに(オーバーヘッドの処理という点で)コストがかかり、したがって、構成ツリーで使うための適切な「レンダリング準備完了」の形態に変換される。容易にレンダリングされ得る形態へのリソースの変換は、構成モジュールにおける構成に対するオーバーヘッドを節約する。リソースは、ユーザコードへのいずれかのコールバックを必要とする場合にも、適切な「レンダリング準備完了」の形態に変換される。構成モジュールによって、必要な場合には適正な解像度に効率的にモザイク化(tessellat)され得る「ジオメトリ」のような他のリソースは、構成モジュール自体によって具現化される。
【0048】
リソースは概して、描画リソース、値リソース、および構造リソースなど、いくつかのタイプに分けられる。描画リソースは、レンダリング層によって定義されるオブジェクトであり、その層によって直接消費されることができる。描画リソースの例は、RenderData、Bitmap、Image、Glyphrun、Geometry、およびBrushを含む。
【0049】
レンダリングコストが非常に低く一定である描画リソースは、構成中に、デバイスおよび解像度非依存ソースデータから直接具現化されることができる。ジオメトリは、構成モジュールの構成ループにおいて効率的に、最終的に要求される解像度にモザイク化され得るので、シンプルな描画リソースである。対照的に、合成描画リソースは、具現物を生成するために、複雑な計算、ユーザコードへのコールバック、または入出力を必要とする。一実施形態では、合成描画リソースは、構成モジュールによって具現化されない。そうではなく、適切な具現化は、構成に先立ってアプリケーション202、204および/またはサーバ206によってもたらされる。「イメージ」が、合成リソースの例である。イメージは、ディスクから読み取られ、デコードされ、適切な解像度でサンプリングされ、フィルタリングされる。
【0050】
値リソースは、別のリソースによって使われるシンプルな可変値または活動値を表す。値リソースの例は、Double、Point、Color、およびTransformである。たとえば、RenderDataリソースは、点の1つが、アニメーションまたはアプリケーションによる強制的な指示によって変化することが期待される場合、線を引くためにPointリソースを参照することができる。値リソースは、静的でも活動的でもよい。値リソースが活動的である場合、値リソースは、値が時間とともにどのように変わるかを定義するアニメーション間隔データを含む。
【0051】
構造リソースは、構成プロセスにおいて役割を担うが、直接にはレンダリングの一部ではないオブジェクトである。こうしたオブジェクトは、変更キューを介してアップデートに関与し、内部の値をアップデートするのに値リソースを使うことができるリソースとして実装される。識別されている構造リソースは、構成ノードを含む。
【0052】
概して、リソースは、使われることができるようになる前に具現化されなければならない。具現化されたものは、「所与の解像度に適し、ある特定のデバイスによって使われる準備ができているリソースの表現」と呼ばれ得る。具現化の例は、ある特定の解像度および形式変換に合わせて三角形になるようにモザイク化されたジオメトリであり、ビデオカード上の頂点バッファにすでにロードされている可能性が高い。具現化は、構成モジュールにおいてオンデマンドで作成されるか、またはサーバ206で作成され、構成モジュールに送られる。要求されるリソースの具現化が見つけられることも作成されることもできない場合、通知が、サーバ206への通知キューによってキューに入れられる。通知は、用いられる具現化のどの形式変換とも一緒に、必要とされるリソースハンドル、形式変換、およびデバイスを示す。
【0053】
パケットは、下に示すような構造をもつ。
【0054】
【表1】
【0055】
ここで、Mil_Packet_Typeは、バッチパケット、コントロールパケット、またはリソースパケットの1つである。HMIL_Resourceハンドルは、リソースに対して適切なタイプでなければならない。こうしたハンドルは、リソース、コンテキスト、または構成ノード(たとえばcompnode)に対するものでなければならない。MIL_Resource_Typeは、上に示すようなリソースのタイプ(たとえば、ビットマップ、形式変換、ジオメトリなど)である。
【0056】
パケットには、タスクを実施するよう構成サービスに命令するのに使われるコマンドが付加されている。このコマンド付加は、サードパーティベンダが、その構成サービスを動作させる独自のコードを供給することを可能にする。このような一実装形態は以下の通りである。
【0057】
【表2−1】
【0058】
【表2−2】
【0059】
【表2−3】
【0060】
【表2−4】
【0061】
【表2−5】
【0062】
【表2−6】
【0063】
【表2−7】
【0064】
【表2−8】
【0065】
【表2−9】
【0066】
【表2−10】
【0067】
ステップ300から314を実施する命令の例は以下の通りである。この例において、構成モジュールおよびレンダリングターゲットが作成される。次いで、バッチオープンコントロールパケットが送信される。構成ノード、レンダリングデータリソース、および構成コンテキストを作成するためのコマンドが送信される。構成コンテキストにおいてルートノードが設定され、構成コンテキストは、hwndターゲット上に設定される。この時点で、構成ノード、構成コンテキスト、レンダリングデータリソース、ルートノード、およびhwndターゲットが関連づけられる。次いで、リソースが作成される。リソースは、ジオメトリリソース、立体ブラシリソース、およびペンリソースである。次いで、ペンをアップデートし、ジオメトリリソースに楕円を追加し、ジオメトリを描画するためにアップデートパケットが送られる。次いで、色塗りされた矩形が描画され、レンダリングデータが構成ノード上に設定され、構成ノードがアップデートされる。構成物を消去するために、リソースを解放するためのリソース解放コマンドが送られ、構成デバイスが消滅させられる。
【0068】
【表3−1】
【0069】
【表3−2】
【0070】
【表3−3】
【0071】
【表3−4】
【0072】
【表3−5】
【0073】
上述の説明から理解され得るように、リモートデバイス上で構成物を作成し制御するための方法およびプロトコルが開示された。このプロトコルは、サーバおよび他のデバイスが、リモートデバイス上に構成物をレンダリングするために、リモートデバイスの処理能力を利用することを可能にする。こうすることは、サーバが、より多くのクライアントを扱うことを可能にする。というのは、サーバは、構成物を実際にレンダリングするのに使われる機能(たとえば、ペイント、ドロー、アニメーションなど)を処理する必要がないからである。この結果、クライアントの3Dハードウェアアクセラレーションパイプ、およびクライアントのCPUなど、クライアント側のハードウェア性能をより多く利用することができるようになる。たとえば、クライアントは、アニメーション機能を処理することができ、このことは、サーバがクライアントに、アニメーションフレームを送る代わりに、アニメーション機能を記述する情報を送ることを可能にする。
【0074】
以上、本発明の原理が適用され得る多くの可能な実施形態を検討したが、図面に関連して本明細書において説明された実施形態は、例示のみを意図しており、本発明の範囲を限定するものととられるべきではないことが理解されるべきである。たとえば、例示された実施形態の、ソフトウェアとして示した要素は、ハードウェアとして実装されることもでき、その逆も可能であり、あるいは、本発明の精神から逸脱することなく、例示された実施形態は、構成および細部において変更され得ることを当業者は理解するであろう。したがって、本明細書に記載した本発明は、このようなすべての実施形態が添付の請求項およびその均等物の範囲内であり得ることを企図している。
【図面の簡単な説明】
【0075】
【図1】本発明が帰属する例示的なコンピュータシステム全体を示すブロック図である。
【図2a】2つのコードセグメントの間のプログラミングインターフェースを示す、簡略化したブロック図である。
【図2b】2つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す、簡略化したブロック図である。
【図3a】因数分解の概念を示す、複数の別々の通信に分けられた通信を有する、2つのコードセグメントの間のプログラミングインターフェースを示す簡略化したブロック図である。
【図3b】因数分解の概念を示す、複数の別々の通信に分けられた通信を有する、2つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。
【図4a】再定義の概念を示す、特定の特徴が無視され、追加され、または再定義されている、2つのコードセグメントの間のプログラミングインターフェースを示す簡略化したブロック図である。
【図4b】再定義の概念を示す、特定の特徴が無視され、追加され、または再定義されている、2つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。
【図5a】インラインコーディングの概念を示す、2つのコードモジュールの間のインターフェースが形態を変えるようにそのコードモジュールの機能の一部をマージさせた、2つのコードセグメントの間のプログラミングインターフェースを示す簡略化したブロック図である。
【図5b】インラインコーディングの概念を示す、2つのコードモジュールの間のインターフェースが形態を変えるようにそのコードモジュールの機能の一部をマージさせた、2つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。
【図6a】分離の概念を示す、通信を複数の別々の通信に分けることによって通信が間接的に遂行される、2つのコードモジュールの間のプログラミングインターフェースを示す簡略化したブロック図である。
【図6b】分離の概念を示す、通信を複数の別々の通信に分けることによって通信が間接的に遂行される、2つのコードモジュールの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。
【図7a】書換えの概念を示す、同じ結果を達成する他のものでプログラミングインターフェースを置き換えるために動的に書き換えられたコードを示す簡略化したブロック図である。
【図7b】書換えの概念を示す、同じ結果を達成する他のものでプログラミングインターフェースを置き換えるために動的に書き換えられたコードの代替実施形態を示す簡略化したブロック図である。
【図8】本発明が作用する例示的な環境全体を示すブロック図である。
【図9】本発明が作用する例示的な代替環境全体を示すブロック図である。
【図10】本発明の教示によって構成物を作成するためのステップを示すフローチャートである。
【技術分野】
【0001】
本発明は、概して電子データ処理に関し、より詳細には、コンピュータシステムにおけるグラフィックスおよび制御情報の流れの管理に関する。
【背景技術】
【0002】
デジタル方式で作成されたマルチメディア、デジタルデバイス上で閲覧するためのデジタル形式のビデオおよびオーディオの組合せ、ならびにイメージおよびアニメーションなどのデジタル媒体は、急速に容量が増え、数も急増している。今日製造されているほぼすべての新しいパーソナルコンピュータは、何らかの形態のマルチメディアを含んでいる。カメラ、ビデオレコーダ、電話およびテレビなどのデジタル製品の売上げは、堅調に伸びている。インターネットの成長が堅調かつ急速に続いているので、マルチメディアは、インターネットの領域にもますます普及しつつある。こうしたコンピュータベースの技術における進歩の継続は、性能の向上をもたらしただけでなく、このようなコンピュータ機器ユーザの、性能への期待も高めている。コンピュータ業界は、CD ROMドライブ、通信モデムの速度向上、ならびにより高速なビデオカードおよびオーディオカードによってこうした期待に応えてきた。こうしたユーザの期待の高まりは、ハードウェアの性能だけでなく、データの処理性能にも及んでいる。
【0003】
たとえば、マルチメディアおよびオーディオ圧縮などの分野において、データは、安定した連続するストリームとして処理され得るように処理される。このデータは、TV会議、ゲーム、DVD(デジタルビデオディスク)、プロ向けのオーディオ、電話などの分野、ならびにオーディオ、ビデオ、またはオーディオおよびビデオがデジタル処理される他の分野で用いられる。
【発明の開示】
【発明が解決しようとする課題】
【0004】
データのレンダリングは、ほとんどいつでも、システム内の様々なモジュールにおける何らかの形態の処理を必要とする。たとえば、ビデオクリップは、専用のハードウェアモジュールでのデコード、別のハードウェアモジュールでのビデオフィールドのラスタ化、ソフトウェアモジュールでのオーディオのデジタルフィルタリング、別のソフトウェアモジュールによるサブタイトルの挿入、ソフトウェアモジュールによる、無音期間をスキップするためのオーディオデータの解析などを必要とするであろう。ストリーミングを働かせるために、データは、定常ストリームとして処理され、次いで、オーディオおよび/またはビデオにレンダリングされる。ただし、データが十分に速く処理されないと、データの提示が円滑にならない。
【0005】
従来のクライアント−サーバ間のレンダリングでは、データは、サーバで処理され、異なる仮想フレームに入れられてクライアントに送られ、ここでフレームがレンダリングされる。各フレームは、レンダリングされる項目に変更がない場合でも、そのフレームをレンダリングするのに必要とされる全データおよび情報を含む。たとえば、すべてのアニメーションフレームは、そのフレームが隣接フレームと同一であっても、そのフレームをレンダリングするための全部のデータおよび情報をもつ。その結果、データの伝送は、大量の利用可能帯域幅を消費する。この帯域幅消費は、サーバがサポートし得るクライアントの数を減少させる。さらに、クライアントマシン上のハードウェアは、データを処理するのに利用されることができない。たとえば、データを処理するサーバは、3Dグラフィックアクセラレータなど、クライアントハードウェアのハードウェア特徴を利用することができない。
【課題を解決するための手段】
【0006】
本発明は、リモートデバイス上で構成物を作成し制御する方法およびプロトコルを提供する。このプロトコルは、サーバおよび他のデバイスが、リモート表示デバイス上に画像コンテンツを構成するために、リモートデバイスの処理能力を利用できるようにさせる。こうすることは、サーバが、より多くのクライアントを扱うことを可能にする。というのは、サーバは、構成物を実際にレンダリングするのに使われる機能(たとえば、ペイント、ドロー、アニメーションなど)を処理する必要がないからである。この結果、クライアントの3Dハードウェアアクセラレーションパイプ、およびクライアントのCPUなど、クライアント側のハードウェア性能をより多く利用することができるようになる。たとえば、クライアントは、アニメーション機能を処理することができ、このことは、サーバがクライアントに、全アニメーション効果を含む個々の静的フレームを送る代わりに、アニメーション機能を記述する情報を送ることを可能にする。
【0007】
本プロトコルは、アプリケーションが、クライアントデバイス上に構成物を作成するために、媒体を介してコマンドを伝達することを可能にする基本的な高レベルのコマンドパケットを提供する。こうしたパケットのペイロードは、構成物を作成するための、デバイス上のコンポーネントに対する実際のコマンドを含むことができる。要求アプリケーションは、構成サービスを作成し、レンダリングターゲットおよびレンダリングコンテキストを作成し、構成ノードを作成し、構成ノード用のリソースを作成し、構成物をレンダリングするためのコマンドのパケットを送る。
【0008】
要求アプリケーションからのパケットは、リソースコマンドパケットおよびコントロールパケットである。リソースコマンドパケットは、クライアント上の該当するリソースに経路指定される。コントロールパケットは、構成状態を制御し、クライアントマシン上でテキストグリフ(text glyph)のキャッシュを維持するのに使われる。通知パケットが、要求アプリケーションに返送される。
【0009】
本発明の追加の特徴および利点が、添付の図面を参照して進められる、例示的な実施形態の以下の詳細な説明から明らかになるであろう。
【0010】
添付の特許請求の範囲は本発明の特徴を具体的に定義するが、本発明、ならびにその目的および利点は、以下の詳細な説明を添付の図面と併せ読むことによって最もよく理解されることができよう。
【発明を実施するための最良の形態】
【0011】
本発明は、サーバが、構成処理の諸態様をクライアントマシンにオフロードする機能を提供する。この結果、サーバ側のスケーラビリティが向上する。通信プロトコルの高レベルの記述性によって、即時モードモデルを用いてデータを送る場合よりも、データをレンダリングするために大幅に少ない量のデータおよび情報がクライアントに送られるようになる。
【0012】
本発明の詳細を述べる前に、本発明が実装され得る例示的なデバイス、および本発明が作用し得る環境の概略が述べられる。図面に移ると、同じ参照番号は同じ要素を指し、本発明は、適切なコンピューティング環境において実装されるものとして示される。そうすることが必要なわけではないが、パーソナルコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的なコンテキストにおいて、本発明が説明される。概して、プログラムモジュールは、特定のタスクを実施しまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、可搬型デバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ネットワークPC、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成を用いて実施され得ることを当業者は理解するであろう。本発明は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実施される分散型コンピューティング環境でも実施されることができる。分散型コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートメモリ記憶装置両方に配置されることができる。
【0013】
図1は、本発明が実施され得る、適切なコンピューティングシステム環境の例100を示す。コンピューティングシステム環境100は、適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲に対するどのような限定を示唆することも意図されない。コンピューティング環境100は、例示的な動作環境100に示されるどのコンポーネントまたはその組合せに関するどのような依存も要件も有していると解釈されるべきでない。
【0014】
本発明は、他の数多くの汎用または専用のコンピューティングシステム環境または構成と動作する。本発明とともに使用するのに適切であり得る公知のコンピューティングシステム、環境、および/または構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ型デバイス、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークPC、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれをも含む分散型コンピューティング環境などを含むが、それに限定されない。
【0015】
本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的なコンテキストにおいて説明されることができる。概して、プログラムモジュールは、特定のタスクを実施しまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実施される分散型コンピューティング環境でも実施されることができる。分散型コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよび/またはリモートコンピュータ記憶媒体に置かれることができる。
【0016】
図1を参照すると、本発明を実施する例示的なシステムは、汎用コンピューティング装置を、コンピュータ110の形態で含む。コンピュータ110のコンポーネントは、処理ユニット120と、システムメモリ130と、システムメモリなど様々なシステムコンポーネントを処理ユニット120に結合するシステムバス121とを含むことができるが、それに限定されない。システムバス121は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスなどいくつかの種類のバス構造のいずれでもよい。限定ではなく例として、このようなアーキテクチャは、ISA(業界標準アーキテクチャ)バス、MCA(マイクロチャネルアーキテクチャ)バス、EISA(拡張ISA)バス、VESA(米国ビデオ電子装置規格化協会)ローカルバス、およびメザニン(Mezzanine)バスとしても知られるPCI(周辺装置相互接続)バスを含む。
【0017】
コンピュータ110は通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ110によってアクセスされ得るとともに揮発性媒体および不揮発性媒体、着脱式媒体および固定式媒体両方を含む、利用可能などの媒体でもよい。限定ではなく例として、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するためのどの方法でも技術でも実施される揮発性媒体および不揮発性媒体、着脱式媒体および固定式媒体を含む。コンピュータ記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD−ROM、DVD(デジタル多用途ディスク)または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは、所望の情報を格納するのに使われることができるとともにコンピュータ110によってアクセスされることができる他のどの媒体も含むが、それに限定されない。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、変調データ信号、たとえば搬送波や他の移送機構として具体化し、どの情報配信媒体も含む。「変調データ信号」という用語は、信号に情報を符号化するように信号特性の1つまたは複数が設定されまたは変更された信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークや直接有線接続などの有線媒体、ならびに音響、RF、赤外線、および他の無線媒体などの無線媒体を含む。上記のどの組合せも、やはりコンピュータ可読媒体の範囲に含まれるべきである。
【0018】
システムメモリ130は、コンピュータ記憶媒体を、ROM(読出し専用メモリ)131およびRAM(ランダムアクセスメモリ)132など、揮発性および/または不揮発性メモリの形態で含む。BIOS(基本入出力システム)133は、たとえば起動中にコンピュータ110内部の要素間での情報の転送を助ける基本ルーチンを含み、通常はROM131に格納される。RAM132は一般に、処理ユニット120に対してただちにアクセス可能な、かつ/または処理ユニット120によって現在操作されているデータおよび/またはプログラムモジュールを含む。限定ではなく例として、図1では、オペレーティングシステム134、アプリケーションプログラム135、他のプログラムモジュール136、およびプログラムデータ137を示す。
【0019】
コンピュータ110は、他の着脱式/固定式、揮発性/不揮発性コンピュータ記憶媒体を含むこともできる。単なる例として、図1では、固定式不揮発性磁気媒体からの読出しまたはそこへの書込みを行うハードディスクドライブ141、着脱式な不揮発性磁気ディスク152からの読出しまたはそこへの書込みを行う磁気ディスクドライブ151、および、CD ROMや他の光学媒体など着脱式な不揮発性光ディスク156からの読出しまたはそこへの書込みを行う光ディスクドライブ155を示す。例示的な動作環境で使われることができる、他の着脱式/固定式、揮発性/不揮発性コンピュータ記憶媒体は、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体状態RAM、固体状態ROMなどを含むが、それに限定されない。ハードディスクドライブ141は通常、インターフェース140などの固定式メモリインターフェースによって、システムバス121に接続され、磁気ディスクドライブ151および光ディスクドライブ155は通常、インターフェース150などの着脱式メモリインターフェースによって、システムバス121に接続される。
【0020】
上述し、かつ図1に示されているディスクドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピュータ110のための他のデータの格納を可能にする。図1では、たとえば、ハードディスクドライブ141は、オペレーティングシステム144、アプリケーションプログラム145、他のプログラムモジュール146、およびプログラムデータ147を格納するものとして示される。こうしたコンポーネントは、オペレーティングシステム134、アプリケーションプログラム135、他のプログラムモジュール136、およびプログラムデータ137と同じでも、異なってもよいことに留意されたい。オペレーティングシステム144、アプリケーションプログラム145、他のプログラムモジュール146、およびプログラムデータ147は、少なくとも異なるものであることを示すために、本明細書では異なる番号が与えられている。ユーザは、キーボード162、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス161、マイクロホン163、およびタブレットまたは電子デジタイザ164を介して、コマンドおよび情報をコンピュータ110に入力することができる。他の入力デバイス(図示せず)は、ジョイスティック、ゲーム用パッド、衛星パラボラアンテナ、スキャナなどを含み得る。こうしたおよび他の入力デバイスはしばしば、システムバスに結合されるユーザ入力インターフェース160を介して処理ユニット120に接続されるが、パラレルポート、ゲームポート、USB(ユニバーサルシリアルバス)など、他のインターフェースおよびバス構造によって接続されることもできる。モニタ191または他の種類の表示デバイスも、ビデオインターフェース190などのインターフェースを介してシステムバス121に接続される。モニタ191は、タッチスクリーンパネルなどとも統合され得る。モニタおよび/またはタッチスクリーンパネルは、タブレットタイプのパーソナルコンピュータでのように、コンピューティング装置110が組み込まれているハウジングに物理的に結合され得ることに留意されたい。さらに、コンピューティング装置110などのコンピュータは、出力周辺インターフェース195などを介して接続されることができるスピーカ197およびプリンタ196など、他の周辺出力デバイスも含むことができる。
【0021】
コンピュータ110は、リモートコンピュータ180など、1つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク接続された環境において動作することができる。リモートコンピュータ180は、パーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピアデバイス、または他の共通ネットワークノードでよく、通常、コンピュータ110に関連して上述された要素の多くまたはすべてを含むが、図1にはメモリ記憶装置181のみが示されている。図1に示される論理接続は、LAN(ローカルエリアネットワーク)171およびWAN(ワイドエリアネットワーク)173を含むが、他のネットワークを含むこともできる。このようなネットワーク環境は、会社、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいてよく見られる。たとえば、コンピュータシステム110は、データがそこから移行されている発信マシンとなることができ、リモートコンピュータ180は、宛先マシンとなることができる。
【0022】
LANネットワーク環境において使われる場合、コンピュータ110は、ネットワークインターフェースまたはアダプタ170を介してLAN171に接続される。WANネットワーク環境において使われる場合、コンピュータ110は通常、モデム172、または、たとえばインターネットなどのWAN173を介して通信を確立する他の手段を含む。モデム172は、内部にあっても外部にあってもよく、ユーザ入力インターフェース160または他の適切な機構を介してシステムバス121に接続されることができる。ネットワーク接続された環境では、コンピュータ110に関連して図示したプログラムモジュールまたはその一部は、リモートメモリ記憶装置に格納されることができる。限定ではなく例として、図1は、リモートアプリケーションプログラム185を、メモリ装置181に常駐するものとして示す。図示したネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段も使われることができることが理解されよう。
【0023】
プログラミングインターフェース(またはより簡単には、インターフェース)は、コードの1つまたは複数のセグメント(群)が、コードの1つまたは複数の他のセグメント(群)によって提供される機能と通信しまたは機能にアクセスすることを可能にする、どの仕組み、処理、プロトコルとしても見なされ得ることに留意されたい。あるいは、プログラミングインターフェースは、他のコンポーネント(群)の、1つまたは複数の仕組み(群)、方法(群)、関数呼出し(群)、モジュール(群)などと通信結合することができる、システムのあるコンポーネントの、1つまたは複数の仕組み(群)、方法(群)、関数呼出し(群)、モジュール(群)、オブジェクト(群)などとして見なされ得る。上記の文における「コードのセグメント」という用語は、適用される専門範囲に関わらず、かつコードセグメントが個別にコンパイルされるかどうか、コードセグメントがソースコード、中間コード、またはオブジェクトコードとして提供されるのか、コードセグメントがランタイムシステムまたは処理において使用されるのか、コードセグメントが同じマシンもしくは異なるマシンに置かれるか、それとも複数のマシンに分散されるか、あるいはコードのセグメントによって表される機能が、完全にソフトウェアとして、完全にハードウェアとして、またはハードウェアおよびソフトウェアの組合せとして実装されるのかに関わらず、1つまたは複数の命令またはコードの行を含み、たとえば、コードモジュール、オブジェクト、サブルーチン、関数などを含むことを意図していることが留意されるべきである。
【0024】
概念的に、プログラミングインターフェースは、図2aまたは図2bに示すように、包括的に見られ得る。図2aは、第1および第2のコードセグメントが通信するためのルート(conduit)としてのインターフェース1というインターフェースを示す。図2bは、インターフェースを、インターフェースオブジェクトI1およびI2(第1および第2のコードセグメントの一部であってもなくてもよい)を備えるものとして示し、こうしたインターフェースオブジェクトは、システムの第1および第2のコードセグメントが、媒体Mを介して通信することを可能にする。図2bを見て、インターフェースオブジェクトI1およびI2を、同一のシステムの別個のインターフェースと見なす人、オブジェクトI1およびI2と媒体Mとがインターフェースを構成すると見なす人がいるかもしれない。図2aおよび2bは、双方向の流れ、およびその流れの両端でのインターフェースを示すが、特定の実装形態は、一方向での情報の流れしかもたない(または後で説明されるように情報の流れをもたない)場合もあり、一端でのインターフェースオブジェクトしかもたない場合もある。限定ではなく例として、API(アプリケーションプログラミングインターフェース)、エントリポイント、方法、関数、サブルーチン、リモートプロシージャコール、およびCOM(コンポーネントオブジェクトモデル)インターフェースなどの用語は、プログラミングインターフェースの定義範囲に包含される。
【0025】
このようなプログラミングインターフェースの特徴は、第1のコードセグメントが、第2のコードセグメントに情報(この場合、「情報」は、広い意味で使われており、データ、コマンド、要求などを含む)を送る方法と、第2のコードセグメントが、その情報を受け取る方法と、その情報の構造、シーケンス、シンタクス、編成、スキーマ、タイミング、および内容とを含み得る。これに関して、情報が、インターフェースによって定義されたやり方で移送される限り、基礎となる移送媒体自体は、有線でも無線でも、あるいは有線および無線の組合せであっても、インターフェースの動作にとって重要でなくてよい。特定の状況では、情報は、従来の意味での一方向または両方向で渡されることができない。というのは、情報の転送は、あるコードセグメントが、第2のコードセグメントによって実施される機能に単にアクセスするときのように、別の仕組み(たとえば、コードセグメントの間の情報の流れとは別に、情報が、バッファ、ファイルなどに置かれる)を介するか、または存在しなくてもよいからである。こうした特徴のいずれかまたは全部は、所与の状況、たとえば、コードセグメントが、疎結合構成または密結合構成のシステムの一部であるかに応じて重要となる場合があり、したがって、このリストは、例示であって限定のためではないと見なされるべきである。
【0026】
このプログラミングインターフェース概念は、当業者に知られており、本発明の上記の詳細な説明から明らかである。しかし、プログラミングインターフェースを実装する他の方法もあり、明示的に除外されない限り、こうした方法も、本明細書に添付され定義される特許請求の範囲に包含されることを意図している。このような他の方法は、図2aおよび2bの単純化された概観より高度または複雑に見え得るが、それにもかかわらず、全体として同じ結果を達成する類似した機能を実施する。ここで、プログラミングインターフェースのいくつかの例示的な代替実装形態を簡潔に説明する。
【0027】
A.因数分解(FACTORING)
あるコードセグメントから別のコードセグメントへの通信は、その通信を、複数の別々の通信に分けることによって、間接的に達成されることができる。このことは、図3aおよび3bで概略的に示される。図に示すように、いくつかのインターフェースは、機能の分割可能な組の用語で説明されることができる。したがって、図2aおよび2bのインターフェース機能は、24または2×2×3×2を数学的にもたらすことができるように、同じ結果を達成するように因数分解されることができる。したがって、図3aに示されるように、インターフェース1というインターフェースによって提供される機能は、インターフェースの通信をインターフェース1A、インターフェース1B、インターフェース1Cなどの複数のインターフェースに変換するように下位分割され、同じ結果を達成することができる。図3bに示されるように、インターフェースI1によって提供される機能は、複数のインターフェースI1a、I1b、I1cなどに下位分割され、同じ結果を達成することができる。同様に、第1のコードセグメントから情報を受け取る、第2のコードセグメントのインターフェースI2は、複数のインターフェースI2a、I2b、I2cなどに因数分解されることができる。因数分解するとき、第1のコードセグメントに含まれるインターフェースの数は、第2のコードセグメントに含まれるインターフェースの数と一致しなくてもよい。図3aおよび3bのいずれの場合でも、インターフェース1およびI1というインターフェースの機能上の意図は、それぞれ図2aおよび2bの場合と同じままである。インターフェースの因数分解は、因数分解が認識困難になり得るように、結合的な、可換な、および他の数学的なプロパティの後に起こることもできる。たとえば、一部のアプリケーションにおいて動作の順序は重要でなくてよく、したがって、インターフェースによって実現される機能は、インターフェースの遂行に先立って、別のコード部分またはインターフェースによって実現されても、システムの別のコンポーネントによって実施されてもよい。さらに、プログラミング分野の当業者であれば、同じ結果を達成する異なる関数呼出しを行う様々な方法があることを理解できよう。
【0028】
B.再定義(REDEFINITION)
いくつかの場合において、プログラミングインターフェースの特定の特徴(たとえばパラメータ)を無視し、追加し、または再定義し、意図した結果を依然として達成することが可能であり得る。このことは、図4aおよび4bに示される。たとえば、図2aのインターフェース1というインターフェースが、Square(input,precision,output)の関数呼出しを含み、この呼出しは、3つのパラメータ、すなわちinput、precision、およびoutputを含み、第1のコードセグメントから第2のコードセグメントに発行されると仮定する。中央のパラメータprecisionは、図4aに示すように、所与のシナリオに関係しない場合、適切に無視されることも、(この状況において)meaninglessパラメータで置き換えられることもできよう。無関係なadditionalパラメータを追加することもできる。いずれの場合でも、第2のコードセグメントによって入力が二乗された後で出力が返される限り、二乗機能は達成されることができる。precisionは、コンピューティングシステムの何らかの下流部分または他の部分にとって有意なパラメータでもよい。ただし、precisionは、二乗計算という狭い目的にとって必要ないと認識されると、置き換えられまたは無視されることができる。たとえば、有効なprecision値を渡すのではなく、誕生日などの無意味な値が、結果に悪影響を与えることなく渡されることができよう。同様に、図4bに示すように、インターフェースI1は、インターフェースI1’で置き換えられ、インターフェースへのパラメータを無視しまたは追加するように再定義される。インターフェースI2は、同様にインターフェースI2’として再定義されることができ、不必要なパラメータまたは他の所で処理されることができるパラメータを無視するように再定義される。ここでのポイントは、いくつかの場合において、プログラミングインターフェースは、何らかの目的には必要とされないパラメータなどの特徴を含む場合があるので、こうした特徴は、無視されまたは再定義され、あるいは他の目的のために他の所で処理されることができることである。
【0029】
C.インラインコーディング(INLINE CODING)
2つの別々のコードモジュールの機能の間の「インターフェース」が形態を変えるように、そうした機能の一部または全部をマージすることも可能であり得る。たとえば、図2aおよび2bの機能は、それぞれ図5aおよび5bの機能に変換されることができる。図5aにおいて、図2aの以前の第1および第2のコードセグメントは、その両方を含むモジュールにマージされる。この場合、コードセグメントは、依然として相互に通信していてもよいが、インターフェースは、単一モジュールにより適した形態に適合されることができる。したがって、たとえば、正式な呼出しおよび戻りステートメントは不必要になり得るが、インターフェース1というインターフェースに順じた同様の処理または応答(群)は依然として有効であり得る。同様に、図5bに示してあるが、図2bのインターフェースI2の一部(または全部)は、インターフェースI1にインラインに書き込まれて、インターフェースI1”を形成することができる。図に示すように、インターフェースI2は、I2aおよびI2bに分割され、インターフェース部分I2aは、インターフェースI1とインラインにコーディングされて、インターフェースI1”を形成している。具体的な例として、図2bのインターフェースI1が、関数呼出しsquare(input,output)を実施し、この呼出しが、インターフェースI2によって受け取られ、インターフェースI2は、第2のコードセグメントによる、inputとともに渡された値の(inputを二乗するための)処理の後、二乗された結果をoutputとともに返す場合を考える。このような場合、第2のコードセグメントによって実施される(inputを二乗する)処理は、インターフェースへの呼出しなしで、第1のコードセグメントによって実施されることができる。
【0030】
D.分離(DIVORCE)
一方のコードセグメントから別のコードセグメントへの通信は、その通信を複数の別々の通信に分けることによって間接的に遂行することができる。このことは、図6aおよび6bに概略的に示される。図6aに示すように、ミドルウェアの1つまたは複数の断片(群)(元のインターフェースから全機能および/またはインターフェース機能を分離するので、分離インターフェース(群))が、第1のインターフェース、すなわちインターフェース1上での通信を変換して、異なるインターフェース、この場合インターフェース2A、インターフェース2B、およびインターフェース2Cというインターフェースに通信を準拠させるように提供される。これは、たとえば、インターフェース1のプロトコルに従ってオペレーティングシステムと通信するように設計されたアプリケーションのベースがインストールされているが、次いで、オペレーティングシステムが、異なるインターフェース、この場合インターフェース2A、インターフェース2B、およびインターフェース2Cというインターフェースを用いるように変更される場合に行われ得るであろう。重要なのは、第2のコードセグメントに使われていた元のインターフェースは、第1のコードセグメントによって使われるインターフェースとの互換性がなくなるように変更され、したがって、古いおよび新しいインターフェースを互換可能にするのに媒介が用いられる点である。同様に、図6bに示すように、DI2と共同で作用するように設計し直されているが同じ機能的結果をもたらす、インターフェースI1からの通信を受けるための分離インターフェースDI1、およびたとえばインターフェースI2aおよびI2bにインターフェース機能を送るための分離インターフェースDI2を有する、第3のコードセグメントが導入されることができる。同様に、DI1およびDI2は、図2bのインターフェースI1およびI2の機能を、新しいオペレーティングシステムに翻訳するように共同作用し、同じまたは類似した機能的結果をもたらすことができる。
【0031】
E.書換え(REWRITING)
インターフェース機能を他のもので置き換えるが全体的に同じ結果を達成するようにコードを動的に書き換える、さらに別の変形体が可能である。たとえば、(.Netフレームワーク、Java(登録商標)ランタイム環境、または他の同様のランタイムタイプの環境によって提供されるような)実行環境において、中間言語(たとえば、マイクロソフトIL、Java(登録商標)バイトコードなど)の形で示されるコードセグメントが、JIT(ジャストインタイム)コンパイラまたはインタープリタに与えられるシステムがあり得る。JITコンパイラは、第1のコードセグメントから第2のコードセグメントへの通信を動的に変換するように、すなわち、第2のコードセグメント(元のまたは異なる第2のコードセグメントのどちらか)によって要求され得る異なるインターフェースに通信を準拠させるように書かれることができる。このことは、図7aおよび7bに示される。図7aに見られ得るように、この手法は、上述された分離シナリオと似ている。これは、たとえば、インターフェース1のプロトコルに従ってオペレーティングシステムと通信するように設計されたインストール済のアプリケーションのベースが、次いで、オペレーティングシステムが、異なるインターフェースを用いるように変更される場合に行われ得るであろう。JITコンパイラは、インストールベースのアプリケーションからのオンザフライでの通信を、オペレーティングシステムの新しいインターフェースに準拠させるのに用いられることができよう。図7bに示されるように、インターフェース(群)を動的に書き換えるこの手法は、インターフェース(群)を動的に因数分解し、あるいは作り変えるのにも適用されることができる。
【0032】
代替実施形態によって、インターフェースと同じまたは類似の結果を達成する上述したシナリオは、様々な方法、すなわち直列および/または並列で、あるいは他の介在コードと組み合わされることもできることにも留意されたい。したがって、上で提示された代替実施形態は、互いに排他的でなく、図2aおよび2bに示される汎用的なシナリオと同じまたは等価なシナリオを作り出すように、混合され、調和され、組み合わされることができる。ほとんどのプログラミング構成の場合のように、本明細書では説明されないであろうが、それにもかかわらず本発明の精神および範囲によって表されるインターフェースの同じまたは類似の機能を達成する他の同様の方法があることにも留意されたい。すなわち、インターフェースの価値を決定するのは、少なくとも一部は、インターフェースによって表される機能、およびインターフェースによって可能にされる有利な結果であることに留意されたい。
【0033】
以下の説明において、特に指定のない限り、動作および1つまたは複数のコンピュータによって実施される操作の象徴的な表現を参照して本発明が説明される。そのようなものとして、このような動作および操作は、コンピュータで実行されるものと見なされる場合があり、構造化された形態でデータを表す電気信号を扱うコンピュータの処理装置による操作を含むことが理解されよう。この処理はデータを変換しまたはコンピュータのメモリシステム内の場所に保持し、メモリシステムは、当業者によく理解されたやり方でコンピュータの動作を再構成しまたは変更する。データが保持されるデータ構造は、データの形式によって定義される特定の特性を有するメモリの物理的な場所である。ただし、本発明は上記の状況で説明されているが、当業者であれば理解するように、限定を意図するものではなく、これ以降説明される様々な動作および操作はハードウェアでも実装され得る。
【0034】
ここで図8に移ると、図8は、本発明が作用する例示的な環境200を示す。アプリケーション202、204は、サーバ206に常駐している。ウィンドウマネージャ208は、ウィンドウと協働しウィンドウを編成することを可能にし、上記の操作をより容易にする、ウィンドウの移動、ウィンドウのサイズ変更、ウィンドウの破壊、タイトルバーおよび他の項目でのウィンドウの装飾などを実施する。アプリケーション202、204は、項目(たとえば、テキストドキュメント、グラフィック、アニメーションなど)がアプリケーションによってどのようにして表示されているかを示すためのビジュアルツリー210、212を作成する。ビジュアルツリーは、グラフィックスシステムによって媒体(たとえば、表示モニタ、プリンタ、面など)にレンダリングされるデータ構造を表す。ビジュアルツリーがレンダリングされると、ビジュアルツリー中のデータは、アプリケーションが使われているときにユーザがディスプレイのアプリケーション領域中で目にする「シーン」となる。アプリケーション202、204は、それぞれのビジュアルツリーに対する制御を保ち続けて、表示デバイス(たとえば、モニタ191)のアプリケーション表示領域で起こりつつあることを制御する。アプリケーション202、204は、そのビジュアルツリーの出力を、インターフェース228を介して処理中構成ループに提出する。この出力は、アプリケーションのビジュアルツリーのサブツリーを構築するのに用いられる。サブツリーは、面に構成され、この面は、デスクトップの構成のためにウィンドウマネージャ208に提出される。ウィンドウマネージャ208は次いで、ディスプレイでのアプリケーションの可視性に基づいて、何が表示され何が表示されないかを判断し、この判断に基づいて、構成ツリー214、216が作成される。構成ツリーは、ビジュアルツリーとは独立してレンダリングされる。構成ツリーは、ユーザが表示デバイス上で目にする、ビジュアルツリーからコンパイルされたすべての要素を含む。たとえば、ビジュアルツリーがドキュメント用に作成された場合、構成ツリーは、表示されているドキュメントのそうした部分となる。
【0035】
本発明は、サーバで構成ツリーを作成する必要なく、構成ツリーがリモートに作成され操作されることを可能にする。本発明は、構成ツリーをリモートに作成し操作するという観点で説明されるが、本発明は、図8のサーバ上で構成物を作成しレンダリングするのにも利用され得ることを理解されたい。ここで、図9に移ると、サーバ206上のアプリケーション202、204が、クライアントデバイス220に表示されている。1台のクライアントデバイスのみが示されているが、任意の数のクライアントデバイスが使われ得ることを理解されたい。アプリケーション202、204およびウィンドウマネージャ208は、パケットを使い、通信チャネル232を経由し、ネットワーク230を介してそれぞれの構成モジュール222〜226と通信するのに、インターフェース228を用いる。1つのアプリケーションドメインとともに使われ得る構成モジュールの数は、要望に応じた任意の数でよい。サーバ206およびクライアント220は、ネットワークまたは他のどの手段によっても接続される必要はなく、データは、サーバプラットフォームによって書き込まれクライアントプラットフォームまたはプラットフォーム群によって読み取られるどの媒体を介しても移行され得ることに留意されたい。一実施形態では、パケットは、クライアント220に構成ツリー214、216を作成するための情報を送るために、リモートデータプロトコルとともにカプセル化される。どの構成モジュール222〜226がパケットの宛先であるかを識別するための識別子が、各パケット中に置かれる。コンポーネント234は、パケットを逆多重化し、モジュール222〜226の適切な変更キュー240、242、244にパケットを送る。
【0036】
本発明のデバイス非依存プロトコルは、内容を構成するために通信チャネル232を介してサーバとインターフェースをとるためのアプリケーションおよびクライアントを提供する。内容のタイプは、リソースコマンドパケットおよびコントロールパケットを含む。リソースタイプは、ペン、ブラシ、ビットマップ、グリフ、ビデオクリップ、ジオメトリ(省略符号、矩形、ボックス、円など)、アニメーション、メモリなどを含む。構成ノードは、クライアントアプリケーションにとって使用可能な、空間的閉じ込め(containment)の基本構成単位である。クライアントは、その構成サービスにおいて構成ノードを作成する。構成ノードは、1つまたは複数のリソースを含むことができる。画面内容またはデスクトップを表す1つのルート構成ノードが常に存在する。オフスクリーン構成を表す1つまたは複数の構成ノードが存在してもよい。
【0037】
以下の説明において、デバイス非依存プロトコルは、一般的なコールシーケンスを用いて説明される。通信は非同期である。特殊な接続、再接続、および切断セマンティクスが用いられる。アプリケーション202、204、208は、クライアント220に常駐するそれぞれの構成モジュール222、224と通信する。通常、アプリケーションの存続期間に対して一度の接続が開始され維持される。というのは、接続および接続の切断はコストのかかる動作であり、クライアント上の構成モジュールへの通信は、頻繁に行われがちだからである。接続を維持するコストは、繰り返し切断し接続するコストよりも大幅に低いであろう。サーバアプリケーション202、204、208と構成モジュール222〜226の間の通信は、パケットの形態にある。
【0038】
サーバアプリケーション202、204、208は、クライアント220へ接続し、パケットの送信を開始する。パケットは、リソースパケット、コントロールパケット、およびバッチパケットでよい。リソースパケットは、リソースを作成しリソースをアップデートするのに使われる。コントロールパケットは、構成状態を制御しクライアントマシン220上にテキストグリフのビットマップキャッシュを維持するのに使われる。バッチパケットは、複数の変更を自動的に適用するのに使われる。バッチ作成コマンドが、バッチの開始を指示するためにクライアント220に送られる。構成モジュールは、バッチが「終了される」まで要求を蓄積する。バッチは、バッチクローズ/コミットパケットを送ることによって終了される。その時点で、構成サービスは、コマンドの処理を開始する。構成サービス内部の変更キューは、変更が自動的に起こるようにするために、バッチ構成体を保持する。
【0039】
ここで、図10に移ると、構成物を作成し制御するステップが示されている。サーバアプリケーション202が、こうしたステップを説明するのに用いられる。コードのどのセグメント(群)も使われ得ることを当業者は理解するであろう。構成モジュールが作成される(ステップ300)。構成モジュールは、すでに行われている接続に関する構成のレンダリングに責任がある。レンダリングターゲットリソースを作成するためのリソースコマンドを生成するレンダリングターゲットが作成され(ステップ302)、レンダリングターゲットリソースに関連づけられたレンダリングコンテキストが作成される(ステップ304)。レンダリングターゲットは、リソースをレンダリングするための宛先ターゲットである。構成ノードが作成される(ステップ306)。次いで、リソースが作成され(ステップ308)、構成物がレンダリングされる(ステップ310)。
【0040】
構成は、ターゲットに内容をレンダリングするために、シンプルリソースおよび合成リソースの組合せを使用する。シンプルリソースとは、内蔵型であり、他のどのリソースにも直接依存しない。合成リソースは、他の依存リソースを参照する。合成リソースの一例は、「レンダリングデータ」リソースである。「レンダリングデータ」リソースは、ブラシ、ペン、またはジオメトリの記述など、他のリソースを参照することができるレンダリング命令を保持したリストからなる。レンダリングデータリソースは、他のリソースの補助によって実施されるレンダリング操作をエンコードするのに用いられる。レンダリングデータリソースは、こうしたレンダリング操作を空間的に限定させる役割をもつ構成ノードに関連づけられる。
【0041】
構成物がアップデートされる必要がある場合、アップデートコマンドが送信される(ステップ312)。アップデートは、リソースの追加でもリソースのアップデートでもよい。ある特定の構成物が消去され、新しい構成物が作成される必要があり得る。たとえば、構成物がテキストドキュメントの場合、テキストドキュメントが閉じられるとその構成物が消去される。構成物が消去されることになると、消滅コマンドが構成サービスに送信される(ステップ314)。
【0042】
アニメーションは、プラットフォーム全体に広がることができる。本発明は、一実施形態では、アニメーションを評価し提示する全責任をクライアントに負わせることによって、スケーラブルアニメーションを生み出す。これは多くの場合、特にアニメーションが複雑である場合、または高速化されていない1組の操作(モザイク化(tessellation)など))が起こることをアニメーションターゲットが要求する場合において十分である。動作アニメーションなど、低コストで可視性の高い特定のユーザインターフェース効果に対して、チェーンの構成パスの間にこうした操作を起こらせることは妥当である。このような場合、アプリケーション202は、高レベルのアニメーション機能をサンプリングし、構成サービスへの要求として、リソースに関連づけられた一連のタイムスタンプ値をもたらすことになる。こうした値は、リソースがアニメーション化される期間、および間隔がアクティブ状態のままであるタイムラインの終点を表す。アプリケーション202は、リソースの値をアップデートするためのアップデートリソースパケットを送る。シーケンスは、基底の複雑さと矛盾することに留意されたい。構成モジュールは、タイムスタンプ値を構成サービスのグローバルタイムラインに正規化し、構成マネージャ(図示せず)は、レンダリングターゲットへの構成中に、アップデートブロックを適切なリソースに詰める。構成された各フレームごとに、構成モジュールは、瞬間値を導出するためにリソースの間隔を評価する。
【0043】
プログラミングインターフェースの全体構造が説明されたので、次にリソースおよび制御コマンドパケットが説明される。コントロールパケットは、構成状態を制御し、クライアント220上の構成モジュールによって使われるテキストグリフのキャッシュを維持するのに用いられる。
【0044】
コントロールパケットは、Resource_Command_Null、Resource_Command_Release、Resource_Command_Shutdown、Resource_Command_Synchronize、Resource_Command_Status、Resource_Command_Add_Glyph_Bitmaps、Resource_Command_Free_Glyph_Bitmaps、およびResource_Command_Flush_Queueである。Resource_Command_Releaseは、リソースを解放する。Resource_Command_Shutdownは、構成モジュールをシャットダウンし、構成モジュールに関連づけられたすべてのものを消去する。Resource_Command_Synchronizeコマンドは、フレッシュスタートを行うために、構成ノードに関連づけられたすべてのものを消去する。Resource_Command_Statusは、構成モジュールに状況メッセージを送る。Resource_Command_Add_Glyph_Bitmapsは、グリフのキャッシュにビットマップを追加する。Resource_Command_Free_Glyph_Bitmapsは、グリフのキャッシュからビットマップを削除する。Resource_Command_Flush_Queueは、変更キューをフラッシュする。
【0045】
クライアント220からサーバ206に通知パケットを移送し戻す通知キューが維持される。こうしたキューは、次のタイプ、すなわちNotification_Resource_Deleted、Notification_Shutdown、Notification_Synchronize、Notification_Status、およびNotification_Errorであり得る。
【0046】
リソースコマンドパケットは、リソースをレンダリングするのに用いられる。リソースとは、「異なる解像度および/または物理デバイスについて異なる具現化を要求するシーンのレンダリングに必要とされる任意のオブジェクト、構成ツリーにおいて何度も使われる任意のオブジェクト、またはアニメーションを介してなど、ユーザと関わりなく変化し得る任意のオブジェクト」と定義されることができる。リソースは、それ自体をシリアル化し、アップデートを適用し、ある特定の解像度およびデバイスに対する具現化をもたらすことができる。リソースタイプは、Null、Memory、Renderdata、Bitmap、Glyphrun、Vertices、Timeline、Doubleanimation、Coloranimation、Pointanimation、Rectanimation、Sizeanimation、Doubleanimationcollection、Coloranimationcollection、Pointanimationcollection、Rectanimationcollection、Sizeanimationcollection、Transform、Double、Color、Point、Rect、Size、Gradient、Brush、Figure、Geometry、Pen、Video、Composition_Node、Composition_Context、Image、Hwnd_Composition_Target、およびIntermediate_Composition_Targetを含む。Hwnd_Composition_Targetは、ウィンドウをレンダリングするのに用いられる。中間構成ターゲットは、オフスクリーンレンダリングのために使われ得る。
【0047】
構成モジュールに送られるリソースは概して、コールバックなしで、構成モジュールによって直接具現化可能である。直接具現化することができない場合、必要とされる具現化されたものが送られる。「テキスト」および「イメージ」のようなリソースは、具現化するのに(オーバーヘッドの処理という点で)コストがかかり、したがって、構成ツリーで使うための適切な「レンダリング準備完了」の形態に変換される。容易にレンダリングされ得る形態へのリソースの変換は、構成モジュールにおける構成に対するオーバーヘッドを節約する。リソースは、ユーザコードへのいずれかのコールバックを必要とする場合にも、適切な「レンダリング準備完了」の形態に変換される。構成モジュールによって、必要な場合には適正な解像度に効率的にモザイク化(tessellat)され得る「ジオメトリ」のような他のリソースは、構成モジュール自体によって具現化される。
【0048】
リソースは概して、描画リソース、値リソース、および構造リソースなど、いくつかのタイプに分けられる。描画リソースは、レンダリング層によって定義されるオブジェクトであり、その層によって直接消費されることができる。描画リソースの例は、RenderData、Bitmap、Image、Glyphrun、Geometry、およびBrushを含む。
【0049】
レンダリングコストが非常に低く一定である描画リソースは、構成中に、デバイスおよび解像度非依存ソースデータから直接具現化されることができる。ジオメトリは、構成モジュールの構成ループにおいて効率的に、最終的に要求される解像度にモザイク化され得るので、シンプルな描画リソースである。対照的に、合成描画リソースは、具現物を生成するために、複雑な計算、ユーザコードへのコールバック、または入出力を必要とする。一実施形態では、合成描画リソースは、構成モジュールによって具現化されない。そうではなく、適切な具現化は、構成に先立ってアプリケーション202、204および/またはサーバ206によってもたらされる。「イメージ」が、合成リソースの例である。イメージは、ディスクから読み取られ、デコードされ、適切な解像度でサンプリングされ、フィルタリングされる。
【0050】
値リソースは、別のリソースによって使われるシンプルな可変値または活動値を表す。値リソースの例は、Double、Point、Color、およびTransformである。たとえば、RenderDataリソースは、点の1つが、アニメーションまたはアプリケーションによる強制的な指示によって変化することが期待される場合、線を引くためにPointリソースを参照することができる。値リソースは、静的でも活動的でもよい。値リソースが活動的である場合、値リソースは、値が時間とともにどのように変わるかを定義するアニメーション間隔データを含む。
【0051】
構造リソースは、構成プロセスにおいて役割を担うが、直接にはレンダリングの一部ではないオブジェクトである。こうしたオブジェクトは、変更キューを介してアップデートに関与し、内部の値をアップデートするのに値リソースを使うことができるリソースとして実装される。識別されている構造リソースは、構成ノードを含む。
【0052】
概して、リソースは、使われることができるようになる前に具現化されなければならない。具現化されたものは、「所与の解像度に適し、ある特定のデバイスによって使われる準備ができているリソースの表現」と呼ばれ得る。具現化の例は、ある特定の解像度および形式変換に合わせて三角形になるようにモザイク化されたジオメトリであり、ビデオカード上の頂点バッファにすでにロードされている可能性が高い。具現化は、構成モジュールにおいてオンデマンドで作成されるか、またはサーバ206で作成され、構成モジュールに送られる。要求されるリソースの具現化が見つけられることも作成されることもできない場合、通知が、サーバ206への通知キューによってキューに入れられる。通知は、用いられる具現化のどの形式変換とも一緒に、必要とされるリソースハンドル、形式変換、およびデバイスを示す。
【0053】
パケットは、下に示すような構造をもつ。
【0054】
【表1】
【0055】
ここで、Mil_Packet_Typeは、バッチパケット、コントロールパケット、またはリソースパケットの1つである。HMIL_Resourceハンドルは、リソースに対して適切なタイプでなければならない。こうしたハンドルは、リソース、コンテキスト、または構成ノード(たとえばcompnode)に対するものでなければならない。MIL_Resource_Typeは、上に示すようなリソースのタイプ(たとえば、ビットマップ、形式変換、ジオメトリなど)である。
【0056】
パケットには、タスクを実施するよう構成サービスに命令するのに使われるコマンドが付加されている。このコマンド付加は、サードパーティベンダが、その構成サービスを動作させる独自のコードを供給することを可能にする。このような一実装形態は以下の通りである。
【0057】
【表2−1】
【0058】
【表2−2】
【0059】
【表2−3】
【0060】
【表2−4】
【0061】
【表2−5】
【0062】
【表2−6】
【0063】
【表2−7】
【0064】
【表2−8】
【0065】
【表2−9】
【0066】
【表2−10】
【0067】
ステップ300から314を実施する命令の例は以下の通りである。この例において、構成モジュールおよびレンダリングターゲットが作成される。次いで、バッチオープンコントロールパケットが送信される。構成ノード、レンダリングデータリソース、および構成コンテキストを作成するためのコマンドが送信される。構成コンテキストにおいてルートノードが設定され、構成コンテキストは、hwndターゲット上に設定される。この時点で、構成ノード、構成コンテキスト、レンダリングデータリソース、ルートノード、およびhwndターゲットが関連づけられる。次いで、リソースが作成される。リソースは、ジオメトリリソース、立体ブラシリソース、およびペンリソースである。次いで、ペンをアップデートし、ジオメトリリソースに楕円を追加し、ジオメトリを描画するためにアップデートパケットが送られる。次いで、色塗りされた矩形が描画され、レンダリングデータが構成ノード上に設定され、構成ノードがアップデートされる。構成物を消去するために、リソースを解放するためのリソース解放コマンドが送られ、構成デバイスが消滅させられる。
【0068】
【表3−1】
【0069】
【表3−2】
【0070】
【表3−3】
【0071】
【表3−4】
【0072】
【表3−5】
【0073】
上述の説明から理解され得るように、リモートデバイス上で構成物を作成し制御するための方法およびプロトコルが開示された。このプロトコルは、サーバおよび他のデバイスが、リモートデバイス上に構成物をレンダリングするために、リモートデバイスの処理能力を利用することを可能にする。こうすることは、サーバが、より多くのクライアントを扱うことを可能にする。というのは、サーバは、構成物を実際にレンダリングするのに使われる機能(たとえば、ペイント、ドロー、アニメーションなど)を処理する必要がないからである。この結果、クライアントの3Dハードウェアアクセラレーションパイプ、およびクライアントのCPUなど、クライアント側のハードウェア性能をより多く利用することができるようになる。たとえば、クライアントは、アニメーション機能を処理することができ、このことは、サーバがクライアントに、アニメーションフレームを送る代わりに、アニメーション機能を記述する情報を送ることを可能にする。
【0074】
以上、本発明の原理が適用され得る多くの可能な実施形態を検討したが、図面に関連して本明細書において説明された実施形態は、例示のみを意図しており、本発明の範囲を限定するものととられるべきではないことが理解されるべきである。たとえば、例示された実施形態の、ソフトウェアとして示した要素は、ハードウェアとして実装されることもでき、その逆も可能であり、あるいは、本発明の精神から逸脱することなく、例示された実施形態は、構成および細部において変更され得ることを当業者は理解するであろう。したがって、本明細書に記載した本発明は、このようなすべての実施形態が添付の請求項およびその均等物の範囲内であり得ることを企図している。
【図面の簡単な説明】
【0075】
【図1】本発明が帰属する例示的なコンピュータシステム全体を示すブロック図である。
【図2a】2つのコードセグメントの間のプログラミングインターフェースを示す、簡略化したブロック図である。
【図2b】2つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す、簡略化したブロック図である。
【図3a】因数分解の概念を示す、複数の別々の通信に分けられた通信を有する、2つのコードセグメントの間のプログラミングインターフェースを示す簡略化したブロック図である。
【図3b】因数分解の概念を示す、複数の別々の通信に分けられた通信を有する、2つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。
【図4a】再定義の概念を示す、特定の特徴が無視され、追加され、または再定義されている、2つのコードセグメントの間のプログラミングインターフェースを示す簡略化したブロック図である。
【図4b】再定義の概念を示す、特定の特徴が無視され、追加され、または再定義されている、2つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。
【図5a】インラインコーディングの概念を示す、2つのコードモジュールの間のインターフェースが形態を変えるようにそのコードモジュールの機能の一部をマージさせた、2つのコードセグメントの間のプログラミングインターフェースを示す簡略化したブロック図である。
【図5b】インラインコーディングの概念を示す、2つのコードモジュールの間のインターフェースが形態を変えるようにそのコードモジュールの機能の一部をマージさせた、2つのコードセグメントの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。
【図6a】分離の概念を示す、通信を複数の別々の通信に分けることによって通信が間接的に遂行される、2つのコードモジュールの間のプログラミングインターフェースを示す簡略化したブロック図である。
【図6b】分離の概念を示す、通信を複数の別々の通信に分けることによって通信が間接的に遂行される、2つのコードモジュールの間のプログラミングインターフェースの代替実施形態を示す簡略化したブロック図である。
【図7a】書換えの概念を示す、同じ結果を達成する他のものでプログラミングインターフェースを置き換えるために動的に書き換えられたコードを示す簡略化したブロック図である。
【図7b】書換えの概念を示す、同じ結果を達成する他のものでプログラミングインターフェースを置き換えるために動的に書き換えられたコードの代替実施形態を示す簡略化したブロック図である。
【図8】本発明が作用する例示的な環境全体を示すブロック図である。
【図9】本発明が作用する例示的な代替環境全体を示すブロック図である。
【図10】本発明の教示によって構成物を作成するためのステップを示すフローチャートである。
【特許請求の範囲】
【請求項1】
デバイス上に構成物をレンダリングするための方法であって、
構成物を作成する構成ノード作成パケットを送信するステップと、
前記構成物をレンダリングするリソースを作成するための少なくとも1つのリソース作成パケットを送信するステップと、
前記構成物を作成するための少なくとも1つのレンダリングアップデートパケットを送信するステップとを含むことを特徴とする方法。
【請求項2】
レンダリングデータリソースを作成するためのレンダリングデータリソース作成パケットを送信するステップをさらに含むことを特徴とする請求項1に記載の方法。
【請求項3】
バッチプロセスをオープンするためのバッチオープンパケットを送信するステップをさらに含むことを特徴とする請求項1に記載の方法。
【請求項4】
複数のリソース作成パケットを送信するステップと、
少なくとも1つのリソースアップデートパケットを送信するステップと、
バッチクローズ/コミットパケットを送信するステップとをさらに含むことを特徴とする請求項3に記載の方法。
【請求項5】
リソースを解放するための解放コマンドを送信するステップをさらに含むことを特徴とする請求項1に記載の方法。
【請求項6】
パケットタイプを有する第1のフィールドと、
前記パケットタイプと合致するハンドルを有する第2のフィールドと、
前記パケットタイプと合致するリソースタイプおよびコマンドタイプの一方を有する第3のフィールドと、
コマンドを有する第4のフィールドとを備えることを特徴とするデータ構造。
【請求項7】
前記パケットタイプは、コントロールパケットおよびリソースコマンドパケットの一方であることを特徴とする請求項6に記載のデータ構造。
【請求項8】
前記コントロールパケットおよび前記リソースコマンドパケットの前記一方は、前記コントロールパケット、前記リソースコマンドパケット、およびバッチパケットの1つを含むことを特徴とする請求項7に記載のデータ構造。
【請求項9】
前記ハンドルは、リソースハンドル、コンテキストハンドル、およびcompnodeハンドルの1つを含むことを特徴とする請求項6に記載のデータ構造。
【請求項10】
リソースタイプおよびコマンドタイプの前記一方は、リソースタイプを含み、前記リソースタイプは、メモリ、ビットマップ、形式変換、ジオメトリ、およびペンの1つを含むことを特徴とする請求項6に記載のデータ構造。
【請求項11】
前記リソースタイプは、アニメーションタイプをさらに含むことを特徴とする請求項10に記載のデータ構造。
【請求項12】
前記アニメーションタイプは、doubleanimation、coloranimation、pointanimation、rectanimation、およびsizeanimationの1つを含むことを特徴とする請求項11に記載のデータ構造。
【請求項13】
前記リソースタイプは、構成ノード、および構成コンテキストの一方を含むことを特徴とする請求項6に記載のデータ構造。
【請求項14】
前記コントロールタイプは、リソースを解放するためのリソース解放タイプ、デバイスをシャットダウンするためのシャットダウンタイプ、および前記デバイス上のすべてのものを消去するための同期タイプの1つを含むことを特徴とする請求項6に記載のデータ構造。
【請求項15】
前記コントロールタイプは、グリフのキャッシュにビットマップを追加するためのグリフビットマップ追加タイプ、前記グリフキャッシュからビットマップを削除するためのグリフビットマップフリータイプ、および変更キューをフラッシュするためのキューフラッシュタイプの1つを含むことを特徴とする請求項6に記載のデータ構造。
【請求項16】
デバイス上に構成物をレンダリングするための方法であって、
構成ノード作成パケットの受取りに応答して構成ノードを作成するステップと、
少なくとも1つのリソース作成パケットの受取りに応答して前記構成物をレンダリングする少なくとも1つのリソースを作成するステップと、
少なくとも1つのレンダリングアップデートパケットに応答して前記構成物を作成するステップとを含むことを特徴とする方法。
【請求項17】
レンダリングデータリソース作成パケットの受取りに応答してレンダリングデータリソースを作成するステップをさらに含むことを特徴とする請求項16に記載の方法。
【請求項18】
バッチオープンパケットの受取りに応答してバッチプロセスをオープンするステップをさらに含むことを特徴とする請求項16に記載の方法。
【請求項19】
バッチクローズ/コミットパケットの受取りに応答して少なくとも1つのリソース作成パケットおよび少なくとも1つのリソースアップデートパケットの一方を処理するステップをさらに含むことを特徴とする請求項18に記載の方法。
【請求項20】
解放コマンドの受取りに応答してリソースを解放するステップをさらに含むことを特徴とする請求項16に記載の方法。
【請求項21】
コマンドパケットの受取りに応答して通知を送信するステップをさらに含むことを特徴とする請求項16に記載の方法。
【請求項1】
デバイス上に構成物をレンダリングするための方法であって、
構成物を作成する構成ノード作成パケットを送信するステップと、
前記構成物をレンダリングするリソースを作成するための少なくとも1つのリソース作成パケットを送信するステップと、
前記構成物を作成するための少なくとも1つのレンダリングアップデートパケットを送信するステップとを含むことを特徴とする方法。
【請求項2】
レンダリングデータリソースを作成するためのレンダリングデータリソース作成パケットを送信するステップをさらに含むことを特徴とする請求項1に記載の方法。
【請求項3】
バッチプロセスをオープンするためのバッチオープンパケットを送信するステップをさらに含むことを特徴とする請求項1に記載の方法。
【請求項4】
複数のリソース作成パケットを送信するステップと、
少なくとも1つのリソースアップデートパケットを送信するステップと、
バッチクローズ/コミットパケットを送信するステップとをさらに含むことを特徴とする請求項3に記載の方法。
【請求項5】
リソースを解放するための解放コマンドを送信するステップをさらに含むことを特徴とする請求項1に記載の方法。
【請求項6】
パケットタイプを有する第1のフィールドと、
前記パケットタイプと合致するハンドルを有する第2のフィールドと、
前記パケットタイプと合致するリソースタイプおよびコマンドタイプの一方を有する第3のフィールドと、
コマンドを有する第4のフィールドとを備えることを特徴とするデータ構造。
【請求項7】
前記パケットタイプは、コントロールパケットおよびリソースコマンドパケットの一方であることを特徴とする請求項6に記載のデータ構造。
【請求項8】
前記コントロールパケットおよび前記リソースコマンドパケットの前記一方は、前記コントロールパケット、前記リソースコマンドパケット、およびバッチパケットの1つを含むことを特徴とする請求項7に記載のデータ構造。
【請求項9】
前記ハンドルは、リソースハンドル、コンテキストハンドル、およびcompnodeハンドルの1つを含むことを特徴とする請求項6に記載のデータ構造。
【請求項10】
リソースタイプおよびコマンドタイプの前記一方は、リソースタイプを含み、前記リソースタイプは、メモリ、ビットマップ、形式変換、ジオメトリ、およびペンの1つを含むことを特徴とする請求項6に記載のデータ構造。
【請求項11】
前記リソースタイプは、アニメーションタイプをさらに含むことを特徴とする請求項10に記載のデータ構造。
【請求項12】
前記アニメーションタイプは、doubleanimation、coloranimation、pointanimation、rectanimation、およびsizeanimationの1つを含むことを特徴とする請求項11に記載のデータ構造。
【請求項13】
前記リソースタイプは、構成ノード、および構成コンテキストの一方を含むことを特徴とする請求項6に記載のデータ構造。
【請求項14】
前記コントロールタイプは、リソースを解放するためのリソース解放タイプ、デバイスをシャットダウンするためのシャットダウンタイプ、および前記デバイス上のすべてのものを消去するための同期タイプの1つを含むことを特徴とする請求項6に記載のデータ構造。
【請求項15】
前記コントロールタイプは、グリフのキャッシュにビットマップを追加するためのグリフビットマップ追加タイプ、前記グリフキャッシュからビットマップを削除するためのグリフビットマップフリータイプ、および変更キューをフラッシュするためのキューフラッシュタイプの1つを含むことを特徴とする請求項6に記載のデータ構造。
【請求項16】
デバイス上に構成物をレンダリングするための方法であって、
構成ノード作成パケットの受取りに応答して構成ノードを作成するステップと、
少なくとも1つのリソース作成パケットの受取りに応答して前記構成物をレンダリングする少なくとも1つのリソースを作成するステップと、
少なくとも1つのレンダリングアップデートパケットに応答して前記構成物を作成するステップとを含むことを特徴とする方法。
【請求項17】
レンダリングデータリソース作成パケットの受取りに応答してレンダリングデータリソースを作成するステップをさらに含むことを特徴とする請求項16に記載の方法。
【請求項18】
バッチオープンパケットの受取りに応答してバッチプロセスをオープンするステップをさらに含むことを特徴とする請求項16に記載の方法。
【請求項19】
バッチクローズ/コミットパケットの受取りに応答して少なくとも1つのリソース作成パケットおよび少なくとも1つのリソースアップデートパケットの一方を処理するステップをさらに含むことを特徴とする請求項18に記載の方法。
【請求項20】
解放コマンドの受取りに応答してリソースを解放するステップをさらに含むことを特徴とする請求項16に記載の方法。
【請求項21】
コマンドパケットの受取りに応答して通知を送信するステップをさらに含むことを特徴とする請求項16に記載の方法。
【図1】
【図2a】
【図2b】
【図3a】
【図3b】
【図4a】
【図4b】
【図5a】
【図5b】
【図6a】
【図6b】
【図7a】
【図7b】
【図8】
【図9】
【図10】
【図2a】
【図2b】
【図3a】
【図3b】
【図4a】
【図4b】
【図5a】
【図5b】
【図6a】
【図6b】
【図7a】
【図7b】
【図8】
【図9】
【図10】
【公表番号】特表2007−519074(P2007−519074A)
【公表日】平成19年7月12日(2007.7.12)
【国際特許分類】
【出願番号】特願2006−536571(P2006−536571)
【出願日】平成16年7月26日(2004.7.26)
【国際出願番号】PCT/US2004/024012
【国際公開番号】WO2005/046102
【国際公開日】平成17年5月19日(2005.5.19)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
【公表日】平成19年7月12日(2007.7.12)
【国際特許分類】
【出願日】平成16年7月26日(2004.7.26)
【国際出願番号】PCT/US2004/024012
【国際公開番号】WO2005/046102
【国際公開日】平成17年5月19日(2005.5.19)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
[ Back to top ]