JP2003157443A - 多重レベル・グラフィックス処理システムおよび方法 - Google Patents

Abstract

(57)【要約】 【課題】 多重レベル・グラフィックス処理システム及
び方法を提供すること。 【解決手段】 スムーズなアニメーション（アニメーシ
ョンをＡと略す）の改良型グラフィックス（グラフィッ
クスをＧと略す）出力を提供する（例えば、ＯＳの）。
このシステムはＴＩＣＫ−ＯＮ−ＤＥＭＡＮＤ又は低速
ＴＩＣＫ高レベル構成要素と高速ＴＩＣＫ（例えば、Ｇ
ハードウェア・フレーム・リフレッシュ速度で）低レベ
ル構成要素を有する。高レベル低頻度の前者は単純化し
たデータ構造を低レベル構成要素にパスするために、Ａ
パラメータを更新しシーン・データ構造をトラバースす
る計算集中的な面を実施し、後者はデータ構造をＧサブ
・システムのための一定出力データに処理するため、Ｇ
サブ・システムのフレーム・リフレッシュ速度など高頻
度で動作する。後者の処理はＡの各フレームのシーンを
レンダリングする瞬時値を得るため必要に応じてパラメ
ータ間隔の補間処理を含む。

Description

【発明の詳細な説明】

【０００１】本発明は、特許仮出願第６０／３３０，２
４４号（２００１年１０月１８日出願）（特許文献１）
への優先権を請求する。本発明は、米国特許出願「Ｇｅ
ｎｅｒｉｃ Ｐａｒａｍｅｔｅｒｉｚａｔｉｏｎ ｆｏ
ｒ ａ Ｓｃｅｎｅ Ｇｒａｐｈ」（弁護士整理番号第
３１３０号）（特許文献２）および米国特許出願「Ｉｎ
ｔｅｌｌｉｇｅｎｔ Ｃａｃｈｉｎｇ Ｄａｔａ Ｓｔ
ｒｕｃｔｕｒｅ ｆｏｒ Ｉｍｍｅｄｉａｔｅ Ｍｏｄ
ｅ Ｇｒａｐｈｉｃｓ」（弁護士整理番号第３１５０
号）（特許文献３）に関し、両文書とも、本出願の譲受
人に譲受され、本明細書とともに同時出願され、参照に
よりそれら全体が組み入れてある。

【０００２】

【発明の属する技術分野】本発明は、一般にコンピュー
タ・システムに関し、より詳細には、コンピュータ・シ
ステムのディスプレイについてのグラフィカル情報およ
びその他のビデオ情報の処理に関する。

【０００３】

【従来の技術】現代の計算機システムにおいて、グラフ
ィックスおよびビデオ・ハードウェアの機能が急速に向
上している。事実、現代の計算機システムに使用される
グラフィックス・システムは、ある程度、単なるグラフ
ィックス・サブシステムと言うより、コプロセッサと考
えることができる。同時に、消費者は、たとえば、モニ
タ、テレビ、携帯電話のディスプレイを見る際に、表示
される画像の品質に、より高い期待を寄せるようになっ
てきている。

【０００４】しかし、メモリやバスの速度が、メイン・
プロセッサおよび／またはグラフィックス・プロセッサ
の進歩に追いついてきていない。その結果、コンピュー
タ・システムのグラフィックスにアクセスする従来のイ
ミーディエイト・モード・モデルの持つ限界に達してし
まっている。同時に、開発者および消費者は、従来のグ
ラフィカル・ウィンドウィング・アーキテクチャでは満
たすことのできないような、新規の機能や特別な効果を
要求してきている。

【０００５】特定のゲーム・プログラムは、グラフィッ
クス・ハードウェアの利点を生かして設計されており、
このようなゲーム・プログラムは、デスクトップ・アプ
リケーション・プログラム等とは異なる条件で動作す
る。これは主に、ゲームでは、同時に実行するかもしれ
ないその他のプログラムを問題にする必要がないからで
ある。このようなゲーム・プログラムとは異なり、アプ
リケーションでは、他のアプリケーションと、グラフィ
ックスおよびその他のシステム・リソースを共有しなけ
ればならない。しかし、一般に、グラフィックス処理に
ついては、協調型（cooperative）で、マシン全体を共
用するモデル（machine-wide sharing model）で書かれ
てはいない。

【０００６】たとえば、デスクトップ・アプリケーショ
ンでアニメーションを実行すると、専用の単一目的のコ
ードを必要とするか、または別のアプリケーションを使
用しなければならない。そして、たとえそうしたとして
も、マルチウィンドウ環境でスムーズなアニメーション
を得ることは不可能ではないにしても、困難ではある。
このことは、一般的に言って、スムーズで高速度なアニ
メーションを得るには、アニメーション・パラメータを
更新し、高いフレーム速度(rate)で、理想的には、グラ
フィックス装置のハードウェア・リフレッシュ速度で、
シーンを再描画（これには、データ構造をトラバース
（traverse；走査、横断）し描画する必要がある）しな
ければならないからである。しかし、アニメーション・
パラメータを更新し、シーンを定義するデータ構造をト
ラバースし描画することは、一般に、コンピュータ処理
の集中化状態となる。シーンのアニメーションを大きく
したり回数を多くしたりすると、コンピュータ処理への
要求が増大し、そのことは、スムーズにアニメーション
することが可能なシーンの複雑度を制限する。

【０００７】問題が複雑となっている、その原因は、グ
ラフィックスのハードウェアがディスプレイ・リフレッ
シュを実行する場合、アニメーションの各フレームを計
算し、描画して、プレゼンテーションのための準備作業
をする必要があることである。ハードウェアの必要とす
るときにフレームの準備ができていなかった場合は、フ
レームが落ちてしまったり、遅れてしまったりすること
となる。一定数のフレームが落ちると、アニメーション
を表示しているディスプレイに、かなりのスタッタ（st
utter；ぎこちない動き）が現れる。また、フレームの
準備作業がリフレッシュ速度と同期がとれていない場合
は、テアリング（tearing；裂け目が見える現象）とし
て周知の、望ましくない影響が起きる可能性がある。実
際、現代の多重タスキング・オペレーティング・システ
ムは、システム上の、多くのタスクの間で計算用のリソ
ースを分割している。しかし、オペレーティング・シス
テム・タスクス・ケジューラによるフレーム処理のため
の時間が、グラフィックス・ハードウェアのフレーム速
度に合うことはめったにない。したがって、たとえ計算
用のリソースが十分にあったとしても、アニメーション
・システムは、スケジューリングの問題によって、やは
りフレームを落としてしまう可能性がある。たとえば、
アニメーション・タスクの動きが遅すぎるようにスケジ
ューリングされている可能性もあり、またはフレームが
完了する前に優先使用されてしまう可能性もあり、スク
リーンの次のハードウェア・リフレッシュのため次のフ
レームを供給するように時間通りに再スケジューリング
されることはない。このような問題は、アニメーション
したグラフィックスを、ビデオまたはその他の非同期式
に生成されるフレームのソースと合成する必要がある場
合に、一層複雑となる。

【０００８】一般的に言って、フレームを準備するため
に現在使われている（たとえば、ＷＭ＿ＰＡＩＮＴ）モ
デルは、複雑なグラフィックス効果（複雑なアニメーシ
ョンなど）が望ましい場合に、リフレッシュ速度に追い
つくためには余りに多くのデータ処理を必要とする。そ
の結果、複雑なグラフィックス効果を従来のモデルを使
って試みると、次のフレームの変更を終了させて次のフ
レームに間に合ってビジュアル効果がやがて知覚される
のではなく、変更が個々のフレームに追加されてしまう
可能性もあり、そのため、ビジュアル的で目立った望ま
しくない結果が引き起こされる。シーン・グラフ内のす
べてのオブジェクトにオブジェクト・ハンドルを与える
ことにより、選択的に変更を組み込むことができるよう
にした計算モデルがある。しかし、このようなモデル
は、かなりの数のオブジェクトを追跡（track）するた
めの複数のアプリケーションを必要とし、また、そのア
プリケーションがオブジェクトを変更させようとしない
場合でさえも、オブジェクト・ハンドルが存在するため
に、余りにも多くのリソースを消費する。

【０００９】

【発明が解決しようとする課題】要するに、コンピュー
タ・システムのグラフィックスにアクセスするための既
存のモデルは、現行ディスプレイ・ハードウェアと一緒
に機能するには、また消費者の期待を満足させるには不
充分となってきている。グラフィックスとビデオを処理
するための新しいモデルが、必要とされている。

【００１０】

【課題を解決するための手段】簡単に言えば、本発明
は、たとえば、スムーズなアニメーションなどの、改良
型グラフィックス・アクセスおよび出力を供給するため
の、多重レベルのグラフィックス処理システム（multi-
level graphics processing system）および方法（たと
えば、オペレーティング・システムについての）を提供
することである。一実施形態では、グラフィックス処理
システムは、２つの構成要素を含む。ティック−オン−
デマンド（tick-on-demand）または低速ティック（slow
tick）高レベル構成要素、そして高速ティック（fast
tick）（たとえば、１つまたは複数のグラフィックス・
ハードウェア・フレーム速度）低レベル構成要素であ
る。

【００１１】一般的に言って、高レベル構成要素は、デ
ィスプレイされるべきシーンをトラバースして、この後
の補間用に間隔を開けて、アニメーション・パラメータ
を更新し、そして単純化したデータ構造を低レベル構成
要素にパスする。低レベル構成要素は、データ構造を、
瞬時値を得るために必要とするパラメータ間隔を補間す
ることを含んで、処理して出力データを獲得し、アニメ
ーションの各フレームに対応するシーンをレンダリング
する。

【００１２】一般的に言って、本発明は、グラフィック
ス・データを要素に分けて、アニメーション・パラメー
タを更新し、シーン・データ構造をトラバースするとい
う、コンピュータ処理の最も集中化する局面は、高レベ
ル処理構成要素で過度に要求されることが少ないスケジ
ュールで実行するように、グラフィック・データを属性
分配することにより、上述した（およびその他の）問題
を解決する。低レベル処理構成要素の方が、より頻繁に
動作するが、比較的単純化したデータ構造と処理すべき
命令とを供給する高レベル前処理のために、コンピュー
タ処理の集中化が少ない状態でタスクを処理する。ビデ
オ・フレームも、これらの低レベル・ティック期間に、
合成に組み込まれることもある。

【００１３】このシステムおよび方法の利点には、オペ
レーティング・システム・シェルの一部として、またア
ニメーションされるコンテンツに相応しいアニメーショ
ン・エンジンとして、テレビのような品質のアニメーシ
ョンが含まれる。さらなる利点には、ビデオ・イメージ
をグラフィックスと合成することと、高帯域幅を必要と
しないネットワーク接続、少なくとも、従来のラスタ化
したグラフィックス・ビットを必要とされる高フレーム
速度で運ぶ程には、十分に高い帯域幅ではない、ネット
ワーク接続を介して、高品質ビデオ・ディスプレイの複
数の端末に情報を配信する機能と、が含まれる。

【００１４】本発明は、グラフィックスを含むディスプ
レイ情報のフレームを出力するグラフィックス・サブシ
ステムと、ディスプレイ情報のフレームを出力するグラ
フィックス・サブシステムに、グラフィックス・データ
を第１の速度で供給する第１の構成要素と、プログラム
・コードとインターフェースして、プログラム・コード
に合うシーン・データを生成する第２の構成要素であっ
て、シーン・データをグラフィックス情報に第１の速度
より遅い第２の速度で処理し、グラフィックス情報を第
１の構成要素に供給するよう構成された第２の構成要素
を含むシステムを介して提供することができる。

【００１５】方法およびコンピュータ実行可能命令を有
するコンピュータ読取り可能媒体は、第１の構成要素に
おいて、出力するグラフィカル・イメージに対応するデ
ータを含むコール（call）を受信することと、そのデー
タをシーン情報として維持することと、そして第１のオ
ペレーティング速度で、シーン情報をグラフィックス情
報に処理することと、グラフィックス情報を第２の構成
要素に伝達することとを含むことができる。第２の構成
要素において、第１のオペレーティング速度より速くグ
ラフィックス・サブシステムのフレーム・リフレッシュ
速度に基づく第２のオペレーティング速度で、本方法
は、グラフィックス情報を受信することと、グラフィッ
クス情報をグラフィックス・サブシステム用にフォーマ
ットしたグラフィックス・データに処理することと、グ
ラフィックス・データをグラフィックス・サブシステム
に伝達して、フレームを出力することとを含むことがで
きる。

【００１６】データ構造をそこに格納したコンピュータ
読取り可能媒体は、その中にビジュアル識別子を有する
識別子フィールドと、命令ブロックに対応するフィール
ドとを含み、その命令ブロックは、ビジュアル識別子に
よって識別されるビジュアルに関連する１組のデータに
対応し、その１組のデータは、高レベル・グラフィック
ス処理構成要素から低レベル・グラフィックス処理構成
要素にパスされて、高レベル構成要素は、シーン・グラ
フからデータ構造を構築してデータ構造を低レベル構成
要素に供給し、低レベル構成要素は、データ構造を、フ
レームを出力するグラフィックス・サブシステムにパス
するためのグラフィックス・データに、処理するビジュ
アル更新ブロック、を備えることができる。

【００１７】その他の利益および利点は、以下に記述す
る詳細な説明を、図面と合わせて読めば、より明らかと
なるであろう。

【００１８】

【発明の実施の形態】オペレーティング環境の例（EXEM
PLARY OPERATING ENVIRONMENT）図１は、本発明を実施
することができる適切なコンピューティング・システム
環境１００の例を示す図である。コンピューティング・
システム環境１００は、適切な計算環境の一例にすぎ
ず、本発明の使用法または機能の範囲を提案することを
意図していない。またコンピューティング環境１００
は、例示したオペレーティング環境１００に示した構成
要素のいずれか１つまたは組み合わせに依存したり、そ
の条件が必要であると解釈されないものとする。

【００１９】本発明は、その他多くの汎用または専用コ
ンピューティング・システム環境またはシステム構成を
使用して動作できるものである。本発明に使用するのに
適切であることができる周知の計算機システム、環境、
および／またはシステむ構成の例として、パーソナル・
コンピュータ、サーバ・コンピュータ、ハンドヘルドま
たはラップトップ装置、タブレット装置、多重プロセッ
サ・システム、マイクロ・プロセッサ・ベースのシステ
ム、セットトップボックス、プログラム可能な家電機
器、ネットワークＰＣ、ミニ・コンピュータ、メイン・
フレーム・コンピュータ、上述のシステムまたは装置の
いずれかを含む分散型計算環境などがあるが、これらに
限定されるものではない。

【００２０】本発明は、コンピュータによって実行され
るプログラム・モジュールなどの、コンピュータ実行可
能命令の一般的なコンテキストにおいて説明することが
できる。一般に、プログラム・モジュールには、特定の
タスクを実行する、または特定の抽象データ・タイプを
実施する、ルーチン、プログラム、オブジェクト、構成
要素、データ構造などが含まれる。本発明はまた、通信
ネットワークを介してリンクされているリモート・プロ
セッシング装置によってタスクが実行される分散型計算
環境で使用されることもできる。分散型計算環境では、
プログラム・モジュールは、メモリ記憶装置を含む、局
所およびリモート・コンピュータ記憶媒体内に配置され
ることができる。

【００２１】図１に関して、本発明を実施するためのシ
ステムの例は、汎用コンピューティング装置をコンピュ
ータ１１０の形で含んでいる。コンピュータ１１０の構
成要素は、プロセッシング・ユニット１２０と、システ
ム・メモリ１３０と、システム・メモリを含むさまざま
なシステム構成要素をプロセッシング・ユニット１２０
に結合するシステム・バス１２１とを含むが、これらに
限定されるものではない。システム・バス１２１は、メ
モリ・バスまたはメモリ・コントローラ、周辺バス、お
よびさまざまなバス・アーキテクチャのいずれかを使用
するローカル・バスを含む、数種類のバス構造のいずれ
かであることができる。例として、限定されるものでは
ないが、このようなアーキテクチャは、業界標準アーキ
テクチャ（Industry Standard Architecture）（ＩＳ
Ａ）バス、マイクロ・チャネル・アーキテクチャ（Micr
o Channel Architecture）（ＭＣＡ）バス、エンハンス
トＩＳＡ（ＥＩＳＡ）バス、ビデオ電子機器標準協会
（Video Electronics Standards Association）（ＶＥ
ＳＡ）ローカル・バス、加速グラフィックス・ポート
（Accelerated Graphics Port）（ＡＧＰ）バス、メザ
ニン・バス（Mezzanine bus）としても周知の、周辺構
成要素相互接続（Peripheral Component Interconnec
t）（ＰＣＩ）を含む。

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

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

【００２４】コンピュータ１１０はまた、その他の取り
外し可能／取り外し不能、揮発性／不揮発性コンピュー
タ記憶媒体を備える。例示のためだけに、図１は、取り
外し不能の不揮発性磁気媒体から読出し、そこに書き込
むハード・ディスク・ドライブ１４１と、取り外し可能
の不揮発性磁気ディスク１５２から読出し、そこに書き
込む磁気ディスク・ドライブ１５１と、ＣＤＲＯＭまた
はその他の光学媒体などの、取り外し可能の不揮発性光
学ディスク１５６から読出し、そこに書き込む光学ディ
スク・ドライブ１５５とを図示している。例示のオペレ
ーティング環境の例で使用することのできる、その他の
取り外し可能／取り外し不能、揮発性／不揮発性コンピ
ュータ記憶媒体は、限定されるものではないが、磁気テ
ープ・カセット、フラッシュ・メモリ・カード、ディジ
タル多目的ディスク（ＤＶＤ）、ディジタル・ビデオ・
テープ、ソリッド・ステートＲＡＭ、ソリッド・ステー
トＲＯＭなどを含む。

【００２５】ハード・ディスク・ドライブ１４１は、一
般に、インターフェース１４０などの取り外し不能メモ
リ・インターフェースを介してシステム・バス１２１に
接続し、磁気ディスク・ドライブ１５１および光学ディ
スク・ドライブ１５５は、一般に、インターフェース１
５０などの取り外し可能メモリ・インターフェースによ
ってシステム・バス１２１に接続する。

【００２６】上記で説明し、図１に示した、ドライブお
よびそれらの関連コンピュータ記憶媒体は、コンピュー
タ１１０のための、コンピュータ読取り可能命令、デー
タ構造、プログラム・モジュールおよびその他のデータ
の記憶域を提供する。図１では、たとえば、ハード・デ
ィスク・ドライブ１４１は、オペレーティング・システ
ム１４４、アプリケーション・プログラム１４５、その
他のプログラム・モジュール１４６およびプログラム・
データ１４７を格納するものとして示してある。これら
の構成要素は、オペレーティング・システム１３４、ア
プリケーション・プログラム１３５、その他のプログラ
ム・モジュール１３６、およびプログラム・データ１３
７と同じまたは異なるもののどちらでもあり得ることに
留意されたい。オペレーティング・システム１４４、ア
プリケーション・プログラム１４５、その他のプログラ
ム・モジュール１４６、およびプログラム・データ１４
７は、本明細書では、最小限で示してあるが個別の数量
が与えられ、それらは異なるコピーである。ユーザは、
コマンドおよび情報を、タブレット（電子ディジタイ
ザ）１６４、マイクロホン１６３、キーボード１６２お
よび通常マウス、トラックボールまたはタッチパッドと
呼ぶポインティング・デバイス１６１、などの入力装置
を介して、コンピュータ２０に入力することができる。
その他の入力装置（図示せず）は、ジョイスティック、
ゲーム・パッド、衛星放送用パラボラ・アンテナ（sate
llite dish）、スキャナなどを備えることができる。こ
れらおよびその他の入力装置は、システム・バスに結合
するユーザ入力インターフェース１６０を介してプロセ
ッシング・ユニット１２０に接続することが多いが、パ
ラレル・ポート、ゲーム・ポートまたはＵＳＢ（univer
sal serial bus）など、その他のインターフェースおよ
びバス構造によって接続することもできるる。モニタ１
９１またはその他の種類のディスプレイ装置も、ビデオ
・インターフェース１９０などのインターフェースを介
してシステム・バス１２１に接続される。モニタ１９１
も、タッチ・スクリーン・インターフェース１９２など
のインターフェースを介してコンピュータ・システム１
１０への手書き（handwriting）など、ディジタル化し
た入力を入力することができるタッチ・スクリーン・パ
ネル１９３などと統合されることもできる。モニタおよ
び／またはタッチ・スクリーン・パネルは、タッチ・ス
クリーン・パネル１９３が、本来タブレット１６４とし
て働く、タブレット・タイプのパーソナル・コンピュー
タなどのように、計算装置１１０がその内部に組み込ま
れているハウジングに物理的に結合できることに留意さ
れたい。さらに、計算装置１１０などのコンピュータは
また、出力周辺インターフェース１９４などを介して接
続することができる、スピーカ１９５やプリンタ１９６
などのその他の周辺出力装置を備えることができる。

【００２７】コンピュータ１１０は、リモート・コンピ
ュータ１８０などの１つまたは複数のリモート・コンピ
ュータへの論理接続を使用するネットワーク環境で動作
することができる。リモート・コンピュータ１８０は、
パーソナル・コンピュータ、サーバ、ルータ、ネットワ
ークＰＣ、ピア装置またはその他の共通ネットワーク・
ノードであることができ、図１ではただ１つのメモリ記
憶装置１８１だけを示してあるが、一般に、コンピュー
タ１１０に関連して上述した多くのまたはすべての要素
を有する。図１に示す論理接続は、ローカル・エリア・
ネットワーク（ＬＡＮ）１７１およびワイド・エリア・
ネットワーク（ＷＡＮ）１７３を含むが、その他のネッ
トワークも含むことができる。このようなネットワーキ
ング環境は、オフィス、全社的なコンピュータ・ネット
ワーク、イントラネットおよびインターネット内で良く
見かけるものである。

【００２８】ＬＡＮネットワーキング環境を使用した場
合、コンピュータ１１０は、ネットワーク・インターフ
ェースまたはアダプタ１７０を介してＬＡＮ１７１に接
続する。ＷＡＮネットワーキング環境を使用した場合、
コンピュータ１１０は、一般に、インターネットなど、
モデム１７２またはその他のＷＡＮ１７３を介して通信
を確立するための手段を備える。モデム１７２は、内部
または外部のいずれかであるが、ユーザ入力インターフ
ェース１６０またはその他の適切なメカニズムを介して
システム・バス１２１に接続する。ネットワーク環境で
は、コンピュータ１１０またはその一部に対して示して
あるプログラム・モジュールは、リモート・メモリ記憶
装置内に格納される。例として、限定するものではない
が、図１には、メモリ装置１８１に存在するリモート・
アプリケーション・プログラム１８５を示してある。示
してあるネットワーク接続は例示のためであり、コンピ
ュータ間の通信を確立するためのその他の手段も使用可
能であることは理解されよう。

【００２９】メディア統合層アーキテクチャ（MEDIA IN
TEGRATION LAYER ARCHITECTURE）本発明の一態様は、一
般に、代表的なコンピュータ・システムに存在するグラ
フィックス・ハードウェアのパワーをより活用すること
に向けられる。この目的のため、図２に概略的に示され
ているように、メディア統合層アーキテクチャ２００が
提供される。アプリケーション、制御またはその他同様
のより高レベルのプログラム・コード（たとえば、オペ
レーティング・システム構成要素のユーザ・インターフ
ェース）２０２が、１組のアプリケーション・プログラ
ミング・インターフェース（ＡＰＩ）２０４などを介し
て、メディア統合層アーキテクチャ２００にアクセスし
て、グラフィカル情報にアクセス（書き込みまたは読出
し）する。本明細書に記述した多くの例は、ＡＰＩとイ
ンターフェースをとるアプリケーション・プログラムを
引用するが、その他のより高レベルのプログラム・コー
ドおよび構成要素（たとえば、オペレーティング・シス
テムのユーザ・インターフェース）も、本明細書に記述
した、より低レベルの構成要素とインターフェースをと
ることができることが理解できることに留意されたい。
したがって、このようなより高レベルのプログラム・コ
ードへの如何なる引用も、アプリケーション・プログラ
ムや、ユーザ・インターフェースなどのいずれであろう
とも、均等物であると考えるべきである。

【００３０】セキュリティを含むさまざまな理由から、
メディア統合層２００（これは、グラフィックスを出力
する）は、好ましくは、オペレーティング・システムに
組み込まれることに留意されるべきである。たとえば、
メディア統合層２００のいくつかまたは一部を、アプリ
ケーションとオペレーティング・システムの間に挿入す
ることができるが、そうすると、有害なプログラムが、
グラフィックスが要求されている場合は何でもディスプ
レイすることを可能にし、それにより、不都合を引き起
こすことになる。たとえば、有害なコードが、パスワー
ドの入力を要求するダイアログ・ボックスを表示し、そ
れにより、ユーザのパスワードを盗むことが可能とな
る。オペレーティング・システムにメディア統合層２０
０を組み込むその他の理由としては、安定性および効率
性を含み、たとえば、より低レベルでは、より高い層か
らのデータおよび命令は既に検証済みであることを効率
的に当てにすることができる。さらに、より低レベル
は、責任を持ってコールをする、信頼されているオペレ
ーティング・システムのみに、インターフェースを公開
する、つまり、予測不可能なプログラムに低レベルのイ
ンターフェースを公開しないとすることができ、これに
より、ためより高い安定性を保証することができる。

【００３１】一実施形態では、メディア統合層アーキテ
クチャ２００は、高レベル合成およびアニメーション・
エンジン２０６、タイミングおよびアニメーション構成
要素２０８、および低レベル合成およびアニメーション
・エンジン２１０を含む。本明細書で使用する用語、
「高レベル」および「低レベル」は、その他のコンピュ
ーティング・シナリオで使用されるものと同様であり、
ここでは、一般的に言って、より高い構成要素に対する
低いソフトウェア構成要素は、その構成要素がより低く
なるとハードウェアになる。このように、たとえば、高
レベル合成およびアニメーション・エンジン２０６から
送信されたグラフィックス情報は、低レベル合成および
アニメーション・エンジン２１０で受信されるが、ここ
で、情報は、グラフィックス・データをハードウェアを
含むグラフィックス・サブシステムに送信するために使
用される。

【００３２】以下に記述するように、高レベル合成およ
びアニメーション・エンジン（本明細書では、高レベル
・コンポジッタ（compositor）およびアニメータまたは
高レベル・エンジンまたは高レベル構成要素とも呼ぶ）
２０６は、ディスプレイ・ツリーを構築して、アプリケ
ーション・プログラム２０２によって供給されるグラフ
ィックス・シーンを表し、この間、タイミングおよびア
ニメーション構成要素は、宣言（またはその他の）アニ
メーションおよびタイミング制御を供給する。また以下
に記述するように、低レベル合成およびアニメーション
・エンジン（本明細書では、低レベル・コンポジッタお
よびアニメータまたは低レベル・エンジンまたは低レベ
ル構成要素とも呼ぶ）２１０は、多数のアプリケーショ
ンのシーンのためのレンダリングを組み立て、そしてレ
ンダラ（renderer）とも呼ばれるレンダリング構成要素
を使用して、スクリーンに対してグラフィックスのレン
ダリングを実際に実行する。しかし、時にはより高いレ
ベルでいくつかのレンダリングをすることが必要および
／または好都合である場合があることに留意されたい。
たとえば、より低い層は、多数のアプリケーションから
の要求にサービスするが、この間、より高い層は、アプ
リケーション毎にインスタンス生成される。これによ
り、より高いレベルで、時間のかかる、またはアプリケ
ーション特有のレンダリングが可能となり、ビットマッ
プへの参照をより低い層にパスすることができる。

【００３３】一般的に言って、高レベル合成およびアニ
メーション・エンジン２０６は、ディスプレイ構造を構
築し、構造をトラバースして、低レベル合成およびアニ
メーション・エンジン２１０にパスされるべき、レンダ
リング命令および単純なアニメーション間隔を生成す
る。高レベル・コンポジッタによって生成されるレンダ
リング命令は、タイミングおよびアニメーション情報を
含むことができる。低レベル合成およびアニメーション
・エンジン２１０は、レンダリング命令およびアニメー
ション間隔を受け取り、次いで、アニメーション、レン
ダリング、およびグラフィックス・サブシステム（たと
えば、グラフィックス・ソフトウェアおよびハードウェ
ア）２１２に供給されるシーンの合成、を管理する。

【００３４】一方、または局所的に表示される出力に加
え、高レベル合成およびアニメーション・エンジン２０
６（またはそれと同様の）は、適切なフォーマットのレ
ンダリングおよびアニメーション命令を、固定イメージ
・データをプリンタ２２２などに送るためのより低レベ
ルの印刷コード２２０に供給し、かつ／または適切なフ
ォーマットのレンダリング命令および単純なアニメーシ
ョン間隔を、より低レベルの、リモート・マシン２２８
に送信する端末移送サーバ２２６に供給する。より豊富
な情報もネットワークを介してパスされることに留意さ
れたい。たとえば、ネットワーク・トラフィックを伴わ
ずに、マウスのロール・オーバ効果をリモート・マシン
に局所的に対処させるのが望ましいかも知れない。

【００３５】多重グラフィックス処理レベル（MULTIPLE
GRAPHICS PROCESSING LEVELS）本発明の一態様に従う
と、メディア統合層アーキテクチャ２００は、上に述べ
たように、グラフィックス処理を多数のレベルに分割す
る。これらのレベルのそれぞれが、アプリケーション、
ユーザ・インターフェースおよびその他２０２が、スム
ーズなアニメーションでグラフィックスを出力し、その
他のアプリケーションのグラフィックスおよびビデオ・
フレームでグラフィックスを合成することを共に許可す
る、いくつかのインテリジェント・グラフィックス処理
を実行する。アニメーションおよび／または合成を、音
声出力に同期させることも可能である。たとえば、音声
を低レベル構成要素のフレーム速度と同期させることに
より、音声のタイミングが、ビデオまたはグラフィック
スのタイミングと実質的に一致し、リフレッシュ速度に
追いつくために複雑な前処理をするタスク・スケジュー
ルについての能力に依存しなくなる。

【００３６】図３に全体を示すように、ＡＰＩｓ２０４
を介して通信するアプリケーション２０２の下で、高レ
ベル・コンポジッタおよびアニメータ・エンジン２０６
は、アプリケーション・グラフィカル・データをツリー
構造３００内にキャッシュし、データをインテリジェン
トな方式で前処理し、その他数々のオペレーション（以
下に記述する）を実行して複雑なグラフィックスの出力
を容易にする。一般的に言って、高レベル・コンポジッ
タおよびアニメータ・エンジン２０６は、処理量を著し
く単純化し、より低いレベルが正しい出力をレンダリン
グする処理に必要とされるデータ量を著しく減少させ
る、複雑な処理（時には、コンパイルと呼ぶ）を実行す
る。しかし、より高いレベルで実行される処理量および
処理のタイプは、かなりの程度、負荷、およびより低い
レベルの機器構成および機能に依存する。たとえば、高
機能のグラフィックス・ハードウェアが存在する場合、
高いレベルは、処理量が減少する可能性があり、またそ
の反対もある。高レベルおよび低レベルの層はこれらの
要因に適応的である。

【００３７】本発明に従って、高レベル合成およびアニ
メーション・エンジン２０６は、そのレベルまたはそれ
以下のレベルより比較的遅い速度で動作するので、利用
可能なシステム・リソースを使い果たすことなく、この
ような複雑な処理を達成することができる。例として、
限定するものではないが、より低いレベルは、ハードウ
ェア・グラフィックス・プロセッサのフレーム（リフレ
ッシュ）速度で動作することができる。たとえば、高レ
ベル・コンポジッタおよびアニメータ２０６は、ディス
プレイの変更を、オン・デマンドで、またはその他のス
ケジュール（たとえば、０．５秒毎に）で、実施する必
要があるときに動作するだけとすることができる。単一
の高レベル・コンポジッタおよびアニメータ・エンジン
２０６は、図３に示してあるが、アプリケーション単位
で１つずつなど、多くの場合があり、一方、一般には、
グラフィックス装置毎に１つだけの低レベル合成および
アニメーションエンジ２１０である、たとえば、マシン
のそれぞれのグラフィックス・ハードウェア・カードに
ついて１つである、ことに留意されたい。

【００３８】さらに、高レベル・コンポジッタおよびア
ニメータ２０６は、たとえば、実質的にいずれかの抽象
装置３０２などの、適切なレベルまたはそれ以下のレベ
ルのフォーマットに、その出力を適合させる（または出
力するように設計する）。たとえば、高レベル・コンポ
ジッタおよびアニメータ２０６は、最終的に、プリンタ
に、ネットワークを介していくつかの、その上にディス
プレイするリモート端末に、送信するために、または、
主に本明細書の以下に記述するが、ローカル・グラフィ
ックス・ソフトウェアおよびハードウェア２１２上に存
在する、より低レベルのコンポジッタおよびアニメータ
２１０のために、コンパイルした出力を作り出すことが
できる。単一の高レベル・コンポジッタおよびアニメー
タが、複数の抽象装置のためのアプリケーションの出力
を処理することができる、がそうでない場合、それぞれ
のタイプの抽象装置のためのアプリケーションの出力を
処理する高レベル・コンポジッタおよびアニメータの適
当な例、たとえば、ローカル・グラフィックスに１つ、
プリンタに１つ、そして端末サーバに１つ、があり得
る。

【００３９】さらに、高レベル・コンポジッタおよびア
ニメータ２０６によって供給されるコマンドおよびその
他のデータを単純化して、ハードウェアの能力および条
件に一致させることができる。たとえば、より劣ったハ
ードウェアであれば、高レベルの前処理が多く必要とな
る。さらにまた、たとえば、１または複数のより低いレ
ベルに配置される処理需要に適応させるように、高レベ
ルの前処理の量は動的とすることができる。

【００４０】ローカル・グラフィックス出力のために、
１機器構成内に、メディア統合層アーキテクチャ２００
は、高レベル・コンポジッタおよびアニメータ２０６
と、低レベル・コンポジッタおよびアニメータ２１０と
を含む。以下に記述するように、一般的に言って、高レ
ベル・コンポジッタおよびアニメータ２０６は、クライ
アントから受け取ったグラフィックス情報（たとえば、
アプリケーション）について複雑な処理を実行して、グ
ラフィックス構造を構築し、これらの構造をグラフィッ
クス・コマンドのストリームに変換する。次いで、低レ
ベル・エンジン２１０は、さまざまなクライアントから
のグラフィックス・コマンドのストリームを使って、コ
ンピュータのユーザが見るデスクトップを合成する。た
とえば、低レベル・コンポジッタは、デスクトップ上に
渡されるさまざまなクライアントによって放出されるコ
マンド・ストリームを結合して、グラフィックス合成エ
ンジンによって消費されるグラフィックス・コマンドに
することにより、デスクトップを合成する。

【００４１】この実施形態では、高レベル・コンポジッ
タおよびアニメータ２０６は、通常、グラフィックス・
サブシステム２１２のグラフィックス・ハードウェアの
ハードウェア・リフレッシュ速度よりはるかに遅い速度
で、構造３００を構築し、グラフィックス・コマンドの
ストリームに変換する、複雑な処理オペレーションを実
行する。この高レベルな前処理の結果、低レベル・エン
ジン２１０は、グラフィックス・サブシステム２１２の
グラフィックス・ハードウェアのハードウェア・リフレ
ッシュ間隔内で、それ自体の処理オペレーションを実行
することが可能となる。しかし、上述したように、低レ
ベル・エンジン２１０は、高レベルの前処理が低レベル
の処理需要に動的に適応できるようにするために、バッ
ク・チャネルを介して高レベル・エンジン２０６に戻り
の通信をすることができる。低レベル・コンポジッタお
よびアニメータ２０６から高レベル・コンポジッタおよ
びアニメータ２０６へのバック・チャネルは、主に、高
レベル・エンジン２０６へのフロー制御（低レベル・エ
ンジン２１０は、より多くのデータを必要とするか、ま
たは余りに多くを受信していることをシグナリングす
る）、および／または高レベル・エンジン２０６によっ
て実行可能なエラー条件を通信するためである。このよ
うな通信の１つの利点として、低レベル合成およびアニ
メーション・エンジン２１０が、優先度やスケジューリ
ングの心配をする必要がないことであるが、リフレッシ
ュ速度との同期の問題は、依然残る。その代り、現代の
オペレーティング・システムに既に存在する高レベルの
ＣＰＵプロセス・スケジューリングは、優先度を制御す
るだろう。したがって、たとえば、アプリケーション・
プロセスが、その優先度と比べて、高レベルのグラフィ
ックス前処理のその配分について余りに多くを使用しよ
うとした場合、その出力に悪影響が出るのはそのアプリ
ケーションである。しかし、低レベル・システムが過負
荷である場合は、あるプロセス／高レベル構成要素の変
更および要求を、別のものより優先させるよう選択する
ことができる。たとえば、前景アプリケーションに優先
度を与えることができる。

【００４２】高レベル・コンポジッタおよびアニメータ
（THE HIGH-LEVEL COMPOSITOR ANDANIMATOR）一実施形
態では、現実的に、多くの種類や差異のあるグラフィッ
クス・ハードウェアに対処するように、それぞれのユー
ザ・アプリケーションを書き込むことができないため、
高レベル・コンポジッタおよびアニメータ２０６を含む
メディア統合層２００が、所与のマシンのハードウェア
の差を調整する。しかし、アプリケーションは、また、
メディア統合層２００によって、つまり、オペレーティ
ング・システムのグラフィックスＡＰＩに、現在パスさ
れるものより多くの（そして異なる）情報を高レベル・
コンポジッタおよびアニメータ２０６に供給することに
よって、提供される改良グラフィックス処理に貢献する
こともできる。たとえば、メディア統合層２００を認識
しているアプリケーションは、メディア統合層ＡＰＩ２
０２を介してアニメーション意図などを含む、種々のデ
ータを供給する。例示として、やや変化するイメージを
連続して再描画することによってアニメーションを実行
する代りに、アプリケーションは、特定のイメージを、
たとえば、固定の背景に対して、どのように時間をかけ
て移動すべきかについての命令を提供することができ
る。次いで、メディア統合層２００は、以下に概略を記
述するように、スムーズなレンダリング方式でオートメ
ーションを処理する。

【００４３】一般的に、図３および４に示すように、ア
プリケーション２０２は、ＡＰＩ２０４を介してシーン
・グラフ・データ構造を構築する。データは、高レベル
構造およびと基本要素（primitive）データを有し、そ
してビジュアル情報をインテリジェントな方式でキャッ
シュに入れるため使用されるキャッシュ・データ構造３
００、内に入れられる。

【００４４】インテリジェント・キャッシング・データ
構造３００全体内のオブジェクト（または構造）の１つ
が、コンテナ４０２、４０４または４０８（あるいはビ
ジュアル２Ｄと呼ぶ）で図４に示したコンテナである。
一実施形態では、コンテナ（たとえば、４０４）が、ア
プリケーションがそれのためのハンドルを保持すること
ができる、そして、アニメーションおよびテンプレーテ
ィング、ヒット−テスト（hit-testing）およびユーザ
・データのフッキング・アップ（hooking up）のために
使用できる手続きパラメータを含む、識別（identity）
を提供する。しかし、本明細書に記載したコンテナは、
明らかにされる可能性のある唯一の種類のコンテナでは
ないことに留意されたい。その他の例では、パラグラフ
内にラインを格納するため、またはグリッド内に多くの
子を格納するために最適化されたコンテナを含むことが
できる。特定の種類のコンテナでは、子に対してランダ
ム・アクセスができないものの、子コンテナは、現行の
子リストをクリアすることなく、追加されたり削除され
たりできる。ＡＰＩを介して使われる構造は、必要に応
じて変更することができる。

【００４５】このデータ構造のその他の（内部）ノード
は、変換４０６、アルファ・ノード、キャッシュ・ノー
ド、および基本要素ノード４１０、４１２を含み、ＡＰ
Ｉコンテナと直接には関連していない内部データを格納
するために使用される。基本要素は、一般に、直接グラ
フィックス装置にパスできる命令のストリームとして格
納される。

【００４６】図５のツリー・セグメント５００に示すよ
うに、５１０のようなコンテナは、したがって、その他
のコンテナ５１２または描画基本要素５１６を保持で
き、ここで、いずれかのコンテナの中の基本要素の記憶
域は、グラフィックス命令のストリームと考えることが
できる。コンテナは、また、その他のコンテナも格納す
ることができ、事実上、グラフを作成する、たとえば、
データ構造がコンテナの「閉路を含まない有向グラフ
（ＤＡＧ）」および基本要素のリストである（ここで、
コンテナは、その親コンテナの１つを含むことができな
い）ように、コンテナを１を越えるコンテナによって参
照されることができる。また図５に示すように、グラフ
的な方式でツリーが他のツリーを参照できることによ
り、ツリー・セグメント５０２内のコンテナ５１８など
の、コンテナのいずれかを、異なるパラメータではある
ものの、異なる場所で再使用することができる。

【００４７】一般に図４の描画コンテキスト４１６に示
すように、コンテナが、開／閉パターンを介して置かれ
ている。より詳細には、より高レベルのコード２０２
が、データ構造内のコンテナ４０８を開け、描画コンテ
キスト４１６を提供して、描画基本要素を書き込み、か
つ／またはその他のコンテナをデータ構造に追加し、次
いでコンテナ４０８を閉じる。一代替実施形態では、コ
ンテナを閉じたとき、そのデータは、変更待ち行列４１
８内に入れられ、次いで、その後適用される。コンテナ
の開閉は、データ構造を変更するための主要メカニズム
の１つである。その他の使用パターンも、特に異なる種
類のコンテナについて、用いることができることに留意
されたい。

【００４８】この代替形態では、データ構造の変更が待
ち行列に入れられるため、データ構造を更新するための
トランザクション的な（またはバッチ的な）システム
が、可能となる。その結果、コンテナを開けてコンテナ
に書き込んだときは、コンテナを閉じるまでスクリーン
上に変更が現れない。スクリーンへの変更はアトミック
（ａｔｏｍｉｃ）であり、部分的に描画したスクリーン
について時間的アーティファクト（構造的なティアリン
グとも呼ぶ）はない。さらに、このようなトランザクシ
ョンの動きを、一度に多数のコンテナが変更されるよう
に、拡張することができる。この方式で、より高レベル
のコード２０２は、多くの変更をシーンにセットアップ
することができ、これらの変更の全てを一度に適用でき
る。

【００４９】一代替実施形態では、待ち行列４１８への
変更をディスプレイ・マネージャ４２０を介して通知す
ることにより、データ構造への変更が、非同期式で行わ
れる。その結果、変更がレンダリング・スレッド４２２
上で処理される、そして、たとえば、低レベル・コンポ
ジッタおよびアニメータ２１０に送信される（ここで、
図３の抽象装置３０２は、低レベル・コンポジッタ２１
０にストリームされたレンダリング・コマンドの中に、
高レベル・コンポジッタ２０６によって出されたレンダ
リング・コマンドの変換をカプセル化する抽象化を含
む）。トランザクション的なモデルは、また、データ構
造への修正が、データ構造からの読出しを中断すること
なく、なされることを可能にする。上述の待ち行列モデ
ルにより、高レベル・エンジン２０６からの読出しパス
が、ユーザの行うどのようなアクションにも関係なく動
作できるようになるが、ユーザ・アプリケーションは、
ＡＰＩの一貫性のあるビューを維持するために、キャッ
シュが必要であり、そのため効率性が損なわれる。例と
して、コンテナ上のプロパティの設定をする主要ユーザ
・スレッド上のユーザ・アプリケーション（高レベル・
エンジン２０６内のオブジェクト）を考えてみよう。待
ち行列モデルでは、このプロパティは、高レベル・エン
ジン２０６データ構造に適用される待ち行列の中に入れ
られる。しかし、ユーザ・アプリケーションが、直ちに
そのプロパティをコンテナからリード・バック（read b
ack）を試みると、システムは、現在待ち行列内にある
ものに基づいてプロパティをリード・バックし（これは
非効率的である）、レンダリング・スレッドと同期をと
り、待ち行列内で待っている変更を適用し（これは非効
率的であり、待ち行列を有するという利点を無駄にする
ものである）、または、レンダリングのバージョンおよ
び待ち中のバージョンの両方とも、ユーザ変更可能デー
タのコピーをコンテナに保管しなければならない（これ
は、非効率的なメモリの使用法である）。

【００５０】アプリケーションによるリード・バック量
がかなりあるため、代替実施形態は、実際のところ、高
レベル・エンジン２０６データ構造および主要ユーザ・
スレッドの更新を同期することにより、待ち行列を削除
する。このことは、ユーザ・アプリケーションがレンダ
リングを凍結できるようにするが、全体的なシステム
は、より効率的になる。しかし、凍結（freeze）による
知覚的な影響を緩和するために、高レベル・エンジン２
０６とは関係なく、より多くのアニメーション処理をす
る低レベル・エンジン２１０に任せている間、さまざま
な部分のアニメーションおよびタイミング・システムが
独自に動作して、低レベル・エンジン２１０まで情報を
通信する。したがって、高レベル・エンジン２０６が、
ユーザによるアクションによって凍結しても、スクリー
ンへの出力は、依然として、比較的スムーズで、かつ一
貫性があるでしょう。

【００５１】さらに別の代替形態では、レンダリング・
スレッドを削除し、主要ユーザ・スレッドに高レベル・
エンジン２０６にとって必要な処理を実行させ、レンダ
リング命令を低レベル・エンジン２１０にパスさせるよ
うにする。これは、場合によっては、より効率的なスレ
ッドの使用法である。

【００５２】図４に戻ると、コンテナ４０８は、描画基
本要素を含む基本識別ノードを備え、描画コンテキスト
４１６は、基本要素、変換、クリップまたはその他の描
画オペレーションをコンテナに追加するために使用する
ことのできる、コンテナから得られたグラフ・ビルダ
（たとえば、ヘルパ・オブジェクト（helper object）
を備える。ディスプレイ・マネージャ４２０は、高レベ
ル・コンポジッタおよびアニメータ２０６のインスタン
スを表す、ホスティング・オブジェクトを備える。そし
て、たとえば、ｈｗｎｄ（ウィンドウへのハンドル）ま
たはｈｖｉｓｕａｌ（ビジュアル・コンテナへのハンド
ル）にアタッチすることができる。ディスプレイ・マネ
ージャ４２０は、シーンのためのルート・コンテナ４０
２へのポインタを有し、コンテナが無効で再描画の必要
がある場合に、イベントを高レベル・コードにディスパ
ッチし、ヒット・テストや座標変換などのサービスへの
アクセスを提供する。

【００５３】より高レベルのコード２０２は、ハンドル
などを、データ構造およびコンテナ内のオブジェクトの
いくつかに保持できるが、コンテナ内の殆どのオブジェ
クトは、アプリケーションの観点からの識別性を持たな
い。具体的には、この構造へのアクセスが、殆どの使用
パターンが「書き込みに限る」という制限がなされてい
る。この方式で識別を制限することにより、データ構造
内に格納された情報の多くを最適化できるようになり、
そしてより高レベルのコード２０２は、オブジェクト情
報を格納したり、オブジェクトの生存期間の管理に対処
したりする必要がなくなる。

【００５４】たとえば、必要でないグラフの一部（たと
えば、スクリーンにクリップされてしまった、またはス
クリーンからスクロール・オフされたビジュアル情報に
対応する）を維持するリソースは、その後必要になれば
シーンを再描画するよう要請するアプリケーションとと
もに、再利用することができる。したがって、一般に、
コンテナが開けられると、その中身がクリアされ、忘れ
去られている。これらの中身が識別を持たない場合は、
それらのリソースはシステムによって再利用することが
できるように、これらのコンテンツは安全に消滅する。
より高レベルのコード２０２またはグラフの別の部分が
子コンテナ上にホールドしている場合は、これらのコン
テナは、そのあたりに留まって、再挿入することができ
る。しかし、このパターンは、より高レベルのコード２
０２の必要性に応じて、変更および適応が可能である。

【００５５】したがって、要するに、コンテナは、デー
タ構造を使用する高レベル・コードがそのオブジェクト
に対するハンドルを保持することができるという点で、
識別を持つオブジェクトである。識別を持つオブジェク
トの反対は、プレーン・データであり、そして、ユーザ
・コードは、識別を持たないデータをオブジェクトとし
て扱うメンタル・モデルを用いるが、いったんこのデー
タがシステムで使用されると、その後そのオブジェクト
を参照する方法はない。このように、システムにとって
好都合な方式で、オブジェクトは、変換され、そして変
更されることができる。

【００５６】単純化した例として、テキストのラインを
描画するためのＡＰＩ機能が、ＴｅｘｔＬｉｎｅオブジ
ェクトを含むことがある。このオブジェクトのユーザ
は、ＴｅｘｔＬｉｎｅオブジェクトに、描画すべき実際
のテキストを、そのテキストについての種々の動作をど
のようにレンダリングするのかに関するその他の情報
（フォント、サイズ、ブラシその他）とともに、入れ
る。ユーザ・プログラム・コードが、そのテキストのラ
インをデータ構造に実際に追加することを求めている場
合、プログラム・コードは、指定の開くノード用に描画
コンテキストを取って、ＴｅｘｔＬｉｎｅオブジェクト
を描画コンテキスト上にある描画機能にパスする。実際
にシステムは、ＴｅｘｔＬｉｎｅオブジェクト内にある
データを取り、そのデータをデータ構造内にコピーす
る。このデータは識別を持たないため、高レベル・コン
ポジッタおよびアニメータ・エンジン２０６は、自由に
そのラインのコンテンツを取ることができ、アルゴリズ
ム（たとえば、ＯｐｅｎＴｙｐｅ）を実行してテキスト
を位置付きのグリフに分割して、位置付けられたグリフ
・データを、生のテキストの代りに格納する。そのライ
ンを描画した後は、システムは、ラインを描画するのに
使用するＴｅｘｔＬｉｎｅオブジェクトへの参照を持た
ない、すなわち、システムが格納するデータは識別を持
たない。

【００５７】あるいは、より高レベルのコード２０２
は、その識別をそのＴｅｘｔＬｉｎｅオブジェクトに保
存するよう要請し、そのオブジェクトの参照をデータ構
造内に格納するよう要求する。この方式で、より高レベ
ルのコード２０２は、その後ＴｅｘｔＬｉｎｅオブジェ
クトを変更する場合、システムは、その変更を発見し、
それをレンダリングの出力に反映する。より現実的な例
においては、識別は、テキスト・ライン・オブジェクト
自体には明らかにされないが、アプリケーションが、コ
ンテナへのハンドルを保持し、上述した（例えば、特許
文献２参照）という米国特許出願に記述しているよう
に、要求のあり次第、そのコンテナをパラメータ化する
ことによって変更をすることになる、ことを留意された
い。しかしながら、データ構造の主要態様の１つに、よ
り高レベルのコード２０２は、このようなオブジェクト
を識別を備えて作成する必要性を減少させることにあ
り、それによって、データ構造内の低減された数のポイ
ントが、制御コード２０２によって参照されることにな
る。このことにより、データ構造がより一層最適化され
る。

【００５８】たとえば、データ構造の外部に明らかにさ
れる識別の量の低減により、基本要素の格納密度を濃く
するなどの最適化が可能となる。この目的のため、ベク
トル・グラフィック・データは、「基本要素リスト」ま
たは「基本要素コンテナ」内に格納される。これらのコ
ンテナは、実施詳細であり、識別がより高レベル・コー
ド２０２に明らかにされることはない。コール元がデー
タをコンテナ内に書き込むと、そのデータは、コンテナ
のような、リンクされている別個のオブジェクト内に格
納されるか、（たとえば、変換とともに）、パック、お
よびフラット化されたデータ・アレイ内にストリームす
る、ことができる。このアレイは、コンパクトな方式で
ベクトル・グラフィック・データを格納できるばかりで
なく、これらの基本要素に沿って実行するリソースを追
跡することができる。個々の基本要素が識別を持たない
ため、基本要素を分離したり、その後これらの基本要素
を変更したりするための方法をユーザに提供する必要が
なく、基本要素のより効率的な格納を可能にする。

【００５９】別の最適化として、サブグラフが変化して
いない場合は、そのツリーのコンテンツのビットマップ
を格納し、そのビットマップをコンテナにアタッチする
ことができ、それによって、必要とされる高レベルの処
理量を減らすことができる。さらに、サブグラフまたは
基本要素リストの一部が、レンダリングのために、より
低レベルのコードにパスされる前に大量の処理を必要と
する場合（たとえば、ハードウェア装置に手渡される前
の、ベクトル・グラフィックスの埋め尽くし）は、その
後の再使用のために、後処理の結果がキャッシュに入れ
られる。

【００６０】さらに、特定の読出しオペレーション（以
下に記述する）以外に、構造についての明らかにされる
ことがないため、データ構造は、レンダリングの結果が
同じである限り、自由にコンテナを再編成することがで
きるようにする。したがって、コンテナは、空間区画化
（space partitioning）ツリー内に子コンテナを格納し
て、レンダリングおよびその他の読出しオペレーション
を最適化することができる。さらに、データ構造を、同
じ装置または多数の装置に何回も表示することができ
る。このため、キャッシュが装置に依存している場合
は、装置に基づいてキーを付けることができる。サブ−
ツリーが静的であると認識されると、その周囲のアニメ
ーションのため何度も再ペイントされ、しかもそのリソ
ースのドレーンを保証するに足りる密度である場合は、
キャッシュ・ノードは、自動的にそのサブ−ツリーに挿
入されることがある。

【００６１】レンダリングのために、データ構造が読み
出され（スケジュールしておいた時間に、または異なる
スレッドによって）、そして処理されたあるフォームの
情報は、より低レベルのアニメータおよびコンポジッタ
２１０にパスされる。このため、一代替実施形態では、
レンダリング・オブジェクトおよびスレッド（プロセス
毎の）４２２が、データ構造３００をトラバースしてレ
ンダリング・プロセスを駆動する。他の代替形態では、
それ自身のスレッドで実行する代りに、レンダリング・
プロセスが、１種の「協調型多重タスキング」配置で、
残りのユーザ・コードを持つ共通スレッドと時間を分配
する。データ構造３００は、非常に高速の合成およびア
ニメーションのために、より低レベルの構成要素に送ら
れるビジュアル情報にコンパイルされるのが好ましい
が、データ構造３００を直接レンダリングに使用するこ
とができる。データ構造３００は、また、ネットワーク
を介して、リモート端末、プリンタに送信し、かつ／ま
たは、相互交換またはキャッシュに入れるためにディス
クまたはその他のよりパーマネントな記憶媒体に直列化
する、などの異なる方式でコンパイルされることがあ
る。

【００６２】一代替実施形態では、データ構造３００
は、レンダリングのために別のスレッド４２２で読み出
される。しかし、別のスレッドを使用することが必要条
件ではなく、たとえば、「レンダリング・スレッド」
は、あるいは、他と同様に、同じスレッド上で実行する
協調型共用メカニズム（cooperative sharing mechanis
m）を、代替的に備えることに留意されたい。

【００６３】レンダリング・プロセス／スレッドを使用
する代替モデルでは、必要に応じてレンダリング・スレ
ッドが動作し、所定の効果を提供する。スレッドが動作
する度ごとに、まず、変更待ち行列４１８内にある、待
ち状態の変更を適用する。次いで、レンダリング・スレ
ッド４２２は、データ構造３００を歩いて、バウンディ
ング・ボックスや収集無効などの（以下に記述する）情
報を収集する。最後に、前回より変更されている、また
は別の理由からレンダリングする必要があるエリアを歩
き、データ構造内に格納されているレンダリング命令を
実行する。変更待ち行列を使用しない代替モデルでは、
変更は、作成されるときに、直接適用され、したがっ
て、ここでは適用する必要がない。

【００６４】このように、データ構造３００からのレン
ダリングは、待ち行列にある変更をデータ構造に適用す
るパス、データ構造の繰返し、あるいはバウンディング
・ボックス、アニメーションされるパラメータ値などレ
ンダリングに必要なデータの計算、を含む事前計算する
パス、レンダリング・パス、などの、別個のレンダリン
グ・スレッド４２２上で実行できる多数のパス・プロセ
スである。レンダリング・パスは、最終的に低レベル・
コンポジッタおよびアニメータ２１０にデレゲートする
抽象装置３０２を使用して、レンダリングする。レンダ
リング・パス中、後続フレーム上のレンダリング性能を
向上させるために、中間キャッシュ・リソース４２６
を、キャッシュに入れることができる。

【００６５】データ構造を最後に歩き回って得られる可
能性のある結果には、データを直接実行して、スクリー
ン上に表示されるか、または最後に歩き回った最後の所
にフリップされるバック・バッファ上で実行されること
が含まれる。その他の結果には（以下に記述するよう
に）拡張タイミングおよびアニメーション情報とともに
運ばれ、より頻繁に実行するレンダリング・スレッド／
プロセスにパスされるデータが含まれる。また、歩き回
った結果、スクリーン・キャプチャまたはその他の理由
によりデータがビットマップ上で実行されたり、プリン
タに方向付けされたり、または、ネットワークに方向付
けされて、次いでリモート・マシンでの以前のある理由
のために使用されたりすることもある。これらの結果の
組み合わせも、また、可能である。

【００６６】お分かりのように、データ構造３００内の
データの記憶域は、大量のメモリを必要とする。さら
に、データ構造３００内のデータの多くは、クリップ、
スクロール、またはその他の理由により、可視可能では
ないために必要とされないことがある。リソース需要を
減らすため、データ構造３００は、オン・デマンドで構
築することができる。これを可能にするために、必要に
応じて、データ構造３００の一部を作成するため、より
高レベルのコード２０２にコール・バックする方法が提
供される。この方法は、「無効化」と呼び、従来のグラ
フィックス・システムで使用されるＷＭ＿ＰＡＩＮＴコ
ール・バック方法と同様であるが、直接スクリーン上の
ビットに適用する代りに、構造３００およびキャッシュ
されるコンテンツに適用される。しかし、１待ち行列モ
デル代替形態では、読出しオペレーション（以下に記述
する、ヒット・テストおよび座標変換と同様）は最初に
変更を適用し、それゆえ、ユーザに提供されるモデルは
同期する。

【００６７】コンテナは、作成されたとき、リソースが
少ないためコンテンツがシステムによって捨て去られた
とき、またはより高レベルのコードがコンテナを無効に
するよう直接要請したとき、無効にされる場合がある。
たとえば、より高いレベルのコード２０２は、コンテナ
を作成して、そのコンテナがどこにあって、どのぐらい
の大きさであるのかを定義するグラフィカル・サイズを
供給する。レンダリング・オペレーション中、そのコン
テナが無効というマークが付けられたが、必要であると
判断された場合、レンダリング・スレッド４２２は、よ
り高レベルのコード２０２にコンテナ内に書き込むよう
要請する。レンダリング・スレッド４２２は、より高レ
ベルのコード２０２がその要請を終了するまで待つか、
または必要なデータがないままレンダリングを続行す
る。第１の選択は理想的なものではないが、状況によっ
ては必要となる場合がある。

【００６８】最終的にデータが書き込まれ、レンダリン
グ・スレッド４２２が再び実行して、これらの新しい変
更を表示する。現行の一実施形態では、コンテナへの書
き込み要請は、別の待ち行列内に入れられ、より高レベ
ルのコード２０２を実行しているスレッドに戻る。しか
し、このことは、レンダラが実行している同じスレッド
上の、より高レベルのコード２０２への同期コールを含
む、他の方式で実施することもできる。しかし、このよ
うなコールを同期させることにより、レンダリング・ス
レッドを機能停止することになる。

【００６９】データ構造３００への待ち行列更新に加え
て、データ構造３００からのリード・バック・サービス
を提供する必要がある。このようなサービスには、ヒッ
ト−テスト、ポイント変換およびサブグラフ・サイジン
グが含まれる。

【００７０】ヒット−テストとは、それによって、ポイ
ントが、データ構造のいくつかのルートの座標空間に与
えられ、データ構造がプローブされて、そのポイントに
よってヒットされるコンテナまたは基本要素が戻される
ようにするプロセスである。現行実施形態では、ヒット
−テスト・プロセスは、それぞれのコンテナ内に格納さ
れた３つのフラグの値によって制御される（追加フラグ
も可能であるが）。第１のフラグには、ヒット−テスト
・アルゴリズムに命令を出して、これまでに収集したヒ
ット・テストの結果を戻す設定が含まれる。第２のフラ
グには、ヒット−テスト・アルゴリズムに対して、ヒッ
トされているそのポイントがそのコンテナに確かに存在
する場合は、結果リスト内にそのコンテナを含むよう伝
えることが含まれる。第３のフラグは、そのコンテナの
子をヒット−テストすべきかどうかを制御する。

【００７１】別の読出しサービスはポイント変換であ
り、ここで、グラフを介して接続する２つのノードがあ
る場合、あるコンテナの座標フレーム内のポイントが、
別のコンテナの座標フレームに変換できるサービスがあ
る。先祖から子孫、子孫から先祖、ピア・ツー・ピア
（任意のノードから別の任意のノード）の変換を含む、
３つの一般的なサブタイプがある。したがって、読出し
サービスは、座標変換のためデータ構造を問い合わせる
方法を提供し、ツリー・アーキテクチャが変換を歩き回
り計算することを促進させる。多くの変換を実施中は、
アニメーション／変更をロックできる。そして、共通の
先祖を介する変換の実行を提供することができる。

【００７２】別の読出しサービスは、サブグラフ・サイ
ジングである。ノードが与えられると、このサービス
は、そのノードとそのサブグラフのグラフィカル・サイ
ズを戻す。このサイズは、サブグラフを入れるのに十分
な大きさがあるという保証されたサイズであるか、また
はサブグラフを入れるのにちょうどの大きさの別のサイ
ズの形状である場合もあり、またはサブグラフの輪郭を
詳細に表す複雑な形状でもあろう。

【００７３】ある実施形態では、これらの読出しオペレ
ーションをデータ構造への変更に同期させたい場合があ
る。このため、これらの読出しオペレーションのいずれ
かを呼び出す前に、変更待ち行列が適用されると、より
一貫性のあるビューが、より高レベルのコードに与えら
れる。

【００７４】低レベル・コンポジッタおよびアニメータ
（THE LOW-LEVEL COMPOSITOR AND ANIMATOR） 低レベル・アニメータおよび合成エンジン２１０の主な
目的は、メディア統合層２００の低レベル・レンダリン
グ・スタックの抽象化を提供することであり、これによ
って、（１）クライアント・グラフィックス・アプリケ
ーションのための高フレーム速度アニメーション、
（２）ウィンドウ管理的なサポートの実施、（３）ネッ
トワーク接続を介したグラフィックス・サービスの遠隔
操作（remoting）へのサポート、を可能にする。図６お
よび７に示すように、低レベル・アニメータおよび合成
エンジン２１０は、レンダラ６０２の集合によって提供
されるサービスを使用することにより、特に、多数のク
ライアントから受取る高フレーム・レート・アニメーシ
ョン要求を調整するためサーバとして機能する（たとえ
ば、それぞれ高レベル・コンポジッタを有する多くのア
プリケーションに対応する）。レンダラ６０２は、グラ
フィックス合成エンジン６０６によって実施されるレン
ダリング抽象化（ビジュアルとも呼ぶ）上で働くレンダ
リング・アクションを生成する。

【００７５】低レベル・アニメータおよび合成エンジン
２１０はまた、特別のクライアント（トップ・レベルの
ビジュアル・マネージャ６０４）が、スクリーン上のレ
ンダリング・エリアとして、クライアント・アプリケー
ションによって使用されるビジュアルを操作できるよう
にすることが目的のインフラストラクチャを備えて、ト
ップ・レベルのビジュアル管理サポートを提供する。レ
ンダリング・スタックへレンダリングするクライアント
・アプリケーション２０２_１−２０２_３（図７では３つ
しか示していないが、いずれの数でもあり得る）のそれ
ぞれが、トップ・レベルのビジュアル（それぞれ、ＴＬ
Ｖ_１−ＴＬＶ_３）を所有し、トップ・レベルのビジュア
ル・マネージャ６０４は、スクリーン上にトップ・レベ
ルのビジュアルのレイアウト上にオーソリティを有する
クライアントである。一般的に言って、低レベル・アニ
メータおよび合成エンジン２１０は、デスクトップ上に
渡されるさまざまなクライアントによって放出されたコ
マンド・ストリームを結合して、グラフィックス合成エ
ンジン６０６によって消費されるグラフィックス・コマ
ンドにすることによって、デスクトップを合成する。低
レベル・アニメータおよび合成エンジン２１０はまた、
ローカル・マシンと同様のリモート・マシン６１０_１−
６１０_ｎのためのユーザ・インターフェースをプログラ
ミングするレンダリング・アーキテクチャを実施するた
めに使用する構成要素を援助（help）する。

【００７６】図７は、低レベル・アニメータおよび合成
エンジン（サーバ）２１０とそのクライアントの間の相
互作用を示す図である。上述したように、トップ・レベ
ルのビジュアル・マネージャ６０４もクライアントであ
る。またこれも上述したように、低レベル・アニメータ
および合成エンジン２１０のクライアント２０２_１−２
０２_３は、高レベル・コンポジッタおよびアニメーショ
ン・エンジン２０６のインスタンスを使用して、グラフ
ィックス構造を構築し、これらを、ビューされるデスク
トップを合成するために低レベル・アニメータおよび合
成エンジン２１０が使用する、グラフィックス・コマン
ドのストリームに変換する。一実施形態では、ローカル
またはリモート・マシンのいずれかで実行するクライア
ント（たとえば、高レベル・コンポジッタ）によって出
されるコマンド・ストリームを取り扱う、ただ１つの低
レベル・アニメータおよび合成エンジン２１０がある。

【００７７】図６に戻ると、プロセス間通信が、低レベ
ル・アニメータおよび合成エンジン（サーバ）２１０に
よって維持されるプロパティ・システム６１４を介して
実行される。それぞれのトップ・レベル・ビジュアルに
関連付けられるプロパティが、このプロパティ・システ
ム６１４によって格納される。クライアントは、これら
のプロパティを書き込み読出しすることができ、またク
ライアントは、プロパティ値の変更要請があれば、その
通知を受けることができる。

【００７８】低レベル・アニメータおよび合成エンジン
２１０は、クライアント−サーバ通信、高速アニメーシ
ョン・レンダリング、およびトップ・レベル・ビジュア
ル管理サポートを提供する。一実施形態では、低レベル
・アニメータおよび合成エンジン２１０とクライアント
の間の通信が、単一の双方向バイト・ストリームおよび
／または共有メモリを介して起きる。バイト・ストリー
ムについては、ローカル・クライアントはプロセス間通
信を使用し、リモート・クライアントはネットワーク・
バイト・ストリーム接続を開ける。バイト・ストリーム
は、クライアント・サーバ相互作用を制御する通信プロ
トコルのトランスポート層である。

【００７９】通信プロトコルには、３つの主要メッセー
ジ、つまり、要請（request）、回答（reply）およびイ
ベント・メッセージが含まれる。エラー・メッセージ
も、提供される。クライアントからサーバへの通信は、
主にレンダリング命令を含み、サーバからクライアント
への通信は、主に、以下に記述する、応答およびエラー
・メッセージの形のフィードバックである。

【００８０】クライアントからサーバに要請が生成さ
れ、そしてその要請は、トップ・レベル・ビジュアル管
理コマンド、レンダリング命令コマンド、およびタイミ
ング間隔コマンドを含むことができる。回答は、要請に
応じてサーバからクライアントに送信される。しかし、
すべての要請が回答を受けるわけではないことに留意さ
れたい。回答は、情報を探す適切な要請に応じてのみ生
成される。たとえば、描画命令は、回答を必要としな
い。しかし、「Ｇｅｔ Ｗｉｎｄｏｗ ｓｉｚｅ」要請
は、回答を必要とし、回答を受取る。

【００８１】イベントが、サーバからクライアントに送
られ、そしてそのイベントは、装置のアクションまたは
前の要請の副作用に関する情報を含む。たとえば、サー
バは、リソースを無効にするため、またクライアントに
目標フレーム速度を伝えるために、イベント・メッセー
ジをクライアントに通信することができる。目標フレー
ム速度を通信する機能により、可変フレーム速度が可能
となる。これは、高いフレーム速度というよりも、一貫
性のあるフレーム速度を確実にするために望ましいこと
である。

【００８２】エラーもまた、クライアントに送られる。
エラーはイベントと同様であるが、一般に、たとえば、
エラーを補償するために、クライアントによって異なる
取り扱いを受ける。

【００８３】クライアントが、低レベル・アニメータお
よび合成エンジン２１０によって供給されるサービスを
使用することができる前に、クライアントは、まず最初
に、接続マネージャ７１０によって提供されるエントリ
・ポイントを介してエンジン２１０に接続する（図
７）。接続マネージャ７１０は、クライアント・サーバ
・プロトコルの双方向バイト・ストリーム・トランスポ
ート層をカプセル化する通信オブジェクト（たとえば、
７１２_１）を割り当てる。これはまた、命令ストリーム
を介して到来するレンダリング命令の追跡をし、それら
を正しいビジュアルに関連付ける命令リスト・マネージ
ャ（たとえば、７１４_１）も割り当てる。

【００８４】いったん接続が確立されると、クライアン
ト２０２は、トップ・レベル・ビジュアルの作成を要請
する。その要請に応答して、低レベル・アニメータおよ
び合成エンジン２１０は、グラフィックス合成エンジン
６０６によって提供されるサービスを使用することによ
り、トップ・レベル・ビジュアル（たとえば、ＴＬ
Ｖ _１）を作成する。そのクライアントのために低レベル
・アニメータおよび合成エンジン２１０によって維持さ
れるビジュアルは、ツリー構造７１８内で編成される。
クライアントが、トップ・レベル・ビジュアルとともに
なされる場合は、クライアントはその破壊を要請する。
ルート・ノード７２０は、デスクトップのバック・グラ
ウンドを表す特別なビジュアルであり、ルート・ビジュ
アルの子はトップ・レベル・ビジュアルであることに留
意されたい。

【００８５】図７に示すように、低レベル・アニメータ
および合成エンジン２１０の１つの重要な役割は、コン
ピュータ・デスクトップへのレンダリングを管理するこ
とであり、これは、別の２つの構成要素、つまり、グラ
フィックス合成エンジン６０６とレンダラ６０２の集合
のサービスに頼ることによって達成される。グラフィッ
クス合成エンジン６０６は、低レベル合成サービスを、
ビジュアルと呼ぶレンダリング抽象化を介して提供す
る。ビジュアルは、デスクトップに構成される長方形の
レンダリング・エリアであり、グラフィックス合成エン
ジン６０６によって供給される１組のＡＰＩを介してレ
ンダリングされることができる。デスクトップを合成す
る時間になると、レンダリング・パス・マネージャ７２
２は、ツリーを左から右へトラバースして、それぞれの
ノードに対して、レンダリング構成要素を使用してビジ
ュアルにレンダリングする。

【００８６】トップ・レベル・ビジュアルの生存期間管
理に加えて、低レベル・アニメータおよび合成エンジン
２１０はまた、トップ・レベル・ビジュアル装飾をサポ
ートし、実質的にはデコレーションをトップ・レベル・
ビジュアルの回りに追加する。装飾７３０_１−７３０_３
は、レンダリング命令リストの形のトップ・レベル・ビ
ジュアル・マネージャによって供給されるデコレーショ
ンをレンダリングするビジュアルである。これらのビジ
ュアルは、それらの属するトップ・レベル・ビジュアル
の子である。クライアント（たとえば、アプリケーショ
ン）は、予め定義されたプロパティをトップ・レベル・
ビジュアル上に設定することにより、トップ・レベル・
ビジュアル・マネージャによって提供された装飾を制御
することができる。

【００８７】低レベル・アニメータおよび合成エンジン
２１０はまた、トップ・レベル・ビジュアルのためのサ
ービスを最小限に抑えるサポートもし、これも、トップ
・レベル・ビジュアル・マネージャ６０４によって、レ
ンダリング命令リストの項において供給されることがで
きる。トップ・レベル・ビジュアル位置付け、サイジン
グ、およびＺオーダ（Ｚ−ｏｒｄｅｒ）は、ビジュアル
を閉じる、および最小化するなどの、ビジュアル・マネ
ージャ・アクションに指定される３次元効果とともに、
サポートされる。したがって、この実施形態は、主に２
次元グラフィックスについて記述しているが、このシス
テムは、３次元グラフィックス、ビデオ、音声を含むそ
の他の種類のメディアを格納するためにも容易に使用で
きる。

【００８８】上述したように、トップ・レベル・ビジュ
アル・マネージャが必要とするレンダリング命令リスト
は、高レベル・アニメータおよびコンポジッタ２０６に
よって生成される。低レベル・アニメータおよび合成エ
ンジン２１０は、最小化や閉じるなど、デフォルトの動
きを有する、１組のトップ・レベル・ビジュアル・アク
ションを定義する。トップ・レベル・ビジュアル・マネ
ージャ６０４が、このような動きをカスタマイズしたい
場合は、高レベルＡＰＩを使用して、取り替えたいアク
ションの記述を構築する。次いで、アクションのための
命令ストリームを低レベル・アニメータおよび合成エン
ジン２１０に送る。低レベル・アニメータおよび合成エ
ンジン２１０は、この記述をそのプロパティ・システム
６１４内に格納し、クライアントが特定のアクションを
要請した場合に、それを使用する。

【００８９】トップ・レベル・ビジュアル・デコレーシ
ョンが、プロパティ・システム６１４を使用して実行さ
れる。スタートアップで、トップ・レベル・ビジュアル
・マネージャが、高レベル・エンジン２０６で生成され
た命令リストで、トップ・レベル・ビジュアル・マネー
ジャ・デコレーションを記述する命令リスト、を送る。
これらのデコレーションへの更新は、プロパティ・シス
テム６１４を介してなされる。つまり、クライアントが
デコレーションを更新することを望んだ場合に、クライ
アントは、指定のプロパティを所望の値に設定する。次
いで、低レベル・アニメータおよび合成エンジン２１０
は、トップ・レベル・ビジュアル・マネージャ６０４
に、プロパティが変更されていることを知らせる。それ
に応答して、トップ・レベル・ビジュアル・マネージャ
６０４は、プロパティを読出し、低レベル・アニメータ
および合成エンジン２１０の幾何図形的配列を更新す
る。

【００９０】上述した米国特許出願（例えば、特許文献
２参照）にさらに記述するように、命令リストがパラメ
ータ化される。これは、一般に、グラフィカル・イメー
ジの色の修正などの単純な変更については、トップ・レ
ベル・ビジュアル・マネージャ６０４がかかわる必要が
ないということを意味する。このような場合、クライア
ントは、新しいパラメータ（たとえば、新しい色）を送
り、デコレーションを同じ命令リストで再レンダリング
するが、異なるパラメータを使用する。このことによ
り、それぞれのデコレーションの記述にはただ１つのコ
ピーしか格納しないようにすることができるようにな
る。

【００９１】図８は、クライアント／サーバ通信チャネ
ルを実施する待ち行列８０１−８０４の論理構造を示す
図である。タイミング間隔が、アニメーションしたレン
ダリング命令内に埋め込まれる。レンダリング時間に、
低レベル・アニメータおよび合成エンジン２１０は、現
在時間をタイミング間隔とともに、レンダラにパスす
る。そして、レンダラは、タイミング間隔を使用して、
以下に記述するように、レンダリングのために適切なパ
ラメータを補間する。アニメーションされたレンダリン
グ命令は、高レベル・クライアントから受取った命令コ
マンドに応答して、命令リスト・マネージャ７１４によ
って管理される。命令リスト・マネージャは、それを受
取ったとき、レンダリング命令を待ち行列７１４に入れ
る。レンダリング待ち行列はＺオーダであり、レンダリ
ング・パス・マネージャ７２２は、それらを合成期間に
消費する。

【００９２】時間調節されたレンダリング命令を待ち行
列に入れることに加えて、命令リスト・マネージャ７１
４は、待ち行列８０１−８０４を空にすること、命令を
待ち行列から削除すること、命令を待ち行列に追加する
こと、待ち行列を新しい命令リストに取り替ること、固
定時間オフセットを待ち行列に適用することを含む、そ
の他のオペレーションもサポートする。タイミング制御
レンダリングの特別な例として、レンダリング命令の可
視性を制御する場合がある。このようなイベントでは、
タイミング間隔を使用して、レンダリング待ち行列内の
命令の生存期間を制御することができる。

【００９３】クライアントが、たとえば、ビデオがシー
ン内に存在するような場合などのよな、その中身を適切
にレンダリングするために、ネストされたビジュアルを
必要としている場合もあり得る。ビデオの更新は、独立
したレンダリング・プロセスによって実施されるため、
低レベル・エンジン２１０は、ビデオおよびそれにオー
バーラップする幾何的配列を合成するグラフィックス合
成エンジンに頼る。このことは、グラフィックス合成エ
ンジンの合成パス内にビデオ更新の非同期性を隠す、新
しいビジュアルを作成して、クライアント・アプリケー
ションのトップ・レベル・ビジュアル内に入れることに
よって達成される。ビジュアルの必要性を共有するオー
バーラップしている幾何的配列は、同じ種類のアルファ
の動き（ピクセル毎または透過）を有する。

【００９４】アニメーション（ANIMATION） 一般に、アニメーションは、高レベル・コンポジッタお
よびアニメーション・エンジン２０６と、低レベル・コ
ンポジッタおよびアニメーション・エンジン２１０の両
方によって遂行される。上述したように、メディア統合
層は、ユーザ・インターフェースまたはアプリケーショ
ン・レベルの下の多重グラフィックス処理レベルに分け
られる。高レベル・エンジン２０６は、シーンをトラバ
ースし、最後の補間に対して間隔をとってアニメーショ
ン・パラメータを更新し、これらの単純化したデータ構
造を、より低レベルのエンジン２１０にパスされる命令
内にパッケージ化する。これは、同期、および／または
非同期方式で実施できる。間隔データは、タイミング・
エンド・ポイント（開始および終了タイミング・デー
タ）と、レンダリング命令のためのパラメータ化した値
とを含むものと考えることができる。高レベル・エンジ
ン２０４は、要請された補間のいくつかまたはすべてを
実行することができる。たとえば、補間またはその他の
動作機能が複雑すぎて、より低レベルのエンジン２１０
では対処できない場合、またはより低レベルのエンジン
が処理要求に追いつかない場合は、より高レベルのエン
ジンが、計算のいくつかまたはすべてを実行して、より
低レベルのエンジンに単純化したデータ、命令、埋め尽
くし（tessellations）などを供給し、所望の結果を得
る。より低レベルのエンジンが、アニメーションの各フ
レームのために補間を実行するという典型的な場合で
は、低レベルのエンジン２１０は、パラメータ間隔を補
間して、瞬時値を得、そして命令を、グラフィックス装
置によって実行されるレンダリング・コマンドに復号す
る。グラフィックス装置は、シーンに存在する可能性の
あるビデオ・フレームを追加する最終シーンを合成す
る。ディジタル権管理によるコンテンツ保護など、その
他のデータも追加可能である。

【００９５】高レベル・エンジン２０６と低レベル・エ
ンジン２１０の間の通信は、以下に記述する、命令スト
リームを介して得られる。高レベル・エンジン２０６
は、より遅い速度で、またはオン・デマンドで、レンダ
リング命令をストリームに書き込む。低レベル・エンジ
ン２１０は、命令を備えたストリームを読出し、シーン
をレンダリングする。低レベル・エンジン２１０はま
た、共有メモリからのビットマップなどの、その他のソ
ースからの、シーンをレンダリングするのに必要となる
データ、を得ることができることに留意されたい。

【００９６】したがって、高レベル（たとえば、ティッ
ク・オン・デマンド）エンジン２１０は、アニメーショ
ン・パラメータを更新し、できるだけ頻度を少なくシー
ン・データ構造をトラバースする、と同時に、スムーズ
なアニメーションを維持する。高レベル・エンジン２０
６は、シーン・データ構造をトラバースし、一定時間ア
ニメーションされるパラメータのそれぞれを記述する間
隔を計算し、これらの間隔と単純パラメータ化した描画
命令を、低レベル・エンジン２１０にパスする。パラメ
ータ・データには、開始時間、終了時間、インターポレ
ータ、補間データが含まれる。例として、移動するよう
に見せるためにイメージを削除し再描画する代りに、高
レベル・コンポジッタおよびアニメーション・エンジン
２０６は、低レベル・コンポジッタおよびアニメーショ
ン・エンジン２１０に、時間とともにイメージがどのよ
うに変更していくべきかを、たとえば、開始座標、終了
座標、座標間をイメージが移動すべき時間量（間隔）、
および、たとえば、線形のような動き機能、を命令す
る。低レベル・コンポジッタおよびアニメーション・エ
ンジン２１０は、フレーム間の新しい位置の決定に合わ
せて補間をし、これらを、グラフィックス装置が理解で
きる命令に変換し、そのコマンドをグラフィックス装置
にパスする。

【００９７】高レベル・エンジン２０６のそれぞれのパ
スが、数フレームにわたってスムーズなアニメーション
を実行するために、低レベル・エンジン２１０に十分な
データを供給することが好ましい。最短間隔の、時間上
の長さを使用して、高レベル・エンジン２０６が、スム
ーズなアニメーションを維持するための実行に必要とす
る最小頻度を決定する。完全に静的、または単一の間隔
によって定義できる単純なアニメーションをのみを含む
シーンは、コール・プログラム２０２によってシーンに
変更がなされた場合に、高レベル・エンジン２０６が実
行することだけを要求する。複雑なアニメーションは、
パラメータが予想され、短期間に正確に補間されるが、
ハードウェア・リフレッシュ速度よりはるかに大きい、
より複雑なアニメーションを含むシーンは、高レベル・
エンジン２０６が、０．５秒毎に１回程度の、比較的頻
度の少ない間隔で実行することを要求する。少なくとも
１つのパラメータでは予想できない、非常に複雑なアニ
メーションは、高レベル・エンジン２０６が、より頻繁
に実行することを要求する（極端な場合には、システム
が、ほとんど単一レベル・アニメーション・システムま
で縮退するまで）。

【００９８】高レベル・エンジン２０６が動く頻度は、
均一または固定である必要はない。たとえば、高レベル
・エンジン２０６は、シーン内のアニメーション・パラ
メータによって供給される最小間隔を越えない均一の間
隔で実行するようにスケジューリングされることが可能
である。あるいは、高レベル・エンジン２０６のそれぞ
れの実行上で計算される最小間隔を、次の実行をスケジ
ューリングし、適切なときに新しいデータが低レベル・
エンジン２１０に供給されることを確実にするために、
使用されることも可能である。同様に、シーンおよび／
またはそのアニメーションしたパラメータに構造上の変
更がなされた場合、高レベル・エンジン２０６の頻度
は、新しいシーンが正確にアニメーションされることを
確実にするための実行であるとすることができる。

【００９９】低レベル（たとえば、高速ティック）エン
ジン２１０は、高レベル・エンジン２０６とは別のタス
クである。低レベル・エンジン２１０は、高レベル・エ
ンジン２０６から、シーンを記述する、単純パラメータ
化した描画命令とパラメータ間隔を受取る。低レベル・
エンジンは、高レベル・エンジン２０６によって新しい
ものが供給されるまで、これらのデータ構造を維持しト
ラバースする。低レベル・エンジンは、多数の高レベル
・エンジン２０６をサービスし、それぞれのために別個
のデータ構造を維持する。低レベル・エンジン２１０と
高レベル・エンジン２０６との間の１対多の関係によ
り、システムは、多くのシーンを同時にスムーズにアニ
メーションできるようになる。

【０１００】低レベル・エンジン２１０は、高レベル・
エンジンの供給した間隔に基づき、ある瞬間のアニメー
ション・パラメータに補間し、描画命令を更新し、すべ
てのフレームに対してシーンをレンダリングする。低レ
ベル・エンジン２１０タスクは、そのフレームが、グラ
フィックス・ハードウェア・スクリーン・リフレッシュ
速度でプレゼンテーションする準備を確実にするため
に、システム上を高い優先度で実行する。したがって、
低レベル・エンジン２１０によって実行される補間は、
一般に、線形、区分線形、３次スプライン、およびこれ
らの同様の速度など、単純で高速の関数に限られる。低
レベル・エンジン２１０は、ハードウェア・リフレッシ
ュ速度の整数除数（integral divisor）である、正規周
波数またはフレーム速度で実行する。低レベル・エンジ
ン２１０によってレンダリングされたそれぞれのフレー
ムは、矛盾しない数を維持して表示されるか、またはグ
ラフィックス・ハードウェアによってリフレッシュされ
る。

【０１０１】高レベル、低レベル通信（HIGH-LEVEL,LOW
-LEVEL COMMUNICATION） 高レベル・コンポジッタおよびアニメーション・エンジ
ン２０６と、低レベル・コンポジッタおよびアニメーシ
ョン・エンジン２１０との間の相互作用についての説明
に移ると、その機器構成は、プロセス間（in-process）
を含むいろいろな機器構成が実現可能であり、低レベル
・エンジン２１０はただ１つの高レベル・エンジン２０
６に対してだけ働き、そして両方が同じプロセス内に存
在する機器構成が実現可能である。低レベル・エンジン
２１０がただ１つの高レベル・エンジン２０６に対して
だけ働くことについては同じであるが、高レベル・エン
ジン２０６および低レベル・エンジン２１０が独立した
プロセス内にある、クロス−プロセス（cross-proces
s）機器構成も利用可能である。

【０１０２】デスクトップ機器構成は、クロス−プロセ
ス機器構成の拡張であり、ここでは、低レベル・エンジ
ン２１０が高レベル・エンジンの多くのインスタンスに
サービスし、デスクトップ全体のレンダリングを制御す
る。高レベル・エンジン２０６がサーバ・マシン上にあ
り、低レベル・エンジン２１０がクライアント・マシン
上にある場合、リモート機器構成も使用可能である。リ
モートの場合は、高レベル・エンジン２０６と低レベル
・エンジン２１０との関係が１対１であるか、または低
レベル・エンジン２１０が多くのローカルおよびリモー
トの高レベル・エンジンに対して働くかのいずれかの場
合とすることができる。リモート機器構成は、クロス・
プロセスおよびデスクトップ機器構成と非常に似ている
と考えることができるが、高レベル・エンジン２０６と
低レベル・エンジン２１０を異なるマシン上に備えた機
器構成である。

【０１０３】本発明によれば、高レベル・エンジン２０
６のデータは、低レベル・エンジン２１０への伝送用に
準備され、低レベル・エンジン２１０は、データを受取
るとすぐに処理する。データ・フォーマット上の詳細に
ついて、そしてデータがどのように高レベル・エンジン
２０６内で作成され、低レベル・エンジン２１０による
レンダリングのために使用されるかとともに、以下にそ
の概要を記述する。

【０１０４】高レベル・エンジン２０６、低レベル・エ
ンジン２１０、グラフィックス装置間の概念的な相互作
用およびデータの流れを、図９−１２に示してあり、図
１３、１４、１５は、通信に使用されるデータ構造のさ
まざまな例を示す図である。一般に、高レベルエンジン
・レンダリング・トラバーサル（traversal；走査、横
断）（たとえば、ループ）９０２は、シーン・キャッシ
ュ・ツリー９００をトラバースし、サブステップを何回
も繰り返すことを通じて、データ構造９０４（図１１の
ビジュアル更新ブロック１１１４を含む）を作成する。
これには、シーン・キャッシュ内で使用するリソースを
作成することと、ディスプレイ・ツリー内で使用するた
めの宣言アニメーションを作成することが含まれる。ア
ニメータ・オブジェクトは、可変の値に対して作成さ
れ、これによって、アニメータが、コンスタントの代り
にメディア統合層描画ＡＰＩ内で使用される。次いで、
高レベル・エンジン２０６ディスプレイ・データ構造９
０４が作成され、前に作成されていたリソースおよびア
ニメータを参照する。ディスプレイ・データも、その他
のサブツリーを参照する。活動化するために、アニメー
タ（たとえば、図１１の１１０４）をタイミング・ツリ
ー／ノード構造（たとえば図１１の１１０２）に接続す
る。一般に、アプリケーションが、時間ノード１１０２
を作成して、それぞれのアニメータ１１０４の開始、停
止、進捗を制御する。

【０１０５】タイミングおよびアニメーションを含み、
いったんモデルが作成されると、高レベル・エンジンの
トラバーサル・ループ９０２が、ディスプレイ・ツリー
９００をトラバースして描画を開始する。上述したよう
に、高レベル・エンジン２０６トラバーサルの頻度は、
タイミングおよびアニメーションの量と複雑さに依存す
る。たとえば、静的シーンは、アプリケーションが変更
したときにだけ、トラバースされる必要がある。

【０１０６】高レベル・トラバーサル・プロセス９０２
は、多くのパス内で起きる。事前計算パスでは、ツリー
９００の第１のトラバーサルは、描画に必要な計算を実
行する。たとえば、バウンディング・ボックスは、それ
ぞれのサブツリーに対して計算され、アニメーション値
を更新する。上述したように、単一の瞬時値ではなく、
アニメータ１１０４が、間隔を供給する。間隔には、開
始および終了時間、どの種類のインターポレータを使用
するのか、補間用データ、が含まれる。次いで、ディス
プレイ・ツリーによって使用されるリソースが、具現化
のために低レベル・エンジン２１０に送られる。

【０１０７】第２のトラバーサルが、レンダリングのた
めに低レベル・エンジン２１０に送られるシーンを記述
する情報をパッケージ化する。このため、グラフ内のそ
れぞれのサブツリーが、図１３−１５に示すデータ構造
および情報内で表されているように、１つまたは複数の
命令ブロックによって表される。高レベル・エンジン２
０６は、命令ブロック（たとえば、図１５の１５００）
を、それぞれのトップ・レベル・ビジュアル（たとえ
ば、ウィンドウ）に対する単一のビジュアル更新ブロッ
ク１１１４に蓄積する。前回のトラバーサルから変更さ
れていない命令ブロック・サブツリーは、付加されな
い。宣言アニメーション変更だけを含むサブツリーのた
めの命令ブロックには、補間情報の変数ブロックだけが
含まれる。変換とともに再位置付けされているサブツリ
ーに対する命令ブロックは、ヘッダのみを含む。

【０１０８】低レベル・エンジン２１０レンダリング・
スレッド（またはプロセス）は、ループ１２０８（図１
２）内で実行し、高フレーム速度で、理想的にはディス
プレイのリフレッシュ速度で、ビジュアルをレンダリン
グし合成する。ループ１２０８は、高レベル・エンジン
２０６から受取ったビジュアル更新ブロック（たとえ
ば、１１１４_１−１１１４_３）の適用を含み、いくつか
のステップを実行する。このパス上で描画されているリ
ソースおよびウィンドウに対して補間される値が、更新
される。命令ブロックの変数リスト内のそれぞれの変数
については、次のフレームのための瞬時値が計算され
る。次いで、ループ１２０８は、それが使用されている
命令リスト内の場所にオフセットを介して、新しい値へ
メモリ・コピーすることを、反復適用する。

【０１０９】リソースは、最初に使用されたときにレン
ダリングされるけれども、更新されたオフ・スクリーン
・リソースはレンダリングされる。それぞれのトップ・
レベル・ビジュアルについての命令リストは、レンダリ
ングされ、ディスプレイ上へのデータ「ｂｌｔ−ｅｄ」
は、フリップされ、あるいは、それぞれのトップ・レベ
ル・ビジュアルがスクリーン上で更新されるように配置
される。

【０１１０】リモート移送（REMOTE TRANSPORT） 上述したように、高レベル・エンジン２０６は、リソー
ス１２０４_１−１２０４_３（図１２）を含む、低レベル
・エンジン２１０に移送されるデータの関連セットを作
成する。たとえば、レンダリングに使用される変数が短
時間の間にどのように変化するのかを、それがどこで使
用されるかのついての情報と一緒に記述する、イメージ
およびテキスト・グリフ、アニメーション間隔／変数、
およびトップ・レベル・ビジュアル（ウィンドウ）をレ
ンダリングするのに必要な、位置付けレンダリング・オ
ペレーションを記述する命令リスト、などである。命令
リストは、静的値の代りに変数への参照を含むことがで
きる。

【０１１１】まず最初に、高レベル・エンジン２０６
は、使用する前に作成する必要のあるリソースを作成
し、命令リスト内の隠されたハンドルによって参照され
る。高レベル・エンジン２０６は、最初に、リソースの
装置独立型表示を作成することによってリソースを作成
する。イメージの場合は、表示は、フル・フレームのビ
ットマップか、またはＪＰＥＧなどのフォーマットの符
号化されたイメージである。通信については、次いで、
高レベル・エンジン２０６は、リソース・データを、そ
れを特有のハンドルに指定する通信スタブに提出する。
ハンドルは、高レベル・エンジン２０６プロセス内で生
成され、そのプロセス内でのみ特有である。

【０１１２】図１６に示すように、通信スタブは、デー
タ構造１６００内に、オペレーションとハンドルの種類
を特定するヘッダを付けて、リソース・データをパッケ
ージ化する。スタブは、ただちにハンドルをレンダリン
グに使用する高レベル・エンジン２０６に戻す。

【０１１３】命令リスト、変数、時間値およびアニメー
ション間隔は、一緒に作られる。命令リストは、レンダ
リングを記述し、静的値の代りに変数への参照を含むこ
とができる。アニメーション間隔は、短時間の間に、ど
のように変数の値が変わるかを記述する。

【０１１４】高レベル・エンジン２０６は、そのレンダ
リング・パスの一部として、命令リストおよびアニメー
ション間隔を収集する。高レベル・エンジン２０６は、
レンダリング情報を、トップ・レベル・ビジュアル（ウ
ィンドウ）毎に１つまたは複数の命令ブロックにパッケ
ージ化する。それぞれのブロックは、特定のウィンドウ
のためのグラフのサブツリーを表す。それぞれのブロッ
クは、命令リストに影響を与える変数のリストを含む。
高レベル・エンジン２０６内に維持される命令リスト
は、使用される変数への参照を含む。これらの変数参照
は、それぞれの変数に対して収集され、レンダリングの
前に変数の瞬時値によって交換されるべき命令リスト内
の場所（オフセット）に変換される。これらのオフセッ
トは、図１６−２２に概要を示すように、そのブロック
のためのアニメーション間隔情報とともにパッケージ化
される。

【０１１５】図１５は、ビジュアル更新データ構造を示
す図である。一般に、ウィンドウを記述する命令ブロッ
クの集合が、上述したように、ビジュアル更新ブロック
１１１４内に収集される。次いで、更新ブロックは、上
述したリソースと同様の方式でパケット内にパッケージ
化される。更新ブロックは、大きいものである場合があ
り、移送のためにより効率的な場合は、多くのパケット
で送ることができる。

【０１１６】低レベル・エンジン２１０は、移送ストリ
ームを聞き（listen）、パケットが到着するとそれを処
理する、通常優先スレッドを有する。好ましくは、レン
ダリング・スレッドとは別のスレッドでその作業を行
い、低レベル・エンジン２１０がすべてのリフレッシュ
をレンダリングできることを確実にする。通信スレッド
は、オペレーション・コード（ｏｐｃｏｄｅ）、高レベ
ル・エンジン識別子（ＩＤ）、オブジェクト・ハンドル
に基づき、それぞれのパケットをパーズ（構文解析）す
る。これらのリソースおよびビジュアル更新シナリオの
処理は、図２３を参照しながら記述する。

【０１１７】より詳細には、受取ったパケットはリソー
ス１２０４（ステップ２３００）のためのものであると
低レベル・エンジン２１０が認識したとき、リソース・
パケットが処理される。次いで、低レベル・エンジン２
１０は、ステップ２３０２で、高レベル・エンジン２０
６ＩＤとリソース・ハンドルを抽出し、ステップ２３０
４で、要求されている種類のリソースを作成する。低レ
ベル・エンジン２１０は、ステップ２３０６で、リソー
スの装置独立型フォームに書き込み、リソースを、指定
された高レベル・エンジン２０６（ステップ２３０８）
のためのハンドル・テーブルに入れる。

【０１１８】単一のパケット・ビジュアル更新ブロック
は、リソース・パケットと同様に取り扱われるが、処理
量が多くなる。ステップ２３００で、低レベル・エンジ
ン２１０が、パケットがビジュアル更新ブロック１１１
４であると認識した場合、そのプロセスは、ステップ２
３１２に分岐する。ステップ２３１２で、低レベル・エ
ンジン２１０は、パケットから高レベル・エンジンＩＤ
とビジュアル・ハンドルを抽出する。次いで、低レベル
・エンジン２１０は、ステップ２３１４で、指定された
高レベル・エンジン２０６のためのハンドル・テーブル
内のビジュアルをルックアップする。ビジュアルが見つ
けられない場合は、ステップ２３１６で、新しいビジュ
アル・オブジェクトが作成され、ハンドル・テーブルに
追加される。次いで、低レベル・エンジン２１０は、ス
テップ２４００および２４１６を介して、図２４に示す
ように、パケット内の命令ブロックのそれぞれを通って
ループする。

【０１１９】このため、ステップ２４００で、低レベル
・エンジン２１０は、命令ブロックを選択し、ステップ
２４０２で、現行ビジュアル内のブロックＩＤをルック
アップする。ブロック識別子が存在しない場合は、新し
いブロックが作成され、パケットからのデータで初期設
定される。反対に、ブロック識別子が存在する場合は、
低レベル・エンジン２１０は、変換とオフセットを更新
する（ステップ２４０６）。ブロックが、変数リストを
含む場合は、既存変数リストが、ステップ２４０８およ
び２４１０を介して置き換えられる。ブロックが命令リ
ストを含む場合は、既存命令リストは、ステップ２４１
２および２４１４を介して置き換えられる。

【０１２０】多数のパケットの場合も、単一のパケット
の場合と同様に対処される。唯一の相違点は、低レベル
・エンジン２１０が、最初に、ビジュアル更新ブロック
を多数のパケットから集めることである。

【０１２１】容易に理解されるように、個々のグラフィ
ックス・ビットではなく、グラフィックス命令が送られ
るため、高レベル・エンジンと低レベル・エンジンの間
で通信する必要のあるデータの量が、著しく減少する。
その結果、高レベル処理システムからのグラフィックス
命令が、ネットワーク接続を介して、それぞれが低レベ
ル処理システムを備える、リモート端末へ送信すること
ができる。その結果生じるグラフィックス出力は、たと
えその接続の帯域幅では、従来のグラフィックス・デー
タを運ぶことができない場合でさえも、いくつかの端末
上に実質的に同じように現れることができる。

【０１２２】結論 上述した詳細な説明からお分かりのように、比較的低い
頻度で複雑な処理を容易にすることにより、比較的高い
頻度で複雑なグラフィックス出力を可能にする多重レベ
ル・グラフィックス処理システムおよび方法が提供され
る。本システムおよび方法では、大量のグラフィックス
・サブシステム・パワーを高めるための多重処理レベル
を使用することにより、スムーズなアニメーション、グ
ラフィックス合成、ビデオおよび音声との組み合わせを
含む、改良型グラフィックス出力が可能となる。さら
に、多重レベルにより、グラフィックス命令とデータの
端末への、複雑なグラフィックス出力をもたらすリモー
ト通信が容易になる。

【０１２３】本発明は、さまざまな修正形態および代替
構成が可能であるが、特定の実施形態を、図面に例示
し、また上記の詳細な説明に記述してある。しかし、本
発明は、開示されている特定の形態に限定されるもので
はなく、その反対に、あらゆる修正形態、代替構成、お
よび本発明の趣旨および範囲内の均等物を包含するもの
であることが理解されるべきである。

【図面の簡単な説明】

【図１】その中に本発明を組み込むことのできるコンピ
ュータ・システムの例を示すブロック図である。

【図２】本発明の一態様に従ったメディア統合層アーキ
テクチャを示すブロック図である。

【図３】本発明の一態様に従った、インテリジェント・
キャッシング・データ構造およびそのさまざまな構成要
素に対する関係を示すブロック図である。

【図４】本発明の一態様に従った、高レベル合成および
アニメーション・エンジンとその他のレベルの間の、一
般的な制御の流れを示すブロック図である。

【図５】本発明の一態様に従った、単純なデータ構造内
にキャッシュされたコンテナおよびその他のノードと、
それらの関係の例を示すブロック図である。

【図６】本発明の一態様に従った、他の構成要素と相互
作用する低レベル合成およびアニメーション・エンジン
の一般的な構成要素を示すブロック図である。

【図７】本発明の一態様に従った、低レベル合成および
アニメーション・エンジンの一般的な構成要素を示すブ
ロック図である。

【図８】本発明の一態様に従った、低レベル合成および
アニメーション・エンジンとの接続の論理構造を示すブ
ロック図である。

【図９】本発明の一態様に従った、高レベル合成および
アニメーション・エンジンから低レベル合成およびアニ
メーション・エンジンへの情報の流れを示すブロック図
である。

【図１０】本発明の一態様に従った、高レベル合成およ
びアニメーション・エンジンから低レベル合成およびア
ニメーション・エンジンへの情報の流れを示すブロック
図である。

【図１１】本発明の一態様に従った、メディア統合層ア
ーキテクチャ層を介するグラフィックス・サブシステム
への情報の流れを示すブロック図である。

【図１２】本発明の一態様に従った、メディア統合層ア
ーキテクチャ層を介するグラフィックス・サブシステム
への情報の流れを示すブロック図である。

【図１３】本発明の一態様に従って、データ構造を備
え、高レベル合成およびアニメーション・エンジンから
低レベル合成およびアニメーション・エンジンへ情報を
通信するために使用されるその他の情報を示す図であ
る。

【図１４】本発明の一態様に従って、データ構造を備
え、高レベル合成およびアニメーション・エンジンから
低レベル合成およびアニメーション・エンジンへ情報を
通信するために使用されるその他の情報を示す図であ
る。

【図１５】本発明の一態様に従って、データ構造を備
え、高レベル合成およびアニメーション・エンジンから
低レベル合成およびアニメーション・エンジンへ情報を
通信するために使用されるその他の情報を示す図であ
る。

【図１６】本発明の一態様に従って、データ構造を備
え、高レベル合成およびアニメーション・エンジンから
低レベル合成およびアニメーション・エンジンへ情報を
通信するために使用されるその他の情報を示す図であ
る。

【図１７】本発明の一態様に従って、データ構造を備
え、高レベル合成およびアニメーション・エンジンから
低レベル合成およびアニメーション・エンジンへ情報を
通信するために使用されるその他の情報を示す図であ
る。

【図１８】本発明の一態様に従って、データ構造を備
え、高レベル合成およびアニメーション・エンジンから
低レベル合成およびアニメーション・エンジンへ情報を
通信するために使用されるその他の情報を示す図であ
る。

【図１９】本発明の一態様に従って、データ構造を備
え、高レベル合成およびアニメーション・エンジンから
低レベル合成およびアニメーション・エンジンへ情報を
通信するために使用されるその他の情報を示す図であ
る。

【図２０】本発明の一態様に従って、データ構造を備
え、高レベル合成およびアニメーション・エンジンから
低レベル合成およびアニメーション・エンジンへ情報を
通信するために使用されるその他の情報を示す図であ
る。

【図２１】本発明の一態様に従って、データ構造を備
え、高レベル合成およびアニメーション・エンジンから
低レベル合成およびアニメーション・エンジンへ情報を
通信するために使用されるその他の情報を示す図であ
る。

【図２２】本発明の一態様に従って、データ構造を備
え、高レベル合成およびアニメーション・エンジンから
低レベル合成およびアニメーション・エンジンへ情報を
通信するために使用されるその他の情報を示す図であ
る。

【図２３】本発明の一態様に従って、パケットを処理す
る論理を一般的に記述したフローチャートである。

【図２４】本発明の一態様に従って、パケットを処理す
る論理を一般的に記述したフローチャートである。

【符号の説明】

１００ コンピューティング環境、オペレーティング
環境 １１０ コンピュータ １２０ プロセッシング・ユニット １２１ システム・バス １３０ システム・メモリ １３１ リード・オンリー・メモリ（ＲＯＭ） １３２ ランダム・アクセス・メモリ（ＲＡＭ） １３３ 基本入出力システム（ＢＩＯＳ） １３４、１４４ オペレーティング・システム １３５、１４５、１８５、２０２ アプリケーション
・プログラム １３６、１４６ プログラム・モジュール １３７、１４７ プログラム・データ １４０、１５０、１６０ インターフェース １４１ ハード・ディスク・ドライブ １５１ 磁気ディスク・ドライブ １５２ 磁気ディスク １５５、１５６ 光学ディスク １６１ ポインティング・デバイス １６２ キーボード １６３ マイクロホン １６４ タブレット １７０ アダプタ １７１ ローカル・エリア・ネットワーク（ＬＡＮ） １７２ モデム １７３ ワイド・エリア・ネットワーク（ＷＡＮ） １８０ リモート・コンピュータ １８１ メモリ記憶装置 １９０ ビデオ・インターフェース １９１ モニタ １９２ タッチ・スクリーン・インターフェース １９３ タッチ・スクリーン・パネル １９４ 周辺インターフェース １９５ スピーカ ２００ メディア統合層アーキテクチャ ２０２ コード、クライアント、アプリケーション ２０４ アプリケーション・プログラミング・インタ
ーフェース（ＡＰＩ） ２０６ 高レベル合成およびアニメーション・エンジ
ン ２０８ タイミングおよび合成アニメーション構成要
素 ２１０ 低レベル合成およびアニメーション・エンジ
ン ２１２ グラフィックス・サブシステム、グラフィッ
クス・ソフトウェアおよびハードウェア ２２０ プリンティング・コード １９６、２２２ プリンタ ２２６ 端末トランスポート・サーバ ２２８、６１０ リモート・マシン ３００、７１８、９０４、１１０２ 構造 ３０２ 抽象装置 ４０６ 変換 ４１０、４１２ 基本ノード ４１６ 描画コンテキスト ４１８ 変換待ち行列 ４２０ ディスプレイ・マネージャ ４２２ レンダリング・スレッド ５００、５０２ セグメント ４０２、４０４、４０８、５１０、５１２、５１８
コンテナ ５１６ 基本要素 ６０４ ビジュアル・マネージャ ６０６ グラフィックス合成エンジン ６１４ プロパティ・システム ７１０ 接続マネージャ ７１４ 命令リスト・マネージャ ７２０ ルート・ノード ７２２ レンダリング・パス・マネージャ ７３０ 装飾 ８０１、８０２、８０３、８０４ 待ち行列 ９００ シーン・キャッシュ・ツリー、ディスプレイ
・ツリー ９０２ トラバーサル １１０４ アニメータ １１１４ ビジュアル更新ブロック １２０４ リソース １２０８ ループ １５００ 命令ブロック

フロントページの続き (72)発明者 ジョーゼフ エス．ベーダ アメリカ合衆国 98103 ワシントン州 シアトル デンスモア アベニュー ノー ス 3819 (72)発明者 グレゴリー ディー．スウェッドバーグ アメリカ合衆国 98006 ワシントン州 ベルビュー 160 コート サウスイース ト 4952 (72)発明者 オレステ ドーリン ウングレアヌ アメリカ合衆国 98019 ワシントン州 ダーバル 279 レーン ノースイースト 15122 (72)発明者 ケビン ティー．ギャロ アメリカ合衆国 98072 ワシントン州 ウッディンビル 222 ウェイ ノースイ ースト 19235 (72)発明者 ポール シー．デビッド アメリカ合衆国 98033 ワシントン州 カークランド ノースイースト 103 プ レイス 11516 (72)発明者 マシュー ダブリュ．カルキンス アメリカ合衆国 98102 ワシントン州 シアトル イースト トーマス ストリー ト 503 ナンバー204 Ｆターム(参考） 5B050 AA08 BA08 BA11 EA24

Claims (59)

【特許請求の範囲】
1. 【請求項１】 コンピューティング環境において、 グラフィックスを含むディスプレイ情報のフレームを出
   力するグラフィックス・サブシステムと、 前記ディスプレイ情報のフレームを出力する前記グラフ
   ィックス・サブシステムに、グラフィックス・データを
   第１の速度で提供する第１の構成要素と、 プログラム・コードとインターフェースをとって、前記
   プログラム・コードに対応するシーン・データを生成す
   る第２の構成要素であって、前記第１の速度より遅い第
   ２の速度で前記シーン・データをグラフィックス情報に
   処理（process）して、前記グラフィックス情報を前記
   第１の構成要素に供給するように構成された第２の構成
   要素とを備えることを特徴とするシステム。
2. 【請求項２】 前記グラフィックス情報は、前記第１の
   構成要素によって解釈されるフォーマットのイメージ・
   データを備えることを特徴とする請求項１に記載のシス
   テム。
3. 【請求項３】 前記グラフィックス情報は、命令を備え
   ることを特徴とする請求項１に記載のシステム。
4. 【請求項４】 前記命令は、少なくとも１つの補間コマ
   ンドを含み、前記第１の構成要素は、時間経過に対応し
   て前記グラフィックス・データ内のイメージを補間する
   ことにより、前記グラフィックス・サブシステムに提供
   される前記グラフィックス・データを変更する補間メカ
   ニズムを含むことを特徴とする請求項３に記載のシステ
   ム。
5. 【請求項５】 前記第２の構成要素は、アニメーション
   ・パラメータにアクセスして、前記第１の構成要素に供
   給される前記グラフィックス情報を変えることを特徴と
   する請求項１に記載のシステム。
6. 【請求項６】 前記第２の構成要素は、前記シーン・デ
   ータの変化に応答して出力するように動作することを特
   徴とする請求項１に記載のシステム。
7. 【請求項７】 前記第１の構成要素が、前記グラフィッ
   クス情報が必要であることを知らせた場合に、前記第２
   の構成要素が動作することを特徴とする請求項１に記載
   のシステム。
8. 【請求項８】 前記第２の構成要素は、第１の構成要素
   からのフィードバックに基づいて、前記第１の構成要素
   に供給される前記グラフィックス情報量を動的に調整す
   ることを特徴とする請求項１に記載のシステム。
9. 【請求項９】 前記第２の構成要素は、前記シーン・デ
   ータ内のアニメーション・パラメータに基づく頻度で動
   作することを特徴とする請求項１に記載のシステム。
10. 【請求項１０】 前記第２の構成要素は、命令ストリー
    ムを介して前記第１の構成要素に前記グラフィックス情
    報を提供することを特徴とする請求項１に記載のシステ
    ム。
11. 【請求項１１】 前記第２の構成要素は、命令ストリー
    ムを介して前記第１の構成要素に前記グラフィックス情
    報を提供することを特徴とする請求項１に記載のシステ
    ム。
12. 【請求項１２】 前記第２の構成要素は、ネットワーク
    接続を介して前記第１の構成要素に前記グラフィックス
    情報を提供することを特徴とする請求項１に記載のシス
    テム。
13. 【請求項１３】 前記第１の構成要素は、前記第２の構
    成要素によって提供される前記グラフィックス情報を、
    少なくとも１つの待ち行列の１組内に維持することを特
    徴とする請求項１に記載のシステム。
14. 【請求項１４】 第１の構成要素にその他のグラフィッ
    クス情報を提供する少なくとも１つのその他の第２の構
    成要素をさらに備え、前記第１の構成要素は、各第２の
    構成要素からの前記グラフィックス情報の合成から、前
    記グラフィックス・サブシステムに提供される前記グラ
    フィックス・データを合成することを特徴とする請求項
    １に記載のシステム。
15. 【請求項１５】 前記第１の構成要素は、前記第２の構
    成要素によって提供される前記グラフィックス情報を、
    それぞれの高レベル構成要素のための少なくとも１つの
    待ち行列の１組内に維持することを特徴とする請求項１
    ４に記載のシステム。
16. 【請求項１６】 前記第２の構成要素がその内部に前記
    シーン・データの少なくともいくつかを維持するキャッ
    シュ・データ構造をさらに備えることを特徴とする請求
    項１に記載のシステム。
17. 【請求項１７】 前記キャッシュ・データ構造は、ノー
    ドの階層木（hierarchical tree）として配置されてい
    ることを特徴とする請求項１６に記載のシステム。
18. 【請求項１８】 少なくとも１つの前記ノードは、描画
    命令を含むコンテナ構造を有することを特徴とする請求
    項１７に記載のシステム。
19. 【請求項１９】 前記第１の構成要素は、前記第２の構
    成要素によって提供される前記グラフィックス情報を、
    ビジュアル・ブロックとリソース・データ構造とに分割
    することを特徴とする請求項１に記載のシステム。
20. 【請求項２０】 前記第１の構成要素および高レベル構
    成要素は、異なるスレッド上で実行することを特徴とす
    る請求項１に記載のシステム。
21. 【請求項２１】 ディスプレイ情報のフレームを出力す
    るグラフィックス・サブシステムを備えるコンピューテ
    ィング環境において、第１の構成要素において、 １）出力するグラフィカル・イメージに対応するデータ
    を含むコール（call）を受取るステップと、 ２）シーン情報として前記データを維持するステップ
    と、 ３）第１の動作速度で、 ａ）前記シーン情報をグラフィックス情報に処理するス
    テップと、 ｂ）前記グラフィックス情報を第２の構成要素に伝達す
    るステップと、前記第２の構成要素において、前記第１
    の動作速度より速く、前記グラフィックス・サブシステ
    ムのフレーム・リフレッシュ速度に基づく第２の動作速
    度で、 ４）前記グラフィックス情報を受取るステップと、 ５）前記グラフィックス情報を、前記グラフィックス・
    サブシステムのためにフォーマットしたグラフィックス
    ・データに処理するステップと、 ６）前記グラフィックス・データを、前記フレームを出
    力する前記グラフィックス・サブシステムに伝達するス
    テップと を備えることを特徴とする方法。
22. 【請求項２２】 前記第１の動作速度は、前記コールを
    受取る速度に対応することを特徴とする請求項２１に記
    載の方法。
23. 【請求項２３】 前記シーン情報を維持するステップ
    は、シーン・グラフ・データ構造を構築するステップを
    備えることを特徴とする請求項２１に記載の方法。
24. 【請求項２４】 前記シーン情報を維持するステップ
    は、シーン・グラフ・データ構造内のコンテナを開け
    て、その中の描画命令にアクセスするステップを備える
    ことを特徴とする請求項２３に記載の方法。
25. 【請求項２５】 前記シーン・グラフ・データ構造を処
    理するステップは、変数の少なくとも１つの値を変更す
    るステップを備えることを特徴とする請求項２３に記載
    の方法。
26. 【請求項２６】 前記シーン情報を維持するステップ
    は、前記コールを介して受取った変更を待ち行列に入れ
    るステップと、前記待ち行列に入れた変更を適用するス
    テップとを備えることを特徴とする請求項２１に記載の
    方法。
27. 【請求項２７】 前記シーン・グラフ・データ構造を処
    理するステップは、変数の少なくとも１つの値を獲得す
    るステップを備えることを特徴とする請求項２１に記載
    の方法。
28. 【請求項２８】 前記第１の構成要素において、前記シ
    ーン情報を処理した後の少なくともいくつかの結果をキ
    ャッシュに入れるステップをさらに備えることを特徴と
    する請求項２１に記載の方法。
29. 【請求項２９】 前記グラフィックス情報を前記第２の
    構成要素に伝達するステップは、命令ストリームを前記
    第２の構成要素に送るステップを備えることを特徴とす
    る請求項２１に記載の方法。
30. 【請求項３０】 前記命令ストリームは、リソース・パ
    ケットを含み、前記グラフィックス情報を、前記グラフ
    ィックス・サブシステムのためにフォーマットしたグラ
    フィックス・データに処理するステップは、リソースを
    作成することによってリソース・パケットを処理するス
    テップと、そのリソースを前記第１の構成要素に関連付
    けるステップとを備えることを特徴とする請求項２９に
    記載の方法。
31. 【請求項３１】 前記命令ストリームは、ビジュアル更
    新パケットを含み、前記グラフィックス情報を前記グラ
    フィックス・サブシステムのためにフォーマットしたグ
    ラフィックス・データに処理するステップは、ビジュア
    ルが前記第１の構成要素に既に関連付けられているかど
    うかを決定することにより、前記ビジュアル更新パケッ
    トを処理するステップであって、関連付けられていなけ
    れば新しいビジュアルを作成して前記新しいビジュアル
    を前記第１の構成要素に関連付け、既に関連付けられて
    いれば、前記ビジュアル更新パケット内の情報に基づ
    き、そのビジュアルの情報を修正するステップを備える
    ことを特徴とする請求項２９に記載の方法。
32. 【請求項３２】 前記第２の構成要素から前記第１の構
    成要素へ情報を戻すステップをさらに備えることを特徴
    とする請求項２１に記載の方法。
33. 【請求項３３】 前記第２の構成要素から前記第１の構
    成要素へ情報を戻すステップは、少なくとも１つのイベ
    ントを待ち行列に入れるステップを備えることを特徴と
    する請求項３２に記載の方法。
34. 【請求項３４】 第３の構成要素において、 出力するその他のグラフィカル・イメージに対応するそ
    の他のデータを含むその他のコールを受取るステップ
    と、 前記その他のデータをその他のシーン情報として維持す
    るステップと、 第３の動作速度で、前記その他のシーン情報をその他の
    グラフィックス情報に処理して、前記その他のグラフィ
    ックス情報を前記第２の構成要素に伝達するステップと
    をさらに備えることを特徴とする請求項２１に記載の方
    法。
35. 【請求項３５】 前記第２の構成要素において、 前記その他のグラフィックス情報を受取るステップと、 前記その他のグラフィックス情報を、前記グラフィック
    ス・サブシステムのためにフォーマットしたその他のグ
    ラフィックス・データに処理するステップと、 前記第１の構成要素に対応する前記グラフィックス・デ
    ータの少なくとも一部と、前記第３の構成要素に対応す
    る前記グラフィックス・データの少なくとも一部とを含
    むグラフィックス・デスクトップを合成するステップ
    と、 前記グラフィックス・デスクトップを、前記フレームを
    出力する前記グラフィックス・サブシステムに伝達する
    ステップとをさらに備えることを特徴とする請求項３４
    に記載の方法。
36. 【請求項３６】 データ構造を格納したコンピュータ読
    取り可能媒体であって、前記データ構造は、 ビジュアル識別子を有する識別子フィールドを含み、フ
    ィールドが命令ブロックに対応する、ビジュアル更新ブ
    ロックと、 前記ビジュアル識別子によって識別されるビジュアルに
    関連する１組のデータに対応する前記命令ブロックであ
    って、前記１組のデータは、高レベル・グラフィックス
    処理構成要素から低レベル・グラフィックス処理構成要
    素にパスされる、前記命令ブロックと、 シーン・グラフから前記データ構造を構築し、前記デー
    タ構造を前記低レベル構成要素に提供する前記高レベル
    構成要素と、前記データ構造を、フレームを出力するグ
    ラフィックス・サブシステムにパスするためのグラフィ
    ックス・データに処理する前記低レベル構成要素とを備
    えることを特徴とするコンピュータ読取り可能媒体。
37. 【請求項３７】 前記１組のデータは、少なくとも１つ
    の変数のリストを含むことを特徴とする請求項３６に記
    載のデータ構造。
38. 【請求項３８】 前記１組のデータは、少なくとも１つ
    の命令のリストを含むことを特徴とする請求項３６に記
    載のデータ構造。
39. 【請求項３９】 前記命令ブロックに対応する前記フィ
    ールドは、前記データ構造内の別の場所を指示する命令
    ブロック・オフセットを備えることを特徴とする請求項
    ３６に記載のデータ構造。
40. 【請求項４０】 前記１組のデータは、前記低レベル・
    グラフィックス処理構成要素に補間情報を提供する命令
    を含むことを特徴とする請求項３６に記載のデータ構
    造。
41. 【請求項４１】 前記補間情報は、補間機能を備えるこ
    とを特徴とする請求項４０に記載のデータ構造。
42. 【請求項４２】 前記補間情報は、時間間隔を備えるこ
    とを特徴とする請求項４０に記載のデータ構造。
43. 【請求項４３】 前記時間間隔は、開始および終了タイ
    ミング・ポイントを備えることを特徴とする請求項４２
    に記載のデータ構造。
44. 【請求項４４】 前記補間情報は、開始および終了位置
    データを有することを特徴とする請求項４０に記載のデ
    ータ構造。
45. 【請求項４５】 第１の構成要素において、 １）出力するグラフィカル・イメージに対応するデータ
    を含むコールを受取るステップと、 ２）シーン情報として前記データを維持するステップ
    と、 ３）第１の動作速度で、 ａ）前記シーン情報をグラフィックス情報に処理するス
    テップと、 ｂ）前記グラフィックス情報を第２の構成要素に伝達す
    るステップと前記第２の構成要素で、前記第１の動作速
    度より速く、グラフィックス・サブシステムのフレーム
    ・リフレッシュ速度に基づく第２の動作速度で、 ４）前記グラフィックス情報を受取るステップと、 ５）前記グラフィックス情報を、前記グラフィックス・
    サブシステムのためにフォーマットしたグラフィックス
    ・データに処理するステップと、 ６）前記グラフィックス・データを、フレームを出力す
    る前記グラフィックス・サブシステムに伝達するステッ
    プとを備えるコンピュータ実行可能命令を有することを
    特徴とするコンピュータ読取り可能媒体。
46. 【請求項４６】 前記第１の動作速度は、前記コールを
    受取る速度に対応することを特徴とする請求項４５に記
    載のコンピュータ読取り可能媒体。
47. 【請求項４７】 前記シーン情報を維持するステップ
    は、シーン・グラフ・データ構造を構築するステップを
    備えることを特徴とする請求項４５に記載のコンピュー
    タ読取り可能媒体。
48. 【請求項４８】 前記シーン情報を維持するステップ
    は、シーン・グラフ・データ構造内のコンテナを開け
    て、その中の描画命令にアクセスするステップを備える
    ことを特徴とする請求項４７に記載のコンピュータ読取
    り可能媒体。
49. 【請求項４９】 前記シーン・グラフ・データ構造を処
    理するステップは、変数の少なくとも１つの値を変える
    ステップを備えることを特徴とする請求項４７に記載の
    コンピュータ読取り可能媒体。
50. 【請求項５０】 前記シーン情報を維持するステップ
    は、前記コールを介して受取った変更を待ち行列に入れ
    るステップと、前記待ち行列に入れた変更を適用するス
    テップとを備えることを特徴とする請求項４５に記載の
    コンピュータ読取り可能媒体。
51. 【請求項５１】 前記シーン・グラフ・データ構造を処
    理するステップは、変数の少なくとも１つの値を得るス
    テップを備えることを特徴とする請求項４５に記載のコ
    ンピュータ読取り可能媒体。
52. 【請求項５２】 前記第１の構成要素において、前記シ
    ーン情報を処理した後の少なくともいくつかの結果をキ
    ャッシュに入れるステップを含む、少なくともさらに１
    つのコンピュータ実行可能命令を有することを特徴とす
    る請求項４５に記載のコンピュータ読取り可能媒体。
53. 【請求項５３】 前記グラフィックス情報を前記第２の
    構成要素に伝達するステップは、命令ストリームを前記
    第２の構成要素に伝達するステップを備えることを特徴
    とする請求項４５に記載のコンピュータ読取り可能媒
    体。
54. 【請求項５４】 前記命令ストリームはリソース・パケ
    ットを備え、前記グラフィックス情報を、前記グラフィ
    ックス・サブシステムのためにフォーマットしたグラフ
    ィックス・データに処理するステップは、リソースを作
    成することによってリソース・パケットを処理するステ
    ップと、そのリソースを前記第１の構成要素に関連付け
    るステップとを含むことを特徴とする請求項５３に記載
    のコンピュータ読取り可能媒体。
55. 【請求項５５】 前記命令ストリームはビジュアル更新
    パケットを有し、前記グラフィックス情報を前記グラフ
    ィックス・サブシステムのためにフォーマットしたグラ
    フィックス・データに処理するステップは、ビジュアル
    が前記第１の構成要素に既に関連付けられているかどう
    かを決定することにより、前記ビジュアル更新パケット
    を処理するステップであって、関連付けられていなけれ
    ば新しいビジュアルを作成して前記新しいビジュアルを
    前記第１の構成要素に関連付け、既に関連付けられてい
    れば、前記ビジュアル更新パケット内の情報に基づき、
    そのビジュアルの情報を修正するステップを備えること
    を特徴とする請求項５３に記載のコンピュータ読取り可
    能媒体。
56. 【請求項５６】 前記第２の構成要素から前記第１の構
    成要素へ情報を戻すステップを備える、少なくともさら
    に１つのコンピュータ実行可能命令を有することを特徴
    とする請求項４５に記載のコンピュータ読取り可能媒
    体。
57. 【請求項５７】 前記第２の構成要素から前記第１の構
    成要素へ情報を戻すステップは、少なくとも１つのイベ
    ントを待ち行列に入れるステップを備えることを特徴と
    する請求項５６に記載のコンピュータ読取り可能媒体。
58. 【請求項５８】 第３の構成要素で、 出力するその他のグラフィカル・イメージに対応するそ
    の他のデータを含むその他のコールを受取るステップ
    と、 前記その他のデータをその他のシーン情報として維持す
    るステップと、 第３の動作速度で、前記その他のシーン情報をその他の
    グラフィックス情報に処理するステップと、 前記その他のグラフィックス情報を前記第２の構成要素
    に伝達するステップとを備えるコンピュータ実行可能命
    令をさらに有することを特徴とする請求項４５に記載の
    コンピュータ読取り可能媒体。
59. 【請求項５９】 前記第２の構成要素で、 前記その他のグラフィックス情報を受取るステップと、 前記その他のグラフィックス情報を、前記グラフィック
    ス・サブシステムのためにフォーマットしたその他のグ
    ラフィックス・データに処理するステップと、 前記第１の構成要素に対応する前記グラフィックス・デ
    ータの少なくとも一部と、前記第３の構成要素に対応す
    る前記グラフィックス・データの少なくとも一部とを含
    むグラフィックス・デスクトップを合成するステップ
    と、 前記グラフィックス・デスクトップを、前記フレームを
    出力する前記グラフィックス・サブシステムに伝達する
    ステップとを備えるコンピュータ実行可能命令をさらに
    有することを特徴とする請求項５８に記載のコンピュー
    タ読取り可能媒体。