JP2009505170A - 対話式メディア環境での複数アプリケーションのレンダリングおよび合成 - Google Patents

Abstract

対話式メディア環境（１２５０）において、０個以上のスクリプト構成要素および０個以上のマークアップ構成要素をそれぞれ有するアプリケーション自体がＺ順序を有する視覚的要素として処理されるモデルが提供される。資源効率の良いレンダリング順序が提供され、対話式メディア環境（１２５０）内でフォーカスを有するアプリケーションが（ユーザイベントの受信によって）最初にレンダリングされる。残りのアプリケーションが、トップダウン順に、すなわち逆Ｚ順序（１３６２）でレンダリングされる。それぞれのアプリケーションに関連する１つまたは複数のグラフィックスバッファ（１５２８）に描画することによってレンダリングが実施される。アプリケーションに関するフレームが、ボトムアップに、Ｚ順序（１３５２）でグラフィックスバッファ（１５２８）から合成され、正しい外観を有する表示が得られる。
【選択図】図１３

Description

本願は、参照により本明細書に組み込まれる２００５年７月１日出願の仮出願第６０／６９５９４４号の特典を主張するものである。

記載の構成、システム、および方法は一般に、対話式メディアに関し、より詳細には、対話式メディア環境での複数のアプリケーションのレンダリングおよび合成に関する。

対話式メディア環境は通常、環境内で動作するアプリケーションにとって利用可能な、利用可能処理能力、メモリ、および他の資源に関して制約された資源である。対話式メディアの１つの一般的な例は、ＤＶＤ（デジタル・バーサタイル・ディスク）上に符号化されたビデオであり、そこでは、ユーザはグラフィカルメニューまたは他の制御と対話して、特定のビデオコンテンツまでナビゲートし、またはＤＶＤ内にオーサリングされた特別な機能を起動することができる。

典型的な対話式メディア環境では、グラフィックスやメニューなどの視覚的要素に、ディスプレイ画面上の要素に関する視覚的順序を提供する「Ｚ順序」が与えられる。Ｚ順序は、ディスプレイ画面から外向きに延びる仮想ｚ軸に沿って視覚的要素が互いの上部にどのように積まれるように見えるかを制御する。低いＺ順序を有する視覚的要素は、ディスプレイの下部にある（閲覧者からさらに離れている）ように見え、高いＺ順序を有する視覚的要素は、低いＺ順序の要素の上部にある（したがって閲覧者に対して近くにある）ように見える。

一般に、視覚的要素を表示のためにレンダリングするとき、低いＺ順序の要素がまず描画され、その後に、高いＺ順序の要素が続く。次いで、高いＺ順序の視覚的要素が上に描画され、低いＺ順序の要素の部分またはすべてを遮ることがある。このようにして、表示が、適切な重なりおよび相対的順序を有するスタック中の視覚的要素と共に正しく出現する。しかし、そのような方法は、強制的に資源を最下部の視覚的要素に集中させ（それが最初に描画されるため）、このことは非効率である可能性がある。完全に描画されたシーンで低いＺ順序の視覚的要素が結局は高いＺ順序の要素で遮られるときであっても、そのような低いＺ順序の要素が描画されることで処理能力が浪費される。そのような非効率性は、システム資源に過度の要求を課し、それにより、ビデオ再生での破壊や、環境内のビデオとグラフィックスとの同期での破壊などの望ましくないプレーヤの挙動が生じる。

対話式メディア環境において、０個以上のスクリプト構成要素および０個以上のマークアップファイルをそれぞれ有するアプリケーション自体がＺ順序を有する視覚的要素として処理されるアプリケーションモデルが提供される。対話式メディア環境でフォーカスを有するアプリケーションが（そのユーザイベントの受信によって）最初にレンダリングされるというレンダリング順序が使用される。次いで、残りのアプリケーションが、トップダウン順に、すなわち逆Ｚ順序でレンダリングされる。それぞれのアプリケーションに関連する１つまたは複数のグラフィックスバッファに描画することによってレンダリングが実施される。アプリケーションに関するフレームが、ボトムアップに、Ｚ順序でグラフィックスバッファから合成され、正しい外観を有する表示が得られる。

様々な例示的実施例では、プレイバックシステム内のナビゲーションマネージャが、プレイバックシステム上で動作するアプリケーションに関するＺ順序を維持する。プレゼンテーションエンジンは、アプリケーションのマークアップ内のキャンバスオブジェクトにアプリケーションを描画し、それが、アプリケーションごとにそれぞれのグラフィックスバッファに逆Ｚ順序でレンダリングされる。グラフィックスレンダリングエンジンは、ペインタのアルゴリズムを使用して、グラフィックスバッファからのフレームをアプリケーションごとにＺ順序で合成する。アプリケーションは、アプリケーションの上に積み重ねられた（すなわち、高いＺ順序を有する）アプリケーションを貫く穴を開ける方法を起動して、アプリケーションの視覚的要素をスタックの下部から視覚的に引き上げ、またはディスプレイの下側に要素を押し下げることもできる。

有利には、アプリケーションをグラフィックスバッファに逆Ｚ順序でレンダリングし、その後に続いてディスプレイをＺ順序で合成することは、プロセッササイクルおよびメモリを含むハードウェア資源が一般に限定される環境で、資源効率の良いモデルを提供する。より自然な優先順位が、フォーカスされたアプリケーションおよび高いＺ順序のアプリケーションに与えられ、その結果、結局は上に描画されて遮られる可能性のある低いＺ順序の視覚的要素の描画に費される資源が少なくなる。

図１を参照すると、対話式メディア環境で使用されるアプリケーション１１０を構成する要素の例示的ブロック図が示されている。アプリケーションは通常、ユーザと、リモートコントロールなどのユーザインターフェースを介して結合されたディスプレイ装置（テレビジョンやモニタなど）上にグラフィックスおよびビデオをレンダリングする対話式メディアプレーヤとの間の対話を可能にするように対話式メディア環境で使用される。より具体的には、アプリケーションは、環境内の、ビデオプレイバックを含む様々なコンテンツオブジェクトのプレゼンテーション挙動を制御する。ビデオを介するメニューや対話ボタンなどのグラフィックオブジェクトのプレゼンテーションもアプリケーションを使用して実現される。アプリケーションはさらに、環境内のオーディオプレイバックおよびサウンドを管理および制御する。ほとんどの対話式メディア設定では複数のアプリケーションが一般に同時に動作していることになることが企図される。しかし、複数のアプリケーションが同時に実行されるという要件はなく、特定の設定でアプリケーションを分割または集約するという決定は、対話式メディア作者の設計の好みである。特定の設定の要件に応じて、アプリケーションをアプリケーションページに論理的に細分することもできる。

アプリケーション１１０は、０個以上のスクリプトファイル１１７および１１９を含むスクリプトホスト１１５と、文書オブジェクトモデル（ＤＯＭ）を生成するのに使用される０個以上のマークアップ文書１２０とを含む。マークアップ文書１２０は、例えばグラフィックオブジェクトのコンテンツ、スタイル、タイミング、およびレイアウトに関する情報を含む。したがって、マークアップコンテキストは、一般には対話式メディア環境内のグラフィックス平面上にグラフィックスを提供するために使用される。

この例示的実施例では、マークアップ文書は、Ｗ３Ｃ規格に従うＸＭＬ文書ファイルである。図１に示されるように、マークアップの＜ｈｅａｄ＞セクション内の＜ｉｎｃｌｕｄｅ＞要素を使用して、複数の物理的ＸＭＬファイルにアクセスすることができる。ある設定では、アプリケーションが一度に複数のアクティブなマークアップを有さないことが好ましいことがある。しかし、アプリケーションは、そのマークアップ１２０を、マークアップ内の＜ｌｉｎｋ＞要素を使用することによって切り換えることができる。あるいは、アプリケーションは、アプリケーションが現アプリケーション内の機能オブジェクトへのアクセスを得ることを可能にするアプリケーションプログラミングインターフェース（ＡＰＩ）を使用することによってそのマークアップ１２０を切り換えることもできる。ＡＰＩを介するｌｏａｄＭａｒｋｕｐ（）呼出しを使用して、アプリケーションは、ＡＰＩを介して新しいマークアップのＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を渡すことによってマークアップファイル１２０を切り換えることができる。

アプリケーションが新しいマークアップにアクセスする場合、ＡＰＩ呼出しは、アプリケーション内の現イベントハンドラがその現タスクの実行を終了した後にのみ効果を現す。保留中の任意の現マークアップ関連イベントハンドラもキャンセルされる。新しいマークアップがロードされると、新しいマークアップはそうしたイベントハンドラを無効にするからである。

この例示的実施例では、スクリプトホスト１１５は、対話式メディア体験を実装するためにマークアップ１２０と共に使用されるスクリプトファイル１１７および１１９を含む。例えば、Ｅｃｍａ ＩｎｔｅｒｎａｔｉｏｎａｌによってＥＣＭＡ−２６２仕様で定義されたＥＣＭＡＳｃｒｉｐｔを使用してスクリプトファイル１１７および１１９を実装することができる。ＥＣＭＡ−２６２に含まれる一般的なスクリプティングプログラミング言語は、ＪａｖａＳｃｒｉｐｔおよびＪＳｃｒｉｐｔを含む。ある設定では、ＥＣＭＡＳｃｒｉｐｔ２６２のサブセット、具体的にはＥＣＭＡ−３２７をホスト環境および１組の共通ＡＰＩと共に使用してスクリプト１１７および１１９を実装することが望ましいことがある。ほとんどの設定でのスクリプトコンテキストは、ユーザからの対話制御問題、ならびにマークアップ１２０単独を使用して容易または効率的に実装されないシステムイベント、グラフィックス制御、ビデオプレイバック、資源管理（例えば、キャッシングまたは永続的ストア資源の使用）、および他の問題に対処するのに使用される。

アプリケーション１１０に対するＡＰＩおよび資源の可用性が、図１の参照番号１２５で示されている。資源は、例えば、オーディオファイルおよびビデオファイル、フォント、ピクチャ、イメージ（例えば、ＰＮＧ、ＪＰＥＧ、ＧＩＦ、ＢＭＰ、ＴＩＦＦなどを含む共通ファイルフォーマットのもの）、および特定の設定の状況に従ってアプリケーションによって必要とされる可能性のある他の資源を含む。

各アプリケーション１１０は、それ自体のスクリプトホスト１１５を維持し、スクリプトホスト１１５は、スクリプトの変数、関数、および他の状態に関するコンテキストを維持する。ほとんどの設定では、例えばすべてのアプリケーションの間で共有されるオブジェクトを使用することによってアプリケーションがアプリケーション間可視性を可能にするように具体的にセットアップされない限り、あるアプリケーションでの変数および関数は、別のアプリケーションからは見えない。例えば、この例示的実施例では、対話式メディアプレーヤオブジェクトは、すべてのアプリケーションにわたって共有される単一のインスタンスを有する。したがって、任意選択で、例えばＣ＋＋オブジェクトを使用して特別なオブジェクトをスクリプトホスト１１５内に配置し、シングルトン（すなわち限定されたインスタンス化を有するオブジェクト）を実装することができ、特別なオブジェクトはすべて、例えばプレーヤの、同一の内部関数を参照する。この任意選択の態様は、対話式メディアスクリプト作者が共通オブジェクトをシングルトンとして論理的に処理することを可能にすると共に、スクリプトホスト１１５が単一のスクリプトホストにオブジェクトを公開するのに必要な機能を実装することを依然として可能にする。

次に図２を参照すると、複数のマークアップ文書およびスクリプトの間の関係を示す例示的な図が与えられている。アプリケーションマニフェスト２３０はアプリケーションと対話し、アプリケーションは、上記で指摘したように、図示される資源１２５、スクリプト２０５、ならびにマークアップ文書２５１、２６０、および２７５によって一般に定義される。各アプリケーションは通常、ほとんどの設定で単一のアプリケーションマニフェストファイルを使用するが、アプリケーションマニフェストは、アプリケーションの実行時状態の部分ではない。この例示的実施例では、アプリケーションマニフェスト２３０がＸＭＬ文書ファイルとして符号化される。

アプリケーションマニフェスト２３０は、アプリケーション１１０（図１）で使用される初期マークアップファイル２５１、ならびにスクリプトホスト１１５（図１）に含まれるスクリプトファイル（図２の参照番号２０５を有する矩形によって集合的に示される）を記述する。この例示的実施例のように、アプリケーションマニフェスト２３０が複数のスクリプトを列挙する場合、すべてのスクリプトが、対話式メディアプレーヤ内のスクリプト処理エンジンにロードされる。したがって、複数のスクリプトファイルが処理され、複数のスクリプトファイルは、スクリプト作者がスクリプトファイルのすべてをアプリケーションマニフェスト２３０に列挙される順序で単一の大きいファイルとして連結したかのように振る舞う。

図２に示されるように、アプリケーションマニフェスト２３０は資源１２５を参照する。対話式メディア環境内のアプリケーションにとって利用可能な資源は、アプリケーションマニフェスト２３０で参照される資源１２５を起源とする有向グラフを形成する。アプリケーションごとのグラフの可能な範囲が、アプリケーションマニフェスト２３０によって禁止される。

図２は、対話式メディア環境で動作するアプリケーションを示す。上記で指摘したように、アプリケーションが一度に有することのできるアクティブなマークアップは１つだけであり、アプリケーションコンテンツがアプリケーションによって別々に保たれる。マークアップページ２５１、２６０、および２７５の間の矢印で示されるように、スクリプト２０５を介して、アプリケーションは、マークアップページ２５１から２６０に進むことができ、次いで、後でページ２６０から２７５に進むことができる。

対話式メディア環境内のアプリケーションによるコンテキスト実行の進行がプレイリスト２９０によって誘導され、プレイリスト２９０はとりわけ、プレーヤによってディスプレイ装置上にレンダリングされるプレゼンテーションオブジェクトを含む環境内のオブジェクト間の関係を記述する。こうしたプレゼンテーションオブジェクトは通常、アプリケーションによって再現されるビデオ（以下でより詳細に説明するように、ビデオは複数のストリームを含むことができる）およびグラフィックスを含む。

プレイリスト２９０はさらに、アプリケーションによる資源の消費を効率的に割り振って制御するために、対話式メディア環境にわたる資源を単一の管理エンティティとして管理する。アプリケーションマニフェスト２３０と同じく、有利には、ほとんどの設定ではプレイリスト２９０をＸＭＬ文書ファイルとして埋め込むことができる。

ある設定で図２のマークアップページを使用して、（図１のスクリプトファイル１１７および１１９によって作成された）実行コンテキストにイベントをファイアすることができる。次いで、実行コンテキストは、現アプリケーションマークアップによって作成されたＤＯＭを操作する。対話式メディア環境でマークアップが使用されて、環境内のグラフィカルオブジェクトのスタイル、コンテンツ、タイミング、およびレイアウト（図２の要素２５３、２６２、および２７７で表されるように）が指定されるので、スクリプトとマークアップの組合せは、包括的な１組の機能の作成を可能にする。

図３は、対話式コンテンツプロセッサ（ＩＣＰ）３３５、ビデオコンテンツプロセッサ（ＶＣＰ）３１０、およびミキサ３３９を含む第１の例示的な対話式メディアプレーヤ３０５のブロック図である。図３に提示される構成は、アプリケーション状態管理に関係する例示的対話式メディアプレーヤ３０５の特徴および機能を記述する論理モデルを提供することに留意されたい。したがって、対話式メディアプレーヤの実際の実装は、様々な構造的形態を使用することができると共に、依然として本明細書に記載の通りに動作し、アプリケーション状態管理の利点を達成する。対話式メディアプレーヤ３０５は通常、スタンドアロンコンシューマエレクトロニクス装置などの専用ハードウェアとして実現され、あるいは、パーソナルコンピュータで見られるような汎用プロセッサと共にコンピュータ可読媒体を使用するソフトウェア実装を使用して実現される。

ＶＣＰ３１０は、ＤＶＤドライブや高精細度ＤＶＤ（ＨＤ−ＤＶＤ）ドライブなどのローカル光学式ドライブ、ローカルメモリ、またはネットワークを介するリモートブロードバンドソースを含む複数のソースから受信することのできる１つまたは複数のメディアストリームを管理する。この例示的実施例では、ＶＣＰ３１０は、図３の要素３０４および３０６で示される１つまたは複数のメディアプロセッサ１、２．．．Ｎを含む。メディアプロセッサ３０４および３０６は、通常はオーディオおよびビデオを含む、受け取ったメディアストリームを処理し、対応するイメージおよびサウンドを復号化およびレンダリングし、それがライン３２５上にオーディオ／ビデオストリームとして出力される。オーディオ／ビデオストリーム３２５は、例えば「ピクチャ・イン・ピクチャ」型構成を使用して複数の別々のビデオウィンドウをレンダリングするために、複数のビデオ要素を表すことができる。

メディアプロセッサ３０４および３０６はそれぞれ、メディアソースインターフェース、デマルチプレクサ、およびデコーダを備える。任意選択で、メディアプロセッサ３０４および３０６は、暗号解読機能も含むことができる。オーディオ／ビデオストリームを受信および表示するためにディスプレイ装置３５５が結合される。

受信した各メディアが関連する「Ｍｅｄｉａ Ｔｉｍｅ」を有するようにメディアクロック３１２が使用される。対話式メディアプレーヤ３０５上でビデオストリームが休止するとき、メディアクロック３１２も休止する。ユーザによってビデオストリームがリアルタイムよりも高速または低速に進むように設定されたとき（例えば、ビデオが早送りモード、巻戻しモード、またはスローモーションモードに置かれたとき。こうしたモードのいずれかを使用することは「トリックプレイ」と呼ばれる）、メディアクロック３１２は、それに応じて加速または減速する。したがって、Ｍｅｄｉａ Ｔｉｍｅは、メディアクロックとメディアプロセッサ３０４および３０６のオペレーションから導出される。Ｍｅｄｉａ Ｔｉｍｅは、ライン３１５を介してＩＣＰ３３５内のプレイリストマネージャ３３７に渡される。Ｍｅｄｉａ Ｔｉｍｅを含む対話式メディア環境内の時間は通常、「チック」単位でカウントされる。

ＩＣＰ３３５は、すべてのアプリケーション関連処理を実施し、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せとして実現することのできるいくつかの構成要素からＩＣＰ３３５を構成することができる。ＩＣＰ３３５の構成要素は、例えばマークアップエンジン、スクリプト言語インタプリタ、およびＸＭＬ構文解析構成要素（図示せず）を含む。ＩＣＰ３３５は、オーディオ／ビデオストリーム３２５と同期されるグラフィックスストリームをライン３２１上に出力する。ミキサ３３９は、ライン３２１上のグラフィックスストリームとライン３２５上のオーディオ／ビデオストリームを取り、その結果、グラフィックスがビデオストリームを介してグラフィックス層でレンダリングされ、ユーザに対する対話式メディアセッションが実装される。

ほとんどの設定では、ＩＣＰ３３５は、ビデオストリームとフレームごとに同期されるグラフィックスを出力する。しかし、例えば時間（以下で定義されるＴｉｔｌｅ ＴｉｍｅおよびＭｅｄｉａ ｔｉｍｅを含む）、ビデオ中のコンテンツ、またはストリーム中の特定の地点を指示またはマークするのに使用される、ビデオに埋め込まれた他のメタデータを含む他の基盤を使用して、そのような同期を実施することができる。

ＩＣＰ３３５は、プレイリストマネージャ３３７およびタスクマネージャ３３０を含む。プレイリストマネージャ３３７は、環境内のプレゼンテーションオブジェクトを制御する任を担う。こうしたオブジェクトは、プレーヤ３０５上のビデオプレイバック、および対話式グラフィックスを生成するために実行中のアプリケーションを含む。プレイリストマネージャ３３７は、上記の図２に伴う本文で説明したプレイリスト２９０を管理する。

プレイリストマネージャ３３７はまた、メディアストリーム中のコンテンツの各部分に関連する「Ｔｉｔｌｅ Ｔｉｍｅ」も計算する。タイトルは、ＤＶＤ作者によって通常は定義される開始時間および終了時間を有する、ビデオおよびオーディオコンテンツの固有のシーケンスである。しかし、そのような作者が何をタイトルと定義するかは任意でよい。したがって、ビデオで認識される特定のコンテンツは、１つのタイトルの一部でよく、完全なタイトルでよく、または複数のタイトルにまたがるものでよい。

タイトルの一例は、米国におけるアナログフォーマットとデジタルフォーマットの両方のすべての事前記録されたビデオに先行する著作権警告である。ＤＶＤ上の注目のアトラクション（例えばメインムービー）は別の例であり、多くの場合、最長のタイトルである。ある設定では、ムービー中の個々のチャプタが、ＤＶＤ作者によって別々のタイトルとして指定されることがある。すべてのそのようなタイトルでは、Ｔｉｔｌｅ Ｔｉｍｅは、所与のタイトルがメディアクロック３１２上で示されるように再生を開始してから経過した時間と定義される。

プレゼンテーションクロック３６０は、プレイリストマネージャとライン３６２で結合される。プレゼンテーションクロック３６０は、現実世界クロックと同じペースで時刻が変化するクロックである（すなわち、プレゼンテーションクロック３６０が１秒進むのに、リアルタイムの１秒がかかる）。メディアクロック３１２とは対照的に、プレゼンテーションクロック３６０は決して停止せず、加速または減速することができない。プレゼンテーションクロック３６０からのプレゼンテーション時間はタスクマネージャ３３０に渡され、タスクマネージャ３３０は、それを使用して「Ａｐｐｌｉｃａｔｉｏｎ Ｔｉｍｅ」およびアプリケーション「Ｐａｇｅ Ｔｉｍｅ」を計算する。

Ａｐｐｌｉｃａｔｉｏｎ Ｔｉｍｅは、アプリケーションが開始してから（または以下でより詳細に説明される「Ａｃｔｉｖｅ」状態に入ってから）経過した時間である。複数のアプリケーションが実行時であるとき、各アプリケーションは、それ自体のＡｐｐｌｉｃａｔｉｏｎ Ｔｉｍｅの概念を有する。各アプリケーションについて、アプリケーションが環境内で開始したときにＡｐｐｌｉｃａｔｉｏｎ Ｔｉｍｅは常に０で開始する。

例えば、アプリケーションＡｐｐ１が２０任意時間単位のプレゼンテーション時間（これはＡｐｐ１について０時間単位である）で開始し、アプリケーションＡｐｐ２が２５時間単位のプレゼンテーション時間（これはＡｐｐ２について０時間単位である）で開始する場合、３５時間単位のプレゼンテーション時間で、Ａｐｐ１のＡｐｐｌｉｃａｔｉｏｎ Ｔｉｍｅは１５時間単位であり、Ａｐｐ２のＡｐｐｌｉｃａｔｉｏｎ Ｔｉｍｅは１０時間単位である。論理的にページに細分されるアプリケーションについて、Ｐａｇｅ Ｔｉｍｅは、アプリケーションのページがロードされてから経過した時間である。

図４は、ＩＣＰ４３５、ＶＣＰ４１０、およびミキサ４３９を含む第２の例示的メディアプレーヤ４０５のブロック図である。対話式メディアプレーヤ４０５は、図３に示される対話式メディアプレーヤ３０５と形態および機能の点で類似している。しかし、注目すべきことに、ＶＣＰ４３５は、別々のフィード４２５および４２７をミキサ４３９に提供するように構成されるメディアプロセッサ１、２．．．Ｎ（図４の要素４０４および４０６で示される）を含む。そのような構成は、個々のメディアストリームの操作が混合の前に実施される一部の設定で望ましいことがある。例えば、メディアストリーム中のビデオのパニングおよびズーミングなどのイメージ処理／選択技法を、図４の参照番号４２５および４２７によって表されるＮ個の別々のフィードのうちの１つまたは複数に対して個々に実施することができる。

オーディオ／ビデオフィード４２５および４２７は、ＩＣＰ４３５からの同期グラフィックスストリームとともに、ミキサ４３９で混合され、ライン４４１上でディスプレイ装置４５５に対して出力される。ＩＣＰ４３５（プレイリストマネージャ４３７およびタスクマネージャ４３０を備える）、ＶＣＰ４１０内のメディアクロック４１２、およびプレゼンテーションクロック４６０を含む図４の他の要素は、図３に示し、付随する本文で説明した、それに対応するものと同様に構成され、機能する。

図５は、参照番号５１０、５１５、および５１８でそれぞれ示される複数のイベントキュー１、２、．．．Ｎと、単一のアプリケーションスレッド５２３とを有する例示的構成５００のブロック図である。この例示的構成では、ＩＣＰ（図４のＩＣＰ４３５など）上で動作するすべてのアプリケーションが単一スレッド化され、アプリケーションスレッド５２３は、そのような目的専用である。しかし、ＩＣＰ４３５は、必ずしもそれ自体単一スレッド化される必要はない。代替実装では、ＩＣＰ４３５は、他のスレッド、例えば資源をキャッシュにプリフェッチングするために使用することができる。

イベントキュー５１０、５１５、および５１８のそれぞれは、そのヘッドエンド（図５の右側に位置する）からアプリケーションスレッド５２３にフィードされるように構成される。参照番号５２７、５３０、および５３２でそれぞれ示される複数のアプリケーションＡｐｐ１、Ａｐｐ２．．．ＡｐｐＮが、代表的に参照番号５３５で示される作業項目をキューのテールエンド（図５の左側）からキュー５１０、５１５、および５１８にポストするように構成される。

アプリケーションイベントは、アプリケーションによってファイアされるイベントである。これらは、スクリプト（例えば図１のスクリプトホスト１１５）またはマークアップ（例えば図１のマークアップ１２０）によってファイアされるイベントを含む。ほとんどのシナリオでは、アプリケーションイベントは、スクリプトのみによって処理される。しかし、アプリケーション５２７、５３０、および５３２は、スクリプトまたはマークアップ機能を直接的に起動せず、その代わりに、すべてのそのような機能は、アプリケーションのそれぞれのイベントキューに作業項目の形でポストされ、アプリケーションスレッド５２３が作業項目を処理するときに起動される。

代替構成では、アプリケーション以外のソースからのイベントもイベントキューを使用してスケジューリングされる。例えば、ユーザイベントは、リモートコントロールとのユーザ対話によってファイアされる。システムイベントは、図４に示し、付随する本文で説明したプレーヤ４０５などの対話式メディアプレーヤによってファイアされるイベントである。

イベントキュー５１０、５１５、および５１８内の各作業項目は、図５に示されるフィールドを含む。こうしたフィールドは、アプリケーション関連フィールド５４０、方法フィールド５４５、ＢｅｇｉｎＴｉｍｅフィールド５５２、ＥｎｄＴｉｍｅフィールド５５５、および任意選択のＣｌｏｃｋＳｅｌｅｃｔｏｒフィールド５５８を含む。

アプリケーション関連フィールド５４０は、作業項目が適用される特定のアプリケーションを示す。方法フィールド５４５は、作業項目がアプリケーションスレッド５２３によって処理されるときに起動される方法を含む。方法フィールド５４５は、方法についての引数も含む。

ＢｅｇｉｎＴｉｍｅフィールド５５２およびＥｎｄＴｉｍｅフィールド５５５は、それぞれ作業項目の方法が開始するとき、および終了するときを示すのに使用される。この例示的実施例では、時間がＡｐｐｌｉｃａｔｉｏｎ Ｔｉｍｅを使用して表される。しかし、代替実施例では、ＢｅｇｉｎＴｉｍｅフィールド５５２およびＥｎｄＴｉｍｅフィールド５５５は、特定の設定の要件に応じて別法としてＴｉｔｌｅ Ｔｉｍｅ、Ａｐｐｌｉｃａｔｉｏｎ Ｔｉｍｅ、またはＰａｇｅ Ｔｉｍｅで表すことのできる値を含む。そのような場合、作業項目で使用される特定の時間フレームが、ＣｌｏｃｋＳｅｌｅｃｔｏｒフィールド５５８で示される。使用される時間フレームの如何に関わらず、作業項目に関するＢｅｇｉｎＴｉｍｅは、常にＥｎｄＴｉｍｅ未満でなければならない。

図６は、その中に含まれる作業項目の順序を示すイベントキュー５１５のブロック図である。図が見やすいように、図６では他のイベントキュー５１０および５１８（図５）を示していない。しかし、以下で説明する順序付け方法は、そのような他のイベントキューにも等しく適用可能である。

イベントキュー５１５は、参照番号６０５、６１０、６１５、および６２０によってそれぞれ示される作業項目１、２、３、．．．Ｎを含む。各作業項目は、図５に示し、付随する本文で説明したフィールドを含む。

作業項目６０５は、図６のブロック６３０で示されるように、ＢｅｇｍＴｉｍｅ_１と、関連するイベントキュー５１５への挿入時間ｔ_１とを含む。同様に、作業項目６１０は、ブロック６３５で示されるように、ＢｅｇｉｎＴｉｍｅ_２と、関連するイベントキュー５１５への挿入時間ｔ_２とを含む。作業項目６１５は、ブロック６４０で示されるように、ＢｅｇｉｎＴｉｍｅ_３と、関連するイベントキュー５１５への挿入時間ｔ_３とを含む。また、作業項目６２０は、ブロック６４５で示されるように、ＢｅｇｉｎＴｉｍｅ_Ｎと、関連するイベントキュー５１５への挿入時間ｔ_Ｎとを含む。

この例示的実施例では、作業項目は、イベントキュー５１５内で、まずＢｅｇｉｎＴｉｍｅで順序付けられ、次いで、作業項目がイベントキューに挿入された時間によって順序付けられる。そのような順序付けの結果、アプリケーションスレッド５２３は、ＢｅｇｉｎＴｉｍｅの順序で作業項目を処理し、または２つの作業項目が同一の開始時間を有するときは、ＦＩＦＯ（先入れ、先出し）の順序で処理する。

したがって、作業項目６２０がイベントキュー５１５の先頭であるので、ＢｅｇｉｎＴｉｍｅ_Ｎ＜ＢｅｇｉｎＴｉｍｅ_３であり、またはＢｅｇｉｎＴｉｍｅ_Ｎ＝ＢｅｇｉｎＴｉｍｅ_３である場合、ｔ_Ｎ＜ｔ_３である（すなわち、作業項目６２０は、作業項目６１５の前にイベントキュー５１５に挿入された）ことが暗示される。作業項目６０５、６１０、および６１５についてこれと同じ推論に従うと、
ＢｅｇｉｎＴｉｍｅ_３＜ＢｅｇｉｎＴｉｍｅ_２；
またはＢｅｇｉｎＴｉｍｅ_３＝ＢｅｇｉｎＴｉｍｅ_２である場合、ｔ_３＜ｔ_２、および
ＢｅｇｉｎＴｉｍｅ_２＜ＢｅｇｉｎＴｉｍｅ_１；
またはＢｅｇｉｎＴｉｍｅ_２＝ＢｅｇｉｎＴｉｍｅ_１である場合、ｔ_２＜ｔ_１
イベントキュー内の作業項目の順序付けは、２つの代替方法を使用して実施される。作業項目がイベントキューに挿入されたとき、または作業項目が処理の前にイベントキューから抽出されたときに作業項目を順序付けることができる。イベントキューからの作業項目の処理がＢｅｇｉｎＴｉｍｅとその後に続くキュー挿入時間によって実施される限り、どちらも構成も等しく使用可能である。

図７は、アプリケーションスレッド５２３が２つの作業項目７０５および７１５をイベントキュー５１５のテールエンドに自動的に挿入する例示的構成のブロック図である。図が見やすいように、図７では他のイベントキュー５１０および５１８（図５）を示していない。しかし、以下で説明するアプリケーションスレッドによる作業項目の自動挿入が、そのような他のイベントキューに等しく適用可能である。図示するように、自動的に導入された作業項目７０５および７１５が、イベントキュー５１５内の作業項目６０５および６２０の後に続く。例示的実施例では、アプリケーションが開始し、各チック後に作業項目が再スケジューリングされるときに、２つの作業項目の自動挿入が実施される。

作業項目７０５は、ブロック７３０で示されるように、アプリケーションＡｐｐ２ ５３０内のページに関するタイミングを処理するためのマークアップエンジン（例えば図４のＩＣＰ４３５に配設されたマークアップエンジン）への呼出しを含む。ブロック７３５では、作業項目７１５は、アプリケーションＡｐｐ２のマークアップをリフローして処理済みのイベントを反映し、次いでディスプレイ装置（例えば図４のディスプレイ４５５）上にマークアップをレンダリングするためのマークアップへの呼出しを含む。作業項目７０５および７１５は常に、アプリケーションスレッド５２３によってアプリケーションのチックで処理される最後の作業項目である。

図８は、対話式メディア環境で生じるイベントに関連する作業項目を待ち行列化する方法の流れ図である。単一アプリケーションスレッドでのイベント待ち行列化の例示的実施例では、方法が、図４〜７に示され、付随する本文で説明される構成によって実施される。図示される方法は通常、各チックについて反復的に実施される。

プロセスはブロック８０５で開始する。ブロック８１０では、アプリケーションスレッド５２３（図５〜７）が作業項目を自由に処理できるとき、アプリケーションスレッド５２３はまず、ＢｅｇｉｎＴｉｍｅが現在または前のチックに対応するイベントキュー５１５内の各作業項目をマークする。アプリケーションスレッド５２３は、マークされた作業項目のみを処理する。したがって、イベントキュー５１５内の作業項目は、そのＢｅｇｉｎＴｉｍｅより前には決して処理されない。

判定ブロック８１６では、マークされた作業項目のＥｎｄＴｉｍｅが既に経過している場合、ブロック８１９で示されるように、作業項目がイベントキュー５１５から除かれる。そのような場合、その作業項目に関する処理は行われない。アプリケーションＡｐｐ２ ５３０がそのページをリロードした場合、アプリケーションのページクロックが０にリセットされ、アプリケーションのページクロックに基づくすべての未処理の（すなわち待ち行列化された）作業項目が、あたかもそれらのＥｎｄＴｉｍｅに達したかのようにイベントキューから除かれる。

判定ブロック８１６で、マークされた作業項目のＥｎｄＴｉｍｅが経過していない場合、制御がブロック８２２に渡され、アプリケーションスレッド５２３が作業項目を処理する。上記で図６に付随する説明で指摘したように、各作業項目は、イベントキュー５１５から、まずＢｅｇｉｎＴｉｍｅによる順序で、その後に続いて、各作業項目がイベントキュー５１５に挿入された時間による順序で処理される。

反復的イベントと単発（すなわち、単一オカレンス、非反復的）イベントはどちらも、図８に示される方法を使用して管理される。反復的イベントは、関連する作業項目が次にスケジューリングされたＢｅｇｉｎＴｉｍｅに等しいＥｎｄＴｉｍｅを有する周期的イベントを含むことができる。すなわち、各周期的イベントは、イベントの周期に等しい持続時間を有する。

周期的イベントは通常、タイマイベントやアプリケーション描画イベントのようなイベントを含む。例えば、アプリケーションのスクリプト（例えば図１のスクリプトホスト１１５）が１０秒ごとにコールバックするタイマを作成する場合、現在時刻に１０秒を加えたものに等しいＢｅｇｉｎＴｉｍｅを有するタイマ作業項目をイベントキュー５１５に追加する。ＥｎｄＴｉｍｅはＢｅｇｉｎＴｉｍｅに１０秒を加えた値に設定される。イベントキュー５１５からタイマ作業項目が実行されると、別の１０秒を追加することによってＢｅｇｉｎＴｉｍｅおよびＥｎｄＴｉｍｅが調節され、作業項目が、イベントキュー５１５内の新しいＢｅｇｉｎＴｉｍｅに基づく適切な位置に再挿入される。

周期的イベントは、可能なときはいつでも起動される。しかし、周期的イベントの関連する作業項目内のＥｎｄＴｉｍｅが満了する前に周期的イベントをアプリケーションスレッド５２３で処理することができない場合、その特定の呼出しが除かれ、次の呼出しが新しい作業項目でスケジューリングされる。したがって、周期的イベントは作業項目タイムアウトの対象となる。

有利には、イベント待ち行列化方法は、パラメータをタイマイベントに渡して、イベントを呼び出すべき時間を示すことを可能にする。このパラメータは、関連する作業項目内のＢｅｇｉｎＴｉｍｅと同じでなければならない。上記で指摘したように、周期的タイマイベントに関連するスクリプトは、呼び出される時間に厳密に実行されないことがある。しかし、各作業項目が、方法に対する引数を指定する方法フィールド５４５（図５）を含むので、引数の値は、実際の時間ではなく、所期の呼出し時間を反映する。したがって、タイマイベントのハンドラは、処理中の時間（すなわちチック）を認識する。

単発イベントは、ＩＮＦＩＮＩＴＥのＥｎｄＴｉｍｅを有する対応する作業項目を有する。したがって、単発イベントは、決してイベントキュー５１５から除かれることはない。例えば、単発イベントが入力イベントである場合、そのイベントのハンドラが、ＩＮＦＩＮＩＴＥのＥｎｄＴｉｍｅを有するイベントキュー５１５内の作業項目としてスケジューリングされる。

ブロック８２２で示されるように、コミットごとに処理が実施される。すなわち、アプリケーションスレッド５２３がイベントキュー５１５からの作業項目の処理を開始すると、アプリケーションスレッド５２３は処理を停止しない。例えば、長時間実行される可能性のあるスクリプトは、打ち切られず、スクリプトを除くためにスクリプトに例外注入されることもない。上記で指摘したように、そのような方式がスクリプトを処理する間にアプリケーションスレッドと提携する間、コミットされた作業項目の処理中に実行し続ける他のスレッドを含むようにＩＣＰ（例えば図４のＩＣＰ４３５）を構成することができる。

ブロック８３０では、マークされた作業項目の処理中に作成される任意の新しい作業項目が、マークされた作業項目の後に、そのＢｅｇｉｎＴｉｍｅの如何に関わらずイベントキュー５１５内に挿入される。作業項目をマークし、作業にコミットし、イベントキュー内のコミットした作業項目の後に新しい作業項目を挿入するプロセス（ブロック８１０、８２２、および８３０で示される）は、アプリケーションに何らかの目に見える進歩が常に与えられることを保証する。

図８のブロック８３５および８２８で示されるように、アプリケーションスレッドは、図７に示し、付随する本文で説明したチックごとに、２つの作業項目を各アプリケーションのイベントキューに自動的に挿入する。これらの作業項目は、アプリケーションごとのマークアップエンジンを呼び出してアプリケーションタイミングを評価し、次いでマークアップをリフローしてディスプレイ装置上にレンダリングする。上記で指摘したように、作業項目は、アプリケーション開始時に挿入され、各チック後に再スケジューリングされる。さらに、２つの作業項目は常に、アプリケーションのチックに関して処理すべき最後の２つであり、イベントキュー５１５から除くことのできる周期的イベントとして処理される。

図９は、ディスプレイ上の視覚的要素を機能および／またはソースごとに論理的にグループ化するために例示的グラフィカル合成モデルで使用されるグラフィックス平面９００のセットの図である。グラフィックス平面セット９００は、カーソル平面９０５、グラフィックス平面９１２、サブピクチャ平面９１８、サブビデオ平面９２２、およびメインビデオ平面９２５を含む。カーソル平面９０５は、グラフィックス平面セット９００の最上の平面（すなわち、最も近いとユーザ９３０に知覚される平面）であり、その平面で、ポインタのようなカーソルオブジェクトが表示される。残りの平面は、ディスプレイの上部から下部に配置され、図９の矢印９３５で示されるように、左から右に配置される。

グラフィックス平面セット９００中のすべての平面は、キャンバスと呼ばれる共通ｘｙ座標系を使用する。第３次元はｚ軸によって記述され、ｚ軸は、図９の参照番号９４０で示されるように、ディスプレイから外向きに投射される。対話式メディア環境で動作するアプリケーションは、特定の平面に属する。アプリケーションを明示的に、または任意に平面に割り当てることはできず、関連付けは、アプリケーションのタイプから暗黙的に行われる。例えば、サブタイトルアプリケーションはサブピクチャ平面９１８でレンダリングされ、他のほとんどのアプリケーションはグラフィックス平面９１２でレンダリングされる。

グラフィックス平面９１２は、グラフィックス平面セット９００の第２平面であり、以下で説明されるように、プレゼンテーションエンジンによって生成される。上記で指摘したように、対話式メディア環境内のグラフィックスやメニューなどの対話式コンテンツを生成するアプリケーションは通常、グラフィックス平面９１２にレンダリングされる。

サブピクチャ平面９１８は、グラフィックス平面セット９００の第３平面であり、通常は、それぞれのアプリケーションによって生成されたサブタイトルおよび／またはキャプションを表示するのに使用される。サブビデオ平面９２２は、グラフィックス平面セット９００中の第４平面であり、通常は、「ピクチャ・イン・ピクチャ」（ＰＩＰ）構成で２次ビデオディスプレイとして使用される。参照番号９４２で示されるようなＰＩＰウィンドウは多くの場合、メインビデオディスプレイよりも小さく、解像度が低い、アスペクト比が異なるなどの別の異なる特徴を有することができる。

メインビデオ平面９２５は、グラフィックス平面セット９００中の第５平面であり、平面のスタックの下部に配置される。メインビデオ平面９２５は通常、上記で図３に伴う説明で説明したように、ビデオタイトルを含む対話式メディア環境内のビデオコンテンツを表示するのに使用される。図９に示されるように、グラフィックス平面セット９００中のすべての平面が、以下で説明するようにグラフィックスレンダリングエンジンによって単一のディスプレイ９５０として混合および合成される。

図１０は、ＡｐｐＡと呼ばれる第１の例示的アプリケーション内の３つの視覚的要素のＺ順序を示す図である。アプリケーション内のＺ順序はアプリケーションのＺ順序とは異なることを強調しておく。すなわち、アプリケーションは、アプリケーション内のＺ順序を有する視覚的要素を生成し、ＩＣＰ（図４のＩＣＰ４３５など）上で実行中の複数のアプリケーションの間で、アプリケーション自体がＺ順序付けされる。

アプリケーションＡｐｐＡは、図示されるような積み重ねられた構成の、それぞれＺ順序０、１、および２を有する要素１０１０（十字）、要素１０２０（星）、および要素１０３０（矢印）を含む３つの視覚的要素を生成する。したがって、１組のＮ個の要素について、１組のＺ順序値は、スタック内の最低の要素に関する０で開始し、スタック内の最高の要素に関するＮ−１で終了する。要素１０１０、１０２０、および１０３０がディスプレイ１０４５上に描画される。図１０のウィンドウ１０５０は、ＡｐｐＡによって生成された視覚的要素のＺ順序を、ディスプレイ１０４５の「縁方向」から見たかのように示す。ディスプレイ１０４５およびウィンドウ１０５０は、ｘｙｚ座標１０５５で示されるような向きに互いに配置される。

図１１は、ＡｐｐＢと呼ばれる第２の例示的アプリケーション内の視覚的要素のＺ順序を示す図である。アプリケーションＡｐｐＢは、ディスプレイ１１４５上に積み重ねられた構成の、それぞれＺ順序０、１、および２を有する要素１１１０（三角形）、要素１０２０（卵形）、および要素１０３０（矩形）３つの視覚的要素を生成する。ウィンドウ１１５０は、ｘｙｚ座標１１５５で示されるディスプレイ１１４５の縁方向から見た、ＡｐｐＢによって生成された視覚的要素のＺ順序を示す。

図１２は、アプリケーションＡｐｐＡとＡｐｐＢの両方から生成される視覚的要素（集合的に参照番号１２１０で示される）を有する合成後のディスプレイ１２４５を示す図である。ウィンドウ１２５０は、ディスプレイ１２４５（ＸＹＺ座標１２５５で示されるように）の端方向のビューを与え、アプリケーションＡｐｐＡおよびＡｐｐＢが互いに相対的Ｚ順序を有することを示す。さらに、図１０および１１に示し、付随する本文で説明したように、アプリケーションＡｐｐＡおよびＡｐｐＢはそれぞれ、アプリケーション内でそれに関するＺ順序が維持される視覚的要素を生成する。

図１３は、アプリケーションが優先順位順にレンダリングされ、ボトムアップ順に合成される例示的構成１３００を示す図である。構成１３００は、ｘｙｚ座標１３５５で示されるようにユーザ１３３０の方向に向くディスプレイの端方向のビュー１３５０を含む。他の例示的構成（図１３では図示せず）では、レンダリングがボトムアップに（すなわち、特定の設定の要件に応答するＺ順序で）実施される。

参照番号１３０５、１３１０、１３１５、１３２０、および１３２５でそれぞれ示されるＡｐｐＡ、ＡｐｐＢ、ＡｐｐＣ、ＡｐｐＤおよびＡｐｐＥを含む５個のアプリケーションが対話式メディア環境で実行中である。アプリケーションは、矢印１３５２で示されるように、ウィンドウ１３５０内でボトムアップに、Ｚ順序で合成される。合成は、Ｚ順序＝０を有するアプリケーションＡｐｐＡ１３０５で開始し、Ｚ順序＝４を有するアプリケーションＡｐｐＤ１３２５で終了する。

この例示的実施例では、図１３で示される瞬間で示されるように、アプリケーションＡｐｐＣ１３２０が、ユーザイベントを受け取る、視覚的要素１３５８を生成するフォーカスされたアプリケーションである。しかし、動的環境で動作することにより、フォーカスを有する特定のアプリケーションは通常は設計によって経時的に変化し、すべてのアプリケーションは、通常はビデオタイトルが進行するにつれてＺ順序が上および下に移動する可能性がある（しかし、メインビデオが停止、休止、またはフリーズした場合であってもアプリケーションは実行および動作するので、アプリケーションはＺ順序を変更できることも強調しておく）。さらに、フォーカスされたアプリケーションは、スタック中の任意の位置でよい（すなわち、任意のＺ順序を有することができる）。しかし、多くのシナリオでは、ユーザの予想と一致する方式でアプリケーションがユーザ１３３０と対話し、ボタンプッシュ、マウスクリックなどのユーザイベントを受け取ることができるように、フォーカスされたアプリケーションはディスプレイ順序の上端に向かう。

矢印１３６２で示されるように、アプリケーションは、フォーカスされたアプリケーション（例えばアプリケーションＡｐｐＤ１３２０）で始まり、その後に残りのアプリケーションがトップダウンで、すなわち逆Ｚ順序で続く優先順位順にレンダリングされる。

図１４は、アプリケーションが優先順位順にレンダリングされ、ボトムアップ順に合成される例示的方法についての流れ図である。この方法はブロック１４０５で開始する。ブロック１４１２では、上述のＺ順序が、対話式メディア環境内で動作するアプリケーションについて維持される。特定のビデオタイトルに関連付けられるアプリケーションについての初期Ｚ順序は、プレイリスト２９０（図２）によって絶対値（例えば１、２、５、７．．．８７など）を使用して指定される。これらの絶対値は、どんな結びつきも破るためのプレイリスト字句順序付けを使用して、プレイリストＺ順序に基づいてすべてのアプリケーションをソートすることによって直ちに相対的Ｚ順序に変換される。

ブロック１４１５では、アプリケーションは、ビデオタイトルが進行するにつれてその相対的Ｚ順序付けを操作する方法を起動するように動作可能にされる。そのような方法は、例えば、ａ）アプリケーションを平面内のＺ順序の上端に移動すること、ｂ）アプリケーションを平面内のＺ順序の下部に移動すること、およびｃ）アプリケーションのＺ順序を、ディスプレイスタック中のそのアプリケーションの上のアプリケーションのすぐ上に変更することを含む。

上記で指摘したように、アプリケーションは、Ｚ順序操作方法の呼出しを介してアプリケーションがＺ順序内でどれほど遠くに移動することができるかに関して制限を課す特定の平面に属する。例えば、サブタイトルアプリケーションを上端に移動する方法を呼び出すことは、アプリケーションをサブピクチャ平面９１８（図９）内の最上端のアプリケーションサブタイトルアプリケーションにするが、その中で生成された視覚的要素は依然として、その平面内のアプリケーションによってグラフィックス平面９１２内にレンダリングされた視覚的要素によって遮られる（すなわち隠される）可能性がある。同様に、通常の対話式アプリケーションを底部に移動する方法を呼び出すことは、アプリケーションをグラフィックス平面９１２内の最下端にするが、依然としてアプリケーションをすべてのサブタイトルアプリケーションの上に残すことになる。

ブロック１４１６では、アプリケーションは、イベントを受信し、アプリケーションのＺ順序が変化したという通知を提供する。別法として、そのような通知は、アプリケーションが最上端のアプリケーションに遷移したとき、または最上端のアプリケーションから遷移したときに受信されるように構成される。そのような通知は、例えば、メニュー生成アプリケーションによって生成されたメニューが最高のＺ順序を有する位置に移動したときにゲームアプリケーションがそれ自体を休止することを可能にする。

例示的方法はブロック１４１８に進み、アプリケーションからの視覚的要素が１つまたは複数のグラフィックスバッファにレンダリングされる。レンダリングは優先順位順に実施され、ほとんどのシナリオでは、優先順位はフォーカスされたアプリケーションで開始し、その後に、ディスプレイの上端から下方向に逆Ｚ順序で残りのアプリケーションが続く。描画（すなわち２次元「２Ｄ」描画）は、アプリケーションのマークアップ（例えば図１のマークアップ１２０）内の「キャンバス」オブジェクトに描画することによって処理され、次いでそれが、ＰＮＧ（Ｐｏｒａｂｌｅ Ｎｅｔｗｏｒｋ Ｇｒａｐｈｉｃｓ）ファイルのレンダリングとほぼ同じ方式でグラフィックスバッファにレンダリングされる。

バッファリングステップは、図１４に示される例示的方法で構成され、その結果、アプリケーションは、それぞれのアプリケーションイベントキュー内の周期的レンダリングイベントに対応する作業項目をポストすることによってレンダリングされる。この構成で使用することのできるイベントキューおよび関連する方法は、図５〜８に示され、付随する本文で説明される。

作業項目のポスティングは、アプリケーションフレームのレンダリングが作業項目タイムアウトの対象となることを意味する。それに応じてアプリケーションの２重バッファリングが実施され、優先順位がプレイバックシステムの別の所に配置された場合に新しいアプリケーションフレームが各ビデオフレームについて常にはレンダリングされない可能性に対処される。そのような場合、新しいフレームが完了するまで、最新の利用可能なフレームが引き続き示されることになる。

ブロック１４２１では、ディスプレイを合成する前に、各アプリケーションがチェックされ、そのマークアップ（例えば図１のマークアップ１２０）内に＜ｃｌｅａｒｒｅｃｔ＞要素を含むかどうかが確認される。そのような要素は、メインビデオ平面９２５をそれを介して見ることができるアプリケーションによって生成されたグラフィックス内に開口（すなわち「穴」）を生成するために含まれる。＜ｃｌｅａｒｒｅｃｔ＞要素は矩形の開口を生成するが、特定の設定の要件に応じて、他の規則的幾何学的形状、不規則的形状、および他の任意の形状も使用可能である。

＜ｃｌｅａｒｒｅｅｔ＞や他のそのような開口生成要素などの要素は、アプリケーションが方法のブロック１４１８でレンダリングされる時にはグラフィックスバッファに含まれない。その代わりに、穴は、合成中に＜ｃｌｅａｒｒｅｃｔ＞要素を有するアプリケーションよりも低いＺ順序を有するアプリケーションで開けられ、それによって、メインビデオ平面９２５がアプリケーション内の穴を通じて見える。レンダリングは優先順位式に実施されるので、アプリケーションがバッファにレンダリングされる時に＜ｃｌｅａｒｒｅｃｔ＞要素を実装するのは現実的ではない。そのように実装され、低い優先順位のアプリケーションが直ちに更新されなかった場合、穴が不適切に出現する可能性がある。このことは、例えば、Ｚ順序が変化した場合、または低い優先順位のアプリケーションがタイムアウト中に更新を待機していた間に＜ｃｌｅａｒｒｅｃｔ＞要素を有するアプリケーションが終了した場合に生じる。

ブロック１４２５では、図１２で示し、付随する本文で説明したように、アプリケーションがボトムアップに、Ｚ順序で合成される。ほとんどの設定では、単純なペインタのアルゴリズムが使用可能であり、各アプリケーションのマークアップが、各アプリケーションについての最も新しくバッファリングされたフレームを使用してグラフィックス平面９１２にレンダリングされる。さらに、上述のように、＜ｃｌｅａｒｒｅｃｔ＞または他の開口生成要素が、合成ステップ中に実装される。例示的方法はブロック１４３３で終了する。

図１５は、例示的プレイバックシステム１５００のブロック図である。ナビゲーションマネージャ１５０５は、対話式メディア環境内で動作するＮ個のアプリケーションの厳密な順序を維持する。各アプリケーションには０からＮ−１のＺ順序が与えられ、すべてのアプリケーションは固有のＺ順序を有する。順序付けでギャップは存在せず、２つのアプリケーションが同じＺ順序を有することはない。Ｚ順序０は、ディスプレイ１５１２の下端に現れる、Ｚ順序Ｎ−１は上端に現れる。ビデオタイトルの時間が進行するときに、ナビゲーションマネージャ１５０５は、上述のように、アプリケーションについてのＺ順序を、プレイリスト（例えば図２のプレイリスト２９０）で設定された初期Ｚ順序値から動的に維持する。

ナビゲーションマネージャ１５０５は、プレゼンテーションエンジン１５１５およびグラフィックスレンダリングエンジン１５１８に結合される。ほとんどの設定では、プレゼンテーションエンジン１５１５は、グラフィックス平面セット９００中の平面のそれぞれをグラフィックスレンダリングエンジン１５１８に提示するように構成され、グラフィックスレンダリングエンジン１５１８は、ディスプレイ１５１２上への平面およびその中のアプリケーションの合成を実施する。

プレゼンテーションエンジン１５１５とグラフィックスレンダリングエンジン１５１８の間に、参照番号１５２２、１５２６、および１５２８でそれぞれ示される１つまたは複数のグラフィックスバッファ１、２、．．Ｎが配設される。Ｎ個のグラフィックスバッファは、それぞれのアプリケーションと１対１に対応付けられるように構成される。すなわちＮ_{ｂｕｆｆｅｒｓ}＝Ｎ_{ａｐｐｌｉｃａｔｉｏｎ}である。代替構成では、単一のバッファ（参照番号１５４０で示される）がすべてのアプリケーションに対して使用され、またはグラフィックスバッファが、アプリケーションと等しくない数で対応付けられる。

図が見やすいように、かつ上記の説明での例示を簡単にするために、データ、プログラム、およびオペレーティングシステムなどの他の実行可能プログラム構成要素を離散的ブロック、ボックス、または他の要素で示したが、そのようなプログラムおよび構成要素は、様々な時間に、使用される任意のハードウェアホストの様々なストレージ、メモリ、または処理構成要素に存在することができ、そのようなホストハードウェア内の１つまたは複数のプロセッサで実行されることに留意されたい。

対話式メディア環境でアプリケーション状態を管理する様々な例示的構成および方法を図示および説明したが、本明細書に添付の特許請求の範囲の範囲は、記載の特定の特徴、構成、または方法に必ずしも限定されないものとすることを理解されたい。むしろ、特定の特徴、構成、または方法は、より具体的に特許請求される対話式メディア環境での管理されたアプリケーション状態を実装する例示的形態として開示される。

対話式メディア環境で使用されるアプリケーションを構成する要素の例示的ブロック図である。 複数のマークアップ文書およびスクリプトの間の関係を示す例示的な図である。 対話式コンテンツプロセッサ、ビデオコンテンツプロセッサ、およびミキサを含む例示的な対話式メディアプレーヤのブロック図である。 第２の例示的な対話式メディアプレーヤのブロック図である。 複数のイベントキューおよび単一のアプリケーションスレッドを有する例示的構成のブロック図である。 まずＢｅｇｉｎＴｉｍｅ、次いで作業項目がイベントキューに挿入された時間による作業項目の順序付けを示す例示的イベントキューのブロック図である。 アプリケーションスレッドが２つの作業項目をイベントキューの端部に自動的に挿入する例示的構成のブロック図である。 対話式メディア環境で生じるイベントに関連する作業項目を待ち行列化する例示的方法の流れ図である。 例示的グラフィカル合成モデルで使用されるグラフィックス平面のセットの図である。 第１の例示的アプリケーション内の視覚的要素のＺ順序を示す図である。 第２の例示的アプリケーション内の視覚的要素のＺ順序を示す図である。 図１０および１１に示されるアプリケーションから生成される視覚的要素を有する合成後のディスプレイを示す図である。 アプリケーションが優先順位順にレンダリングされ、ボトムアップ順に合成される例示的構成を示す図である。 アプリケーションが優先順位順にレンダリングされ、ボトムアップ順に合成される例示的方法についての流れ図である。 例示的プレイバックシステムのブロック図である。

Claims (20)

1. ディスプレイを合成する方法であって、
   対話式メディア環境（１２５０）で動作する複数のアプリケーションのそれぞれについてＺ順序を維持するステップであって、前記Ｚ順序が、前記ディスプレイ上の視覚的要素についての相対的順序を記述するステップと、
   アプリケーションに関連するそれぞれのグラフィックスバッファ（１５２８）に前記アプリケーションをレンダリングするステップであって、前記レンダリングが、フォーカスを有するアプリケーションで始まるアプリケーションによって実施され、最高のＺ順序から最低のＺ順序（１３６２）まで、前記複数のアプリケーション中の残りのアプリケーションで続行されるステップと、
   前記グラフィックスバッファ内の視覚的要素から前記ディスプレイを合成するステップであって、前記合成が、アプリケーションによって最低のＺ順序から最高のＺ順序まで（１３５２）実施されるステップと
   を含む方法。
2. 初期Ｚ順序がプレイリスト（２９０）で設定される請求項１に記載の方法。
3. 前記レンダリングが、レンダリングした要素が表示のために合成される前に２重バッファリングされるように、２重バッファリング構成を使用するステップを含む請求項１に記載の方法。
4. 前記対話式メディア環境が複数のディスプレイ平面（９００）を含み、前記アプリケーションが、前記複数のディスプレイ平面（９００）中のグラフィックス平面（９１２）にレンダリングされるように割り当てられる請求項１に記載の方法。
5. 前記対話式メディア環境が、複数のディスプレイ平面（９００）を含み、前記アプリケーションが、前記複数のディスプレイ平面（９００）内のサブピクチャ平面（９１８）にレンダリングされるように割り当てられる請求項１に記載の方法。
6. それぞれのグラフィックスバッファが、すべてのアプリケーションからの視覚的要素がレンダリングされる単一グラフィックスバッファとして維持される請求項１に記載の方法。
7. ディスプレイと接続するためのプレイバックシステムであって、
   対話式メディア環境内で動作するアプリケーションについてのＺ順序を維持するナビゲーションマネージャ（１５０５）であって、前記Ｚ順序が、前記ディスプレイ上の視覚的要素についての相対的順序を記述するナビゲーションマネージャ（１５０５）と、
   前記アプリケーションによって生成された視覚的要素をバッファリングする１つまたは複数のグラフィックスバッファ（１５２８）と、
   前記ナビゲーションマネージャと動作可能に結合され、アプリケーションによる視覚的要素を逆Ｚ順序で前記グラフィックスバッファにレンダリングするプレゼンテーションエンジン（１５１５）と、
   前記１つまたは複数のグラフィックスバッファから前記ディスプレイに関するフレームイメージを合成するグラフィックスレンダリングエンジン（１５１８）であって、前記合成が、アプリケーションによってＺ順序で実施されるグラフィックスレンダリングエンジン（１５１８）と
   を備えるプレイバックシステム。
8. 前記合成が、クリア開口要素をマークアップ中に有するアプリケーションよりも低いＺ順序を有するすべてのアプリケーションのグラフィックスバッファ内に開口を開け、それによって前記開口を通じてビデオ平面（９２５）を見ることができるステップを含む請求項７に記載のプレイバックシステム。
9. 前記開口が、複数の形状のうちの１つから選択される形状を有し、前記形状が、矩形、円形、卵型、および任意の形状を含む請求項８に記載のプレイバックシステム。
10. 合成フレームイメージが、ビデオフレームごとのアプリケーションフレームを含む請求項７に記載のプレイバックシステム。
11. 新しいアプリケーションフレームが利用不能である場合、前記アプリケーションフレームが、最も新しく利用可能となったアプリケーションフレームである請求項１０に記載のプレイバックシステム。
12. 電子装置内の１つまたは複数のプロセッサで実行されたとき、複数のＮ個のアプリケーションについての描画順序を設定する方法を実施するコンピュータ可読媒体において、戦記複数のアプリケーションの中の各アプリケーションが、ディスプレイ上の視覚的要素としてレンダリング可能であり、前記方法が、
    アプリケーションが前記ディスプレイ（１４１５）上のアプリケーションのＺ順序を操作する１つまたは複数の方法を起動することを可能にするステップであって、前記Ｚ順序が、前記ディスプレイ上のＮ個のアプリケーションについての相対的順序を記述し、Ｚ順序の値が、０およびＮ−１によって束縛される組から選択されるステップと、
    前記アプリケーション（１４１８）を前記アプリケーションに関連するそれぞれのグラフィックスバッファにレンダリングするステップであって、前記レンダリングが、Ｎ−１で開始し、０で終了する逆Ｚ順序でアプリケーションによって実施されるステップと
    を含む方法であるコンピュータ可読媒体。
13. 前記レンダリングが、イベントキュー（５１５）に挿入される１つまたは複数の作業項目（５３５）を使用して実施される請求項１２に記載のコンピュータ可読媒体。
14. アプリケーションのＺ順序が変化したとき、前記アプリケーションに通知（１４１６）を供給するステップをさらに含む方法である請求項１２に記載のコンピュータ可読媒体。
15. 前記レンダリングが、アプリケーションのマークアップ内のキャンバスオブジェクトに描画することを含む請求項１２に記載のコンピュータ可読媒体。
16. 前記キャンバスオブジェクトが、アプリケーションのそれぞれのグラフィックスバッファにレンダリングされる請求項１５に記載のコンピュータ可読媒体。
17. ペインタのアルゴリズムを使用して最新のバッファから前記ディスプレイ（１４２５）を合成するステップをさらに含む方法である請求項１２に記載のコンピュータ可読媒体。
18. 起動する前記方法が、アプリケーションを最高のＺ順序に移動するステップを含む方法である請求項１２に記載のコンピュータ可読媒体。
19. 起動する前記方法が、アプリケーションを最低のＺ順序に移動するステップを含む方法である請求項１２に記載のコンピュータ可読媒体。
20. 起動する前記方法が、移動するアプリケーションよりも１つ高いＺ順序を有するアプリケーションのすぐ上の位置にアプリケーションを移動するステップを含む方法である請求項１２に記載のコンピュータ可読媒体。

Images