(57)【特許請求の範囲】
【請求項１】
コンピューティング・システムであって、
グラフィックスを含むディスプレイ情報のフレームを出力するグラフィックス・サブシステム手段と、
前記ディスプレイ情報のフレームを出力する前記グラフィックス・サブシステム手段に、グラフィックス・データを前記グラフィックス・サブシステム手段のフレーム・リフレッシュ速度に基づく第１のフレーム速度で提供する動作を実行する第１の構成要素手段と、
プログラム・コードとインターフェースをとって、前記プログラム・コードに対応するシーン・データを生成する第２の構成要素手段であって、キャッシュ・データ構造内に前記シーン・データの少なくとも幾つかを維持し、前記第１のフレーム速度より遅い第２のフレーム速度で、前記キャッシュ・データ構造をトラバースすることによって、前記シーン・データをグラフィックス情報に処理（process）して、前記グラフィックス情報を前記第１の構成要素手段に、供給するように動作する第２の構成要素手段と
を備え、
前記キャッシュ・データ構造は、少なくとも１つのノードが、描画命令を含むコンテナ要素を備える複数のノードからなる階層木として構成され、
前記第１の構成要素手段は、前記第２の構成要素手段に、前記キャッシュ・データ構造をトラバースするのに、あるいは前記シーン・データを維持するのに使用する情報を提供する
ことを特徴とするコンピューティング・システム。
【請求項２】
前記グラフィックス情報は、前記第１の構成要素手段によって解釈されるフォーマットのイメージ・データを備えることを特徴とする請求項１に記載のコンピューティング・システム。
【請求項３】
前記グラフィックス情報は、命令を備えることを特徴とする請求項１に記載のコンピューティング・システム。
【請求項４】
前記命令は、少なくとも１つの補間コマンドを含み、前記第１の構成要素手段は、時間経過に対応して前記グラフィックス・データ内のイメージを補間することにより、前記グラフィックス・サブシステム手段に提供される前記グラフィックス・データを変更する補間メカニズムを含むことを特徴とする請求項３に記載のコンピューティング・システム。
【請求項５】
前記第２の構成要素手段は、アニメーション・パラメータにアクセスして、前記第１の構成要素手段に供給される前記グラフィックス情報を変えることを特徴とする請求項１に記載のコンピューティング・システム。
【請求項６】
前記第２の構成要素手段は、前記シーン・データの変化に応答して出力するように動作することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項７】
前記第１の構成要素手段が、前記グラフィックス情報が必要であることを知らせた場合に、前記第２の構成要素手段が動作することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項８】
前記第２の構成要素手段は、第１の構成要素手段からのフィードバックに基づいて、前記第１の構成要素手段に供給される前記グラフィックス情報量を動的に調整することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項９】
前記第２の構成要素手段は、前記シーン・データ内のアニメーション・パラメータに基づく頻度で動作することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項１０】
前記第２の構成要素手段は、命令ストリームを介して前記第１の構成要素手段に前記グラフィックス情報を提供することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項１１】
前記第２の構成要素手段は、命令ストリームを介して前記第１の構成要素手段に前記グラフィックス情報を提供することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項１２】
前記第２の構成要素手段は、ネットワーク接続を介して前記第１の構成要素手段に前記グラフィックス情報を提供することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項１３】
前記第１の構成要素手段は、前記第２の構成要素手段によって提供される前記グラフィックス情報を、少なくとも１つの待ち行列の１組内に維持することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項１４】
第１の構成要素手段にその他のグラフィックス情報を提供する少なくとも１つのその他の第２の構成要素手段をさらに備え、前記第１の構成要素手段は、各第２の構成要素手段からの前記グラフィックス情報の合成から、前記グラフィックス・サブシステム手段に提供される前記グラフィックス・データを合成することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項１５】
前記第１の構成要素手段は、前記第２の構成要素手段によって提供される前記グラフィックス情報を、それぞれの高レベル構成要素手段のための少なくとも１つの待ち行列の１組内に維持することを特徴とする請求項１４に記載のコンピューティング・システム。
【請求項１６】
少なくとも１つの前記ノードは、描画命令を含むコンテナ構造を有することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項１７】
前記第１の構成要素手段は、前記第２の構成要素手段によって提供される前記グラフィックス情報を、ビジュアル・ブロックとリソース・データ構造とに分割することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項１８】
前記第１の構成要素手段および第２の構成要素手段は、異なるスレッド上で実行することを特徴とする請求項１に記載のコンピューティング・システム。
【請求項１９】
ディスプレイ情報のフレームを出力するグラフィックス・サブシステム手段、第１および第２の構成要素手段を備え、前記第１の構成要素手段がデータを含むコールを受信して、前記第２の構成要素手段にグラフィック情報を伝達し、前記第２の構成要素手段が前記グラフィック情報を受信し、グラフィック・データを前記グラフィック・サブシステム手段に伝達する、コンピューティング環境において、
第１の構成要素手段において、
１）出力するグラフィカル・イメージに対応するデータを含むコール（call）を受取るステップと、
２）キャッシュ・データ構造内にシーン情報として前記データを維持するステップと、
３）第１のフレーム速度で、
ａ）前記キャッシュ・データ構造をトラバースすることによって前記シーン情報をグラフィックス情報に処理するステップと、
ｂ）前記グラフィックス情報を第２の構成要素手段に伝達するステップと、
前記第２の構成要素手段において、前記第１のフレーム速度より速く、前記グラフィックス・サブシステム手段のフレーム・リフレッシュ速度に基づく第２のフレーム速度で、
４）前記グラフィックス情報を受取るステップと、
５）前記グラフィックス情報を、前記グラフィックス・サブシステム手段のためにフォーマットしたグラフィックス・データに処理するステップと、
６）前記グラフィックス・データを、前記フレームを出力する前記グラフィックス・サブシステム手段に伝達するステップと
を備え、
前記キャッシュ・データ構造は、少なくとも１つのノードが描画命令を含むコンテナ要素を備える複数のノードからなる階層木として構成され
前記第２の構成要素手段は、前記第１の構成要素手段に、前記キャッシュ・データ構造をトラバースするのに、あるいは前記シーン情報を維持するのに使用する情報を提供する
ことを特徴とする方法。
【請求項２０】
前記第１のフレーム速度は、前記コールを受取るフレーム速度に対応することを特徴とする請求項１９に記載の方法。
【請求項２１】
前記シーン情報を維持するステップは、シーン・グラフ・データ構造を構築するステップを備えることを特徴とする請求項１９に記載の方法。
【請求項２２】
前記シーン情報を維持するステップは、シーン・グラフ・データ構造内のコンテナを開けて、その中の描画命令にアクセスするステップを備えることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記シーン・グラフ・データ構造を構築するステップは、変数の少なくとも１つの値を変更するステップを備えることを特徴とする請求項２１に記載の方法。
【請求項２４】
前記シーン情報を維持するステップは、前記コールを介して受取った変更を待ち行列に入れるステップと、前記待ち行列に入れた変更を適用するステップとを備えることを特徴とする請求項１９に記載の方法。
【請求項２５】
前記シーン情報をグラフィックス情報に処理するステップは、変数の少なくとも１つの値を獲得するステップを備えることを特徴とする請求項１９に記載の方法。
【請求項２６】
前記第１の構成要素手段において、前記シーン情報を処理した後の少なくともいくつかの結果をキャッシュに入れるステップをさらに備えることを特徴とする請求項１９に記載の方法。
【請求項２７】
前記グラフィックス情報を前記第２の構成要素手段に伝達するステップは、命令ストリームを前記第２の構成要素手段に送るステップを備えることを特徴とする請求項１９に記載の方法。
【請求項２８】
前記命令ストリームは、リソース・パケットを含み、前記グラフィックス情報を、前記グラフィックス・サブシステム手段のためにフォーマットしたグラフィックス・データに処理するステップは、リソースを作成することによってリソース・パケットを処理するステップと、そのリソースを前記第１の構成要素手段に関連付けるステップとを備えることを特徴とする請求項２７に記載の方法。
【請求項２９】
前記命令ストリームは、ビジュアル更新パケットを含み、前記グラフィックス情報を前記グラフィックス・サブシステム手段のためにフォーマットしたグラフィックス・データに処理するステップは、ビジュアルが前記第１の構成要素手段に既に関連付けられているかどうかを決定することにより、前記ビジュアル更新パケットを処理するステップであって、関連付けられていなければ新しいビジュアルを作成して前記新しいビジュアルを前記第１の構成要素手段に関連付け、既に関連付けられていれば、前記ビジュアル更新パケット内の情報に基づき、そのビジュアルの情報を修正するステップを備えることを特徴とする請求項２７に記載の方法。
【請求項３０】
前記第２の構成要素手段から前記第１の構成要素手段へ情報を戻すステップをさらに備えることを特徴とする請求項１９に記載の方法。
【請求項３１】
前記第２の構成要素手段から前記第１の構成要素手段へ情報を戻すステップは、少なくとも１つのイベントを待ち行列に入れるステップを備えることを特徴とする請求項３０に記載の方法。
【請求項３２】
第３の構成要素手段において、
出力するその他のグラフィカル・イメージに対応するその他のデータを含むその他のコールを受取るステップと、
前記その他のデータをその他のシーン情報として維持するステップと、
第３のフレーム速度で、前記その他のシーン情報をその他のグラフィックス情報に処理して、前記その他のグラフィックス情報を前記第２の構成要素手段に伝達するステップと
をさらに備えることを特徴とする請求項１９に記載の方法。
【請求項３３】
前記第２の構成要素手段において、
前記その他のグラフィックス情報を受取るステップと、
前記その他のグラフィックス情報を、前記グラフィックス・サブシステム手段のためにフォーマットしたその他のグラフィックス・データに処理するステップと、
前記第１の構成要素手段に対応する前記グラフィックス・データの少なくとも一部と、前記第３の構成要素手段に対応する前記グラフィックス・データの少なくとも一部とを含むグラフィックス・デスクトップを合成するステップと、
前記グラフィックス・デスクトップを、前記フレームを出力する前記グラフィックス・サブシステム手段に伝達するステップと
をさらに備えることを特徴とする請求項３２に記載の方法。
【請求項３４】
記録されたプログラムを有するコンピュータ読取り可能記録媒体であって、前記プログラムは、
データを含むコールを受信し、第２の構成要素手段にグラフィックス情報を伝達する第１の構成要素手段において、
１）出力するグラフィカル・イメージに対応するデータを含むコールを受取るステップと、
２）キャッシュ・データ構造内にシーン情報として前記データを維持するステップと、
３）第１のフレーム速度で、
ａ）少なくとも１つのノードが描画命令を含むコンテナ要素を備える複数のノードからなる階層木として構成される前記キャッシュ・データ構造をトラバースすることによって前記シーン情報をグラフィックス情報に処理するステップと、
ｂ）前記グラフィックス情報を前記第２の構成要素手段に伝達するステップと、
前記第１の構成要素手段から前記グラフィックス情報を受信し、グラフィックス・データをグラフィクス・サブ・システム手段に伝達する前記第２の構成要素手段であって、前記第１の構成要素手段に、前記キャッシュ・データ構造をトラバースするのに、あるいは前記シーン情報を維持するのに使用する情報を提供する前記第２の構成要素手段で、前記第１のフレーム速度より速く、前記グラフィックス・サブシステム手段のフレーム・リフレッシュ速度に基づく第２のフレーム速度で、
４）前記グラフィックス情報を受取るステップと、
５）前記グラフィックス情報を、前記グラフィックス・サブシステム手段のためにフォーマットしたグラフィックス・データに処理するステップと、
６）前記グラフィックス・データを、フレームを出力する前記グラフィックス・サブシステム手段に伝達するステップと
をコンピュータに実行させることを特徴とするコンピュータ読取り可能記録媒体。
【請求項３５】
前記第１のフレーム速度は、前記コールを受取る速度に対応することを特徴とする請求項３４に記載のコンピュータ読取り可能記録媒体。
【請求項３６】
前記シーン情報を維持するステップは、シーン・グラフ・データ構造を構築するステップを備えることを特徴とする請求項３４に記載のコンピュータ読取り可能記録媒体。
【請求項３７】
前記シーン情報を維持するステップは、シーン・グラフ・データ構造内のコンテナを開けて、その中の描画命令にアクセスするステップを備えることを特徴とする請求項３６に記載のコンピュータ読取り可能記録媒体。
【請求項３８】
前記シーン・グラフ・データ構造を処理するステップは、変数の少なくとも１つの値を変えるステップを備えることを特徴とする請求項３６に記載のコンピュータ読取り可能媒体。
【請求項３９】
前記シーン情報を維持するステップは、前記コールを介して受取った変更を待ち行列に入れるステップと、前記待ち行列に入れた変更を適用するステップとを備えることを特徴とする請求項３４に記載のコンピュータ読取り可能記録媒体。
【請求項４０】
前記シーン情報をグラフィックス情報に処理するステップは、変数の少なくとも１つの値を得るステップを備えることを特徴とする請求項３４に記載のコンピュータ読取り可能媒体。
【請求項４１】
前記プログラムは、前記第１の構成要素手段において、前記シーン情報を処理した後の少なくともいくつかの結果をキャッシュに入れるステップをさらにコンピュータに実行させることを特徴とする請求項３４に記載のコンピュータ読取り可能記録媒体。
【請求項４２】
前記グラフィックス情報を前記第２の構成要素手段に伝達するステップは、命令ストリームを前記第２の構成要素手段に伝達するステップを備えることを特徴とする請求項３４に記載のコンピュータ読取り可能記録媒体。
【請求項４３】
前記命令ストリームはリソース・パケットを備え、前記グラフィックス情報を、前記グラフィックス・サブシステム手段のためにフォーマットしたグラフィックス・データに処理するステップは、リソースを作成することによってリソース・パケットを処理するステップと、そのリソースを前記第１の構成要素手段に関連付けるステップとを含むことを特徴とする請求項４２に記載のコンピュータ読取り可能記録媒体。
【請求項４４】
前記命令ストリームはビジュアル更新パケットを有し、前記グラフィックス情報を前記グラフィックス・サブシステム手段のためにフォーマットしたグラフィックス・データに処理するステップは、ビジュアルが前記第１の構成要素手段に既に関連付けられているかどうかを決定することにより、前記ビジュアル更新パケットを処理するステップであって、関連付けられていなければ新しいビジュアルを作成して前記新しいビジュアルを前記第１の構成要素手段に関連付け、既に関連付けられていれば、前記ビジュアル更新パケット内の情報に基づき、そのビジュアルの情報を修正するステップを備えることを特徴とする請求項４２に記載のコンピュータ読取り可能記録媒体。
【請求項４５】
前記第２の構成要素手段から前記第１の構成要素手段へ情報を戻すステップを備える、少なくともさらに１つのコンピュータ実行可能命令を有することを特徴とする請求項３４に記載のコンピュータ読取り可能記録媒体。
【請求項４６】
前記第２の構成要素手段から前記第１の構成要素手段へ情報を戻すステップは、少なくとも１つのイベントを待ち行列に入れるステップを備えることを特徴とする請求項４５に記載のコンピュータ読取り可能記録媒体。
【請求項４７】
前記プログラムは、第３の構成要素手段で、
出力するその他のグラフィカル・イメージに対応するその他のデータを含むその他のコールを受取るステップと、
前記その他のデータをその他のシーン情報として維持するステップと、
第３のフレーム速度で、前記その他のシーン情報をその他のグラフィックス情報に処理するステップと、
前記その他のグラフィックス情報を前記第２の構成要素手段に伝達するステップと
をさらにコンピュータに実行させることを特徴とする請求項３４に記載のコンピュータ読取り可能記録媒体。
【請求項４８】
前記プログラムは、前記第２の構成要素手段で、
前記その他のグラフィックス情報を受取るステップと、
前記その他のグラフィックス情報を、前記グラフィックス・サブシステム手段のためにフォーマットしたその他のグラフィックス・データに処理するステップと、
前記第１の構成要素手段に対応する前記グラフィックス・データの少なくとも一部と、前記第３の構成要素手段に対応する前記グラフィックス・データの少なくとも一部とを含むグラフィックス・デスクトップを合成するステップと、
前記グラフィックス・デスクトップを、前記フレームを出力する前記グラフィックス・サブシステム手段に伝達するステップと
をさらにコンピュータに実行させることを特徴とする請求項４７に記載のコンピュータ読取り可能記録媒体。
【発明の詳細な説明】
【０００１】
本発明は、特許仮出願第６０／３３０，２４４号（２００１年１０月１８日出願）（特許文献１）への優先権を請求する。本発明は、米国特許出願「Ｇｅｎｅｒｉｃ  Ｐａｒａｍｅｔｅｒｉｚａｔｉｏｎ  ｆｏｒ  ａ  Ｓｃｅｎｅ  Ｇｒａｐｈ」（弁護士整理番号第３１３０号）（特許文献２）および米国特許出願「Ｉｎｔｅｌｌｉｇｅｎｔ  Ｃａｃｈｉｎｇ  Ｄａｔａ  Ｓｔｒｕｃｔｕｒｅ  ｆｏｒ  Ｉｍｍｅｄｉａｔｅ  Ｍｏｄｅ  Ｇｒａｐｈｉｃｓ」（弁護士整理番号第３１５０号）（特許文献３）に関し、両文書とも、本出願の譲受人に譲受され、本明細書とともに同時出願され、参照によりそれら全体が組み入れてある。
【０００２】
【発明の属する技術分野】
本発明は、一般にコンピュータ・システムに関し、より詳細には、コンピュータ・システムのディスプレイについてのグラフィカル情報およびその他のビデオ情報の処理に関する。
【０００３】
【従来の技術】
現代の計算機システムにおいて、グラフィックスおよびビデオ・ハードウェアの機能が急速に向上している。事実、現代の計算機システムに使用されるグラフィックス・システムは、ある程度、単なるグラフィックス・サブシステムと言うより、コプロセッサと考えることができる。同時に、消費者は、たとえば、モニタ、テレビ、携帯電話のディスプレイを見る際に、表示される画像の品質に、より高い期待を寄せるようになってきている。
【０００４】
しかし、メモリやバスの速度が、メイン・プロセッサおよび／またはグラフィックス・プロセッサの進歩に追いついてきていない。その結果、コンピュータ・システムのグラフィックスにアクセスする従来のイミーディエイト・モード・モデルの持つ限界に達してしまっている。同時に、開発者および消費者は、従来のグラフィカル・ウィンドウィング・アーキテクチャでは満たすことのできないような、新規の機能や特別な効果を要求してきている。
【０００５】
特定のゲーム・プログラムは、グラフィックス・ハードウェアの利点を生かして設計されており、このようなゲーム・プログラムは、デスクトップ・アプリケーション・プログラム等とは異なる条件で動作する。これは主に、ゲームでは、同時に実行するかもしれないその他のプログラムを問題にする必要がないからである。このようなゲーム・プログラムとは異なり、アプリケーションでは、他のアプリケーションと、グラフィックスおよびその他のシステム・リソースを共有しなければならない。しかし、一般に、グラフィックス処理については、協調型（cooperative）で、マシン全体を共用するモデル（machine-wide sharing model）で書かれてはいない。
【０００６】
たとえば、デスクトップ・アプリケーションでアニメーションを実行すると、専用の単一目的のコードを必要とするか、または別のアプリケーションを使用しなければならない。そして、たとえそうしたとしても、マルチウィンドウ環境でスムーズなアニメーションを得ることは不可能ではないにしても、困難ではある。このことは、一般的に言って、スムーズで高速度なアニメーションを得るには、アニメーション・パラメータを更新し、高いフレーム速度(rate)で、理想的には、グラフィックス装置のハードウェア・リフレッシュ速度で、シーンを再描画（これには、データ構造をトラバース（traverse；走査、横断）し描画する必要がある）しなければならないからである。しかし、アニメーション・パラメータを更新し、シーンを定義するデータ構造をトラバースし描画することは、一般に、コンピュータ処理の集中化状態となる。シーンのアニメーションを大きくしたり回数を多くしたりすると、コンピュータ処理への要求が増大し、そのことは、スムーズにアニメーションすることが可能なシーンの複雑度を制限する。
【０００７】
問題が複雑となっている、その原因は、グラフィックスのハードウェアがディスプレイ・リフレッシュを実行する場合、アニメーションの各フレームを計算し、描画して、プレゼンテーションのための準備作業をする必要があることである。ハードウェアの必要とするときにフレームの準備ができていなかった場合は、フレームが落ちてしまったり、遅れてしまったりすることとなる。一定数のフレームが落ちると、アニメーションを表示しているディスプレイに、かなりのスタッタ（stutter；ぎこちない動き）が現れる。また、フレームの準備作業がリフレッシュ速度と同期がとれていない場合は、テアリング（tearing；裂け目が見える現象）として周知の、望ましくない影響が起きる可能性がある。実際、現代の多重タスキング・オペレーティング・システムは、システム上の、多くのタスクの間で計算用のリソースを分割している。しかし、オペレーティング・システム・タスクス・ケジューラによるフレーム処理のための時間が、グラフィックス・ハードウェアのフレーム速度に合うことはめったにない。したがって、たとえ計算用のリソースが十分にあったとしても、アニメーション・システムは、スケジューリングの問題によって、やはりフレームを落としてしまう可能性がある。たとえば、アニメーション・タスクの動きが遅すぎるようにスケジューリングされている可能性もあり、またはフレームが完了する前に優先使用されてしまう可能性もあり、スクリーンの次のハードウェア・リフレッシュのため次のフレームを供給するように時間通りに再スケジューリングされることはない。このような問題は、アニメーションしたグラフィックスを、ビデオまたはその他の非同期式に生成されるフレームのソースと合成する必要がある場合に、一層複雑となる。
【０００８】
一般的に言って、フレームを準備するために現在使われている（たとえば、ＷＭ＿ＰＡＩＮＴ）モデルは、複雑なグラフィックス効果（複雑なアニメーションなど）が望ましい場合に、リフレッシュ速度に追いつくためには余りに多くのデータ処理を必要とする。その結果、複雑なグラフィックス効果を従来のモデルを使って試みると、次のフレームの変更を終了させて次のフレームに間に合ってビジュアル効果がやがて知覚されるのではなく、変更が個々のフレームに追加されてしまう可能性もあり、そのため、ビジュアル的で目立った望ましくない結果が引き起こされる。シーン・グラフ内のすべてのオブジェクトにオブジェクト・ハンドルを与えることにより、選択的に変更を組み込むことができるようにした計算モデルがある。しかし、このようなモデルは、かなりの数のオブジェクトを追跡（track）するための複数のアプリケーションを必要とし、また、そのアプリケーションがオブジェクトを変更させようとしない場合でさえも、オブジェクト・ハンドルが存在するために、余りにも多くのリソースを消費する。
【０００９】
【発明が解決しようとする課題】
要するに、コンピュータ・システムのグラフィックスにアクセスするための既存のモデルは、現行ディスプレイ・ハードウェアと一緒に機能するには、また消費者の期待を満足させるには不充分となってきている。グラフィックスとビデオを処理するための新しいモデルが、必要とされている。
【００１０】
【課題を解決するための手段】
簡単に言えば、本発明は、たとえば、スムーズなアニメーションなどの、改良型グラフィックス・アクセスおよび出力を供給するための、多重レベルのグラフィックス処理システム（multi-level graphics processing system）および方法（たとえば、オペレーティング・システムについての）を提供することである。一実施形態では、グラフィックス処理システムは、２つの構成要素を含む。ティック−オン−デマンド（tick-on-demand）または低速ティック（slow tick）高レベル構成要素、そして高速ティック（fast tick）（たとえば、１つまたは複数のグラフィックス・ハードウェア・フレーム速度）低レベル構成要素である。
【００１１】
一般的に言って、高レベル構成要素は、ディスプレイされるべきシーンをトラバースして、この後の補間用に間隔を開けて、アニメーション・パラメータを更新し、そして単純化したデータ構造を低レベル構成要素にパスする。低レベル構成要素は、データ構造を、瞬時値を得るために必要とするパラメータ間隔を補間することを含んで、処理して出力データを獲得し、アニメーションの各フレームに対応するシーンをレンダリングする。
【００１２】
一般的に言って、本発明は、グラフィックス・データを要素に分けて、アニメーション・パラメータを更新し、シーン・データ構造をトラバースするという、コンピュータ処理の最も集中化する局面は、高レベル処理構成要素で過度に要求されることが少ないスケジュールで実行するように、グラフィック・データを属性分配することにより、上述した（およびその他の）問題を解決する。低レベル処理構成要素の方が、より頻繁に動作するが、比較的単純化したデータ構造と処理すべき命令とを供給する高レベル前処理のために、コンピュータ処理の集中化が少ない状態でタスクを処理する。ビデオ・フレームも、これらの低レベル・ティック期間に、合成に組み込まれることもある。
【００１３】
このシステムおよび方法の利点には、オペレーティング・システム・シェルの一部として、またアニメーションされるコンテンツに相応しいアニメーション・エンジンとして、テレビのような品質のアニメーションが含まれる。さらなる利点には、ビデオ・イメージをグラフィックスと合成することと、高帯域幅を必要としないネットワーク接続、少なくとも、従来のラスタ化したグラフィックス・ビットを必要とされる高フレーム速度で運ぶ程には、十分に高い帯域幅ではない、ネットワーク接続を介して、高品質ビデオ・ディスプレイの複数の端末に情報を配信する機能と、が含まれる。
【００１４】
本発明は、グラフィックスを含むディスプレイ情報のフレームを出力するグラフィックス・サブシステムと、ディスプレイ情報のフレームを出力するグラフィックス・サブシステムに、グラフィックス・データを第１の速度で供給する第１の構成要素と、プログラム・コードとインターフェースして、プログラム・コードに合うシーン・データを生成する第２の構成要素であって、シーン・データをグラフィックス情報に第１の速度より遅い第２の速度で処理し、グラフィックス情報を第１の構成要素に供給するよう構成された第２の構成要素を含むシステムを介して提供することができる。
【００１５】
方法およびコンピュータ実行可能命令を有するコンピュータ読取り可能媒体は、第１の構成要素において、出力するグラフィカル・イメージに対応するデータを含むコール（call）を受信することと、そのデータをシーン情報として維持することと、そして第１のオペレーティング速度で、シーン情報をグラフィックス情報に処理することと、グラフィックス情報を第２の構成要素に伝達することとを含むことができる。第２の構成要素において、第１のオペレーティング速度より速くグラフィックス・サブシステムのフレーム・リフレッシュ速度に基づく第２のオペレーティング速度で、本方法は、グラフィックス情報を受信することと、グラフィックス情報をグラフィックス・サブシステム用にフォーマットしたグラフィックス・データに処理することと、グラフィックス・データをグラフィックス・サブシステムに伝達して、フレームを出力することとを含むことができる。
【００１６】
データ構造をそこに格納したコンピュータ読取り可能媒体は、その中にビジュアル識別子を有する識別子フィールドと、命令ブロックに対応するフィールドとを含み、その命令ブロックは、ビジュアル識別子によって識別されるビジュアルに関連する１組のデータに対応し、その１組のデータは、高レベル・グラフィックス処理構成要素から低レベル・グラフィックス処理構成要素にパスされて、高レベル構成要素は、シーン・グラフからデータ構造を構築してデータ構造を低レベル構成要素に供給し、低レベル構成要素は、データ構造を、フレームを出力するグラフィックス・サブシステムにパスするためのグラフィックス・データに、処理するビジュアル更新ブロック、を備えることができる。
【００１７】
その他の利益および利点は、以下に記述する詳細な説明を、図面と合わせて読めば、より明らかとなるであろう。
【００１８】
【発明の実施の形態】
オペレーティング環境の例（EXEMPLARY OPERATING ENVIRONMENT）
図１は、本発明を実施することができる適切なコンピューティング・システム環境１００の例を示す図である。コンピューティング・システム環境１００は、適切な計算環境の一例にすぎず、本発明の使用法または機能の範囲を提案することを意図していない。またコンピューティング環境１００は、例示したオペレーティング環境１００に示した構成要素のいずれか１つまたは組み合わせに依存したり、その条件が必要であると解釈されないものとする。
【００１９】
本発明は、その他多くの汎用または専用コンピューティング・システム環境またはシステム構成を使用して動作できるものである。本発明に使用するのに適切であることができる周知の計算機システム、環境、および／またはシステむ構成の例として、パーソナル・コンピュータ、サーバ・コンピュータ、ハンドヘルドまたはラップトップ装置、タブレット装置、多重プロセッサ・システム、マイクロ・プロセッサ・ベースのシステム、セットトップボックス、プログラム可能な家電機器、ネットワークＰＣ、ミニ・コンピュータ、メイン・フレーム・コンピュータ、上述のシステムまたは装置のいずれかを含む分散型計算環境などがあるが、これらに限定されるものではない。
【００２０】
本発明は、コンピュータによって実行されるプログラム・モジュールなどの、コンピュータ実行可能命令の一般的なコンテキストにおいて説明することができる。一般に、プログラム・モジュールには、特定のタスクを実行する、または特定の抽象データ・タイプを実施する、ルーチン、プログラム、オブジェクト、構成要素、データ構造などが含まれる。本発明はまた、通信ネットワークを介してリンクされているリモート・プロセッシング装置によってタスクが実行される分散型計算環境で使用されることもできる。分散型計算環境では、プログラム・モジュールは、メモリ記憶装置を含む、局所およびリモート・コンピュータ記憶媒体内に配置されることができる。
【００２１】
図１に関して、本発明を実施するためのシステムの例は、汎用コンピューティング装置をコンピュータ１１０の形で含んでいる。コンピュータ１１０の構成要素は、プロセッシング・ユニット１２０と、システム・メモリ１３０と、システム・メモリを含むさまざまなシステム構成要素をプロセッシング・ユニット１２０に結合するシステム・バス１２１とを含むが、これらに限定されるものではない。システム・バス１２１は、メモリ・バスまたはメモリ・コントローラ、周辺バス、およびさまざまなバス・アーキテクチャのいずれかを使用するローカル・バスを含む、数種類のバス構造のいずれかであることができる。例として、限定されるものではないが、このようなアーキテクチャは、業界標準アーキテクチャ（Industry Standard Architecture）（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（Micro Channel Architecture）（ＭＣＡ）バス、エンハンストＩＳＡ（ＥＩＳＡ）バス、ビデオ電子機器標準協会（Video Electronics Standards Association）（ＶＥＳＡ）ローカル・バス、加速グラフィックス・ポート（Accelerated Graphics Port）（ＡＧＰ）バス、メザニン・バス（Mezzanine bus）としても周知の、周辺構成要素相互接続（Peripheral Component Interconnect）（ＰＣＩ）を含む。
【００２２】
コンピュータ１１０は、一般に、さまざまなコンピュータ読取り可能媒体を備える。コンピュータ読取り可能媒体は、コンピュータ１１０によってアクセス可能な媒体であることができ、揮発性および不揮発性媒体、取り外し可能および取り外し不能媒体の両方を含む。例として、限定されるものではないが、コンピュータ読取り可能媒体は、コンピュータ記憶媒体と通信媒体を備えることができる。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造、プログラム・モジュールまたはその他のデータなどの情報を格納するための方法または技術で実施される、揮発性および不揮発性、取り外し可能および取り外し不能媒体の両方を備える。コンピュータ記憶媒体は、限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多目的ディスク（ＤＶＤ）またはその他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、またはその他の、所望の情報を格納するために使用され、コンピュータ１１０によってアクセス可能な媒体を備える。通信媒体は、一般に、コンピュータ読取り可能命令、データ構造、プログラム・モジュールまたはその他の、搬送波またはその他の移送メカニズムなどの変調データ信号内のデータを包含し、情報配信媒体を含む。「変調データ信号」という用語は、１つまたは複数の特性を有し、または情報を信号内に符号化する方式で変更された信号を意味する。例として、限定されるものではないが、通信媒体は、ワイヤード・ネットワークまたは直接ワイヤード接続などのワイヤード媒体、および音響、ＲＦ、赤外線およびその他のワイヤレス媒体などのワイヤレス媒体を備える。上述のもののいずれの組み合わせも、コンピュータ読取り可能媒体の範囲内に含まれる。
【００２３】
システム・メモリ１３０は、リード・オンリー・メモリ（ＲＯＭ）１３１やランダム・アクセス・メモリ（ＲＡＮ）１３２などの揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を備える。基本入力／出力システム１３３（ＢＩＯＳ）は、スタートアップ中などに、コンピュータ１１０内の要素間の情報の転送に力を貸す基本ルーチンを含み、一般にＲＯＭ１３１内に格納される。ＲＡＭ１３２は、一般に、ただちにアクセス可能および／または、現在、プロセッシング・ユニット１２０によって動作中のデータおよび／またはプログラム・モジュールを含む。例として、限定されるものではないが、図１は、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６およびプログラム・データ１３７を備える。
【００２４】
コンピュータ１１０はまた、その他の取り外し可能／取り外し不能、揮発性／不揮発性コンピュータ記憶媒体を備える。例示のためだけに、図１は、取り外し不能の不揮発性磁気媒体から読出し、そこに書き込むハード・ディスク・ドライブ１４１と、取り外し可能の不揮発性磁気ディスク１５２から読出し、そこに書き込む磁気ディスク・ドライブ１５１と、ＣＤＲＯＭまたはその他の光学媒体などの、取り外し可能の不揮発性光学ディスク１５６から読出し、そこに書き込む光学ディスク・ドライブ１５５とを図示している。例示のオペレーティング環境の例で使用することのできる、その他の取り外し可能／取り外し不能、揮発性／不揮発性コンピュータ記憶媒体は、限定されるものではないが、磁気テープ・カセット、フラッシュ・メモリ・カード、ディジタル多目的ディスク（ＤＶＤ）、ディジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭなどを含む。
【００２５】
ハード・ディスク・ドライブ１４１は、一般に、インターフェース１４０などの取り外し不能メモリ・インターフェースを介してシステム・バス１２１に接続し、磁気ディスク・ドライブ１５１および光学ディスク・ドライブ１５５は、一般に、インターフェース１５０などの取り外し可能メモリ・インターフェースによってシステム・バス１２１に接続する。
【００２６】
上記で説明し、図１に示した、ドライブおよびそれらの関連コンピュータ記憶媒体は、コンピュータ１１０のための、コンピュータ読取り可能命令、データ構造、プログラム・モジュールおよびその他のデータの記憶域を提供する。図１では、たとえば、ハード・ディスク・ドライブ１４１は、オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６およびプログラム・データ１４７を格納するものとして示してある。これらの構成要素は、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７と同じまたは異なるもののどちらでもあり得ることに留意されたい。オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７は、本明細書では、最小限で示してあるが個別の数量が与えられ、それらは異なるコピーである。ユーザは、コマンドおよび情報を、タブレット（電子ディジタイザ）１６４、マイクロホン１６３、キーボード１６２および通常マウス、トラックボールまたはタッチパッドと呼ぶポインティング・デバイス１６１、などの入力装置を介して、コンピュータ２０に入力することができる。その他の入力装置（図示せず）は、ジョイスティック、ゲーム・パッド、衛星放送用パラボラ・アンテナ（satellite dish）、スキャナなどを備えることができる。これらおよびその他の入力装置は、システム・バスに結合するユーザ入力インターフェース１６０を介してプロセッシング・ユニット１２０に接続することが多いが、パラレル・ポート、ゲーム・ポートまたはＵＳＢ（universal serial bus）など、その他のインターフェースおよびバス構造によって接続することもできるる。モニタ１９１またはその他の種類のディスプレイ装置も、ビデオ・インターフェース１９０などのインターフェースを介してシステム・バス１２１に接続される。モニタ１９１も、タッチ・スクリーン・インターフェース１９２などのインターフェースを介してコンピュータ・システム１１０への手書き（handwriting）など、ディジタル化した入力を入力することができるタッチ・スクリーン・パネル１９３などと統合されることもできる。モニタおよび／またはタッチ・スクリーン・パネルは、タッチ・スクリーン・パネル１９３が、本来タブレット１６４として働く、タブレット・タイプのパーソナル・コンピュータなどのように、計算装置１１０がその内部に組み込まれているハウジングに物理的に結合できることに留意されたい。さらに、計算装置１１０などのコンピュータはまた、出力周辺インターフェース１９４などを介して接続することができる、スピーカ１９５やプリンタ１９６などのその他の周辺出力装置を備えることができる。
【００２７】
コンピュータ１１０は、リモート・コンピュータ１８０などの１つまたは複数のリモート・コンピュータへの論理接続を使用するネットワーク環境で動作することができる。リモート・コンピュータ１８０は、パーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置またはその他の共通ネットワーク・ノードであることができ、図１ではただ１つのメモリ記憶装置１８１だけを示してあるが、一般に、コンピュータ１１０に関連して上述した多くのまたはすべての要素を有する。図１に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）１７１およびワイド・エリア・ネットワーク（ＷＡＮ）１７３を含むが、その他のネットワークも含むことができる。このようなネットワーキング環境は、オフィス、全社的なコンピュータ・ネットワーク、イントラネットおよびインターネット内で良く見かけるものである。
【００２８】
ＬＡＮネットワーキング環境を使用した場合、コンピュータ１１０は、ネットワーク・インターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続する。ＷＡＮネットワーキング環境を使用した場合、コンピュータ１１０は、一般に、インターネットなど、モデム１７２またはその他のＷＡＮ１７３を介して通信を確立するための手段を備える。モデム１７２は、内部または外部のいずれかであるが、ユーザ入力インターフェース１６０またはその他の適切なメカニズムを介してシステム・バス１２１に接続する。ネットワーク環境では、コンピュータ１１０またはその一部に対して示してあるプログラム・モジュールは、リモート・メモリ記憶装置内に格納される。例として、限定するものではないが、図１には、メモリ装置１８１に存在するリモート・アプリケーション・プログラム１８５を示してある。示してあるネットワーク接続は例示のためであり、コンピュータ間の通信を確立するためのその他の手段も使用可能であることは理解されよう。
【００２９】
メディア統合層アーキテクチャ（MEDIA INTEGRATION LAYER ARCHITECTURE）
本発明の一態様は、一般に、代表的なコンピュータ・システムに存在するグラフィックス・ハードウェアのパワーをより活用することに向けられる。この目的のため、図２に概略的に示されているように、メディア統合層アーキテクチャ２００が提供される。アプリケーション、制御またはその他同様のより高レベルのプログラム・コード（たとえば、オペレーティング・システム構成要素のユーザ・インターフェース）２０２が、１組のアプリケーション・プログラミング・インターフェース（ＡＰＩ）２０４などを介して、メディア統合層アーキテクチャ２００にアクセスして、グラフィカル情報にアクセス（書き込みまたは読出し）する。本明細書に記述した多くの例は、ＡＰＩとインターフェースをとるアプリケーション・プログラムを引用するが、その他のより高レベルのプログラム・コードおよび構成要素（たとえば、オペレーティング・システムのユーザ・インターフェース）も、本明細書に記述した、より低レベルの構成要素とインターフェースをとることができることが理解できることに留意されたい。したがって、このようなより高レベルのプログラム・コードへの如何なる引用も、アプリケーション・プログラムや、ユーザ・インターフェースなどのいずれであろうとも、均等物であると考えるべきである。
【００３０】
セキュリティを含むさまざまな理由から、メディア統合層２００（これは、グラフィックスを出力する）は、好ましくは、オペレーティング・システムに組み込まれることに留意されるべきである。たとえば、メディア統合層２００のいくつかまたは一部を、アプリケーションとオペレーティング・システムの間に挿入することができるが、そうすると、有害なプログラムが、グラフィックスが要求されている場合は何でもディスプレイすることを可能にし、それにより、不都合を引き起こすことになる。たとえば、有害なコードが、パスワードの入力を要求するダイアログ・ボックスを表示し、それにより、ユーザのパスワードを盗むことが可能となる。オペレーティング・システムにメディア統合層２００を組み込むその他の理由としては、安定性および効率性を含み、たとえば、より低レベルでは、より高い層からのデータおよび命令は既に検証済みであることを効率的に当てにすることができる。さらに、より低レベルは、責任を持ってコールをする、信頼されているオペレーティング・システムのみに、インターフェースを公開する、つまり、予測不可能なプログラムに低レベルのインターフェースを公開しないとすることができ、これにより、より高い安定性を保証することができる。
【００３１】
一実施形態では、メディア統合層アーキテクチャ２００は、高レベル合成およびアニメーション・エンジン２０６、タイミングおよびアニメーション構成要素２０８、および低レベル合成およびアニメーション・エンジン２１０を含む。本明細書で使用する用語、「高レベル」および「低レベル」は、その他のコンピューティング・シナリオで使用されるものと同様であり、ここでは、一般的に言って、より高い構成要素に対する低いソフトウェア構成要素は、その構成要素がより低くなるとハードウェアになる。このように、たとえば、高レベル合成およびアニメーション・エンジン２０６から送信されたグラフィックス情報は、低レベル合成およびアニメーション・エンジン２１０で受信されるが、ここで、情報は、グラフィックス・データをハードウェアを含むグラフィックス・サブシステムに送信するために使用される。
【００３２】
以下に記述するように、高レベル合成およびアニメーション・エンジン（本明細書では、高レベル・コンポジッタ（compositor）およびアニメータまたは高レベル・エンジンまたは高レベル構成要素とも呼ぶ）２０６は、ディスプレイ・ツリーを構築して、アプリケーション・プログラム２０２によって供給されるグラフィックス・シーンを表し、この間、タイミングおよびアニメーション構成要素は、宣言（またはその他の）アニメーションおよびタイミング制御を供給する。また以下に記述するように、低レベル合成およびアニメーション・エンジン（本明細書では、低レベル・コンポジッタおよびアニメータまたは低レベル・エンジンまたは低レベル構成要素とも呼ぶ）２１０は、多数のアプリケーションのシーンのためのレンダリングを組み立て、そしてレンダラ（renderer）とも呼ばれるレンダリング構成要素を使用して、スクリーンに対してグラフィックスのレンダリングを実際に実行する。しかし、時にはより高いレベルでいくつかのレンダリングをすることが必要および／または好都合である場合があることに留意されたい。たとえば、より低い層は、多数のアプリケーションからの要求にサービスするが、この間、より高い層は、アプリケーション毎にインスタンス生成される。これにより、より高いレベルで、時間のかかる、またはアプリケーション特有のレンダリングが可能となり、ビットマップへの参照をより低い層にパスすることができる。
【００３３】
一般的に言って、高レベル合成およびアニメーション・エンジン２０６は、ディスプレイ構造を構築し、構造をトラバースして、低レベル合成およびアニメーション・エンジン２１０にパスされるべき、レンダリング命令および単純なアニメーション間隔を生成する。高レベル・コンポジッタによって生成されるレンダリング命令は、タイミングおよびアニメーション情報を含むことができる。低レベル合成およびアニメーション・エンジン２１０は、レンダリング命令およびアニメーション間隔を受け取り、次いで、アニメーション、レンダリング、およびグラフィックス・サブシステム（たとえば、グラフィックス・ソフトウェアおよびハードウェア）２１２に供給されるシーンの合成、を管理する。
【００３４】
一方、または局所的に表示される出力に加え、高レベル合成およびアニメーション・エンジン２０６（またはそれと同様の）は、適切なフォーマットのレンダリングおよびアニメーション命令を、固定イメージ・データをプリンタ２２２などに送るためのより低レベルの印刷コード２２０に供給し、かつ／または適切なフォーマットのレンダリング命令および単純なアニメーション間隔を、より低レベルの、リモート・マシン２２８に送信する端末移送サーバ２２６に供給する。より豊富な情報もネットワークを介してパスされることに留意されたい。たとえば、ネットワーク・トラフィックを伴わずに、マウスのロール・オーバ効果をリモート・マシンに局所的に対処させるのが望ましいかも知れない。
【００３５】
多重グラフィックス処理レベル（MULTIPLE GRAPHICS PROCESSING LEVELS）
本発明の一態様に従うと、メディア統合層アーキテクチャ２００は、上に述べたように、グラフィックス処理を多数のレベルに分割する。これらのレベルのそれぞれが、アプリケーション、ユーザ・インターフェースおよびその他２０２が、スムーズなアニメーションでグラフィックスを出力し、その他のアプリケーションのグラフィックスおよびビデオ・フレームでグラフィックスを合成することを共に許可する、いくつかのインテリジェント・グラフィックス処理を実行する。アニメーションおよび／または合成を、音声出力に同期させることも可能である。たとえば、音声を低レベル構成要素のフレーム速度と同期させることにより、音声のタイミングが、ビデオまたはグラフィックスのタイミングと実質的に一致し、リフレッシュ速度に追いつくために複雑な前処理をするタスク・スケジュールについての能力に依存しなくなる。
【００３６】
図３に全体を示すように、ＡＰＩｓ２０４を介して通信するアプリケーション２０２の下で、高レベル・コンポジッタおよびアニメータ・エンジン２０６は、アプリケーション・グラフィカル・データをツリー構造３００内にキャッシュし、データをインテリジェントな方式で前処理し、その他数々のオペレーション（以下に記述する）を実行して複雑なグラフィックスの出力を容易にする。一般的に言って、高レベル・コンポジッタおよびアニメータ・エンジン２０６は、処理量を著しく単純化し、より低いレベルが正しい出力をレンダリングする処理に必要とされるデータ量を著しく減少させる、複雑な処理（時には、コンパイルと呼ぶ）を実行する。しかし、より高いレベルで実行される処理量および処理のタイプは、かなりの程度、負荷、およびより低いレベルの機器構成および機能に依存する。たとえば、高機能のグラフィックス・ハードウェアが存在する場合、高いレベルは、処理量が減少する可能性があり、またその反対もある。高レベルおよび低レベルの層はこれらの要因に適応的である。
【００３７】
本発明に従って、高レベル合成およびアニメーション・エンジン２０６は、そのレベルまたはそれ以下のレベルより比較的遅い速度で動作するので、利用可能なシステム・リソースを使い果たすことなく、このような複雑な処理を達成することができる。例として、限定するものではないが、より低いレベルは、ハードウェア・グラフィックス・プロセッサのフレーム（リフレッシュ）速度で動作することができる。たとえば、高レベル・コンポジッタおよびアニメータ２０６は、ディスプレイの変更を、オン・デマンドで、またはその他のスケジュール（たとえば、０．５秒毎に）で、実施する必要があるときに動作するだけとすることができる。単一の高レベル・コンポジッタおよびアニメータ・エンジン２０６は、図３に示してあるが、アプリケーション単位で１つずつなど、多くの場合があり、一方、一般には、グラフィックス装置毎に１つだけの低レベル合成およびアニメーションエンジ２１０である、たとえば、マシンのそれぞれのグラフィックス・ハードウェア・カードについて１つである、ことに留意されたい。
【００３８】
さらに、高レベル・コンポジッタおよびアニメータ２０６は、たとえば、実質的にいずれかの抽象装置３０２などの、適切なレベルまたはそれ以下のレベルのフォーマットに、その出力を適合させる（または出力するように設計する）。たとえば、高レベル・コンポジッタおよびアニメータ２０６は、最終的に、プリンタに、ネットワークを介していくつかの、その上にディスプレイするリモート端末に、送信するために、または、主に本明細書の以下に記述するが、ローカル・グラフィックス・ソフトウェアおよびハードウェア２１２上に存在する、より低レベルのコンポジッタおよびアニメータ２１０のために、コンパイルした出力を作り出すことができる。単一の高レベル・コンポジッタおよびアニメータが、複数の抽象装置のためのアプリケーションの出力を処理することができる、がそうでない場合、それぞれのタイプの抽象装置のためのアプリケーションの出力を処理する高レベル・コンポジッタおよびアニメータの適当な例、たとえば、ローカル・グラフィックスに１つ、プリンタに１つ、そして端末サーバに１つ、があり得る。
【００３９】
さらに、高レベル・コンポジッタおよびアニメータ２０６によって供給されるコマンドおよびその他のデータを単純化して、ハードウェアの能力および条件に一致させることができる。たとえば、より劣ったハードウェアであれば、高レベルの前処理が多く必要となる。さらにまた、たとえば、１または複数のより低いレベルに配置される処理需要に適応させるように、高レベルの前処理の量は動的とすることができる。
【００４０】
ローカル・グラフィックス出力のために、１機器構成内に、メディア統合層アーキテクチャ２００は、高レベル・コンポジッタおよびアニメータ２０６と、低レベル・コンポジッタおよびアニメータ２１０とを含む。以下に記述するように、一般的に言って、高レベル・コンポジッタおよびアニメータ２０６は、クライアントから受け取ったグラフィックス情報（たとえば、アプリケーション）について複雑な処理を実行して、グラフィックス構造を構築し、これらの構造をグラフィックス・コマンドのストリームに変換する。次いで、低レベル・エンジン２１０は、さまざまなクライアントからのグラフィックス・コマンドのストリームを使って、コンピュータのユーザが見るデスクトップを合成する。たとえば、低レベル・コンポジッタは、デスクトップ上に渡されるさまざまなクライアントによって放出されるコマンド・ストリームを結合して、グラフィックス合成エンジンによって消費されるグラフィックス・コマンドにすることにより、デスクトップを合成する。
【００４１】
この実施形態では、高レベル・コンポジッタおよびアニメータ２０６は、通常、グラフィックス・サブシステム２１２のグラフィックス・ハードウェアのハードウェア・リフレッシュ速度よりはるかに遅い速度で、構造３００を構築し、グラフィックス・コマンドのストリームに変換する、複雑な処理オペレーションを実行する。この高レベルな前処理の結果、低レベル・エンジン２１０は、グラフィックス・サブシステム２１２のグラフィックス・ハードウェアのハードウェア・リフレッシュ間隔内で、それ自体の処理オペレーションを実行することが可能となる。しかし、上述したように、低レベル・エンジン２１０は、高レベルの前処理が低レベルの処理需要に動的に適応できるようにするために、バック・チャネルを介して高レベル・エンジン２０６に戻りの通信をすることができる。低レベル・コンポジッタおよびアニメータ２０６から高レベル・コンポジッタおよびアニメータ２０６へのバック・チャネルは、主に、高レベル・エンジン２０６へのフロー制御（低レベル・エンジン２１０は、より多くのデータを必要とするか、または余りに多くを受信していることをシグナリングする）、および／または高レベル・エンジン２０６によって実行可能なエラー条件を通信するためである。このような通信の１つの利点として、低レベル合成およびアニメーション・エンジン２１０が、優先度やスケジューリングの心配をする必要がないことであるが、リフレッシュ速度との同期の問題は、依然残る。その代り、現代のオペレーティング・システムに既に存在する高レベルのＣＰＵプロセス・スケジューリングは、優先度を制御するだろう。したがって、たとえば、アプリケーション・プロセスが、その優先度と比べて、高レベルのグラフィックス前処理のその配分について余りに多くを使用しようとした場合、その出力に悪影響が出るのはそのアプリケーションである。しかし、低レベル・システムが過負荷である場合は、あるプロセス／高レベル構成要素の変更および要求を、別のものより優先させるよう選択することができる。たとえば、前景アプリケーションに優先度を与えることができる。
【００４２】
高レベル・コンポジッタおよびアニメータ（THE HIGH-LEVEL COMPOSITOR AND ANIMATOR）
一実施形態では、現実的に、多くの種類や差異のあるグラフィックス・ハードウェアに対処するように、それぞれのユーザ・アプリケーションを書き込むことができないため、高レベル・コンポジッタおよびアニメータ２０６を含むメディア統合層２００が、所与のマシンのハードウェアの差を調整する。しかし、アプリケーションは、また、メディア統合層２００によって、つまり、オペレーティング・システムのグラフィックスＡＰＩに、現在パスされるものより多くの（そして異なる）情報を高レベル・コンポジッタおよびアニメータ２０６に供給することによって、提供される改良グラフィックス処理に貢献することもできる。たとえば、メディア統合層２００を認識しているアプリケーションは、メディア統合層ＡＰＩ２０２を介してアニメーション意図などを含む、種々のデータを供給する。例示として、やや変化するイメージを連続して再描画することによってアニメーションを実行する代りに、アプリケーションは、特定のイメージを、たとえば、固定の背景に対して、どのように時間をかけて移動すべきかについての命令を提供することができる。次いで、メディア統合層２００は、以下に概略を記述するように、スムーズなレンダリング方式でオートメーションを処理する。
【００４３】
一般的に、図３および４に示すように、アプリケーション２０２は、ＡＰＩ２０４を介してシーン・グラフ・データ構造を構築する。データは、高レベル構造およびと基本要素（primitive）データを有し、そしてビジュアル情報をインテリジェントな方式でキャッシュに入れるため使用されるキャッシュ・データ構造３００、内に入れられる。
【００４４】
インテリジェント・キャッシング・データ構造３００全体内のオブジェクト（または構造）の１つが、コンテナ４０２、４０４または４０８（あるいはビジュアル２Ｄと呼ぶ）で図４に示したコンテナである。一実施形態では、コンテナ（たとえば、４０４）が、アプリケーションがそれのためのハンドルを保持することができる、そして、アニメーションおよびテンプレーティング、ヒット−テスト（hit-testing）およびユーザ・データのフッキング・アップ（hooking up）のために使用できる手続きパラメータを含む、識別（identity）を提供する。しかし、本明細書に記載したコンテナは、明らかにされる可能性のある唯一の種類のコンテナではないことに留意されたい。その他の例では、パラグラフ内にラインを格納するため、またはグリッド内に多くの子を格納するために最適化されたコンテナを含むことができる。特定の種類のコンテナでは、子に対してランダム・アクセスができないものの、子コンテナは、現行の子リストをクリアすることなく、追加されたり削除されたりできる。ＡＰＩを介して使われる構造は、必要に応じて変更することができる。
【００４５】
このデータ構造のその他の（内部）ノードは、変換４０６、アルファ・ノード、キャッシュ・ノード、および基本要素ノード４１０、４１２を含み、ＡＰＩコンテナと直接には関連していない内部データを格納するために使用される。基本要素は、一般に、直接グラフィックス装置にパスできる命令のストリームとして格納される。
【００４６】
図５のツリー・セグメント５００に示すように、５１０のようなコンテナは、したがって、その他のコンテナ５１２または描画基本要素５１６を保持でき、ここで、いずれかのコンテナの中の基本要素の記憶域は、グラフィックス命令のストリームと考えることができる。コンテナは、また、その他のコンテナも格納することができ、事実上、グラフを作成する、たとえば、データ構造がコンテナの「閉路を含まない有向グラフ（ＤＡＧ）」および基本要素のリストである（ここで、コンテナは、その親コンテナの１つを含むことができない）ように、コンテナを１を越えるコンテナによって参照されることができる。また図５に示すように、グラフ的な方式でツリーが他のツリーを参照できることにより、ツリー・セグメント５０２内のコンテナ５１８などの、コンテナのいずれかを、異なるパラメータではあるものの、異なる場所で再使用することができる。
【００４７】
一般に図４の描画コンテキスト４１６に示すように、コンテナが、開／閉パターンを介して置かれている。より詳細には、より高レベルのコード２０２が、データ構造内のコンテナ４０８を開け、描画コンテキスト４１６を提供して、描画基本要素を書き込み、かつ／またはその他のコンテナをデータ構造に追加し、次いでコンテナ４０８を閉じる。一代替実施形態では、コンテナを閉じたとき、そのデータは、変更待ち行列４１８内に入れられ、次いで、その後適用される。コンテナの開閉は、データ構造を変更するための主要メカニズムの１つである。その他の使用パターンも、特に異なる種類のコンテナについて、用いることができることに留意されたい。
【００４８】
この代替形態では、データ構造の変更が待ち行列に入れられるため、データ構造を更新するためのトランザクション的な（またはバッチ的な）システムが、可能となる。その結果、コンテナを開けてコンテナに書き込んだときは、コンテナを閉じるまでスクリーン上に変更が現れない。スクリーンへの変更はアトミック（ａｔｏｍｉｃ）であり、部分的に描画したスクリーンについて時間的アーティファクト（構造的なティアリングとも呼ぶ）はない。さらに、このようなトランザクションの動きを、一度に多数のコンテナが変更されるように、拡張することができる。この方式で、より高レベルのコード２０２は、多くの変更をシーンにセットアップすることができ、これらの変更の全てを一度に適用できる。
【００４９】
一代替実施形態では、待ち行列４１８への変更をディスプレイ・マネージャ４２０を介して通知することにより、データ構造への変更が、非同期式で行われる。その結果、変更がレンダリング・スレッド４２２上で処理される、そして、たとえば、低レベル・コンポジッタおよびアニメータ２１０に送信される（ここで、図３の抽象装置３０２は、低レベル・コンポジッタ２１０にストリームされたレンダリング・コマンドの中に、高レベル・コンポジッタ２０６によって出されたレンダリング・コマンドの変換をカプセル化する抽象化を含む）。トランザクション的なモデルは、また、データ構造への修正が、データ構造からの読出しを中断することなく、なされることを可能にする。上述の待ち行列モデルにより、高レベル・エンジン２０６からの読出しパスが、ユーザの行うどのようなアクションにも関係なく動作できるようになるが、ユーザ・アプリケーションは、ＡＰＩの一貫性のあるビューを維持するために、キャッシュが必要であり、そのため効率性が損なわれる。例として、コンテナ上のプロパティの設定をする主要ユーザ・スレッド上のユーザ・アプリケーション（高レベル・エンジン２０６内のオブジェクト）を考えてみよう。待ち行列モデルでは、このプロパティは、高レベル・エンジン２０６データ構造に適用される待ち行列の中に入れられる。しかし、ユーザ・アプリケーションが、直ちにそのプロパティをコンテナからリード・バック（read back）を試みると、システムは、現在待ち行列内にあるものに基づいてプロパティをリード・バックし（これは非効率的である）、レンダリング・スレッドと同期をとり、待ち行列内で待っている変更を適用し（これは非効率的であり、待ち行列を有するという利点を無駄にするものである）、または、レンダリングのバージョンおよび待ち中のバージョンの両方とも、ユーザ変更可能データのコピーをコンテナに保管しなければならない（これは、非効率的なメモリの使用法である）。
【００５０】
アプリケーションによるリード・バック量がかなりあるため、代替実施形態は、実際のところ、高レベル・エンジン２０６データ構造および主要ユーザ・スレッドの更新を同期することにより、待ち行列を削除する。このことは、ユーザ・アプリケーションがレンダリングを凍結できるようにするが、全体的なシステムは、より効率的になる。しかし、凍結（freeze）による知覚的な影響を緩和するために、高レベル・エンジン２０６とは関係なく、より多くのアニメーション処理をする低レベル・エンジン２１０に任せている間、さまざまな部分のアニメーションおよびタイミング・システムが独自に動作して、低レベル・エンジン２１０まで情報を通信する。したがって、高レベル・エンジン２０６が、ユーザによるアクションによって凍結しても、スクリーンへの出力は、依然として、比較的スムーズで、かつ一貫性があるでしょう。
【００５１】
さらに別の代替形態では、レンダリング・スレッドを削除し、主要ユーザ・スレッドに高レベル・エンジン２０６にとって必要な処理を実行させ、レンダリング命令を低レベル・エンジン２１０にパスさせるようにする。これは、場合によっては、より効率的なスレッドの使用法である。
【００５２】
図４に戻ると、コンテナ４０８は、描画基本要素を含む基本識別ノードを備え、描画コンテキスト４１６は、基本要素、変換、クリップまたはその他の描画オペレーションをコンテナに追加するために使用することのできる、コンテナから得られたグラフ・ビルダ（たとえば、ヘルパ・オブジェクト（helper object）を備える。ディスプレイ・マネージャ４２０は、高レベル・コンポジッタおよびアニメータ２０６のインスタンスを表す、ホスティング・オブジェクトを備える。そして、たとえば、ｈｗｎｄ（ウィンドウへのハンドル）またはｈｖｉｓｕａｌ（ビジュアル・コンテナへのハンドル）にアタッチすることができる。ディスプレイ・マネージャ４２０は、シーンのためのルート・コンテナ４０２へのポインタを有し、コンテナが無効で再描画の必要がある場合に、イベントを高レベル・コードにディスパッチし、ヒット・テストや座標変換などのサービスへのアクセスを提供する。
【００５３】
より高レベルのコード２０２は、ハンドルなどを、データ構造およびコンテナ内のオブジェクトのいくつかに保持できるが、コンテナ内の殆どのオブジェクトは、アプリケーションの観点からの識別性を持たない。具体的には、この構造へのアクセスが、殆どの使用パターンが「書き込みに限る」という制限がなされている。この方式で識別を制限することにより、データ構造内に格納された情報の多くを最適化できるようになり、そしてより高レベルのコード２０２は、オブジェクト情報を格納したり、オブジェクトの生存期間の管理に対処したりする必要がなくなる。
【００５４】
たとえば、必要でないグラフの一部（たとえば、スクリーンにクリップされてしまった、またはスクリーンからスクロール・オフされたビジュアル情報に対応する）を維持するリソースは、その後必要になればシーンを再描画するよう要請するアプリケーションとともに、再利用することができる。したがって、一般に、コンテナが開けられると、その中身がクリアされ、忘れ去られている。これらの中身が識別を持たない場合は、それらのリソースはシステムによって再利用することができるように、これらのコンテンツは安全に消滅する。より高レベルのコード２０２またはグラフの別の部分が子コンテナ上にホールドしている場合は、これらのコンテナは、そのあたりに留まって、再挿入することができる。しかし、このパターンは、より高レベルのコード２０２の必要性に応じて、変更および適応が可能である。
【００５５】
したがって、要するに、コンテナは、データ構造を使用する高レベル・コードがそのオブジェクトに対するハンドルを保持することができるという点で、識別を持つオブジェクトである。識別を持つオブジェクトの反対は、プレーン・データであり、そして、ユーザ・コードは、識別を持たないデータをオブジェクトとして扱うメンタル・モデルを用いるが、いったんこのデータがシステムで使用されると、その後そのオブジェクトを参照する方法はない。このように、システムにとって好都合な方式で、オブジェクトは、変換され、そして変更されることができる。
【００５６】
単純化した例として、テキストのラインを描画するためのＡＰＩ機能が、ＴｅｘｔＬｉｎｅオブジェクトを含むことがある。このオブジェクトのユーザは、ＴｅｘｔＬｉｎｅオブジェクトに、描画すべき実際のテキストを、そのテキストについての種々の動作をどのようにレンダリングするのかに関するその他の情報（フォント、サイズ、ブラシその他）とともに、入れる。ユーザ・プログラム・コードが、そのテキストのラインをデータ構造に実際に追加することを求めている場合、プログラム・コードは、指定の開くノード用に描画コンテキストを取って、ＴｅｘｔＬｉｎｅオブジェクトを描画コンテキスト上にある描画機能にパスする。実際にシステムは、ＴｅｘｔＬｉｎｅオブジェクト内にあるデータを取り、そのデータをデータ構造内にコピーする。このデータは識別を持たないため、高レベル・コンポジッタおよびアニメータ・エンジン２０６は、自由にそのラインのコンテンツを取ることができ、アルゴリズム（たとえば、ＯｐｅｎＴｙｐｅ）を実行してテキストを位置付きのグリフに分割して、位置付けられたグリフ・データを、生のテキストの代りに格納する。そのラインを描画した後は、システムは、ラインを描画するのに使用するＴｅｘｔＬｉｎｅオブジェクトへの参照を持たない、すなわち、システムが格納するデータは識別を持たない。
【００５７】
あるいは、より高レベルのコード２０２は、その識別をそのＴｅｘｔＬｉｎｅオブジェクトに保存するよう要請し、そのオブジェクトの参照をデータ構造内に格納するよう要求する。この方式で、より高レベルのコード２０２は、その後ＴｅｘｔＬｉｎｅオブジェクトを変更する場合、システムは、その変更を発見し、それをレンダリングの出力に反映する。より現実的な例においては、識別は、テキスト・ライン・オブジェクト自体には明らかにされないが、アプリケーションが、コンテナへのハンドルを保持し、上述した（例えば、特許文献２参照）という米国特許出願に記述しているように、要求のあり次第、そのコンテナをパラメータ化することによって変更をすることになる、ことを留意されたい。しかしながら、データ構造の主要態様の１つに、より高レベルのコード２０２は、このようなオブジェクトを識別を備えて作成する必要性を減少させることにあり、それによって、データ構造内の低減された数のポイントが、制御コード２０２によって参照されることになる。このことにより、データ構造がより一層最適化される。
【００５８】
たとえば、データ構造の外部に明らかにされる識別の量の低減により、基本要素の格納密度を濃くするなどの最適化が可能となる。この目的のため、ベクトル・グラフィック・データは、「基本要素リスト」または「基本要素コンテナ」内に格納される。これらのコンテナは、実施詳細であり、識別がより高レベル・コード２０２に明らかにされることはない。コール元がデータをコンテナ内に書き込むと、そのデータは、コンテナのような、リンクされている別個のオブジェクト内に格納されるか、（たとえば、変換とともに）、パック、およびフラット化されたデータ・アレイ内にストリームする、ことができる。このアレイは、コンパクトな方式でベクトル・グラフィック・データを格納できるばかりでなく、これらの基本要素に沿って実行するリソースを追跡することができる。個々の基本要素が識別を持たないため、基本要素を分離したり、その後これらの基本要素を変更したりするための方法をユーザに提供する必要がなく、基本要素のより効率的な格納を可能にする。
【００５９】
別の最適化として、サブグラフが変化していない場合は、そのツリーのコンテンツのビットマップを格納し、そのビットマップをコンテナにアタッチすることができ、それによって、必要とされる高レベルの処理量を減らすことができる。さらに、サブグラフまたは基本要素リストの一部が、レンダリングのために、より低レベルのコードにパスされる前に大量の処理を必要とする場合（たとえば、ハードウェア装置に手渡される前の、ベクトル・グラフィックスの埋め尽くし）は、その後の再使用のために、後処理の結果がキャッシュに入れられる。
【００６０】
さらに、特定の読出しオペレーション（以下に記述する）以外に、構造についての明らかにされることがないため、データ構造は、レンダリングの結果が同じである限り、自由にコンテナを再編成することができるようにする。したがって、コンテナは、空間区画化（space partitioning）ツリー内に子コンテナを格納して、レンダリングおよびその他の読出しオペレーションを最適化することができる。さらに、データ構造を、同じ装置または多数の装置に何回も表示することができる。このため、キャッシュが装置に依存している場合は、装置に基づいてキーを付けることができる。サブ−ツリーが静的であると認識されると、その周囲のアニメーションのため何度も再ペイントされ、しかもそのリソースのドレーンを保証するに足りる密度である場合は、キャッシュ・ノードは、自動的にそのサブ−ツリーに挿入されることがある。
【００６１】
レンダリングのために、データ構造が読み出され（スケジュールしておいた時間に、または異なるスレッドによって）、そして処理されたあるフォームの情報は、より低レベルのアニメータおよびコンポジッタ２１０にパスされる。このため、一代替実施形態では、レンダリング・オブジェクトおよびスレッド（プロセス毎の）４２２が、データ構造３００をトラバースしてレンダリング・プロセスを駆動する。他の代替形態では、それ自身のスレッドで実行する代りに、レンダリング・プロセスが、１種の「協調型多重タスキング」配置で、残りのユーザ・コードを持つ共通スレッドと時間を分配する。データ構造３００は、非常に高速の合成およびアニメーションのために、より低レベルの構成要素に送られるビジュアル情報にコンパイルされるのが好ましいが、データ構造３００を直接レンダリングに使用することができる。データ構造３００は、また、ネットワークを介して、リモート端末、プリンタに送信し、かつ／または、相互交換またはキャッシュに入れるためにディスクまたはその他のよりパーマネントな記憶媒体に直列化する、などの異なる方式でコンパイルされることがある。
【００６２】
一代替実施形態では、データ構造３００は、レンダリングのために別のスレッド４２２で読み出される。しかし、別のスレッドを使用することが必要条件ではなく、たとえば、「レンダリング・スレッド」は、あるいは、他と同様に、同じスレッド上で実行する協調型共用メカニズム（cooperative sharing mechanism）を、代替的に備えることに留意されたい。
【００６３】
レンダリング・プロセス／スレッドを使用する代替モデルでは、必要に応じてレンダリング・スレッドが動作し、所定の効果を提供する。スレッドが動作する度ごとに、まず、変更待ち行列４１８内にある、待ち状態の変更を適用する。次いで、レンダリング・スレッド４２２は、データ構造３００を歩いて、バウンディング・ボックスや収集無効などの（以下に記述する）情報を収集する。最後に、前回より変更されている、または別の理由からレンダリングする必要があるエリアを歩き、データ構造内に格納されているレンダリング命令を実行する。変更待ち行列を使用しない代替モデルでは、変更は、作成されるときに、直接適用され、したがって、ここでは適用する必要がない。
【００６４】
このように、データ構造３００からのレンダリングは、待ち行列にある変更をデータ構造に適用するパス、データ構造の繰返し、あるいはバウンディング・ボックス、アニメーションされるパラメータ値などレンダリングに必要なデータの計算、を含む事前計算するパス、レンダリング・パス、などの、別個のレンダリング・スレッド４２２上で実行できる多数のパス・プロセスである。レンダリング・パスは、最終的に低レベル・コンポジッタおよびアニメータ２１０にデレゲートする抽象装置３０２を使用して、レンダリングする。レンダリング・パス中、後続フレーム上のレンダリング性能を向上させるために、中間キャッシュ・リソース４２６を、キャッシュに入れることができる。
【００６５】
データ構造を最後に歩き回って得られる可能性のある結果には、データを直接実行して、スクリーン上に表示されるか、または最後に歩き回った最後の所にフリップされるバック・バッファ上で実行されることが含まれる。その他の結果には（以下に記述するように）拡張タイミングおよびアニメーション情報とともに運ばれ、より頻繁に実行するレンダリング・スレッド／プロセスにパスされるデータが含まれる。また、歩き回った結果、スクリーン・キャプチャまたはその他の理由によりデータがビットマップ上で実行されたり、プリンタに方向付けされたり、または、ネットワークに方向付けされて、次いでリモート・マシンでの以前のある理由のために使用されたりすることもある。これらの結果の組み合わせも、また、可能である。
【００６６】
お分かりのように、データ構造３００内のデータの記憶域は、大量のメモリを必要とする。さらに、データ構造３００内のデータの多くは、クリップ、スクロール、またはその他の理由により、可視可能ではないために必要とされないことがある。リソース需要を減らすため、データ構造３００は、オン・デマンドで構築することができる。これを可能にするために、必要に応じて、データ構造３００の一部を作成するため、より高レベルのコード２０２にコール・バックする方法が提供される。この方法は、「無効化」と呼び、従来のグラフィックス・システムで使用されるＷＭ＿ＰＡＩＮＴコール・バック方法と同様であるが、直接スクリーン上のビットに適用する代りに、構造３００およびキャッシュされるコンテンツに適用される。しかし、１待ち行列モデル代替形態では、読出しオペレーション（以下に記述する、ヒット・テストおよび座標変換と同様）は最初に変更を適用し、それゆえ、ユーザに提供されるモデルは同期する。
【００６７】
コンテナは、作成されたとき、リソースが少ないためコンテンツがシステムによって捨て去られたとき、またはより高レベルのコードがコンテナを無効にするよう直接要請したとき、無効にされる場合がある。たとえば、より高いレベルのコード２０２は、コンテナを作成して、そのコンテナがどこにあって、どのぐらいの大きさであるのかを定義するグラフィカル・サイズを供給する。レンダリング・オペレーション中、そのコンテナが無効というマークが付けられたが、必要であると判断された場合、レンダリング・スレッド４２２は、より高レベルのコード２０２にコンテナ内に書き込むよう要請する。レンダリング・スレッド４２２は、より高レベルのコード２０２がその要請を終了するまで待つか、または必要なデータがないままレンダリングを続行する。第１の選択は理想的なものではないが、状況によっては必要となる場合がある。
【００６８】
最終的にデータが書き込まれ、レンダリング・スレッド４２２が再び実行して、これらの新しい変更を表示する。現行の一実施形態では、コンテナへの書き込み要請は、別の待ち行列内に入れられ、より高レベルのコード２０２を実行しているスレッドに戻る。しかし、このことは、レンダラが実行している同じスレッド上の、より高レベルのコード２０２への同期コールを含む、他の方式で実施することもできる。しかし、このようなコールを同期させることにより、レンダリング・スレッドを機能停止することになる。
【００６９】
データ構造３００への待ち行列更新に加えて、データ構造３００からのリード・バック・サービスを提供する必要がある。このようなサービスには、ヒット−テスト、ポイント変換およびサブグラフ・サイジングが含まれる。
【００７０】
ヒット−テストとは、それによって、ポイントが、データ構造のいくつかのルートの座標空間に与えられ、データ構造がプローブされて、そのポイントによってヒットされるコンテナまたは基本要素が戻されるようにするプロセスである。現行実施形態では、ヒット−テスト・プロセスは、それぞれのコンテナ内に格納された３つのフラグの値によって制御される（追加フラグも可能であるが）。第１のフラグには、ヒット−テスト・アルゴリズムに命令を出して、これまでに収集したヒット・テストの結果を戻す設定が含まれる。第２のフラグには、ヒット−テスト・アルゴリズムに対して、ヒットされているそのポイントがそのコンテナに確かに存在する場合は、結果リスト内にそのコンテナを含むよう伝えることが含まれる。第３のフラグは、そのコンテナの子をヒット−テストすべきかどうかを制御する。
【００７１】
別の読出しサービスはポイント変換であり、ここで、グラフを介して接続する２つのノードがある場合、あるコンテナの座標フレーム内のポイントが、別のコンテナの座標フレームに変換できるサービスがある。先祖から子孫、子孫から先祖、ピア・ツー・ピア（任意のノードから別の任意のノード）の変換を含む、３つの一般的なサブタイプがある。したがって、読出しサービスは、座標変換のためデータ構造を問い合わせる方法を提供し、ツリー・アーキテクチャが変換を歩き回り計算することを促進させる。多くの変換を実施中は、アニメーション／変更をロックできる。そして、共通の先祖を介する変換の実行を提供することができる。
【００７２】
別の読出しサービスは、サブグラフ・サイジングである。ノードが与えられると、このサービスは、そのノードとそのサブグラフのグラフィカル・サイズを戻す。このサイズは、サブグラフを入れるのに十分な大きさがあるという保証されたサイズであるか、またはサブグラフを入れるのにちょうどの大きさの別のサイズの形状である場合もあり、またはサブグラフの輪郭を詳細に表す複雑な形状でもあろう。
【００７３】
ある実施形態では、これらの読出しオペレーションをデータ構造への変更に同期させたい場合がある。このため、これらの読出しオペレーションのいずれかを呼び出す前に、変更待ち行列が適用されると、より一貫性のあるビューが、より高レベルのコードに与えられる。
【００７４】
低レベル・コンポジッタおよびアニメータ（THE LOW-LEVEL COMPOSITOR AND ANIMATOR）
低レベル・アニメータおよび合成エンジン２１０の主な目的は、メディア統合層２００の低レベル・レンダリング・スタックの抽象化を提供することであり、これによって、（１）クライアント・グラフィックス・アプリケーションのための高フレーム速度アニメーション、（２）ウィンドウ管理的なサポートの実施、（３）ネットワーク接続を介したグラフィックス・サービスの遠隔操作（remoting）へのサポート、を可能にする。図６および７に示すように、低レベル・アニメータおよび合成エンジン２１０は、レンダラ６０２の集合によって提供されるサービスを使用することにより、特に、多数のクライアントから受取る高フレーム・レート・アニメーション要求を調整するためサーバとして機能する（たとえば、それぞれ高レベル・コンポジッタを有する多くのアプリケーションに対応する）。レンダラ６０２は、グラフィックス合成エンジン６０６によって実施されるレンダリング抽象化（ビジュアルとも呼ぶ）上で働くレンダリング・アクションを生成する。
【００７５】
低レベル・アニメータおよび合成エンジン２１０はまた、特別のクライアント（トップ・レベルのビジュアル・マネージャ６０４）が、スクリーン上のレンダリング・エリアとして、クライアント・アプリケーションによって使用されるビジュアルを操作できるようにすることが目的のインフラストラクチャを備えて、トップ・レベルのビジュアル管理サポートを提供する。レンダリング・スタックへレンダリングするクライアント・アプリケーション２０２１−２０２３（図７では３つしか示していないが、いずれの数でもあり得る）のそれぞれが、トップ・レベルのビジュアル（それぞれ、ＴＬＶ１−ＴＬＶ３）を所有し、トップ・レベルのビジュアル・マネージャ６０４は、スクリーン上にトップ・レベルのビジュアルのレイアウト上にオーソリティを有するクライアントである。一般的に言って、低レベル・アニメータおよび合成エンジン２１０は、デスクトップ上に渡されるさまざまなクライアントによって放出されたコマンド・ストリームを結合して、グラフィックス合成エンジン６０６によって消費されるグラフィックス・コマンドにすることによって、デスクトップを合成する。低レベル・アニメータおよび合成エンジン２１０はまた、ローカル・マシンと同様のリモート・マシン６１０１−６１０ｎのためのユーザ・インターフェースをプログラミングするレンダリング・アーキテクチャを実施するために使用する構成要素を援助（help）する。
【００７６】
図７は、低レベル・アニメータおよび合成エンジン（サーバ）２１０とそのクライアントの間の相互作用を示す図である。上述したように、トップ・レベルのビジュアル・マネージャ６０４もクライアントである。またこれも上述したように、低レベル・アニメータおよび合成エンジン２１０のクライアント２０２１−２０２３は、高レベル・コンポジッタおよびアニメーション・エンジン２０６のインスタンスを使用して、グラフィックス構造を構築し、これらを、ビューされるデスクトップを合成するために低レベル・アニメータおよび合成エンジン２１０が使用する、グラフィックス・コマンドのストリームに変換する。一実施形態では、ローカルまたはリモート・マシンのいずれかで実行するクライアント（たとえば、高レベル・コンポジッタ）によって出されるコマンド・ストリームを取り扱う、ただ１つの低レベル・アニメータおよび合成エンジン２１０がある。
【００７７】
図６に戻ると、プロセス間通信が、低レベル・アニメータおよび合成エンジン（サーバ）２１０によって維持されるプロパティ・システム６１４を介して実行される。それぞれのトップ・レベル・ビジュアルに関連付けられるプロパティが、このプロパティ・システム６１４によって格納される。クライアントは、これらのプロパティを書き込み読出しすることができ、またクライアントは、プロパティ値の変更要請があれば、その通知を受けることができる。
【００７８】
低レベル・アニメータおよび合成エンジン２１０は、クライアント−サーバ通信、高速アニメーション・レンダリング、およびトップ・レベル・ビジュアル管理サポートを提供する。一実施形態では、低レベル・アニメータおよび合成エンジン２１０とクライアントの間の通信が、単一の双方向バイト・ストリームおよび／または共有メモリを介して起きる。バイト・ストリームについては、ローカル・クライアントはプロセス間通信を使用し、リモート・クライアントはネットワーク・バイト・ストリーム接続を開ける。バイト・ストリームは、クライアント・サーバ相互作用を制御する通信プロトコルのトランスポート層である。
【００７９】
通信プロトコルには、３つの主要メッセージ、つまり、要請（request）、回答（reply）およびイベント・メッセージが含まれる。エラー・メッセージも、提供される。クライアントからサーバへの通信は、主にレンダリング命令を含み、サーバからクライアントへの通信は、主に、以下に記述する、応答およびエラー・メッセージの形のフィードバックである。
【００８０】
クライアントからサーバに要請が生成され、そしてその要請は、トップ・レベル・ビジュアル管理コマンド、レンダリング命令コマンド、およびタイミング間隔コマンドを含むことができる。回答は、要請に応じてサーバからクライアントに送信される。しかし、すべての要請が回答を受けるわけではないことに留意されたい。回答は、情報を探す適切な要請に応じてのみ生成される。たとえば、描画命令は、回答を必要としない。しかし、「Ｇｅｔ  Ｗｉｎｄｏｗ  ｓｉｚｅ」要請は、回答を必要とし、回答を受取る。
【００８１】
イベントが、サーバからクライアントに送られ、そしてそのイベントは、装置のアクションまたは前の要請の副作用に関する情報を含む。たとえば、サーバは、リソースを無効にするため、またクライアントに目標フレーム速度を伝えるために、イベント・メッセージをクライアントに通信することができる。目標フレーム速度を通信する機能により、可変フレーム速度が可能となる。これは、高いフレーム速度というよりも、一貫性のあるフレーム速度を確実にするために望ましいことである。
【００８２】
エラーもまた、クライアントに送られる。エラーはイベントと同様であるが、一般に、たとえば、エラーを補償するために、クライアントによって異なる取り扱いを受ける。
【００８３】
クライアントが、低レベル・アニメータおよび合成エンジン２１０によって供給されるサービスを使用することができる前に、クライアントは、まず最初に、接続マネージャ７１０によって提供されるエントリ・ポイントを介してエンジン２１０に接続する（図７）。接続マネージャ７１０は、クライアント・サーバ・プロトコルの双方向バイト・ストリーム・トランスポート層をカプセル化する通信オブジェクト（たとえば、７１２１）を割り当てる。これはまた、命令ストリームを介して到来するレンダリング命令の追跡をし、それらを正しいビジュアルに関連付ける命令リスト・マネージャ（たとえば、７１４１）も割り当てる。
【００８４】
いったん接続が確立されると、クライアント２０２は、トップ・レベル・ビジュアルの作成を要請する。その要請に応答して、低レベル・アニメータおよび合成エンジン２１０は、グラフィックス合成エンジン６０６によって提供されるサービスを使用することにより、トップ・レベル・ビジュアル（たとえば、ＴＬＶ１）を作成する。そのクライアントのために低レベル・アニメータおよび合成エンジン２１０によって維持されるビジュアルは、ツリー構造７１８内で編成される。クライアントが、トップ・レベル・ビジュアルとともになされる場合は、クライアントはその破壊を要請する。ルート・ノード７２０は、デスクトップのバック・グラウンドを表す特別なビジュアルであり、ルート・ビジュアルの子はトップ・レベル・ビジュアルであることに留意されたい。
【００８５】
図７に示すように、低レベル・アニメータおよび合成エンジン２１０の１つの重要な役割は、コンピュータ・デスクトップへのレンダリングを管理することであり、これは、別の２つの構成要素、つまり、グラフィックス合成エンジン６０６とレンダラ６０２の集合のサービスに頼ることによって達成される。グラフィックス合成エンジン６０６は、低レベル合成サービスを、ビジュアルと呼ぶレンダリング抽象化を介して提供する。ビジュアルは、デスクトップに構成される長方形のレンダリング・エリアであり、グラフィックス合成エンジン６０６によって供給される１組のＡＰＩを介してレンダリングされることができる。デスクトップを合成する時間になると、レンダリング・パス・マネージャ７２２は、ツリーを左から右へトラバースして、それぞれのノードに対して、レンダリング構成要素を使用してビジュアルにレンダリングする。
【００８６】
トップ・レベル・ビジュアルの生存期間管理に加えて、低レベル・アニメータおよび合成エンジン２１０はまた、トップ・レベル・ビジュアル装飾をサポートし、実質的にはデコレーションをトップ・レベル・ビジュアルの回りに追加する。装飾７３０１−７３０３は、レンダリング命令リストの形のトップ・レベル・ビジュアル・マネージャによって供給されるデコレーションをレンダリングするビジュアルである。これらのビジュアルは、それらの属するトップ・レベル・ビジュアルの子である。クライアント（たとえば、アプリケーション）は、予め定義されたプロパティをトップ・レベル・ビジュアル上に設定することにより、トップ・レベル・ビジュアル・マネージャによって提供された装飾を制御することができる。
【００８７】
低レベル・アニメータおよび合成エンジン２１０はまた、トップ・レベル・ビジュアルのためのサービスを最小限に抑えるサポートもし、これも、トップ・レベル・ビジュアル・マネージャ６０４によって、レンダリング命令リストの項において供給されることができる。トップ・レベル・ビジュアル位置付け、サイジング、およびＺオーダ（Ｚ−ｏｒｄｅｒ）は、ビジュアルを閉じる、および最小化するなどの、ビジュアル・マネージャ・アクションに指定される３次元効果とともに、サポートされる。したがって、この実施形態は、主に２次元グラフィックスについて記述しているが、このシステムは、３次元グラフィックス、ビデオ、音声を含むその他の種類のメディアを格納するためにも容易に使用できる。
【００８８】
上述したように、トップ・レベル・ビジュアル・マネージャが必要とするレンダリング命令リストは、高レベル・アニメータおよびコンポジッタ２０６によって生成される。低レベル・アニメータおよび合成エンジン２１０は、最小化や閉じるなど、デフォルトの動きを有する、１組のトップ・レベル・ビジュアル・アクションを定義する。トップ・レベル・ビジュアル・マネージャ６０４が、このような動きをカスタマイズしたい場合は、高レベルＡＰＩを使用して、取り替えたいアクションの記述を構築する。次いで、アクションのための命令ストリームを低レベル・アニメータおよび合成エンジン２１０に送る。低レベル・アニメータおよび合成エンジン２１０は、この記述をそのプロパティ・システム６１４内に格納し、クライアントが特定のアクションを要請した場合に、それを使用する。
【００８９】
トップ・レベル・ビジュアル・デコレーションが、プロパティ・システム６１４を使用して実行される。スタートアップで、トップ・レベル・ビジュアル・マネージャが、高レベル・エンジン２０６で生成された命令リストで、トップ・レベル・ビジュアル・マネージャ・デコレーションを記述する命令リスト、を送る。これらのデコレーションへの更新は、プロパティ・システム６１４を介してなされる。つまり、クライアントがデコレーションを更新することを望んだ場合に、クライアントは、指定のプロパティを所望の値に設定する。次いで、低レベル・アニメータおよび合成エンジン２１０は、トップ・レベル・ビジュアル・マネージャ６０４に、プロパティが変更されていることを知らせる。それに応答して、トップ・レベル・ビジュアル・マネージャ６０４は、プロパティを読出し、低レベル・アニメータおよび合成エンジン２１０の幾何図形的配列を更新する。
【００９０】
上述した米国特許出願（例えば、特許文献２参照）にさらに記述するように、命令リストがパラメータ化される。これは、一般に、グラフィカル・イメージの色の修正などの単純な変更については、トップ・レベル・ビジュアル・マネージャ６０４がかかわる必要がないということを意味する。このような場合、クライアントは、新しいパラメータ（たとえば、新しい色）を送り、デコレーションを同じ命令リストで再レンダリングするが、異なるパラメータを使用する。このことにより、それぞれのデコレーションの記述にはただ１つのコピーしか格納しないようにすることができるようになる。
【００９１】
図８は、クライアント／サーバ通信チャネルを実施する待ち行列８０１−８０４の論理構造を示す図である。タイミング間隔が、アニメーションしたレンダリング命令内に埋め込まれる。レンダリング時間に、低レベル・アニメータおよび合成エンジン２１０は、現在時間をタイミング間隔とともに、レンダラにパスする。そして、レンダラは、タイミング間隔を使用して、以下に記述するように、レンダリングのために適切なパラメータを補間する。アニメーションされたレンダリング命令は、高レベル・クライアントから受取った命令コマンドに応答して、命令リスト・マネージャ７１４によって管理される。命令リスト・マネージャは、それを受取ったとき、レンダリング命令を待ち行列７１４に入れる。レンダリング待ち行列はＺオーダであり、レンダリング・パス・マネージャ７２２は、それらを合成期間に消費する。
【００９２】
時間調節されたレンダリング命令を待ち行列に入れることに加えて、命令リスト・マネージャ７１４は、待ち行列８０１−８０４を空にすること、命令を待ち行列から削除すること、命令を待ち行列に追加すること、待ち行列を新しい命令リストに取り替ること、固定時間オフセットを待ち行列に適用することを含む、その他のオペレーションもサポートする。タイミング制御レンダリングの特別な例として、レンダリング命令の可視性を制御する場合がある。このようなイベントでは、タイミング間隔を使用して、レンダリング待ち行列内の命令の生存期間を制御することができる。
【００９３】
クライアントが、たとえば、ビデオがシーン内に存在するような場合などのような、その中身を適切にレンダリングするために、ネストされたビジュアルを必要としている場合もあり得る。ビデオの更新は、独立したレンダリング・プロセスによって実施されるため、低レベル・エンジン２１０は、ビデオおよびそれにオーバーラップする幾何的配列を合成するグラフィックス合成エンジンに頼る。このことは、グラフィックス合成エンジンの合成パス内にビデオ更新の非同期性を隠す、新しいビジュアルを作成して、クライアント・アプリケーションのトップ・レベル・ビジュアル内に入れることによって達成される。ビジュアルの必要性を共有するオーバーラップしている幾何的配列は、同じ種類のアルファの動き（ピクセル毎または透過）を有する。
【００９４】
アニメーション（ANIMATION）
一般に、アニメーションは、高レベル・コンポジッタおよびアニメーション・エンジン２０６と、低レベル・コンポジッタおよびアニメーション・エンジン２１０の両方によって遂行される。上述したように、メディア統合層は、ユーザ・インターフェースまたはアプリケーション・レベルの下の多重グラフィックス処理レベルに分けられる。高レベル・エンジン２０６は、シーンをトラバースし、最後の補間に対して間隔をとってアニメーション・パラメータを更新し、これらの単純化したデータ構造を、より低レベルのエンジン２１０にパスされる命令内にパッケージ化する。これは、同期、および／または非同期方式で実施できる。間隔データは、タイミング・エンド・ポイント（開始および終了タイミング・データ）と、レンダリング命令のためのパラメータ化した値とを含むものと考えることができる。高レベル・エンジン２０４は、要請された補間のいくつかまたはすべてを実行することができる。たとえば、補間またはその他の動作機能が複雑すぎて、より低レベルのエンジン２１０では対処できない場合、またはより低レベルのエンジンが処理要求に追いつかない場合は、より高レベルのエンジンが、計算のいくつかまたはすべてを実行して、より低レベルのエンジンに単純化したデータ、命令、埋め尽くし（tessellations）などを供給し、所望の結果を得る。より低レベルのエンジンが、アニメーションの各フレームのために補間を実行するという典型的な場合では、低レベルのエンジン２１０は、パラメータ間隔を補間して、瞬時値を得、そして命令を、グラフィックス装置によって実行されるレンダリング・コマンドに復号する。グラフィックス装置は、シーンに存在する可能性のあるビデオ・フレームを追加する最終シーンを合成する。ディジタル権管理によるコンテンツ保護など、その他のデータも追加可能である。
【００９５】
高レベル・エンジン２０６と低レベル・エンジン２１０の間の通信は、以下に記述する、命令ストリームを介して得られる。高レベル・エンジン２０６は、より遅い速度で、またはオン・デマンドで、レンダリング命令をストリームに書き込む。低レベル・エンジン２１０は、命令を備えたストリームを読出し、シーンをレンダリングする。低レベル・エンジン２１０はまた、共有メモリからのビットマップなどの、その他のソースからの、シーンをレンダリングするのに必要となるデータ、を得ることができることに留意されたい。
【００９６】
したがって、高レベル（たとえば、ティック・オン・デマンド）エンジン２１０は、アニメーション・パラメータを更新し、できるだけ頻度を少なくシーン・データ構造をトラバースする、と同時に、スムーズなアニメーションを維持する。高レベル・エンジン２０６は、シーン・データ構造をトラバースし、一定時間アニメーションされるパラメータのそれぞれを記述する間隔を計算し、これらの間隔と単純パラメータ化した描画命令を、低レベル・エンジン２１０にパスする。パラメータ・データには、開始時間、終了時間、インターポレータ、補間データが含まれる。例として、移動するように見せるためにイメージを削除し再描画する代りに、高レベル・コンポジッタおよびアニメーション・エンジン２０６は、低レベル・コンポジッタおよびアニメーション・エンジン２１０に、時間とともにイメージがどのように変更していくべきかを、たとえば、開始座標、終了座標、座標間をイメージが移動すべき時間量（間隔）、および、たとえば、線形のような動き機能、を命令する。低レベル・コンポジッタおよびアニメーション・エンジン２１０は、フレーム間の新しい位置の決定に合わせて補間をし、これらを、グラフィックス装置が理解できる命令に変換し、そのコマンドをグラフィックス装置にパスする。
【００９７】
高レベル・エンジン２０６のそれぞれのパスが、数フレームにわたってスムーズなアニメーションを実行するために、低レベル・エンジン２１０に十分なデータを供給することが好ましい。最短間隔の、時間上の長さを使用して、高レベル・エンジン２０６が、スムーズなアニメーションを維持するための実行に必要とする最小頻度を決定する。完全に静的、または単一の間隔によって定義できる単純なアニメーションをのみを含むシーンは、コール・プログラム２０２によってシーンに変更がなされた場合に、高レベル・エンジン２０６が実行することだけを要求する。複雑なアニメーションは、パラメータが予想され、短期間に正確に補間されるが、ハードウェア・リフレッシュ速度よりはるかに大きい、より複雑なアニメーションを含むシーンは、高レベル・エンジン２０６が、０．５秒毎に１回程度の、比較的頻度の少ない間隔で実行することを要求する。少なくとも１つのパラメータでは予想できない、非常に複雑なアニメーションは、高レベル・エンジン２０６が、より頻繁に実行することを要求する（極端な場合には、システムが、ほとんど単一レベル・アニメーション・システムまで縮退するまで）。
【００９８】
高レベル・エンジン２０６が動く頻度は、均一または固定である必要はない。たとえば、高レベル・エンジン２０６は、シーン内のアニメーション・パラメータによって供給される最小間隔を越えない均一の間隔で実行するようにスケジューリングされることが可能である。あるいは、高レベル・エンジン２０６のそれぞれの実行上で計算される最小間隔を、次の実行をスケジューリングし、適切なときに新しいデータが低レベル・エンジン２１０に供給されることを確実にするために、使用されることも可能である。同様に、シーンおよび／またはそのアニメーションしたパラメータに構造上の変更がなされた場合、高レベル・エンジン２０６の頻度は、新しいシーンが正確にアニメーションされることを確実にするための実行であるとすることができる。
【００９９】
低レベル（たとえば、高速ティック）エンジン２１０は、高レベル・エンジン２０６とは別のタスクである。低レベル・エンジン２１０は、高レベル・エンジン２０６から、シーンを記述する、単純パラメータ化した描画命令とパラメータ間隔を受取る。低レベル・エンジンは、高レベル・エンジン２０６によって新しいものが供給されるまで、これらのデータ構造を維持しトラバースする。低レベル・エンジンは、多数の高レベル・エンジン２０６をサービスし、それぞれのために別個のデータ構造を維持する。低レベル・エンジン２１０と高レベル・エンジン２０６との間の１対多の関係により、システムは、多くのシーンを同時にスムーズにアニメーションできるようになる。
【０１００】
低レベル・エンジン２１０は、高レベル・エンジンの供給した間隔に基づき、ある瞬間のアニメーション・パラメータに補間し、描画命令を更新し、すべてのフレームに対してシーンをレンダリングする。低レベル・エンジン２１０タスクは、そのフレームが、グラフィックス・ハードウェア・スクリーン・リフレッシュ速度でプレゼンテーションする準備を確実にするために、システム上を高い優先度で実行する。したがって、低レベル・エンジン２１０によって実行される補間は、一般に、線形、区分線形、３次スプライン、およびこれらの同様の速度など、単純で高速の関数に限られる。低レベル・エンジン２１０は、ハードウェア・リフレッシュ速度の整数除数（integral divisor）である、正規周波数またはフレーム速度で実行する。低レベル・エンジン２１０によってレンダリングされたそれぞれのフレームは、矛盾しない数を維持して表示されるか、またはグラフィックス・ハードウェアによってリフレッシュされる。
【０１０１】
高レベル、低レベル通信（HIGH-LEVEL,LOW-LEVEL COMMUNICATION）
高レベル・コンポジッタおよびアニメーション・エンジン２０６と、低レベル・コンポジッタおよびアニメーション・エンジン２１０との間の相互作用についての説明に移ると、その機器構成は、プロセス間（in-process）を含むいろいろな機器構成が実現可能であり、低レベル・エンジン２１０はただ１つの高レベル・エンジン２０６に対してだけ働き、そして両方が同じプロセス内に存在する機器構成が実現可能である。低レベル・エンジン２１０がただ１つの高レベル・エンジン２０６に対してだけ働くことについては同じであるが、高レベル・エンジン２０６および低レベル・エンジン２１０が独立したプロセス内にある、クロス−プロセス（cross-process）機器構成も利用可能である。
【０１０２】
デスクトップ機器構成は、クロス−プロセス機器構成の拡張であり、ここでは、低レベル・エンジン２１０が高レベル・エンジンの多くのインスタンスにサービスし、デスクトップ全体のレンダリングを制御する。高レベル・エンジン２０６がサーバ・マシン上にあり、低レベル・エンジン２１０がクライアント・マシン上にある場合、リモート機器構成も使用可能である。リモートの場合は、高レベル・エンジン２０６と低レベル・エンジン２１０との関係が１対１であるか、または低レベル・エンジン２１０が多くのローカルおよびリモートの高レベル・エンジンに対して働くかのいずれかの場合とすることができる。リモート機器構成は、クロス・プロセスおよびデスクトップ機器構成と非常に似ていると考えることができるが、高レベル・エンジン２０６と低レベル・エンジン２１０を異なるマシン上に備えた機器構成である。
【０１０３】
本発明によれば、高レベル・エンジン２０６のデータは、低レベル・エンジン２１０への伝送用に準備され、低レベル・エンジン２１０は、データを受取るとすぐに処理する。データ・フォーマット上の詳細について、そしてデータがどのように高レベル・エンジン２０６内で作成され、低レベル・エンジン２１０によるレンダリングのために使用されるかとともに、以下にその概要を記述する。
【０１０４】
高レベル・エンジン２０６、低レベル・エンジン２１０、グラフィックス装置間の概念的な相互作用およびデータの流れを、図９−１２に示してあり、図１３、１４、１５は、通信に使用されるデータ構造のさまざまな例を示す図である。一般に、高レベルエンジン・レンダリング・トラバーサル（traversal；走査、横断）（たとえば、ループ）９０２は、シーン・キャッシュ・ツリー９００をトラバースし、サブステップを何回も繰り返すことを通じて、データ構造９０４（図１１のビジュアル更新ブロック１１１４を含む）を作成する。これには、シーン・キャッシュ内で使用するリソースを作成することと、ディスプレイ・ツリー内で使用するための宣言アニメーションを作成することが含まれる。アニメータ・オブジェクトは、可変の値に対して作成され、これによって、アニメータが、コンスタントの代りにメディア統合層描画ＡＰＩ内で使用される。次いで、高レベル・エンジン２０６ディスプレイ・データ構造９０４が作成され、前に作成されていたリソースおよびアニメータを参照する。ディスプレイ・データも、その他のサブツリーを参照する。活動化するために、アニメータ（たとえば、図１１の１１０４）をタイミング・ツリー／ノード構造（たとえば図１１の１１０２）に接続する。一般に、アプリケーションが、時間ノード１１０２を作成して、それぞれのアニメータ１１０４の開始、停止、進捗を制御する。
【０１０５】
タイミングおよびアニメーションを含み、いったんモデルが作成されると、高レベル・エンジンのトラバーサル・ループ９０２が、ディスプレイ・ツリー９００をトラバースして描画を開始する。上述したように、高レベル・エンジン２０６トラバーサルの頻度は、タイミングおよびアニメーションの量と複雑さに依存する。たとえば、静的シーンは、アプリケーションが変更したときにだけ、トラバースされる必要がある。
【０１０６】
高レベル・トラバーサル・プロセス９０２は、多くのパス内で起きる。事前計算パスでは、ツリー９００の第１のトラバーサルは、描画に必要な計算を実行する。たとえば、バウンディング・ボックスは、それぞれのサブツリーに対して計算され、アニメーション値を更新する。上述したように、単一の瞬時値ではなく、アニメータ１１０４が、間隔を供給する。間隔には、開始および終了時間、どの種類のインターポレータを使用するのか、補間用データ、が含まれる。次いで、ディスプレイ・ツリーによって使用されるリソースが、具現化のために低レベル・エンジン２１０に送られる。
【０１０７】
第２のトラバーサルが、レンダリングのために低レベル・エンジン２１０に送られるシーンを記述する情報をパッケージ化する。このため、グラフ内のそれぞれのサブツリーが、図１３−１５に示すデータ構造および情報内で表されているように、１つまたは複数の命令ブロックによって表される。高レベル・エンジン２０６は、命令ブロック（たとえば、図１５の１５００）を、それぞれのトップ・レベル・ビジュアル（たとえば、ウィンドウ）に対する単一のビジュアル更新ブロック１１１４に蓄積する。前回のトラバーサルから変更されていない命令ブロック・サブツリーは、付加されない。宣言アニメーション変更だけを含むサブツリーのための命令ブロックには、補間情報の変数ブロックだけが含まれる。変換とともに再位置付けされているサブツリーに対する命令ブロックは、ヘッダのみを含む。
【０１０８】
低レベル・エンジン２１０レンダリング・スレッド（またはプロセス）は、ループ１２０８（図１２）内で実行し、高フレーム速度で、理想的にはディスプレイのリフレッシュ速度で、ビジュアルをレンダリングし合成する。ループ１２０８は、高レベル・エンジン２０６から受取ったビジュアル更新ブロック（たとえば、１１１４１−１１１４３）の適用を含み、いくつかのステップを実行する。このパス上で描画されているリソースおよびウィンドウに対して補間される値が、更新される。命令ブロックの変数リスト内のそれぞれの変数については、次のフレームのための瞬時値が計算される。次いで、ループ１２０８は、それが使用されている命令リスト内の場所にオフセットを介して、新しい値へメモリ・コピーすることを、反復適用する。
【０１０９】
リソースは、最初に使用されたときにレンダリングされるけれども、更新されたオフ・スクリーン・リソースはレンダリングされる。それぞれのトップ・レベル・ビジュアルについての命令リストは、レンダリングされ、ディスプレイ上へのデータ「ｂｌｔ−ｅｄ」は、フリップされ、あるいは、それぞれのトップ・レベル・ビジュアルがスクリーン上で更新されるように配置される。
【０１１０】
リモート移送（REMOTE TRANSPORT）
上述したように、高レベル・エンジン２０６は、リソース１２０４１−１２０４３（図１２）を含む、低レベル・エンジン２１０に移送されるデータの関連セットを作成する。たとえば、レンダリングに使用される変数が短時間の間にどのように変化するのかを、それがどこで使用されるかのついての情報と一緒に記述する、イメージおよびテキスト・グリフ、アニメーション間隔／変数、およびトップ・レベル・ビジュアル（ウィンドウ）をレンダリングするのに必要な、位置付けレンダリング・オペレーションを記述する命令リスト、などである。命令リストは、静的値の代りに変数への参照を含むことができる。
【０１１１】
まず最初に、高レベル・エンジン２０６は、使用する前に作成する必要のあるリソースを作成し、命令リスト内の隠されたハンドルによって参照される。高レベル・エンジン２０６は、最初に、リソースの装置独立型表示を作成することによってリソースを作成する。イメージの場合は、表示は、フル・フレームのビットマップか、またはＪＰＥＧなどのフォーマットの符号化されたイメージである。通信については、次いで、高レベル・エンジン２０６は、リソース・データを、それを特有のハンドルに指定する通信スタブに提出する。ハンドルは、高レベル・エンジン２０６プロセス内で生成され、そのプロセス内でのみ特有である。
【０１１２】
図１６に示すように、通信スタブは、データ構造１６００内に、オペレーションとハンドルの種類を特定するヘッダを付けて、リソース・データをパッケージ化する。スタブは、ただちにハンドルをレンダリングに使用する高レベル・エンジン２０６に戻す。
【０１１３】
命令リスト、変数、時間値およびアニメーション間隔は、一緒に作られる。命令リストは、レンダリングを記述し、静的値の代りに変数への参照を含むことができる。アニメーション間隔は、短時間の間に、どのように変数の値が変わるかを記述する。
【０１１４】
高レベル・エンジン２０６は、そのレンダリング・パスの一部として、命令リストおよびアニメーション間隔を収集する。高レベル・エンジン２０６は、レンダリング情報を、トップ・レベル・ビジュアル（ウィンドウ）毎に１つまたは複数の命令ブロックにパッケージ化する。それぞれのブロックは、特定のウィンドウのためのグラフのサブツリーを表す。それぞれのブロックは、命令リストに影響を与える変数のリストを含む。高レベル・エンジン２０６内に維持される命令リストは、使用される変数への参照を含む。これらの変数参照は、それぞれの変数に対して収集され、レンダリングの前に変数の瞬時値によって交換されるべき命令リスト内の場所（オフセット）に変換される。これらのオフセットは、図１６−２２に概要を示すように、そのブロックのためのアニメーション間隔情報とともにパッケージ化される。
【０１１５】
図１５は、ビジュアル更新データ構造を示す図である。一般に、ウィンドウを記述する命令ブロックの集合が、上述したように、ビジュアル更新ブロック１１１４内に収集される。次いで、更新ブロックは、上述したリソースと同様の方式でパケット内にパッケージ化される。更新ブロックは、大きいものである場合があり、移送のためにより効率的な場合は、多くのパケットで送ることができる。
【０１１６】
低レベル・エンジン２１０は、移送ストリームを聞き（listen）、パケットが到着するとそれを処理する、通常優先スレッドを有する。好ましくは、レンダリング・スレッドとは別のスレッドでその作業を行い、低レベル・エンジン２１０がすべてのリフレッシュをレンダリングできることを確実にする。通信スレッドは、オペレーション・コード（ｏｐｃｏｄｅ）、高レベル・エンジン識別子（ＩＤ）、オブジェクト・ハンドルに基づき、それぞれのパケットをパーズ（構文解析）する。これらのリソースおよびビジュアル更新シナリオの処理は、図２３を参照しながら記述する。
【０１１７】
より詳細には、受取ったパケットはリソース１２０４（ステップ２３００）のためのものであると低レベル・エンジン２１０が認識したとき、リソース・パケットが処理される。次いで、低レベル・エンジン２１０は、ステップ２３０２で、高レベル・エンジン２０６ＩＤとリソース・ハンドルを抽出し、ステップ２３０４で、要求されている種類のリソースを作成する。低レベル・エンジン２１０は、ステップ２３０６で、リソースの装置独立型フォームに書き込み、リソースを、指定された高レベル・エンジン２０６（ステップ２３０８）のためのハンドル・テーブルに入れる。
【０１１８】
単一のパケット・ビジュアル更新ブロックは、リソース・パケットと同様に取り扱われるが、処理量が多くなる。ステップ２３００で、低レベル・エンジン２１０が、パケットがビジュアル更新ブロック１１１４であると認識した場合、そのプロセスは、ステップ２３１２に分岐する。ステップ２３１２で、低レベル・エンジン２１０は、パケットから高レベル・エンジンＩＤとビジュアル・ハンドルを抽出する。次いで、低レベル・エンジン２１０は、ステップ２３１４で、指定された高レベル・エンジン２０６のためのハンドル・テーブル内のビジュアルをルックアップする。ビジュアルが見つけられない場合は、ステップ２３１６で、新しいビジュアル・オブジェクトが作成され、ハンドル・テーブルに追加される。次いで、低レベル・エンジン２１０は、ステップ２４００および２４１６を介して、図２４に示すように、パケット内の命令ブロックのそれぞれを通ってループする。
【０１１９】
このため、ステップ２４００で、低レベル・エンジン２１０は、命令ブロックを選択し、ステップ２４０２で、現行ビジュアル内のブロックＩＤをルックアップする。ブロック識別子が存在しない場合は、新しいブロックが作成され、パケットからのデータで初期設定される。反対に、ブロック識別子が存在する場合は、低レベル・エンジン２１０は、変換とオフセットを更新する（ステップ２４０６）。ブロックが、変数リストを含む場合は、既存変数リストが、ステップ２４０８および２４１０を介して置き換えられる。ブロックが命令リストを含む場合は、既存命令リストは、ステップ２４１２および２４１４を介して置き換えられる。
【０１２０】
多数のパケットの場合も、単一のパケットの場合と同様に対処される。唯一の相違点は、低レベル・エンジン２１０が、最初に、ビジュアル更新ブロックを多数のパケットから集めることである。
【０１２１】
容易に理解されるように、個々のグラフィックス・ビットではなく、グラフィックス命令が送られるため、高レベル・エンジンと低レベル・エンジンの間で通信する必要のあるデータの量が、著しく減少する。その結果、高レベル処理システムからのグラフィックス命令が、ネットワーク接続を介して、それぞれが低レベル処理システムを備える、リモート端末へ送信することができる。その結果生じるグラフィックス出力は、たとえその接続の帯域幅では、従来のグラフィックス・データを運ぶことができない場合でさえも、いくつかの端末上に実質的に同じように現れることができる。
【０１２２】
結論
上述した詳細な説明からお分かりのように、比較的低い頻度で複雑な処理を容易にすることにより、比較的高い頻度で複雑なグラフィックス出力を可能にする多重レベル・グラフィックス処理システムおよび方法が提供される。本システムおよび方法では、大量のグラフィックス・サブシステム・パワーを高めるための多重処理レベルを使用することにより、スムーズなアニメーション、グラフィックス合成、ビデオおよび音声との組み合わせを含む、改良型グラフィックス出力が可能となる。さらに、多重レベルにより、グラフィックス命令とデータの端末への、複雑なグラフィックス出力をもたらすリモート通信が容易になる。
【０１２３】
本発明は、さまざまな修正形態および代替構成が可能であるが、特定の実施形態を、図面に例示し、また上記の詳細な説明に記述してある。しかし、本発明は、開示されている特定の形態に限定されるものではなく、その反対に、あらゆる修正形態、代替構成、および本発明の趣旨および範囲内の均等物を包含するものであることが理解されるべきである。
【図面の簡単な説明】
【図１】その中に本発明を組み込むことのできるコンピュータ・システムの例を示すブロック図である。
【図２】本発明の一態様に従ったメディア統合層アーキテクチャを示すブロック図である。
【図３】本発明の一態様に従った、インテリジェント・キャッシング・データ構造およびそのさまざまな構成要素に対する関係を示すブロック図である。
【図４】本発明の一態様に従った、高レベル合成およびアニメーション・エンジンとその他のレベルの間の、一般的な制御の流れを示すブロック図である。
【図５】本発明の一態様に従った、単純なデータ構造内にキャッシュされたコンテナおよびその他のノードと、それらの関係の例を示すブロック図である。
【図６】本発明の一態様に従った、他の構成要素と相互作用する低レベル合成およびアニメーション・エンジンの一般的な構成要素を示すブロック図である。
【図７】本発明の一態様に従った、低レベル合成およびアニメーション・エンジンの一般的な構成要素を示すブロック図である。
【図８】本発明の一態様に従った、低レベル合成およびアニメーション・エンジンとの接続の論理構造を示すブロック図である。
【図９】本発明の一態様に従った、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへの情報の流れを示すブロック図である。
【図１０】本発明の一態様に従った、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへの情報の流れを示すブロック図である。
【図１１】本発明の一態様に従った、メディア統合層アーキテクチャ層を介するグラフィックス・サブシステムへの情報の流れを示すブロック図である。
【図１２】本発明の一態様に従った、メディア統合層アーキテクチャ層を介するグラフィックス・サブシステムへの情報の流れを示すブロック図である。
【図１３】本発明の一態様に従って、データ構造を備え、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへ情報を通信するために使用されるその他の情報を示す図である。
【図１４】本発明の一態様に従って、データ構造を備え、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへ情報を通信するために使用されるその他の情報を示す図である。
【図１５】本発明の一態様に従って、データ構造を備え、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへ情報を通信するために使用されるその他の情報を示す図である。
【図１６】本発明の一態様に従って、データ構造を備え、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへ情報を通信するために使用されるその他の情報を示す図である。
【図１７】本発明の一態様に従って、データ構造を備え、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへ情報を通信するために使用されるその他の情報を示す図である。
【図１８】本発明の一態様に従って、データ構造を備え、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへ情報を通信するために使用されるその他の情報を示す図である。
【図１９】本発明の一態様に従って、データ構造を備え、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへ情報を通信するために使用されるその他の情報を示す図である。
【図２０】本発明の一態様に従って、データ構造を備え、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへ情報を通信するために使用されるその他の情報を示す図である。
【図２１】本発明の一態様に従って、データ構造を備え、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへ情報を通信するために使用されるその他の情報を示す図である。
【図２２】本発明の一態様に従って、データ構造を備え、高レベル合成およびアニメーション・エンジンから低レベル合成およびアニメーション・エンジンへ情報を通信するために使用されるその他の情報を示す図である。
【図２３】本発明の一態様に従って、パケットを処理する論理を一般的に記述したフローチャートである。
【図２４】本発明の一態様に従って、パケットを処理する論理を一般的に記述したフローチャートである。
【符号の説明】
１００    コンピューティング環境、オペレーティング環境
１１０    コンピュータ
１２０    プロセッシング・ユニット
１２１    システム・バス
１３０    システム・メモリ
１３１    リード・オンリー・メモリ（ＲＯＭ）
１３２    ランダム・アクセス・メモリ（ＲＡＭ）
１３３    基本入出力システム（ＢＩＯＳ）
１３４、１４４    オペレーティング・システム
１３５、１４５、１８５、２０２    アプリケーション・プログラム
１３６、１４６    プログラム・モジュール
１３７、１４７    プログラム・データ
１４０、１５０、１６０    インターフェース
１４１    ハード・ディスク・ドライブ
１５１    磁気ディスク・ドライブ
１５２    磁気ディスク
１５５、１５６    光学ディスク
１６１    ポインティング・デバイス
１６２    キーボード
１６３    マイクロホン
１６４    タブレット
１７０    アダプタ
１７１    ローカル・エリア・ネットワーク（ＬＡＮ）
１７２    モデム
１７３    ワイド・エリア・ネットワーク（ＷＡＮ）
１８０    リモート・コンピュータ
１８１    メモリ記憶装置
１９０    ビデオ・インターフェース
１９１    モニタ
１９２    タッチ・スクリーン・インターフェース
１９３    タッチ・スクリーン・パネル
１９４    周辺インターフェース
１９５    スピーカ
２００    メディア統合層アーキテクチャ
２０２    コード、クライアント、アプリケーション
２０４    アプリケーション・プログラミング・インターフェース（ＡＰＩ）
２０６    高レベル合成およびアニメーション・エンジン
２０８    タイミングおよび合成アニメーション構成要素
２１０    低レベル合成およびアニメーション・エンジン
２１２    グラフィックス・サブシステム、グラフィックス・ソフトウェアおよびハードウェア
２２０    プリンティング・コード
１９６、２２２    プリンタ
２２６    端末トランスポート・サーバ
２２８、６１０    リモート・マシン
３００、７１８、９０４、１１０２    構造
３０２    抽象装置
４０６    変換
４１０、４１２    基本ノード
４１６    描画コンテキスト
４１８    変換待ち行列
４２０    ディスプレイ・マネージャ
４２２    レンダリング・スレッド
５００、５０２    セグメント
４０２、４０４、４０８、５１０、５１２、５１８    コンテナ
５１６    基本要素
６０４    ビジュアル・マネージャ
６０６    グラフィックス合成エンジン
６１４    プロパティ・システム
７１０    接続マネージャ
７１４    命令リスト・マネージャ
７２０    ルート・ノード
７２２    レンダリング・パス・マネージャ
７３０    装飾
８０１、８０２、８０３、８０４    待ち行列
９００    シーン・キャッシュ・ツリー、ディスプレイ・ツリー
９０２    トラバーサル
１１０４    アニメータ
１１１４    ビジュアル更新ブロック
１２０４    リソース
１２０８    ループ
１５００    命令ブロック
【図１】
0004371350.tif 000002
【図２】
0004371350.tif 000003
【図３】
0004371350.tif 000004
【図４】
0004371350.tif 000005
【図５】
0004371350.tif 000006
【図６】
0004371350.tif 000007
【図７】
0004371350.tif 000008
【図８】
0004371350.tif 000009
【図９】
0004371350.tif 000010
【図１０】
0004371350.tif 000011
【図１１】
0004371350.tif 000012
【図１２】
0004371350.tif 000013
【図１３】
0004371350.tif 000014
【図１４】
0004371350.tif 000015
【図１５】
0004371350.tif 000016
【図１６】
0004371350.tif 000017
【図１７】
0004371350.tif 000018
【図１８】
0004371350.tif 000019
【図１９】
0004371350.tif 000020
【図２０】
0004371350.tif 000021
【図２１】
0004371350.tif 000022
【図２２】
0004371350.tif 000023
【図２３】
0004371350.tif 000024
【図２４】
0004371350.tif 000025