(57)【要約】【課題】ホストデバイスと描画装置の間の、描画装置のユーザーインターフェイスをコントロールするための通信の例示的な方法を提供すること。【解決手段】この方法は、メッセージを生成すること、メッセージをバッファ内でデータのブロブとしてエンコードすること、および、データのブロブを描画装置に通信することを含む。様々な他の例示的な方法、デバイス、システムなどもまた開示される。【選択図】図４
2006313536.tif 000002
【特許請求の範囲】
【請求項１】
データは、グラフィカルユーザーインターフェイスの１つ以上のコンポーネントを実行するようにレンダラに命令する、メッセージのバッチを含む、データのブロブを備えたことを特徴とするデータ構造を格納するコンピュータ読み取り可能な媒体。
【請求項２】
ネットワークバッファをさらに備えたことを特徴とする請求項１に記載のコンピュータ読み取り可能な媒体。
【請求項３】
前記メッセージのバッチを含む前記メッセージの少なくともいくつかは、前記レンダラを実行するリモートデバイスと通信するホストコンピュータ上で実行するアプリケーションから発信されることを特徴とする請求項１に記載のコンピュータ読み取り可能な媒体。
【請求項４】
ホストデバイスと描画装置との間で、前記描画装置のユーザーインターフェイスを制御する通信の方法であって、
メッセージを生成するステップと、
前記メッセージをバッファ内でデータのブロブとしてエンコードするステップと、
前記データのブロブを前記描画装置に通信するステップと
を備えたことを特徴とする方法。
【請求項５】
前記生成するステップは、遠隔操作から前記描画装置へ発行された１つ以上のコマンドを受信するステップと、
前記１つ以上のコマンドに応答して、前記ホストデバイス上で実行するアプリケーションによって前記メッセージを生成するステップと
をさらに備えたことを特徴とする請求項４に記載の方法。
【請求項６】
前記アプリケーションは、前記ホストデバイス上で実行するユーザーインターフェイスフレームワークによって、前記メッセージを生成し、前記メッセージを前記バッファ内でエンコードすることを特徴とする請求項５に記載の方法。
【請求項７】
前記ホストデバイスと前記描画装置との間の通信は非同期的に行なわれることを特徴とする請求項４に記載の方法。
【請求項８】
通信は、グラフィックスおよびアニメーションを描画するグラフィックスモデルを含む通信プロトコルに従って、行なわれることを特徴とする請求項４に記載の方法。
【請求項９】
前記描画装置は、イメージのフレームをフレームレートで表示し、前記描画装置は、前記フレームレートでのフレームの表示を中断させることなく、前記データのブロブに従って描画することを特徴とする請求項４に記載の方法。
【請求項１０】
前記バッファは、ネットワークバッファを含むことを特徴とする請求項４に記載の方法。
【請求項１１】
データを前記描画装置から前記ホストデバイスへ通信するステップをさらに備えたことを特徴とする請求項４に記載の方法。
【請求項１２】
前記メッセージに関連しない、状況に応じて１つ以上の後続のメッセージに関連する、追加の情報を前記バッファ内でエンコードするステップをさらに備えたことを特徴とする請求項４に記載の方法。
【請求項１３】
前記通信するステップの後、追加のメッセージを生成するステップと、
前記追加のメッセージを前記バッファ内でデータのブロブとしてエンコードするステップと、
前記描画装置から送信された、前記ホストデバイスによるメッセージの受信に先立って、前記データのブロブを前記描画装置に通信するステップと
をさらに備えたことを特徴とする請求項４に記載の方法。
【請求項１４】
前記通信は通信プロトコルに従って発生し、前記通信プロトコルは、前記プロトコル内のルートオブジェクトとしてのブローカオブジェクト、論理計算サイトを表すコンテキストオブジェクト、実行時におけるレンダポートからのコールバックのレンダポートコールバックオブジェクト、バルクデータ転送の状況についてレポートするデータバッファコールバックオブジェクト、および、リモートノード上のバルクデータを表すデータバッファオブジェクトからなるグループから選択された、少なくとも１つのメンバを含むことを特徴とする請求項４に記載の方法。
【請求項１５】
前記メッセージの最後のメッセージは、メッセージを前記ホストデバイスに送信するように前記描画装置に命令するコールを含むことを特徴とする請求項４に記載の方法。
【請求項１６】
前記メッセージは、１つ以上のグラフィックスまたはアニメーションコマンドを含むことを特徴とする請求項４に記載の方法。
【請求項１７】
前記メッセージは、グラフィックスまたはアニメーションのソフトウェアインターフェイスに関連付けられた１つ以上のコマンドを含むことを特徴とする請求項４に記載の方法。
【請求項１８】
前記１つ以上のメッセージは、ドローコマンドのパケットを保持するためのレンダビルダオブジェクト、プレゼンテーションコンテナを表すウィンドウオブジェクト、離散座標空間を表すビジュアルオブジェクト、前記描画装置の状況についてレポートするデバイスコールバックオブジェクト、描画技術ドライバを表すレンダリングデバイスオブジェクト、イメージビットの論理コンテナを表すサーフェスオブジェクト、イメージビットの物理コンテナを表すサーフェスプールオブジェクト、コンテナスコープ内のカラースペースの修正のグラディエントオブジェクト、アニメーションコントロールに役立つアニメーションマネージャオブジェクト、アニメーションについてレポートするアニメーションコールバックオブジェクト、および論理アニメーションシーケンスを記述するアニメーションオブジェクトからなるグループから選択された、少なくとも１つのメンバによることを特徴とする請求項４に記載の方法。
【請求項１９】
前記バッファは複数であることを特徴とする請求項４に記載の方法。
【請求項２０】
ホストデバイス上で方法を実行するためのコンピュータ実行可能命令を有するコンピュータ読み取り可能な媒体であって、前記方法は、
メッセージを生成するステップと、
前記メッセージをバッファ内でデータのブロブとしてエンコードするステップと、
前記データのブロブを描画装置に通信するステップと
を備えることを特徴とするコンピュータ読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、グラフィカルユーザーインターフェイスに命令するための１つ以上のメッセージの通信に関する。
【背景技術】
【０００２】
ユーザーインターフェイスシステムによって、ローカルプログラムコードを介し、高い双方向性を実現する場合、典型的には、遠隔描画装置（remote rendering device）への表示（projection）が問題となる、すなわち、そのネットワーク帯域幅により高い双方向性を提供することができなくなることが多い。描画装置または「レンダラ」を使用する際、多数のシステムでは、双方向性または品質が低下するだけである。別のシステムでは、描画装置上で実行するための支援プログラムの一部を表示するものがある。さらに他のシステムでは、ユーザーインターフェイスのための明確なホスト／表示器機モデルを採用することから、開発者が互いに通信する２つのソフトウェア全体を設計しなければならないものがある。最後に、いくつかの手法においては、このような状況で高品質な表示を行なうために、描画装置のハードウェアおよび接続をより高い性能にするしかない。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
これらのシステムには著しい問題がある。品質の低下により、エンドユーザーの使用感が悪化する。支援プログラムの一部を表示することにより、プログラミングおよび対話モデルが複雑になる。表示器機／ホストコンピューティングにより、各アプリケーション開発者は、考えられる各描画装置のための開発が必要となり、それにより、実現可能な範囲が制限され、または多数の解決策を用意するためコストを非常に増大することとなる。描画装置のハードウェアおよび接続をより高い性能にするためにも、非常に高いコストがかかる。
【課題を解決するための手段】
【０００４】
本発明は、例えば表示器機およびホストランタイムコンポーネント、通信プロトコル設計、およびプログラミングモデルの適切な選択によって、これらおよび他の問題に対処する構成を示す。
【０００５】
ホストデバイスと描画装置との間の、描画装置のユーザーインターフェイスを制御するための通信の例示的な方法は、メッセージを生成するステップ、メッセージをバッファ内でデータのブロブとしてエンコードするステップ、およびデータのブロブを描画装置に通信するステップを備える。様々な他の例示的な方法、デバイス、システムなども開示する。
【発明を実施するための最良の形態】
【０００６】
以下の図面を参照して、限定的および網羅的ではない実施例を説明するが、図面において、特別の定めのない限り、全体として同様の参照番号は、同様部分を指すものとする。
【０００７】
以下の説明では、様々な例示的な方法、デバイス、システムなどを提示する。
【０００８】
図１は、開発者環境１１０、サーバ１２０、およびクライアント環境１３０を備える例示的なシステム１００を示す図である。言うまでもなく、多数のこのようなクライアント環境は、サーバ１２０と通信することができる。ワークステーション１１２、１１２’によって表されるような、開発者環境１１０内の開発者は、サーバ１２０により配布または使用されるアプリケーションを開発する。サーバ１２０は、クライアント環境１３０内のホスト１３２がこのようなアプリケーションをダウンロードすること、このようなアプリケーションと協調することなどを可能にする。
【０００９】
クライアント環境１３０内のホスト１３２は、１つ以上の描画装置１３４、１３６を管理する。本明細書で説明するように、様々な例示的な方法、デバイス、システムなどにより、ホストと通信する描画装置上でのユーザーインターフェイスの効率的な実行が可能になる。このようなユーザーインターフェイスは、ホストのネイティブアプリケーションによって、または、非ネイティブアプリケーションによって動作させることができる。このような非ネイティブアプリケーションは、一定の範囲でリモートサーバによって制御することができる。ホストと、１つ以上の描画装置１３４、１３６との間の通信は、単一方向、双方向または多方向であってもよい。本明細書で説明する特定の実施例は、単一方向および双方向のものであるが、複数のホストが存在する多方向の方法で実施することもできる。場合によっては、描画装置と描画装置との通信が発生することがある。
【００１０】
例示的なクライアント環境１３０において、描画装置１３４は、情報家電、セキュリティシステム、環境システムなどのための携帯端末またはコントローラなど、より小型の描画装置を示す。描画装置１３６は、ＴＶ、プロジェクタ、モニタなど、より大型の描画装置を示し、このデバイスを使用して、ＴＶ番組、映画、ニュース放送、スポーツなどを視聴することができる。他の例示的な描画装置は、電子額縁（picture frame devices）、セットトップボックス、携帯電話、ゲームボックスなどとすることができる。描画装置は一般に、パーソナルコンピュータの代用としての機能をすることは意図されていないが、本明細書で提示される様々な例示的な方法、プロトコルなどが、ホストおよびパーソナルコンピュータの間の通信のために実施される。このような実施例では、ホストはパーソナルコンピュータであっても他のコンピュータであってもよい。
【００１１】
描画装置は、通常のパーソナルコンピュータを越えるメモリまたは記憶容量を有することがあるが、その処理リソースは通常、特別な目的のためのタスク向けに使用される。例えば、セットトップボックスは、ＨＤＴＶのフレームをキャプチャするためのＲＡＭを有することがあるが、ノーカットの映画を記録するための高容量ハードディスクは、大部分のパーソナルコンピュータ上で実行するビジネスアプリケーションを実行する能力を制限されている。このようなビジネスアプリケーションを実行するためのセットトップボックスを構築することにより、コストは増大するようになり、専用のオーディオビジュアルタスクのプログラミングを複雑にする可能性がある。
【００１２】
すでに述べたように、描画装置には、あらゆる種類の形状およびサイズがあり、多数の異なる種類のタスクを実行するための様々な機能がある。製造業者にホストのジョブを支援するリソースを増強するように要求するのは、特に増分コストが重要な要素になる可能性のある国内市場においては非現実的である。その代わりに、このような環境で（例えば、国内であろうと海外であろうと）描画装置上のユーザーインターフェイスの提供（presentation）またはそれとの対話が必要な場合、ホストデバイスは一般に負担の大部分を負うことができなければならない。
【００１３】
描画装置１３６を参照すると、この装置は、約１０フィート（３０４．８ｃｍ）の距離を置いてうまく機能するユーザーインターフェイスを表し、遠隔操作を介して制御することができる。通常の遠隔操作は、従来のキーボードおよびマウスより小型であり、より使いやすいが、一般に、ユーザー入力はより制限される（例えば、キーまたはボタンがより少ない）。より大きい視聴距離はより快適なエクスペリエンスを提供するが、明確さ、首尾一貫性、および可読性を確保するために、ビジュアル設計機能が必要になる可能性がある。加えて、ユーザーは、ユーザーインターフェイスが従来のＴＶまたはＨＤＴＶのものと等しい表示品質を有することを期待することができ、従来のＴＶまたはＨＤＴＶにおいて、フレームは、スムーズに、すなわち、連続的なフレームによりユーザーまたは視聴者に割り込みなしで正常に見えるような特定のフレームレートで表示される。
【００１４】
ユーザーはまた、デバイス１３６のような描画装置に、動的なアニメーション視聴できることを期待することができる。ユーザーはまた、入力が容易になり、ユーザーの視聴がより容易になり、より簡潔になることを期待することができる。ユーザーはまた、アプリケーションが、キーボードまたはマウスによって制御される場合よりも便利で、学習しやすく、使用しやすくなることを期待することができる。
【００１５】
本明細書で説明する様々な例示的な方法、デバイス、システムなどは、非同期通信によっており、これによって、例えば、描画装置による割り込み、異常、フレームの欠落、フレームの遅延などの危険性を低減することができる。以下でより詳細に説明するように、例示的な非同期通信プロトコルはネットワーク時間を低減し、同期通信プロトコルと比較すると、よりよいユーザー視聴環境を提供することができる。典型的な同期通信プロトコルを図２を参照して説明し、その後、図３の典型的な非同期通信プロトコル、および様々な例示的な非同期通信プロトコル（例えば、図４）を説明する。
【００１６】
図２は、ホストと描画装置との間の通信のための、典型的な同期通信プロトコルのタイムライン２００を示す。描画装置からホストへの通信も発生する場合は、タイムライン２００は双方向通信を示す。一般に、ホストは、描画装置の「レンダラ」のためのメッセージを発行する「フレームワーク」による場合がある。フレームワークは通常、アプリケーションと、通信インターフェイスに関連付けられた通信レイヤとの間の中間物の機能を果たす。フレームワークは、ユーザーインターフェイスタスク専用とすることができ、または他の機能を提供することもできる。レンダラは通常、命令を（例えば、ユーザーインターフェイスフレームワークから）受信することができ、ハードウェアに、ユーザーインターフェイス、ユーザーインターフェイスコンポーネントなど（例えば、グラフィックス、アニメーションなど）を表示させるように命令することができるソフトウェアである。従来のレンダラは通常、１つ以上の規格をサポートし、これらの規格は、それに限定されないが、ＤｉｒｅｃｔＸグラフィクス（例えば、ＤｉｒｅｃｔＤｒａｗ、Ｄｉｒｅｃｔ３Ｄ）、ＯｐｅｎＧＬグラフィックス（例えば、Ｏｐｅｎ  Ｇｒａｐｈｉｃｓ  Ｌｉｂｒａｒｙ）、または、ＧＤＩグラフィックス（例えば、グラフィカルデバイスインターフェイス）などである。
【００１７】
図２のタイムライン２００を参照すると、タイムライン２００は、いつ様々なイベントがホスト側および描画装置側で発生するか、どこでホストおよび描画装置がネットワーク、無線リンク、ケーブルなどを介して通信するかを示す。
【００１８】
これらのイベントは、描画装置によるユーザーインターフェイスの表示のための描画タスクに対応する。ホストで生成されるタスクには、（１）レンダビルダ（ＲＢ）を作成すること、（２）塗りつぶす（solid fill）こと、（３）円を描くこと、（４）ビジュアルコンテンツを設定すること、および（５）レンダビルダ（ＲＢ）を破棄することが含まれる。
【００１９】
レンダビルダ作成タスク（１）および破棄タスク（５）は、基本的に１つ以上の描画（drawing）または関連メッセージ（例えば、タスク（２）〜（４））のための開始点および終了点としてそれぞれ機能し、同期通信プロトコルタイムライン２００では、これらのメッセージは、ホストから描画装置への一連の通信において通信される。
【００２０】
描画装置は、タスク（１）〜（５）のための命令またはメタデータを受信し、ネットワークを介して受信すると、これらの命令を（例えば、レンダラを使用して）処理する。命令またはメタデータ（本明細書の全体に渡って、「または」は一般に「および／または」を意味する）を送信するホストの間に遅延が存在し、その遅延は、Δｔｉ  ＮｅｔｗｏｒｋＨＲによって表される。ホストΔｔｉ  Ｈｏｓｔは遅延を有し、描画装置は遅延Δｔｉ  ＲＤを有する。さらに、描画装置が情報をホストに送信する場合、別の遅延Δｔｉ  ＮｅｔｗｏｒｋＲＨが発生する。したがって、図２の実施例では、各タスクは４つの関連付けられた遅延、すなわちΔｔｉ  ＮｅｔｗｏｒｋＨＲ、Δｔｉ  ＮｅｔｗｏｒｋＲＨ、Δｔｉ  Ｈｏｓｔ、およびΔｔｉ  ＲＤを有する。
【００２１】
ホストリソースを増大または最適化して、Δｔｉ  Ｈｏｓｔを縮小することができ、ネットワークトラフィックを低減または最適化して、Δｔｉ  ＮｅｔｗｏｒｋＨＲおよびΔｔｉ  ＮｅｔｗｏｒｋＲＨを縮小することができるが、本明細書で説明するように、描画装置の性能は、ユーザーインターフェイスのパフォーマンスを改善する解決策の一部とはならない。したがって、Δｔｉ  ＲＤは、描画装置に依存したり制限するものと考えられる。
【００２２】
また、タイムライン２００を参照すると、描画装置は、「ビジュアルコンテンツを設定する」タスクの受信、および、描画装置によるそのタスクの処理の後、実際に円を表示することができる。表示の時点で、７つのネットワーク遅延、４つのホスト遅延、および４つの描画装置の遅延が発生している。さらに、ネットワークトラフィックが大きいか、または他のホストタスクが多数である場合、遅延が追加される可能性がある。したがって、ホストと描画装置との間のネットワーク通信の数を減らすことが必要となる。
【００２３】
図３は、図２で提示したものと同じタスクに関する典型的な非同期通信プロトコルのタイムライン３００を示す。しかし、タイムライン３００はまた、描画装置によって表示されたフレーム（例えば、フレームｎ、フレームｎ＋１およびフレームｎ＋２）をも示す。これらのフレームは描画装置によって実行されるべき追加のタスクを表すが、ホストにより通信されたタスクの実行のために割り込まれ、移され、または表示されない可能性がある。前述のように、このようなコンフリクトはユーザーの体感を損なう可能性がある。
【００２４】
レンダビルダ作成タスク（１）および破棄タスク（５）は基本的には、１つ以上の描画（drawing）または関連メッセージ（例えば、タスク（２）〜（４））のための開始点および終了点としてそれぞれ機能し、非同期通信プロトコルのタイムライン３００では、これらのメッセージは、ホストから描画装置への一連の通信において通信される。
【００２５】
タイムライン３００によって表された非同期通信プロトコルは、タイムライン２００によって表された同期プロトコルよりも少数の、描画装置からホストへの通信を使用する。具体的には、この数は、描画装置が１つの通信のみをホストに送信するため大幅に減少し、この通信は、ホストにより要求されたすべてのタスクの実行の後に行なわれる。しかし、ホストはなお５つの別々の通信を描画装置へ送信する。したがって、同期通信プロトコルのタイムライン２００では１０であることに比較して、通信の総数は６となる。
【００２６】
典型的な同期通信プロトコルおよび典型的な非同期通信プロトコルを説明した後、図のように、双方向に通信が可能なタイムライン４００に示した例示的な非同期通信プロトコルを考察されたい。他の実施例では、単一方向または多方向通信は、必要に応じて、例示的な通信プロトコルを使用して行なわれる場合がある。図４の実施例では、例示的な非同期通信プロトコルは、ホストから描画装置への１つの通信、および任意とすることができる描画装置からホストへの１つの通信だけが必要である。したがって、レンダビルダ作成タスク（１）および破棄タスク（５）は基本的には、１つ以上の描画（drawing）または関連メッセージ（例えば、タスク（２）〜（４））を、それらの間に保持するメッセージとして機能する。タイムライン２００およびタイムライン３００のプロトコルとは対照的に、作成タスク（１）および破棄タスク（５）は、非同期通信プロトコルのタイムライン４００では、ホストから描画装置への単一の通信において、タスク（２）〜（４）と共に通信される。言うまでもなく、他の構成も可能である。
【００２７】
本明細書で説明するように、例示的な非同期通信プロトコルシステムでは、比較的「多数」のまたは「豊富」なメッセージ（例えば、複数のメッセージ）を「大容量データを含む」方法で送信することが可能となる。例示的な非同期通信プロトコルは、すべてのまたはいくらかの同期呼び出しを許可せず、したがって多数の（すなわち、大容量データのワイヤトランザクションにおいて多数の通信を搬送する）バッチメッセージを介してレイテンシコストを償却する場合もある。したがって、例示的な通信モデルを、実質的に１００％非同期にすることができる。
【００２８】
図４の実施例では、前述の同期および非同期の実施例におけるような、別々の、異なる個々の遅延ではなく、遅延ΔｔＢａｔｃｈ  Ｈｏｓｔを有するバッチを準備することによって、ホストから描画装置への通信の数が減らされる。さらに、描画装置は、通信されたバッチ命令またはメタデータを、遅延ΔｔＢａｔｃｈ  ＲＤを有するバッチとして処理することができる。一般に、バッチ処理は、ホストによるものであろうと、描画装置によるものであろうと、タスクのシリアル通信によって直列的に遅延および管理されるタスクの直列の処理よりも効率的である。
【００２９】
タイムライン４００の実施例では、ホストは５つのタスクを実質的に割り込みのない方法で処理し、その結果、個々の各タスクの処理後に描画装置との通信が行なわれる５つのタスクの直列処理と比較すると、かなりの時間節約となる。図のように、ホストはｔ０からｔｆまでの期間を必要とし、この期間は通常、図３のタイムライン３００に示すような個々のタスク処理時間の合計より少ない。
【００３０】
タイムライン４００の実施例では、ホストは５つのタスクをネットワークバッファ内でエンコードすることができる。情報のバッチをネットワークバッファまたは通信バッファ内でエンコードするプロセスは通常、一連の個々のタスクをネットワークバッファまたは通信バッファ内でエンコードするために必要とされた時間の合計よりも少ない時間で行なわれ、効率的である。したがって、時間の短縮はホスト側で、例示的な非同期通信プロトコルにより管理される。
【００３１】
例示的な非同期通信プロトコルは、通信の数、および描画装置によって必要とされた処理時間の量を低減するので、タスクのバッチによって、映像が割り込まれたり、またはその他の点で損なわれるようになる可能性はより少ない。全体的に見れば、これにより、描画装置がユーザーによりよい視聴環境を提供することが可能となる。
【００３２】
グラフィカルユーザーインターフェイスはしばしば、多数の小部分から構築される。メッセージ指向モデルでは、各メッセージをある部分のある面への最新情報にすることができる。単一の論理的変更では、１つまたは複数のアプリケーションはいくつかの変更をユーザーインターフェイスの様々な部分に、好ましくは一度に（例えば、アニメーションシーケンスにおいて実質的に瞬時に、など）行うことを必要とする場合がある。これらの変更が個々に実行されない場合、ユーザーは部分的状態を見ることがあるが、これは意図しないものである。例えば、図３のタイムライン３００および図４のタイムライン４００を考察されたい。図３のタイムライン３００では、メッセージは複数のフレームに渡って到着する。ユーザーの視聴体感に関して、例えば、レンダラ側で原始性を保証する、別の技術または方法が使用されない限り、介在するフレームは事実上、ユーザーインターフェイス上で、部分的に更新された状態を提示するようになるが、これは、視覚的に望ましくない場合がある。このような有害な動作を回避するために、図３のタイムライン３００および関連付けられたプロトコルでは、レンダラ側の原始性の管理を実行することができ、この管理を実行すると、それ自体で複雑となって、および（例えば、描画装置にとっての）コストが増大するようになる。対照的に、図４の例示的なタイムライン４００および関連付けられた例示的なプロトコルは、様々な例示的な方法と共に、負担をホスト側に課すことができ、これにより、より軽量の描画装置の使用も可能になる。
【００３３】
例示的な方法は、メッセージ（例えば、コマンドまたはタスク）を１つ以上のアトミックユニットに構成することができる。各ユニットは、１つのメッセージであってもメッセージのバッチであってもよい。このような例示的な方法は、原始性のために用いることができる。例えば、描画コマンドの特定のセットは、描画装置上で実行されるとき、あるユーザー体感を提供することができ、アトミックユニットに構成またはグループ化されない場合、ユーザー体感の品質を低下させる危険性が存在する場合がある。したがって、例示的な方法はメッセージを、ユーザーにとっての望ましい結果に基づいて、論理的にグループ化することができる。さらに、このような例示的な方法により、他の情報、またはビデオなどの媒体の表示が可能となるが、この場合、フレームレートまたはフレーム毎の完全性は、最良のユーザー体感を提供するために維持されるべきである。
【００３４】
例示的な方法により、グラフィックスまたはアニメーションのためのメッセージ（例えば、コマンドまたはタスク）を、オーディオ（例えば、ビープ、サウンド、音楽など）と共に構成することができる。例えば、「ヒュー」というサウンドと組み合わせられたアニメーションのためのメッセージを、メッセージのバッチとして通信することができる。したがって、本明細書で説明するように、オーディオ、描画装置の他の制御などに関係するメッセージを、様々な例示的な方法、プロトコルなどを使用して通信することができる。例えば、描画装置が電気製品（例えば、冷蔵庫）を制御する場合、グラフィック、サウンド、および温度調節信号を、メッセージのバッチとして送信することができる。
【００３５】
例示的な非同期通信プロトコルは、フェーズを使用して説明することができる。例えば、タイムライン４００は、ホストバッチ処理フェーズ、ホストから描画装置への通信フェーズ、および描画装置のバッチ処理フェーズを備える。
【００３６】
タイムライン４００を参照して説明した例示的な非同期通信プロトコルを、いかなる適切な送信側と受信側の間の通信のためにも使用することができる。例えば、フレームワークおよびレンダラは例示的な通信プロトコルレイヤを備えることができ、このプロトコルレイヤは、フレームワークとレンダラ、および、状況に応じて、１つ以上の中間物の間の転送情報のサービスまたはそのためのオペレーションを提供する抽象概念である。例示的な通信プロトコルにより任意に拡張、および例えば、メッセージセグメントを定義し、関連付けられた処理ルールを定義することができる、１つ以上のモジュールが提供される。
【００３７】
例示的な通信プロトコルはメッセージを基本ユニットとして使用し、通信は１つのメッセージであってもメッセージのバッチであってもよい。例示的な通信プロトコルはメッセージングモデルに従って動作することができ、メッセージングモデルを、プロトコルレイヤと協調するメッセージングレイヤと見なすことができる。例示的なプロトコルレイヤは任意にメッセージを、送信されたメッセージの数、送信されたメッセージの種類、バッチサイズなどに関して制御する。
【００３８】
例示的な通信プロトコルは、描画装置上のユーザーインターフェイス、または、１つ以上のそのコンポーネントを実行する際使用するための、メッセージングモデルおよびグラフィクスモデルを明示するが、メッセージはホストデバイスから発信し、またはホストデバイスへの中間物となる。このようなメッセージングモデルまたはグラフィクスモデルは、タスクを実行するオブジェクト、またはユーザーインターフェイスに関係する機能を表現するためのオブジェクトを備えることができる。例示的なホストデバイスは、アプリケーションがユーザーインターフェイス、ユーザーインターフェイスコンポーネントなどを描画装置上でうまく実行することを可能にする、フレームワークを備えることができ、それにより、ホストデバイスと描画装置との間の通信は、例示的な通信プロトコル（例えば、図４のタイムライン４００に関して説明したような非同期通信プロトコル）に従って行なわれる。
【００３９】
タイムライン４００を参照して説明した例示的な非同期通信プロトコルを、図１に示すものなど、機器を使用して実施することができるが、図５は、図４の例示的な非同期通信プロトコルを実施することができる、より詳細な例示的なシステムを示す図である。
【００４０】
例示的なシステム５００は、ホストコンピュータ５０４、描画装置５０６、および通信リンク５２０を備え、破線５４０は、ホストコンピュータ５０４と描画装置５０６との間の通信を表す。ホストコンピュータ５０４は、アプリケーション５０８、およびアプリケーション５０８と共に動作するフレームワーク５１０を備える。フレームワーク５１０は様々なフレームワークコンポーネントを備え、これらのコンポーネントは、それに限定されないが、グラフィカルユーザーインターフェイス（ＧＵＩ）アブストラクションレイヤ５１２、スケジューリングレイヤ５１４、オブジェクトレイヤ５１５、他のサービス５１６、および通信レイヤ５１８などである。描画装置５０６はレンダラ５３０を備え、レンダラ５３０は、ソフトウェア、ハードウェア、ソフトウェアおよびハードウェアの組合せなどであってもよい。描画装置５０６は、例えば、ホストコンピュータ５０４からリモートに位置する、リモートデバイスであってもよい。図５のように、レンダラ５３０は、オブジェクトレイヤ５３２、通信レイヤ５３４、アニメーションレイヤ５３６、およびグラフィックスレイヤ５３８を備える。
【００４１】
例示的なシステム５００は、高性能の非同期メッセージングモデルを使用することができ、このモデルは、描画装置５０６に関連付けられたリモートユーザーインターフェイスのための論理的レンダリングおよび対話を記述する。ホストコンピュータ５０４と描画装置５０６との間の通信において使用される例示的なプロトコル要素には、アクティブ接続を維持し、様々な通信パターンを容易にするためのオブジェクトが含まれる場合がある。例示的なプロトコルオブジェクトには、プロトコル内のルートオブジェクトとしてのブローカオブジェクト、論理計算サイトを表すコンテキストオブジェクト、ランタイムにおけるレンダポートからのコールバックのためのレンダポートコールバックオブジェクト（レンダポートは、通常はレンダラ関連メッセージのための、メッセージポートと呼ばれる場合がある）、バルクデータ転送の状況についてレポートするためのデータバッファコールバックオブジェクト、および、バルクデータをリモートノード上で表すデータバッファオブジェクトが含まれる場合がある。例示的なシステム５００は、図４のタイムライン４００に関して説明した例示的通信プロトコルに従って動作することができ、このプロトコルはこのような例示的オブジェクトまたは他のオブジェクトの１つまたは複数を使用する。
【００４２】
例示的なシステム５００では、例示的な通信プロトコルを使用して、高性能のメッセージングモデルを、描画装置５０６上で実行するレンダラ５３０のインスタンスに接続することができる。通常、レンダラ５３０は、描画装置５０６のグラフィクス／アニメーションハードウェアのためのソフトウェアインターフェイスである。レンダラ５３０は、オブジェクトを管理するオブジェクトレイヤ５３２など、様々なレイヤを備える。オブジェクトの管理には、オブジェクトの作成、オブジェクトの名前付け、オブジェクトのアクセスなどを含むことができる。
【００４３】
「グラフィクス」言語、仕様またはインターフェイスで提供された機能は一般に、アニメーションレイヤ５３６およびグラフィクスレイヤ５３８のための基礎を形成する。例えば、２Ｄまたは３Ｄコンピュータグラフィクスを作成するアプリケーションを書くための、クロス言語、クロスプラットフォームのアプリケーションプログラムインターフェイス（ＡＰＩ）を定義する仕様である、Ｏｐｅｎ  Ｇｒａｐｈｉｃｓ  Ｌｉｂｒａｒｙ（ＯｐｅｎＧＬ）を参照されたい。ＯｐｅｎＧＬインターフェイスは、約２５０もの異なるファンクションコールを備え、これらのファンクションコールを使用して、様々なグラフィクス（例えば、単純な基本要素から、単純な基本要素から構築された複雑な３次元シーンまで）を描く（draw）することができる。ＯｐｅｎＧＬはまた、他の仕様、例えば、ＤｉｒｅｃｔＸ（例えば、ＤｉｒｅｃｔＤｒａｗ、Ｄｉｒｅｃｔ３Ｄなど）のように、ビデオゲーム産業においても使用される。ＨＴＭＬまたは他のマークアップ言語ベースの命令を、グラフィクスなどのために使用することができる。
【００４４】
本明細書で説明したように、例示的なレンダラは通常、２Ｄおよび３Ｄグラフィクスイメージを（例えば、グラフィクスレイヤ５３８で使用するために）定義するためのアプリケーションプログラムインターフェイス（ＡＰＩ）を備え、このＡＰＩは、ハードウェアおよびオペレーティングシステム全体で一定の互換性を提供し、一連のメッセージ（例えば、メッセージとして使用するために適切なもの）を指定することができる。このようなＡＰＩを介してエクスポーズされた特定のグラフィクス／アニメーション機能には、陰面消去、アルファブレンディング、アンチエイリアス処理、テクスチャ・マッピング、ピクセル操作、視野変換およびモデリング変換、ぼかし効果または他の機能が含まれる場合がある。このようなグラフィック描画機能を通常、高品質の静止およびアニメ３次元カラーイメージを作成するために使用することができる（例えば、アニメーションレイヤ５３６を考察されたい）。一般に、描画装置は、少なくともいくつかの基本アニメーション機能を有するレンダラを備える。
【００４５】
すでに述べたように、レンダラ５３０の通信レイヤ５３４は、フレームワーク５１０の通信レイヤ５１８と通信する。通信レイヤ５３４により、ホストコンピュータ５０４以外のデバイスとの通信が可能となり、状況に応じて、他のフレームワークとの通信が可能となる。描画装置５０６は、図示しない他のレイヤを備える場合があり、これらのレイヤには、それに限定されないが、描画において使用されたハードウェアのための１つ以上の特定のソフトウェアインターフェイスを記述するドライバレイヤ、および表示を作成するハードウェアを記述するハードウェアレイヤなどがある。
【００４６】
図５に示すホストコンピュータ５０４の例示的なフレームワーク５１０を参照すると、フレームワーク５１０は、通常は様々なＧＵＩ要素のために一連のＡＰＩを提供する、ＧＵＩアブストラクションレイヤ５１２を備える。ＧＵＩアブストラクションレイヤ５１２は、オブジェクトが作成され、名前付けされるなどのときにオブジェクトレイヤ５１５と、または、他のレイヤと対話することができる。他のサービス５１６には、ドローサービス、マークアップ言語（例えば、ＸＭＬ）解析サービス、方向ナビゲーションサービス、データバインディングサービス、コマンドインタープリタサービス、アニメーションコントロールシステムサービス、ＵＩ記述テンプレートモデルサービス、ＵＩレイアウトシステムサービスなどを含むことができる。
【００４７】
一般に、フレームワーク５１０によって、アプリケーション５０８が、描画装置５０６による、例えば、描画装置５０６のユーザーへの様々な情報またはグラフィクスのプレゼンテーションを要求することが可能になる。フレームワーク５１０により、複数の描画装置へのこのような要求が可能になる。一般に、例示的なシステム５００は、メッセージをバッチしてこのようなバッチを（例えば、通信として）非同期の方法で通信することができる、例示的なプロトコルを利用することによって、ユーザーインターフェイスまたはユーザーインターフェイスコンポーネントのハイファイの遠隔表示に備えることができる。
【００４８】
例示的なシステム５００またはそのコンポーネントは、様々な例示的な方法を実施することができる。言うまでもなく、他のシステムまたはコンポーネントを使用して、様々な例示的な方法（例えば、図１および６のデバイスを参照）を実施することができる。例示的な方法は、１つ以上のメッセージを、ホストコンピュータ上で実行するアプリケーションから描画装置へ通信するステップを含むことができ、この通信は例示的な非同期通信プロトコルを使用する。例えば、アプリケーションはメッセージを発行することができ、フレームワークはメッセージのバッチを形成し、メッセージのバッチを通信として描画装置に通信することができ、バッチを受信すると、描画装置はメッセージに従って描画を実行する。例示的なフレームワークは、メッセージのバッチ（またはいずれかのメッセージ）の受信、１つ以上のメッセージの実行、１つ以上のメッセージに従った描画、バッチ内の情報と関連付けた描画装置とのユーザーとの対話などに応答して、１つ以上のメッセージをリモートデバイスから受信することができる。
【００４９】
描画装置の描画機能のアプリオリな知識によって、例示的なフレームワークがアプリケーションと協調し、またはアプリケーションをある一連のメッセージに制限すること、および、バッチ内のメッセージの数またはメッセージの種類を管理することが可能になる。描画装置の現在の状態のアプリオリな知識によって、例示的なフレームワークがメッセージまたはメッセージのバッチをスケジュールして（例えば、スケジューリングレイヤ５１４を考察されたい）、例えば描画装置のユーザーのユーザー体感への割り込みまたは干渉を回避することが可能になる。通信リンクの特性（例えば、帯域幅、使用量など）のアプリオリな知識は、例示的なフレームワークがメッセージのバッチをスケジュールまたはそうでない場合は管理することが可能になる。様々な機能を例示的なフレームワークについて個々に述べるが、このような機能の多くは状況に応じて、適切なユーザー視聴をスケジューリングし、管理し、提供するなどのために結合することができる。
【００５０】
すでに述べたように、例示的なプロトコルには様々なオブジェクト、すなわちブローカオブジェクト、コンテキストオブジェクト、レンダポートコールバックオブジェクト（または、メッセージポートコールバックオブジェクト）、データバッファコールバックオブジェクト、データバッファオブジェクトなどが含まれる場合がある。これらのオブジェクトは、メッセージングモデルの一部を形成することができる。例示的なプロトコルはまた、グラフィクスモデルを形成するために、このようなメッセージング定義またはオブジェクトの上に階層化された追加の定義を含むこともできる。例えば、例示的なプロトコルは、ドローコマンド（例えば、グラフィック、アニメーションなどのコマンド）のパケットを保持するためのレンダビルダオブジェクト、プレゼンテーションコンテナを表すウィンドウオブジェクト、離散座標空間を表すビジュアルオブジェクト、デバイスの状況についてレポートするためのデバイスコールバックオブジェクト、描画技術ドライバを表すデバイスオブジェクト、イメージビットのための論理コンテナを表すサーフェスオブジェクト、イメージビットのための物理コンテナを表すサーフェスプールオブジェクト、コンテナスコープ内の他の基本要素のカラースペースの修正のためのグラディエント・オブジェクト、アニメーションコントロールに役立つアニメーションマネージャオブジェクト、アニメーションについてレポートするアニメーションコールバックオブジェクト、および論理アニメーションシーケンスを記述するアニメーションオブジェクトを含む、グラフィクスモデルを含むことができる。本明細書で説明するように、メッセージはコマンド、情報などであってもよい。
【００５１】
したがって、例示的なプロトコルはメッセージングモデルおよびグラフィクスモデルを使用することができる。メッセージングモデルは、コアプロトコルの実装を簡素化し、拡張を可能にし、ホストデバイスおよび描画装置の通信タイミングの適切な分離を可能にする、などのように動作することができる。メッセージングモデルは、バッファレイヤ（例えば、プロトコル対話の基本フレーミングのためのレイヤ）、およびオブジェクトメッセージングモデルレイヤ（例えば、ライフタイム管理および通信のためのレイヤ、およびメッセージがバッファ内で搬送され、常にオブジェクトインスタンスを参照するレイヤ）など、様々なレイヤを備えることができる。バッファに関して、メッセージバッファ（例えば、１つのメッセージ、または、メッセージのバッチ）を、処理するためにオブジェクトレイヤに直接渡すことができ、処理が戻るときに廃棄することができ、データバッファを様々なコンテンツのために予約することができ、到着するとオブジェクトレイヤに登録することができ、バッファは対照におよび双方向にすることができる。つまり、ホストデバイスにとって描画装置へのモデルと、描画装置にとってホストデバイスへのモデルとは同様となる。メッセージングモデルは、オブジェクト実装インスタンスをホストデバイスおよび描画装置上に備えることができる。すべてのオブジェクトは状況に応じてセッション毎のテーブル内に存在し、一意のハンドルを有し、実装「クラス」に関連付けられることができる。オブジェクトのインスタンスを、ワイヤ上のハンドルによって参照することができ、非対称オーナーシップモデルをサポートすることができる。一般に、メッセージングモデルは、ホストデバイスが個々の応答（すなわち、効率的な非同期）を待機する必要がないと規定することができる。
【００５２】
一般に、非同期オーナーシップは、デバイスリソースのためのマスタ／スレーブオーナーシップモデルを参照する。本明細書で提示された様々な例示的な技術により実装することができる例示的なオーナーシップモデルでは、プロトコル可視オブジェクトをホスト側で管理する場合がある。例えば、ホスト側のマネージャは、すべてのプロトコル可視オブジェクトのライフタイムを、それらがどちらの側（例えば、描画装置／レンダラ側またはホストデバイス／フレームワーク側）が生きているかにかかわらず、管理することができる。このような例示的オーナーシップモデルによりオブジェクト作成および消滅を非同期に（オブジェクトへの単なるメッセージではなく）することが可能になり、これによってより高いパフォーマンスに備えることができ、また接続性損失またはデバイスリセットの後のレンダラ状態の容易な「再構成」を可能にすること（例えば、ホストをリセットすることなく）、および、レンダラの実装からこのようなリソースのための複雑なアロケーションおよび管理コードの必要性を取り除くことができ、これによりコストを削減することができる。
【００５３】
メッセージに関して、メッセージングモデルは、一意のメッセージ番号に関連付けることができるデータの、大きさ順に並べたブロブとしてのメッセージを可能にすることができるが、この番号付けは状況に応じてクラス毎である。メッセージングモデルは、インスタンスのメッセージをオブジェクトのハンドルに送信し、静的メッセージをクラスのオブジェクトハンドルに送信する、ノンゼロ・宛先オブジェクトのハンドルを可能にすることができ、および、メッセージ番号付けを可能にすることができる。メッセージングモデルは、例えば、最後にパックされた、任意のペイロードを可能にすることができる。すでに述べたブローカオブジェクトは、周知のハンドルと共に存在する例示的なプロトコルをブートするために使用される、ルートクラスとすることができる。このようなブローカは、基本サービスのための静的なメソッド、例えば、クラス発見（例えば、使用可能な場合、指定された名前のクラスインスタンスを作成する）、インスタンス作成（例えば、指定されたクラスハンドルのためのオブジェクトインスタンスを作成し、任意の「コンストラクタ」メッセージの受け渡しをサポートする）、およびインスタンス消滅（例えば、オブジェクトをハンドルによって破棄する）だけを備えることができる。一般に、このようなメッセージングモデルオブジェクトは、描画装置上のユーザーインターフェイス（ＵＩ）またはＵＩコンポーネントの実行を要求するアプリケーションによって、直接使用されない。
【００５４】
例示的な方法は、メッセージまたは情報をアプリケーションから描画装置のレンダラへ通信するための例示的なプロトコルを使用する。このような例示的な方法を説明するために、前述のメッセージングモデルおよびグラフィクスモデルの様々なオブジェクトが、例示的なプロトコルトラフィックを提示する際に使用される。具体的には、以下のサンプルトレース（サンプルトレース１）は、新しいＲｅｎｄｅｒＢｕｉｌｄｅｒオブジェクトを作成するための単一のワイヤメッセージに対応する。送信された実際のメッセージは、Ｂｒｏｋｅｒへの静的なＣｒｅａｔｅＯｂｊｅｃｔコールであり、新しいトレースは、パラメータなどのプロセスを（Ｂｒｏｋｅｒによって、インスタンスを作成した後に呼び出される）コンストラクタに示すために出される。このようなトレース（サンプルトレース１）は、例えば、例示的なシステム１００において、図１の描画装置１３４、１３６がホストデバイス１３２上で実行するアプリケーションによって駆動されるとき、それらのうち１つの間で発生させることができる。
【００５５】
Sample Trace 1 
(new RenderBuilder [class 1000003], constructor Msgl_Create as MessagePtr) 
cat = InScene 
16 bytes total 
send Broker [class 1000000] static Msgl_CreateObject 
idObjectClass = RH:1000003 
idObjectNew = RH:5000146 
msgConstruction = [blob MessagePtr] 215548588 
+16 bytes blob data 
40 bytes total
【００５６】
このサンプルトレースでは、コンストラクタのサイズは、ＣｒｅａｔｅＯｂｊｅｃｔコールへのｍｓｇＣｏｎｓｔｒｕｃｔｉｏｎパラメータのためのＢＬＯＢデータのサイズに一致する。このシーケンスでは、送信されたメッセージングバイトの総量は４０であり、５６ではない。ＢＬＯＢはバイナリラージオブジェクトを参照する場合があるが、このようなデータのサイズは、様々な要素によって決まる可能性があり、実施例のサイズまたは他のサイズになることもあり、したがって、ＢＬＯＢという語は必ずしも「大きな」オブジェクトを指すとは限らない場合がある。データは一般に、様々な実施例において通信されるとき、バイナリデータであるが、データは状況に応じてバイナリデータ以外であってもよい。
【００５７】
メッセージのバッチがレンダラ（例えば、遠隔の描画装置上のレンダラ）に通信されるとき、コールバックを追加することができ、そのため、アプリケーション側のメッセージングコードは、いつバッファが実際に処理されたかを知ることができる。したがって、いかなるバッチバッファ内の最終メッセージも、エンクローズされたメッセージをアプリケーション側に戻すように送信するようにレンダラに命令するＦｏｒｗａｒｄＭｅｓｓａｇｅコールにすることができる。この実施例では、エンクローズされたメッセージのペイロードは、メッセージングランタイム自体へのＯｎＢａｔｃｈＰｒｏｃｅｓｓｅｄコールバックである（サンプルトレース２を参照）。
【００５８】
Sample Trace 2 
(encode RenderPortCallback Msg0_OnBatchProcessed as MessagePtr) 
target = RH:0 
uBatchCompleted = 64 
20 bytes total 
send Context [class 1000002] static Msg2_ForwardMessage
idContextDest = ctx:1 
msgReturn = [blob MessagePtr] 215548920 
+20 bytes blob data 
40 bytes total
【００５９】
メッセージのランタイムが現在のバッチをアセンブルして、送信するとき、全体としてのバッチ、および、それを搬送するために使用されている個々のバッファまたはバッファ群についての情報をトレースすることができる（例えば、「ＭＥＳＳＡＧＥ  ＢＡＴＣＨ  ６４」および「ＳＥＮＤＩＮＧ  ＢＡＴＣＨ  ＢＵＦＦＥＲ：ｉｄ＝ＲＨ：０，９１２バイト」）。
【００６０】
メッセージのバッチを含むバッファを送信中であるとき、識別子（例えば、インスタンスｉｄ）により、複数のバッファと共に大型のバッチのためにリンクすることが可能にな。バッファは、大量のバイナリデータ（サーフェスのイメージピクセル、サウンドのための波形データなど）を含むことができる。バッチまたはバッファのためのインスタンスｉｄにより、メッセージが後続のレンダリングコマンドにおいてバッチまたはバッファのデータを参照することが可能になる。様々な実施例では、バッファはメッセージおよびデータを含むことができ、これらのメッセージおよびデータは、状況に応じて、メッセージまたは後続のメッセージに関係する１つ以上のタスクによって使用することができる。
【００６１】
サンプル「ｓｅｎｄ」トレース１および２は、実際のプロトコルメッセージがバッファに入れられることを表す。「Ｓｅｎｄｉｎｇ  Ｂｕｆｆｅｒ」トレースが使用可能とすることができ、このトレースは、プロトコルデータのバッファがレンダラへの転送のために提供されることを表す。
【００６２】
もう１つのサンプルトレース（サンプルトレース３）が後に続き、これはレンダラへ、例示的なフレームワークによって送信されたメッセージのトレースであり、ここでは、フォーカスを２つのＧＵＩボタンの間で変更するための要求が行われている。さらに具体的に言うと、以下のバッチは、フォーカスをあるボタンから別のボタン（例えば、図１の描画装置上のＧＵＩボタン上のフォーカス）へシフトするために必要とされた、状態およびアニメーション変更を記述し、例えば、ボタンは複数のレイヤおよび連続的に振動するオーバーレイアニメーションから構成される。サンプルトレース３には、ユーザーが遠隔操作上で矢印キーを押すことが含まれ、そのため、最初の少数のメッセージは入力状態に関係し（例えば、カーソルを隠し、適切なフォーカスを保証する）、メッセージの残りはビジュアルレンダリング状態およびアニメーションに関係する。
【００６３】
Sample Trace 3 
send FormWindow:100001F Msg16_ForceMouseIdle 
fIdle = True 
16 bytes total 
send FormWindow:100001F Msg15_TakeFocus 
12 bytes total 
send Animation:7000062 Msg4_Stop 
12 bytes total 
send Visua1:1000177 Msg23_SetVisible 
fVisible = False 
16 bytes total 
send Visual:1000177 Msg0_ChangeDataBits
nValue = 0 
nMask = 7340039 
20 bytes total 
send Visual:1000177 Msg22_SetContent 
rbContent = RenderBuilder:0 
16 bytes total 
send Visual:1000185 Msg23_SetVisible 
fVisible = True 
16 bytes total 
send Visual:1000185 Msg0_ChangeDataBits 
nValue = 1 
nMask = 7340039 
20 bytes total 
send AnimationBuilder [class 100000F] static Msg27_BuildAlphaAnimation 
viSubject = Visual:1000185 
idAnimation = RH:7000142 
20 bytes total 
send Animation:7000142 Msgl_AddCallback 
cb = AnimationCallback:5 
20 bytes total 
send Animation:7000142 Msg10_SetRepeatCount 
cRepeats = -1
16 bytes total 
send Animation:7000142 Msg6_SetStopCommand 
cmd = MoveToEnd 
16 bytes total 
send Anirnation:7000142 Msg2_AddKeyframe 
idxKeyframe = 0 
f1TimeSec = 0 
20 bytes total 
send AnimationBuilder [class 100000F] static Msg3_SetSCurve 
ani = Animation:7000142 
idxKeyframe = 0 
f1Scale = 1 
24 bytes total 
send AnimationBuilder [class 100000F] static Msg16_SetFloat 
ani = Animation:7000142 
idxKeyframe = 0 
f1Value = 0 
24 bytes total 
send Animation:7000142 Msg2_AddKeyframe 
idxKeyframe = 1 
f1TimeSec = 1.5 
20 bytes total
send AnimationBuilder [class 100000F] static Msg3_SetSCurve 
ani = Animation:7000142 
idxKeyframe = 1 
f1Scale =1 
24 bytes total 
send AnimationBuilder [class 100000F] static Msg16_SetFloat 
ani = Animation:7000142 
idxKeyframe = 1 
f1Value = 0.627451 
24 bytes total 
send Animation:7000142 Msg2_AddKeyframe 
idxKeyframe = 2 
f1TimeSec = 3 
20 bytes total 
send AnimationBuilder [class 100000F] static Msg3_SetSCurve 
ani = Animation:7000142 
idxKeyframe = 2 
f1Scale = 1 
24 bytes total 
send AnimationBuilder [class 100000F] static Msg16_SetFloat 
ani = Animation:7000142 
idxKeyframe = 2
f1Value = 0 
24 bytes total 
send Animation:7000142 Msg5_Play 
12 bytes total 
(new RenderBuilder [class 1000003], constructor Msg1_Create as MessagePtr) 
cat = InScene 
16 bytes total 
send Broker [class 1000000] static Msgl_CreateObject 
idObjectClass = RH:1000003 
idObjectNew = RH:5000146 
msgConstruction = [blob MessagePtr] 215548588 
+16 bytes blob data 
40 bytes total 
send Surface:30000EE Msg0_DrawGrid 
rb = RenderBuilder:5000146 
f1X1Pxl = 20 
f1X2Pxl = 231 
f1Y1Pxl = 12 
f1Y2Pxl = 41 
rcfDestPxl= {X=0, Y=0, Width=-1, Height=-1} 
48 bytes total 
send Visua1:1000176 Msg22_SetContent
rbContent = RenderBuilder:5000146 
16 bytes total 
send RenderBuilder:5000146 Msg0_Clear 
12 bytes total 
send Surface:10000C6 Msg0_DrawGrid 
rb = RenderBuilder:5000146 
f1x1Pxl = 20 
f1X2Pxl = 231 
f1Y1Pxl = 12 
f1Y2Pxl = 41 
rcfDestPxl = {X=0, Y=0, Width=-1, Height=-1} 
48 bytes total 
send Visua1:1000184 Msg22_SetContent 
rbContent = RenderBuilder:50004146 
16 bytes total 
send RenderBuilder:5000146 Msg0_Clear 
12 bytes total 
send Surface:10000C8 Msg0_DrawGrid 
rb = RenderBuilder:5000146 
f1X1Pxl = 20 
f1X2Pxl = 231 
f1Y1Pxl = 12
f1Y2Pxl = 41 
rcfDestPxl= {X=0, Y=0, Width=-1, Height=-1} 
48 bytes total 
send Visua1:1000185 Msg22_SetContent 
rbContent = RenderBuilder:5000146 
16 bytes total 
(dispose RenderBuilder:5000146) 
send Broker [class 1000000] static Msg0_DestroyObject 
idObject = RH:5000146 
16 bytes total 
(encode RenderPortCallback Msg0_OnBatchProcessed as MessagePtr) 
target = RH:0 
uBatchCompleted = 64 
20 bytes total 
send Context [class 1000002] static Msg2_ForwardMessage 
idContextDest = ctx: 1 
msgReturn = [blob MessagePtr] 215548920 
+20 bytes blob data 
40 bytes total 
MESSAGE BATCH 64 
[SENDING BATCH BUFFER: id=RH:0, 912 bytes]
【００６４】
サンプルトレース３では、メッセージは、以前にレンダラに送信されたサーフェスからのみ描かれる（draw）。メッセージが、新しいグラフィカルリソースを必要とした遷移のためにトレースされた場合、より多くのトラフィックが、サーフェスの割り振り、バルクデータバッファからのピクセルデータのローディング、および極端な場合、サーフェスプールの圧縮にあてられていたであろう。
【００６５】
サンプルトレース３のバッチは、古いフォーカスされたボタン上で振動するフォーカスアニメーションを停止した。これが発生したとき、レンダラは、アニメーションが停止されたという通知をフレームワークに戻すように送信し、および、その通知がその特定のアニメーションオブジェクトで行われたことを判断したアプリケーション側のある汎用ハンドリングを作動させた。これは、次に、サンプルトレース４に提示するように、古いアニメーションを破棄するようにレンダラに命令する、別の小さいメッセージのバッチを作成した。
【００６６】
Sample Trace 4 
(dispose Animation:7000062) 
send Broker [class 1000000] static Msg0_DestroyObject 
idObject = RH:7000062 
16 bytes total 
(encode RenderPortCallback Msg0_OnBatchProcessed as MessagePtr) 
target = RH:0 
uBatchCompleted = 65 
20 bytes total 
send Context [class 1000002] static Msg2_ForwardMessage 
idContextDest = ctx:1
msgReturn = [blob MessagePtr] 215515328 
+20 bytes blob data 
40 bytes total 
MESSAGE BATCH 65 
[SENDING BATCH BUFFER: id=RH:0, 96 bytes]
【００６７】
本明細書で説明するように、例示的なプロトコルはメッセージングモデルに基づいて、ホストコンピュータからリモートに位置する場合がある描画装置に関連付けられた、ハイファイユーザーインターフェイスのための論理的描画および対話モデルを記述する。
【００６８】
例示的なプロトコルは、機能性特定のモジュールなど、様々なレイヤを含むことができ。そして、これらのモジュールは、サービスを実装するもの、プログラミングインターフェイスをオブジェクト／メッセージとしてエクスポーズするもの、およびグラフィクスモデルに関係するオブジェクトのプライマリセットを使用するものである。
【００６９】
例示的なプロトコルのための例示的なグラフィックスモデルは、デバイスオブジェクト、プレゼンテーションコンテナオブジェクト、サーフェスプールオブジェクト（例えば、ビットマップデータのためのコヒーレントな格納領域を表す）、サーフェスオブジェクト（例えば、個々の描画可能な多くのサーフェスプール）、ビジュアルオブジェクト（例えば、基本要素を画面上で描くための論理コンテナであり、座標空間を所有し、プレゼンテーションコンテナをルートとするツリーとして編成される）、および、レンダビルダオブジェクト（例えば、アセンブルされている描画基本要素のリストのためのコンテナ）を含むことができる。例示的なグラフィックスモデルは、アニメーションマネージャ（例えば、アニメーションの座標処理）、および、アニメーションのための個々のファンクションインスタンスを含むことができる。エクステンダー・グラフィクス・オブジェクトを含めることができ、これらのオブジェクトは、ラスタライザ・オブジェクト（例えば、サーフェスデータを準備するために使用されたヘルパオブジェクト）、および、グラディエント・オブジェクト（例えば、他の基本要素をその範囲内で修正することができるカラーチャネル修正オブジェクトであり、従来の「グラディエント」機能は、内側に塗りつぶしを行なうことによって達成される）などである。他のオブジェクトには、デスクトップマネージャオブジェクト（例えば、デスクトップとの統合に適したもの）、フォームオブジェクト（デスクトップ指向のプレゼンテーション・コンテナ・ビヘイビアに適したもの）、および様々なコールバックインターフェイスを含むことができる。
【００７０】
すでに述べたように、メッセージは、グラフィクスまたはアニメーション以外のタスクに関連付けすることができる。さらに、メッセージのバッチは、必要に応じて、または、要望通りに、タスクの混合を含むことができ、これらのタスクは、必ずしもこれらに限定されないが、グラフィクスタスク、オーディオタスク、アプライアンス・コントロール・タスクなどがある。例えば、メッセージのバッチは、電気製品（例えば、冷蔵庫、サーモスタット、セキュリティカメラ、ゲームユニットなど）、グラフィック、サウンドまたは他のタスクの制御に関連させることができる。
【００７１】
例示的なプロトコルは状況に応じて拡張することができる。例えば、例示的なプロトコルの拡張は、リモーティング、すなわち、リモートユーザーインターフェイスへの命令と連動する機能を提供することができる。このような拡張は、描画装置の状態に応じて、全画面または部分画面処理のために行なうことができる。例えば、１つまたは複数のメッセージの通信は、描画装置のグラフィカルユーザーインターフェイスへの全画面モードの命令と、デスクトップコンピュータのグラフィカルユーザーインターフェイスへの命令とでは異なる場合がある。命令がデスクトップコンピュータに通信中である場合、拡張したプロトコルをホストコンピュータ上にロードして、メッセージの別の機能または通信を提供することができる。
【００７２】
例示的なプロトコルは状況に応じて、ホストデバイスから描画装置への、描画装置に関するユーザーのメディア体感を決定するメッセージの通信を可能にする。例えば、このようなユーザーがＴＶメディアを約６０ｆｐｓのフレームレートで視聴中である場合、次に通信は、１つまたは複数のフレームの表示にあえて割り込むようになるメッセージのバッチの送信を回避することができる。さらに、多数のアニメーション（例えば、フェードイン、フェードアウト、拡大など）は、ユーザーがこのようなアニメーションとなるよう意図したように、スムーズに知覚することが通常は保証される、一定のフレームレートが必要である。通信があえてフレームに割り込むか、またはフレームの表示を遅延させる場合、次いで例示的なフレームワーク（例えば、フレームワーク５１０）はこのようなリスクを説明し、より小さいバッチにおいて、または他の調整によって通信することができる。言うまでもなく、ＴＶの実施例およびアニメーションの実施例では、メッセージまたはメッセージのバッチを送信するホストデバイスはまた、アニメーションまたはＴＶ媒体を提供中である場合もある。このようなことに基づいて、例示的なフレームワークは適宜に、ユーザーに、スムーズな期待された視聴環境を提供するように動作することができる。したがって、例示的なフレームワークは、描画装置のユーザーインターフェイス上の情報の表示に関して、最適なフレームレートを保証するように動作することができる。
【００７３】
例示的なフレームワークは状況に応じて、１つ以上のメッセージをバッチで送信し、描画装置へのバッチの通信のタイミングにより、描画装置のユーザーインターフェイスへの変更がアニメーションのフレームまたは他のビデオ表示に割り込まないことが保証される。例えば、バッチの受信、バッチメッセージの実行（例えば、コマンドの実行、情報の転送など）、または表示は、このようなアニメーションのフレームまたは他のビデオ表示の間で発生させることができる。ユーザーインターフェイスが現在ビデオを６０ｆｐｓのフレームレートで表示中である描画装置のユーザーインターフェイス上で、ダイアログボックスの表示を要求する、ホストデバイス上で実行するアプリケーションを考察されたい。ホストデバイス上の例示的なフレームワークによって、バッチの方法、タイミングの方法、または他の方法によりメッセージを制御して、描画装置によるダイアログボックスの表示がビデオの表示に割り込まないことが保証される。
【００７４】
一般に、いくつかの描画装置では、ユーザーは、このような描画装置に関連付けられたユーザーインターフェイスが、６０Ｈｚのフレームレートを有する、正常なテレビビデオの表示を、期待するだろう。ユーザーは通常、２４ｆｐｓおよび６０ｆｐｓの両方でほぼ等しく信号異常（glitches）を識別することができるが、２４ｆｐｓビデオの単一のフレーム上で１／６０だけ遅れることでさえ、目に見える「一時的な中断」を引き起こし、ユーザーは、これを品質の損失として知覚する。したがって、例示的なプロトコルは、６０ｆｐｓ未満のフレームレートでさえ品質の向上のために用いることができる。フレームレートが上がるにつれて、例示的なフレームワークは通常、エラーの余地がより少なくなり、それによりメッセージ管理の必要性が増す。再度、ホスト側の管理により、描画装置側の負担を減らすことができ、描画装置側はそれ自体で、描画装置が表示品質を向上させることを可能になる。
【００７５】
例示的なプロトコルを、アップデート、変更、新しいユーザーインターフェイス、新しいユーザーインターフェイスコンポーネント、ビデオのプレゼンテーションなどを通信するために使用することができる。
【００７６】
様々な実施例を、異なるコンピュータ環境内で実施することができる。図６に示すコンピュータ環境は、コンピュータ環境の一実施例でしかなく、使用に適切なコンピュータおよびネットワークアーキテクチャの使用または機能性の範囲についてのいかなる限定をも示唆することを目的とはしてない。このコンピュータ環境はまた、コンピュータ環境の例において説明されるコンポーネントのいずれか１つまたは組合せに関係するいかなる依存性または要件をも有するとして解釈されるべきでもない。
【００７７】
図６は、様々な例示的な方法を実施することができる、適切なコンピュータシステム環境６００の一実施例を説明する図である。様々な例示的なデバイスまたはシステムは、例示的な環境６００の機能のいずれかを含むこともできる。コンピュータシステム環境６００は、適切なコンピュータ環境の一実施例でしかなく、本発明の使用または機能性の範囲についてのいかなる限定をも示唆することを目的とはしていない。コンピュータ環境６００はまた、例示的なオペレーティング環境６００において説明されるコンポーネントのいずれか１つまたは組合せに関係するいかなる依存性または要件をも有するとして解釈されるべきでもない。
【００７８】
様々な例示的な方法は、多数の他の汎用または専用のコンピュータシステム環境または機器構成と共に使用できる。実施または使用するために適切である可能性のある周知のコンピュータシステム、環境および／または機器構成の例には、必ずしもそれらに限定されないが、パーソナルコンピュータ、サーバーコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラムで制御できる家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピュータ環境などが含まれる。例えば、図１の例示的なシステム１００は、リモートコンピュータを使用して、ＵＩの表示のための情報を生成することができ、表示されたＵＩは、遠隔操作または他の入力デバイスと共に動作する。
【００７９】
様々な例示的な方法、アプリケーションなどを一般に、コンピュータによって実行されるプログラムモジュールなど、コンピュータ実行可能命令に関連して説明することができる。一般に、プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれ、これらは特定のタスクを実行するか、または特定の抽象データ型を実装する。様々な例示的な方法をまた分散コンピュータ環境において実施することもでき、この環境ではタスクが、通信ネットワークまたは他の通信（例えば、赤外線など）を通じてリンクされるリモート処理デバイスによって実行される。分散コンピュータ環境では、プログラムモジュールは、メモリストレージデバイスを含む、ローカルおよびリモートのコンピュータストレージ媒体内に位置することができる。
【００８０】
図６を参照すると、様々な例示的な方法を実施するための例示的なシステムは、コンピュータ６１０の形態における汎用コンピュータ・デバイスを含む。コンピュータ６１０のコンポーネントに、必ずしもそれに限定されないが、処理装置６２０、システムメモリ６３０、およびシステムメモリ６３０を含む様々なシステムコンポーネントを処理装置６２０に結合するシステムバス６２１を含むことができる。システムバス６２１をいくつかの種類のバス構造のいずれにすることもでき、これらのバス構造には、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスが含まれる。限定ではなく、一例として、このようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、および、メザニンバスとしても知られるＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。
【００８１】
コンピュータ６１０は通常、様々なコンピュータ読み取り可能な媒体を含む。コンピュータ読み取り可能な媒体は、コンピュータ６１０によってアクセスすることができるいかなる使用可能な媒体にすることもでき、揮発性および不揮発性の媒体、リムーバブルおよび固定の媒体が含まれる。限定ではなく、一例として、コンピュータ読み取り可能な媒体は、コンピュータストレージ媒体および通信媒体を備えることができる。コンピュータストレージ媒体には、揮発性および不揮発性、リムーバブルおよび固定の媒体が含まれ、これらの媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュールまたは他のデータなど、情報の格納のためのいずれかの方法または技術において実装される。コンピュータストレージ媒体には、それに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または目的とする情報を格納するために使用することができ、コンピュータ６１０によってアクセスすることができる他のいかなる媒体もが含まれる。通信媒体は通常、コンピュータ読み取り可能な命令、データ構造、プログラムモジュールまたは他のデータを、搬送波などの変調データ信号または他のトランスポートメカニズムにおいて実施し、いかなる情報配信媒体をも含む。「変調データ信号」という語は、信号内の情報をエンコードするような方法でその特性の１つまたは複数が設定または変更されている信号を意味する。限定ではなく、一例として、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、および、音響、ＲＦ、赤外線および他の無線媒体などの無線媒体が含まれる。上記のいずれの組合せもまた、コンピュータ読み取り可能な媒体の範囲内に含まれるべきである。
【００８２】
システムメモリ６３０は、読み取り専用メモリ（ＲＯＭ）６３１およびランダムアクセスメモリ（ＲＡＭ）６３２など、揮発性および／または不揮発性メモリの形態におけるコンピュータストレージ媒体を含む。基本入出力システム６３３（ＢＩＯＳ）は、起動中など、コンピュータ６１０内の複数の要素の間で情報を転送する助けとなる基本ルーチンを含み、通常はＲＯＭ６３１に格納される。ＲＡＭ６３２は通常、処理装置６２０によって即時アクセス可能および／または現在操作中であるデータおよび／またはプログラムモジュールを含む。限定ではなく、一例として、図６は、オペレーティングシステム６３４、アプリケーションプログラム６３５、他のプログラムモジュール６３６およびプログラムデータ６３７を例示する。
【００８３】
コンピュータ６１０はまた、他のリムーバブル／固定、揮発性／不揮発性のコンピュータストレージ媒体を含むこともできる。ほんの一例として、図６は、固定、不揮発性の磁気媒体に対する読み取りまたは書き込みを行うハードディスクドライブ６４１、リムーバブル、不揮発性の磁気ディスク６５２に対する読み取りまたは書き込みを行う磁気ディスクドライブ６５１、および、ＣＤ−ＲＯＭまたは他の光媒体（例えば、ＤＶＤなど）など、リムーバブル、不揮発性の光ディスク６５６に対する読み取りまたは書き込みを行う光ディスクドライブ６５５を例示する。例示的なオペレーティング環境で使用することができる他のリムーバブル／固定、揮発性／不揮発性のコンピュータストレージ媒体には、それらに限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどが含まれる。ハードディスクドライブ６４１は通常システムバス６２１に、インターフェイス６４０などのデータ媒体インターフェイスを通じて接続され、磁気ディスクドライブ６５１および光ディスクドライブ６５５は通常システムバス６２１に、状況に応じてリムーバブルメモリインターフェイスであるデータ媒体インターフェイスを通じて接続される。この特定の実施例の説明のため、磁気ディスクドライブ６５１および光ディスクドライブは、データ媒体インターフェイス６４０を使用する。
【００８４】
上述し、図６に例示した、これらのドライブおよびそれらの関連付けられたコンピュータストレージ媒体は、コンピュータ６１０用のコンピュータ読み取り可能な命令、データ構造、プログラムモジュールおよび他のデータのストレージを提供する。図６では、例えば、ハードディスクドライブ６４１は、オペレーティングシステム６４４、アプリケーションプログラム６４５、他のプログラムモジュール６４６およびプログラムデータ６４７を格納するものとして例示される。これらのコンポーネントを、オペレーティングシステム６３４、アプリケーションプログラム６３５、他のプログラムモジュール６３６およびプログラムデータ６３７と同じものにも異なるものにもすることができることに留意されたい。オペレーティングシステム６４４、アプリケーションプログラム６４５、他のプログラムモジュール６４６およびプログラムデータ６４７にはここで異なる番号が与えられており、最低でも、それらが異なるコピーであることが例示される。ユーザーはコマンドおよび情報をコンピュータ６１０へ、キーボード６６２、および、一般にマウス、トラックボールまたはタッチパッドと呼ばれるポインティングデバイス６６１など、入力デバイスを通じて入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどが含まれる可能性がある。これらおよび他の入力デバイスはしばしば処理装置６２０へ、システムバス６２１に結合されるユーザー入力インターフェイス６６０を通じて接続されるが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェイスおよびバス構造によって接続することができる。モニタ６９１または他のタイプの表示デバイスもまたシステムバス６２１へ、ビデオインターフェイス６９０などのインターフェイスを介して接続される。モニタ６９１に加えて、コンピュータは、スピーカおよびプリンタなど、出力周辺インターフェイス６９５を通じて接続することができる他の周辺出力デバイスを含むこともできる。
【００８５】
コンピュータ６１０はネットワーク環境において、リモートコンピュータ６８０など、１つ以上のリモートコンピュータへの論理接続を使用して動作することができる。リモートコンピュータ６８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードにすることができ、通常は、コンピュータ６１０に関連して上述した機能の多数またはすべてを含む。図６に描いた論理接続には、ローカルエリアネットワーク（ＬＡＮ）６７１およびワイドエリアネットワーク（ＷＡＮ）６７３が含まれるが、他のネットワークが含まれる可能性もある。このようなネットワーク環境は、オフィス、企業全体のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的である。
【００８６】
ＬＡＮネットワーク環境において使用されるとき、コンピュータ６１０はＬＡＮ６７１へ、ネットワークインターフェイスまたはアダプタ６７０を通じて接続される。ＷＡＮネットワーク環境において使用されるとき、コンピュータ６１０は通常、モデム６７２、またはインターネットなどのＷＡＮ６７３を介して通信を確立するための他の手段を含む。モデム６７２、それは内蔵または外付けであるかもしれないが、システムバス６２１へ、ユーザー入力インターフェイス６６０または他の適切なメカニズムを介して接続することができる。ネットワーク環境では、コンピュータ６１０に関連して描かれたプログラムモジュールまたはその一部を、リモートメモリストレージデバイスに格納することができる。限定ではなく、一例として、図６はリモートアプリケーションプログラム６８５をリモートコンピュータ６８０上に（例えば、リモートコンピュータ６８０のメモリ内に）存在するとして例示する。図示のネットワーク接続は例示的なものであり、複数のコンピュータの間で通信リンクを確立する他の手段を使用することができることは理解されよう。
【００８７】
様々な例示的な方法、デバイス、システムなどを、構造的特徴および／または方法的動作に特有の言語において説明したが、特許請求の範囲で定義された構成は必ずしも、説明した特定の特徴または動作に限定されないことを理解されたい。むしろ、特定の特徴および動作は、特許請求の範囲に記載されている構成を実施する例示的な形態として開示される。
【図面の簡単な説明】
【００８８】
【図１】開発者、サーバ、ホスト、および、１つ以上のレンダラを含む、例示的なシステムを示す図である。
【図２】レンダリングデバイスがグラフィカルユーザーインターフェイスのための命令をホストデバイスから受信するための、同期通信プロトコルのためのタイムラインを示す図である。
【図３】レンダリングデバイスがグラフィカルユーザーインターフェイスのための命令をホストデバイスから受信するための、非同期通信プロトコルのためのタイムラインを示す図である。
【図４】レンダリングデバイスがグラフィカルユーザーインターフェイスのための命令をホストデバイスから受信するための、例示的な非同期通信プロトコルのためのタイムラインを示す図である。
【図５】通信が例示的なプロトコルに従って発生することができる、ホストコンピュータおよびレンダリングデバイスのための様々なコンポーネントを含む例示的なシステムを示す図である。
【図６】本明細書で説明する様々な例示的技術を実施するために使用することができる、例示的コンピュータ環境を例示する図である。
【符号の説明】
【００８９】
６４１  ハードディスクドライブ
６５１  磁気ディスクドライブ
６５２  磁気ディスク
６５５  光ディスクドライブ
６５６  光ディスク
６６１  ポインティングデバイス
６８０  リモートコンピュータ
６９１  モニタ
【図１】
2006313536.tif 000003
【図２】
2006313536.tif 000004
【図３】
2006313536.tif 000005
【図４】
2006313536.tif 000006
【図５】
2006313536.tif 000007
【図６】
2006313536.tif 000008