JP2003162733A - シーングラフのための汎用パラメータ設定 - Google Patents

Abstract

(57)【要約】 【課題】 グラフィックス出力を制御するための新しい
モデルを提供する。 【解決手段】 パラメータ設定されたシーングラフが、
可変(アニメートされた)値、およびパラメータ設定され
たグラフコンテナを提供して、アプリケーションプログ
ラム等が、シーングラフ記述のいくつかの態様を、その
他の態様をそのままにしながら、選択的に変更できるよ
うにする。また異なるパラメータでシーングラフの部分
を再使用することができるようにする。

Description

【発明の詳細な説明】

【０００１】本発明は、米国仮特許出願第60/330,231号
(2001年10月18日出願)への優先権を請求する。本発明
は、係属米国特許出願「Multiple-Level Graphics Proc
essingSystem and Method」(弁護士整理番号第3140号)
および係属米国特許出願「Intelligent Caching Data S
tructure for Immediate Mode Graphics」(弁護士整理
番号第3150号)に関し、両文書とも、本出願の譲受人に
譲受され、本明細書とともに同時出願され、参照により
それら全体が組み入れてある。

【０００２】

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

【０００３】

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

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

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

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

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

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

【０００９】

【発明が解決しようとする課題】要するに、グラフィッ
クスを制御するための既存のモデルは、効率的な仕方で
複雑なグラフィックスを扱うには不十分である。グラフ
ィックス出力を制御するための新しいモデルが必要とさ
れている。

【００１０】

【課題を解決するための手段】簡単に言えば、本発明
は、より高レベルのコード(例えば、アプリケーション
プログラム)が、シーングラフ記述のある態様を、その
他の態様をそのままにしながら、選択的に変更すること
ができるようにレンダリングされるグラフィックスデー
タを表すパラメータ設定されたシーングラフを提供す
る。この目的で、シーングラフを再構成することなく、
またはカストマイズされたコードを実装することなくシ
ーン記述を変更できるようにするシーングラフの中への
汎用フックを高レベルのコードに提供する可変値が提供
される。例えば、ユーザは、従来のシーングラフで必要
とされるようにシーングラフ、またはシーングラフの一
部分を再構成することなしに、マウスクリックのような
アプリケーションイベントに反応してボタンのカラーを
変更することができる。パラメータを変更することによ
って外観の特質を変化させるシーングラフで表現された
比較的固定されたイメージに加え、外観、サイズ、およ
び/または位置を時間とともに変化させることによって
その他のイメージをアニメートすることができる。すな
わち、可変値が、アニメーションをシーングラフと結合
する。

【００１１】また、シーングラフに対する抽象化の概念
を提供するパラメータ設定されたグラフコンテナも説明
する。言い換えれば、パラメータ設定されたグラフコン
テナにより、一般的な仕方でシーン全体にわたって再使
用するためにシーングラフをテンプレート化することが
できるようになる。このようにして、単一のパラメータ
設定されたグラフコンテナを、パラメータとして異なる
値を使用して、シーングラフの中で効率的に再使用する
ことができる。例えば、特定の形状を表す単一のパラメ
ータ設定されたグラフコンテナが、カラー、サイズ、角
などの様々なパラメータ値を使用して、フレームの中の
異なる位置で現れるその形状の多数のインスタンスをも
たらすことが可能である。そのような再使用により、複
雑なシーングラフが、そのシーングラフからフレームを
レンダリングするのに必要とされるリソースの点で極め
て効率的であることが可能になる。

【００１２】パラメータ設定は、本来的なシーングラフ
プリミティブとして実装されるので、汎用メソッドを適
用してレンダリングプロセスを最適化することができ、
これにより、効率的なコンパイルメカニズムおよびレン
ダリングメカニズムでシーングラフを使用することが可
能になる。その他の利点には、特定のシーングラフイン
スタンスにおけるリソースの効率的で柔軟性のある再使
用、堅牢性、より費用のかかる構造上の変更とパラメー
タ設定システムを介する極めて効率的な変更の間の区別
を含め、スケーラブルな変更が含まれる。

【００１３】本発明は、トラバースされたとき、グラフ
ィックデータを出力するための命令を提供する、変更さ
れることが可能な値を有する可変値に少なくとも1つが
関連する複数のコンテナを含むシーングラフと、シーン
グラフをトラバースして可変値の現行の値に基づいたデ
ータを含む命令を提供するレンダリングメカニズムとを
含むシステムを介して提供することができる。コンピュ
ータ実行可能命令を有するメソッドおよびコンピュータ
可読媒体は、シーングラフに対する1組の少なくとも1つ
の関数を含むインターフェースを提供すること、可変値
をシーングラフのコンテナの中に含める要求をそのイン
ターフェースを介して受け取り、その可変値が、このイ
ンターフェースを介して受け取られる別の要求によって
変更されることが可能な値を有すること、およびシーン
グラフに対応する、可変値の現行の値に基づくデータを
含むグラフィックス命令を提供することを含めてシーン
グラフのレンダリングを行うことを含むことが可能であ
る。

【００１４】システムは、トラバースされたとき、デー
タを出力するための1組の命令を提供する複数のコンテ
ナを含むシーングラフと、変更することが可能な1組の
少なくとも1つの変数値に対応するパラメータ設定され
たグラフコンテナと、変数値に関する実際の値を決定
し、その実際の値に対応するデータを1組の命令の中に
入れる処理を行うことを含めてシーングラフのトラバー
スを行うレンダリングメカニズムとを含むことが可能で
ある。コンピュータ実行可能命令を有するメソッドおよ
びコンピュータ可読媒体は、コンテナを自らに追加する
ためのインターフェースを含むシーングラフを提供する
こと、内容を表し、変更することが可能な1組の少なく
とも1つの変数値に対応するパラメータ設定されたグラ
フコンテナをシーングラフに追加する要求を受け取るこ
と、ならびにセットの中の各変数値に関する第1の実際
の値を決定し、それぞれの第1の実際の値に対応する第1
のデータを命令ストリームの中に入れること、およびセ
ットの中の各変数値に関する第2の実際の値を決定し、
それぞれの第2の実際の値に対応する第2のデータを命令
ストリームの中に入れることを含めてシーングラフから
の命令ストリームのレンダリングを行うことを含むこと
が可能である。

【００１５】データ構造が記憶されているコンピュータ
可読媒体は、シーングラフのパラメータ設定された命令
ストリームの中のグラフィックス命令に対応する命令タ
イプを示す第1のフィールドと、パラメータ設定された
命令のためのプレースホルダをそれぞれが含む少なくと
も1つのパラメータフィールドとを含むことが可能であ
り、シーングラフがレンダリングされると、このプレー
スホルダは、シーングラフに対応する情報から定数値を
獲得することによって定数値にインスタンス化される。
第1のプロセスと第2のプロセスの間で通信するためのメ
ソッドは、第1のプロセスにおいて、コンテナを自らに
追加するためのインターフェースを含むシーングラフを
提供すること、第2のプロセスから、内容を表し、変更
することが可能な1組の少なくとも1つの変数値に対応す
るパラメータ設定されたグラフコンテナをシーングラフ
に追加する要求を受け取ること、ならびに第1のプロセ
スにおいて、セットの中の各変数値に関する第1の実際
の値を決定し、それぞれの第1の実際の値に対応する第1
のデータを命令ストリームの中に入れること、およびセ
ットの中の各変数値に関する第2の実際の値を決定し、
それぞれの第2の実際の値に対応する第2のデータを命令
ストリームの中に入れることを含めてシーングラフから
の命令ストリームのレンダリングを行うことを含むこと
が可能である。

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

【００１７】

【発明の実施の形態】オペレーティング環境の例図1
は、本発明を実施する適切な計算機システム環境100の
例を示す図である。計算機システム環境100は、適切な
計算環境の一例にすぎず、本発明の使用法または機能の
範囲を限定するものではない。また計算環境100は、例
示したオペレーティング環境100に示した構成要素のい
ずれか1つまたは組み合わせに依存したり、その条件が
必要であると解釈されないものとする。

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

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

【００２０】図1を参照すると、本発明を実施するため
のシステムの例が、コンピュータ110の形の汎用計算装
置を含む。コンピュータ110の構成要素は、処理装置120
と、システムメモリ130と、システムメモリを含むさま
ざまなシステム構成要素を処理装置120に結合するシス
テムバス121とを含むが、これらに限定されるものでは
ない。システムバス121は、メモリバスまたはメモリコ
ントローラ、周辺バス、およびさまざまなバスアーキテ
クチャのいずれかを使用するローカルバスを含む、数種
類のバス構造のいずれかである。このようなアーキテク
チャが、業界標準アーキテクチャ(Industry Standard A
rchitecture)(ISA)バス、マイクロチャネルアーキテク
チャ(Micro Channel Architecture)(MCA)バス、エンハ
ンストISA(EISA)バス、ビデオ電子機器標準協会(Video
Eletronics Standards Association)(VESA)ローカルバ
ス、加速グラフィックスポート(Accelerated Graphics
Port(AGP)バス、メザニンバス(Mezzanine bus)としても
周知の、周辺構成要素相互接続(Peripheral Component
Interconnect)(PCI)を含むが、これらは例示のためであ
って、これらに限定されるものではない。

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

【００２２】システムメモリ130は、リードオンリーメ
モリ(ROM)131やランダムアクセスメモリ(RAN)132などの
揮発性および/または不揮発性メモリの形のコンピュー
タ記憶媒体を備える。基本入力/出力システム133(BIOS)
は、スタートアップ中などに、コンピュータ110内の要
素間で情報の転送の一端を担う基本ルーチンを含み、一
般にROM131内に格納される。RAM132は、一般に、ただち
にアクセス可能および/または現在処理装置120によって
動作中の、データおよび/またはプログラムモジュール
を含む。図1は、オペレーティングシステム134、アプリ
ケーションプログラム135、その他のプログラムモジュ
ール136およびプログラムデータ137を備えるが、これら
は例示のためであって、これらに限定されるものではな
い。

【００２３】コンピュータ110はまた、その他の取り外
し可能/取り外し不能、揮発性/不揮発性コンピュータ記
憶媒体を備える。例示のためだけに、図1は、取り外し
不能の不揮発性磁気媒体から読出し、そこに書き込むハ
ードディスクドライブ141と、取り外し可能の不揮発性
磁気ディスク152から読出し、そこに書き込む磁気ディ
スクドライブ151と、CDROMまたはその他の光学媒体など
の、取り外し可能の不揮発性光学ディスク156から読出
し、そこに書き込む光学ディスクドライブ155とを備え
る。オペレーティング環境の例で使用することのでき
る、その他の取り外し可能/取り外し不能、揮発性/不揮
発性コンピュータ記憶媒体は、磁気テープカセット、フ
ラッシュメモリカード、ディジタル多目的ディスク、デ
ィジタルビデオテープ、ソリッドステートRAM、ソリッ
ドステートROMなどを備えるが、これらに限定されるも
のではない。ハードディスクドライブ141は、一般に、
インターフェイス140などの取り外し不能メモリインタ
ーフェイスを介してシステムバス121に接続し、磁気デ
ィスクドライブ151および光学ディスクドライブ155は、
一般に、インターフェイス150などの取り外し可能メモ
リインターフェイスによってシステムバス121に接続す
る。

【００２４】上記で説明し、図1に示した、ドライブお
よびそれらの関連コンピュータ記憶媒体は、コンピュー
タ110のための、コンピュータ読取り可能命令の記憶装
置、データ構造、プログラムモジュールおよびその他の
データを備える。図1では、たとえば、ハードディスク
ドライブ141が、オペレーティングシステム144、アプリ
ケーションプログラム145、その他のプログラムモジュ
ール146およびプログラムデータ147を格納するものとし
て示してある。これらの構成要素は、オペレーティング
システム134、アプリケーションプログラム135、その他
のプログラムモジュール136、およびプログラムデータ1
37と同じまたは異なるもののどちらでもあり得ることに
留意されたい。オペレーティングシステム144、アプリ
ケーションプログラム145、その他のプログラムモジュ
ール146、およびプログラムデータ147は、本明細書で
は、最小限の異なる数で示してあるが、これとは異なる
数であり得る。ユーザが、コマンドおよび情報を、タブ
レット(電子ディジタイザ)164、マイクロホン163、キー
ボード162および通常マウスと呼ぶポインティングデバ
イス161、トラックボールまたはタッチパッドなどの入
力装置を介して、コンピュータ20に入力する。その他の
入力装置(図示せず)は、ジョイスティック、ゲームパッ
ド、衛星放送用パラボラアンテナ、スキャナなどを備え
る。これらおよびその他の入力装置は、システムバスに
結合するユーザ入力インターフェイス160を介して処理
装置120に接続することが多いが、パラレルポート、ゲ
ームポートまたはUSB(universal serial bus)など、そ
の他のインターフェイスおよびバス構造によって接続す
ることもある。モニタ191またはその他の種類のディス
プレイ装置も、ビデオインターフェイス190などのイン
ターフェイスを介してシステムバス121に接続する。モ
ニタ191も、タッチスクリーンインターフェイス192など
のインターフェイスを介してコンピュータシステム110
への手書き(handwriting)など、ディジタル化した入力
を入力するタッチスクリーンパネル193などに統合され
る。モニタおよび/またはタッチスクリーンパネルが、
タブレットタイプのパーソナルコンピュータなどの中
に、計算装置110が組み込まれているハウジングに物理
的に結合でき、ここで、タッチスクリーンパネル193
は、本来タブレット164として働くことに留意された
い。さらに、計算装置110などのコンピュータはまた、
出力周辺インターフェイス194などを介して接続され
る、スピーカ195やプリンタ196などのその他の周辺出力
装置を備える。

【００２５】コンピュータ110は、遠隔コンピュータ180
などの1つまたは複数の遠隔コンピュータへの論理接続
を使用するネットワーク環境で動作する。遠隔コンピュ
ータ180は、パーソナルコンピュータ、サーバ、ルー
タ、ネットワークPC、ピア装置またはその他の共通ネッ
トワークノードであり、図1ではただ1つのメモリ記憶装
置181だけを示してあるが、一般に、コンピュータ110に
対して、上述した多くのまたはすべての要素を有する。
図1に示す論理接続は、ローカルエリアネットワーク(LA
N)171およびワイドエリアネットワーク(WAN)173を含む
が、その他のネットワークも含むことができる。このよ
うなネットワーキング環境は、オフィス、全社的なコン
ピュータネットワーク、イントラネットおよびインター
ネット内で良く見かけるものである。

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

【００２７】グラフィックス層アーキテクチャ 本発明の一態様は、通常のコンピュータシステム上に存
在するグラフィックスハードウェアの能力のより多くを
活用することによることを含め、複雑なグラフィックス
をレンダリングするのにアプリケーションおよびその他
の構成要素に必要とされる処理を軽減することを対象と
する。このため、図2に概略が示してあるように、本発
明を組み込むことができる1つのコンピュータ環境にお
いて、グラフィックス層アーキテクチャ(メディア統合
層とも呼ばれる)200が提供される。アプリケーション、
制御またはその他同様のより高レベルのプログラムコー
ド(たとえば、オペレーティングシステム構成要素のユ
ーザインターフェイス)202が、1組のアプリケーション
プログラミングインターフェイス(API)204などを介し
て、グラフィックス層アーキテクチャ200にアクセスし
て、グラフィカル情報にアクセス(書き込みまたは読出
し)する。本明細書に記述した多くの例は、APIとインタ
ーフェイスをとるアプリケーションプログラムを指す
が、その他のより高レベルのプログラムコードおよび構
成要素(たとえば、オペレーティングシステムのユーザ
インターフェイス)も、本明細書に記述した、より低レ
ベルの構成要素とインターフェイスをとることができる
ことが理解できることに留意されたい。したがって、こ
のようなより高レベルのプログラムコードが、アプリケ
ーションプログラムや、ユーザインターフェイスなどの
いずれであろうとも、均等物であると考えるべきであ
る。

【００２８】安全上の理由などのさまざまな理由から、
グラフィックス層200(これは、グラフィックスを出力す
る)は、好ましくは、オペレーティングシステムに組み
込まれることに留意されたい。たとえば、グラフィック
ス層200のいくつかまたは一部を、アプリケーションと
オペレーティングシステムの間に挿入することができる
が、そうすると、どのようなグラフィックスを要求して
いる場合でも有害なプログラムが現れて、それにより、
トラブルの起きることがある。たとえば、有害なコード
により、ダイアログボックスに、パスワードを入力する
よう要求が出て、ユーザのパスワードが盗まれてしまう
ようなことが起きる可能性がある。オペレーティングシ
ステムにグラフィックス層200を組み込むその他の理由
としては、安定性および効率性がある。たとえば、より
低レベルでは、より高い層からのデータおよび命令が既
に検証済みであることが保証されているという効率性を
有する。さらに、より低レベルでは、確実に信用してオ
ペレーティングシステムを呼び出すインターフェイスだ
けに繋がることができる、つまり、予測不可能なプログ
ラムのインターフェイスには繋がらないということであ
り、このためより高い安定性が保証される。

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

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

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

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

【００３３】多重グラフィックス処理レベル グラフィックス層アーキテクチャ200は、したがって、
グラフィックス処理を多数のレベルに分割する。これら
のレベルのそれぞれが、アプリケーション、ユーザイン
ターフェイスおよびその他202が、スムーズなアニメー
ションでグラフィックスを出力し、その他のアプリケー
ションのグラフィックスおよびビデオフレームでグラフ
ィックスを合成できる、いくつかのインテリジェントグ
ラフィックス処理を実行する。アニメーションおよび/
または合成は、音声出力とも同期する。たとえば、音声
を低レベル構成要素のフレーム速度と同期させることに
より、音声のタイミングが、ビデオまたはグラフィック
スのタイミングと実質的に一致し、リフレッシュ速度に
追いつくためタスクスケジューリングされた、複雑な前
処理機能に依存しなくなる。

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

【００３５】同じく上述の(例えば、特許文献1参照)に
記載されているように、高レベル合成およびアニメーシ
ョンエンジン206は、そのレベルまたはそれ以下のレベ
ルより比較的遅い速度で動作するため、例示のために、
システムリソースを使い果たすことなく、このような複
雑な処理を達成することができる。より低いレベルは、
ハードウェアグラフィックスプロセッサのフレーム(リ
フレッシュ)速度で動作することは、例示目的であり、
これらに限定されるものではない。たとえば、高レベル
コンポジッタおよびアニメータ206は、ディスプレイの
変更を、オンデマンドで、またはその他のスケジュール
(たとえば、0.5秒毎に)を実施する必要がある時にのみ
動作する。単一の高レベルコンポジッタおよびアニメー
タエンジン206が図3に示してあるが、アプリケーション
単位で1つずつなど、多くの場合があり、一般には、グ
ラフィックス装置毎に1つだけの低レベル合成およびア
ニメーションエンジ210、たとえば、マシンのそれぞれ
のグラフィックスハードウェアカードについて1つであ
ることに留意されたい。

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

【００３７】さらに、高レベルコンポジッタおよびアニ
メータ206によって供給されるコマンドおよびその他の
データを単純化して、ハードウェアの能力および条件に
一致させることができる。たとえば、ハードウェアの数
が少なくなればなる程、高レベルの前処理が多く必要と
なる。さらにまた、たとえば、1または複数のより低い
レベルにある、変化し続ける処理需要に合わせるため、
高レベルの前処理量は動的である。

【００３８】ローカルグラフィックス出力については、
1機器構成において、グラフィックス層アーキテクチャ2
00は、高レベルコンポジッタおよびアニメータ206と、
低レベルコンポジッタおよびアニメータ210とを含む。
一般的に言って、高レベルコンポジッタおよびアニメー
タ206は、クライアントから受け取ったグラフィックス
情報(たとえば、アプリケーション)の複雑な処理を実行
して、グラフィックス構造を構築し、これらの構造をグ
ラフィックスコマンドのストリームに変換する。次い
で、低レベルエンジン210は、さまざまなクライアント
からのグラフィックスコマンドのストリームを使って、
コンピュータのユーザが見るデスクトップを合成する。
たとえば、低レベルコンポジッタは、デスクトップ上に
存在するさまざまなクライアントによって放出されるコ
マンドストリームを、グラフィックス合成エンジンによ
って消費されるグラフィックスコマンドに組み合わせる
ことにより、デスクトップを合成する。

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

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

【００４１】以下でも説明するとおり、アプリケーショ
ン204は、シーングラフが、可変値と呼ばれる、アプリ
ケーションがパラメータを介して調整することができる
変数データを含むことをAPIコールを介して要求するこ
とができる。例えば、アプリケーションは、シーングラ
フの中のサブグラフによって表されるレンダリングされ
る内容のカラー、サイズ、位置、その他を選択的に制御
することができる。また、アプリケーションは、シーン
グラフが、所望される場合、パラメータ設定されたグラ
フコンテナを介してシーングラフの中で実装することが
できる異なる変数値を有する再使用可能な部分を含むこ
とをAPIコールを介して要求することができる。

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

【００４３】インテリジェントキャッシングデータ構造
300全体内のオブジェクト(または構造)の1つが、コンテ
ナ402、404または408、(あるいはビジュアル2Dと呼ぶ)
で図4に示したコンテナである。コンテナ(たとえば、40
4)が、アプリケーションがそれのためのハンドルを保持
することができるという識別を提供し、そして、アニメ
ーションおよびテンプレーティング、ヒットテストおよ
びユーザデータのフックアップのために使用できる手続
きパラメータを含む。しかし、本明細書に記載したコン
テナは、作られる可能性のある唯一の種類のコンテナで
はないことに留意されたい。その他の例では、パラグラ
フ内にラインを格納するため、またはグリッド内に多く
の子を格納するために最適化されたコンテナを含むこと
ができる。特定の種類のコンテナでは、子に対してラン
ダムアクセスができないものの、子コンテナは、現行の
子リストをクリアすることなく、追加したり削除したり
できる。APIを介して使われる構造は、必要に応じて採
用できる。

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

【００４５】図5のツリーセグメント500に示すように、
510のようなコンテナは、したがって、その他のコンテ
ナ512または描画基本要素516を保持でき、ここで、いず
れかのコンテナの中の基本要素の記憶装置は、グラフィ
ックス命令のストリームと考えることができる。コンテ
ナはまた、その他のコンテナも格納することができ、実
際、グラフを作成する、すなわち、コンテナを1を越え
るコンテナによって参照でき、その結果、データ構造
は、コンテナの閉路なし有向グラフ(DAG)および基本要
素のリストである(ここで、コンテナは、その親コンテ
ナの1つを含むことができる)。

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

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

【００４８】一代替実施形態では、待ち行列418への変
更をディスプレイマネージャ420を介して通知すること
により、データ構造への変更が、非同期式で行われる。
その結果、変更がレンダリングスレッド422上で処理さ
れる、そして、たとえば、低レベルコンポジッタおよび
アニメータ210に送信される(ここで、図3の抽象装置302
は、低レベルコンポジッタ210にストリームされたレン
ダリングコマンドの中に、高レベルコンポジッタ206に
よって出されたレンダリングコマンドの変換をカプセル
化する抽象化を含む)。トランザクション的なモデルに
より、データ構造への修正が、データ構造からの読出し
を中断することなくできるようになる。

【００４９】上述の待ち行列モデルにより、高レベルエ
ンジン206からの読出しパスが、ユーザの行うどのよう
なアクションにも関係なく走行できるようになるが、ユ
ーザアプリケーションには、APIの一貫性のあるビュー
を維持するために、キャッシュが必要であり、そのため
効率性が損なわれる。例示のために、コンテナ上のプロ
パティの設定をする主要ユーザスレッド上のユーザアプ
リケーション(高レベルエンジン206内のオブジェクト)
を考えてみよう。待ち行列モデルでは、このプロパティ
が待ち行列の中に入れられて、高レベルエンジン206デ
ータ構造に適用される。しかし、ユーザアプリケーショ
ンが、直ちにそのプロパティをコンテナからリードバッ
ク(read back)を試みると、システムは、現在待ち行列
内にあるものに基づいてプロパティをリードバックし
(これは非効率的である)、レンダリングスレッドと同期
をとり、待ち行列内で待っている変更を適用し(これは
非効率的であり、待ち行列を有するという利点を無駄に
するものである)、または、レンダリングのバージョン
および待ち中のバージョンの両方とも、ユーザ変更可能
データのコピーをコンテナに保管しなければならない
(これは、非効率的なメモリの使用法である)。

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

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

【００５２】図4に戻ると、コンテナ408は、描画基本要
素を含む基本識別ノードを備え、描画コンテキスト416
は、基本要素、変換、クリップまたはその他の描画オペ
レーションをコンテナに追加するために使用することの
できる、コンテナから得られたグラフビルダ(たとえ
ば、ヘルパオブジェクト)を含む。ディスプレイマネー
ジャ420は、高レベルコンポジッタおよびアニメータ206
のインスタンスを表す、ホストとなっているオブジェク
トを含む。そして、たとえば、hwnd(ウィンドウへのハ
ンドル)またはhvisual(ビジュアルコンテナへのハンド
ル)にアタッチすることができる。ディスプレイマネー
ジャ420は、シーンのためのルートコンテナ402へのポイ
ンタを有し、コンテナが無効で再描画の必要がある場合
に、事象を高レベルコードにディスパッチし、ヒットテ
ストや座標変換などのサービスにアクセスする。

【００５３】本発明に従って、以下に説明するとおり、
より高レベルのコード202は、データ構造の中のオブジ
ェクトのいくつかに対するハンドルまたはそれに類する
もの、およびパラメータ設定を介したシーングラフに対
する変更を可能にするコンテナを保持することが可能で
ある。ただし、通常のシーングラフでは、コンテナ内の
殆どのオブジェクトは、アプリケーションの観点から見
て識別を持たないことに留意されたい。具体的には、こ
の構造へのアクセスが、殆どの使用パターンが「書き込
みに限る」という制限がなされている。この方式で識別
を制限することにより、データ構造内に格納された情報
がより多く最適化できるようになり、そしてより高レベ
ルのコード202は、オブジェクト情報を格納したり、オ
ブジェクトの生存期間の管理に対処する必要がなくな
る。

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

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

【００５６】単純化した例として、テキストのラインを
描画するためのAPI機能が、TextLineオブジェクトを含
むことがある。このオブジェクトのユーザは、TextLine
オブジェクトに描画すべき実際のテキストを、そのテキ
ストの異なる走行(run)をどのようにレンダリングする
のかに関するその他の情報(フォント、サイズ、ブラシ
その他)とともに、入れる。ユーザプログラムコード
が、そのテキストのラインをデータ構造に実際に追加し
たい場合は、プログラムコードは、特定の開いているノ
ード用に描画コンテキストを取って、TextLineオブジェ
クトを描画コンテキスト上にある描画機能にパスする。
実際にシステムは、TextLineオブジェクト内にあるデー
タを取り、そのデータをデータ構造内にコピーする。こ
のデータは識別を持たないため、高レベルコンポジッタ
およびアニメータエンジン206は、自由にそのラインの
中身を取ることができ、アルゴリズム(たとえば、OpenT
ype)を走行してテキストを位置付きのグリフに分割し
て、位置付けられたグリフデータを、生のテキストの代
りに格納することができる。そのラインを描画した後
は、システムは、ラインを描画するのに使用するTextLi
neオブジェクトへの参照を持たない、すなわち、システ
ムが格納するデータは識別を持たない。

【００５７】あるいは、より高レベルのコード202は、
その識別をそのTextLineオブジェクトに保存するよう要
請し、そのオブジェクトの参照をデータ構造内に格納す
るよう要求する。この方式で、より高レベルのコード20
2は、その後TextLineオブジェクトを変更する場合、シ
ステムは、その変更を発見し、それをレンダリングの出
力に反映する。より現実的な例においては、識別は、テ
キストラインオブジェクト上自体には使用されないが、
アプリケーションが、コンテナへのハンドルを保持し、
下記のように、要求のあり次第、そのコンテナをパラメ
ータ化することによって変更することに留意されたい。

【００５８】しかしながら、データ構造の主要態様の1
つに、より高レベルのコード202が、このようなこのよ
うなオブジェクトを識別とともに作成する必要性が減少
し、それによって、制御コード202によって参照され
る、データ構造内のポイントがより少なくて済むことに
なる。このことにより、データ構造がより一層最適化さ
れる。

【００５９】たとえば、データ構造の外側に出される識
別量が少なくなるため、基本要素の格納密度を濃くする
などの最適化が可能となる。このため、ベクトルグラフ
ィックデータが、「基本リスト」または「基本コンテ
ナ」内に格納される。これらのコンテナは、それぞれの
実施毎に行われ、識別がより高レベルのコード202に行
くことはない。発信者がデータをコンテナ内に書きこむ
と、そのデータは、コンテナと同様、リンクされている
別個のオブジェクト内に格納されるか、(たとえば、変
換とともに)、パックまたはフラットにしたデータアレ
イ内にストリームすることができる。このアレイは、コ
ンパクトな方式でベクトルグラフィックデータを格納で
きるばかりでなく、これらの基本要素とともにリソース
を追跡することができる。個々の基本要素が識別を持た
ないため、基本要素を分離したり、その後これらの基本
要素を変更するための方法をユーザに提供する必要がな
く、基本要素をより効率的に格納できるようになる。

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

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

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

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

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

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

【００６６】データ構造を最後に歩き回った結果には、
データを直接実行して、スクリーン上に表示されるか、
または最後に歩き回った最後の所にフリップされるバッ
クバッファ上で実行されることが含まれる。その他の結
果には、データが、拡張されたタイミングおよびアニメ
ーション情報(上述した米国仮特許出願第60/330,231号
(2001年10月18日出願)に記載されている)とともに運ば
れ、はるかに頻繁に実行されるレンダリングスレッド/
プロセスに渡されることが含まれる。また、歩き回った
結果、スクリーン捕獲またはその他の理由によりデータ
がビットマップ上で実行され、プリンタへ行き、または
ネットワークを介し、次いで遠隔マシンでの以前の結果
のいずれかのために使用されるようになる。これらの結
果の組み合わせも可能である。

【００６７】お分かりのように、データ構造300内のデ
ータの記憶装置は、大量のメモリを必要とする。さら
に、データ構造300内の大量のデータは、クリップ、ス
クロール、またはその他の理由により、見ることができ
ないため、必要とされないことがある。リソース需要を
減らすため、データ構造300は、オンデマンドで構築す
ることができる。これを可能にするために、必要に応じ
て、データ構造300の一部を作成するため、より高レベ
ルのコード202にコールバックする方法が提供される。
この方法は、「無効化」と呼び、従来のグラフィックス
システムで使用されるWM_PAINTコールバック方法と同様
であるが、直接スクリーン上のビットに適用する代り
に、構造300およびキャッシュに入れた中身に適用され
る。しかし、1待ち行列モデル代替形態では、読出しオ
ペレーション(以下に記述する、ヒットテストおよび座
標変換と同様)は最初に変更を適用し、その後ユーザに
示されるモデルが同期をとる。

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

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

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

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

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

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

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

【００７５】シーングラフのための汎用パラメータ設定 本発明の態様によれば、アプリケーションプログラムな
どの高レベルのプログラムコード202に一般的な仕方で
シーングラフ構成要素を効率的に使用し、操作する能力
を与えるパラメータ設定されたシーングラフが提供され
る。シーンが変更されたとき再構成されるグラフィック
スイメージの構造化された表現である従来のシーングラ
フとは異なり、パラメータ設定されたシーングラフは、
グラフ構造が構築された後、シーングラフ構造を変更す
ることなく、またはカストマイズされたコードを実装す
ることなくあるデータ構造を変更できるようにする。ま
た、パラメータ設定されたシーングラフにより、場合に
よっては、異なるパラメータ値を使用してグラフの部分
を再使用することができるようになる。

【００７６】この目的で、以下に一般的に説明するとお
り、パラメータ設定されたシーングラフは、パラメータ
設定された命令/プリミティブ、パラメータ設定された
専用ノード(例えば、可変変換コンテナ、可変アルファ
コンテナ、その他)、およびパラメータ設定されたグラ
フ-ノード/コンテナを含む。例えば、本発明のパラメー
タ設定されたシーングラフは、シーングラフをパラメー
タ設定するためのメカニズムである可変値、およびシー
ングラフの中で再使用することが可能なコンテナである
パラメータ設定されたグラフコンテナを提供する。

【００７７】「可変値」は、グラフ構造自体が構成され
た後、シーングラフのレンダリングを行うことができる
パラメータ設定されたシーングラフの中のプログラマブ
ルエンティティを含む。可変値のこの包含により、シー
ングラフの構造を変更することなしにシーングラフの中
の情報を変更する方策が提供され、この方策は、極めて
効率的であり、高いパフォーマンスのモデルを提供す
る。一般に、可変値は、シーングラフ構造を再構成する
必要なしにシーン記述のいくつかの態様を変更し、また
別の形で制御するシーングラフの中へのフックをユーザ
に提供する。例えば、ユーザは、マウスクリックのよう
なアプリケーションイベントに反応してボタンのカラー
を変更することができ、かつ/またはオンデマンドで、
または時間とともにイメージの外観および/または位置
を変更することができる。したがって、可変値はまた、
アニメーションをシーングラフと結合する。

【００７８】また、通常のシーングラフを抽象化の概念
で拡張し、これにより、例えば、様々なパラメータ値で
シーングラフの部分を再使用するのを可能にするパラメ
ータ設定されたグラフコンテナ524(図5)も提供される。
言い換えれば、パラメータ設定されたグラフコンテナに
より、一般的な仕方で再使用するためにシーングラフを
テンプレート化することが可能になる。アプライノード
525、526が、値変更メカニズム(例えば、アニメータお
よび/または手動で制御されるプロセス)527、528によっ
て命令されるとおり、パラメータを制御する。

【００７９】上記に説明し、上述した係属米国特許出願
「Multiple-Level Graphics Processing System and Me
thod」(弁護士整理番号第3140号)に記載されているとお
り、ドローイングコンテキストと呼ばれる一時的オブジ
ェクトを使用してシーングラフ構造を構成することがで
きる。以下のテーブル(C#様の擬似コードで書かれた)
が、例としてのドローイングコンテキストを提供してい
る(ただし、本明細書の例は、単純化された例であり、
以下に説明するとおり可変値の使用を可能にする実際の
APIではないことに留意されたい)。

【００８０】

【表１】

【００８１】ドローイングコンテキストは、通常、以下
のテーブルの例に記載されるとおり、GraphContainer構
造に対してOpen()関数を呼び出すことによってGraphCon
tainerから獲得される。

【００８２】

【表２】

【００８３】シーングラフを構成する1つの可能なやり
方であるドローイングコンテキスト動作は、以下の例の
テーブルに記載されるとおり、グラフコンテナを分布す
るのに使用される。

【００８４】

【表３】

【００８５】前述したとおり、好ましくは、トランザク
ション様のモデルを提供し、例えば、「dv.Close();」
関数を介して開かれたコンテナが閉じられるまで、動作
が行われないようする。この目的で、前述したインテリ
ジェントキャッシュにより、中間シーンのレンダリング
が行われることなしに、シーングラフ構造を構成し、変
更するトランザクションシステムが提供される。アニメ
ートされた値の変更をグラフ変更と同期させるため、ア
ニメートされた値に対する変更も、同様に扱われる。つ
まり、変更待ち行列418(図4)またはそれと等価のものを
介してアニメートされた値に対する変更を送ることによ
って扱われる。非同期式の構成は、可能な1つの解決策
に過ぎないことに留意されたい。例えば、シーングラフ
は、変更中にシーングラフをロックすることによって同
期式に構成することも可能である。これは、更新が余り
にも遅い場合、不規則なアニメーションまたは不規則な
再ドローイングの問題につながる可能性があるが、構造
上の解体が防止される。

【００８６】したがって、可変値は、シーングラフの中
の変更可能なエンティティをフックする手段をユーザに
提供する。可変値の構成により、アニメーションをシス
テムに結合することが可能になる。

【００８７】可変値自体は、以下の例としてのテーブル
に記載されるとおり、プログラマブルエンティティ(抽
象クラスなどの)である。

【００８８】

【表４】

【００８９】MutableValueは、可変値オブジェクトの現
行の値を戻すGetValueを含む関数を提供する。この関数
は、各サブクラスによってオーバーライドされる必要が
ある。関数GetTypeを使用して可変値の中に記憶された
現行の値のタイプ(例えば、パラメータがカラーを表す
ことを示す)が判定され、このタイプは、特定の可変値
の構成中に決定され、一実施形態では、変更することが
できない。あらゆる導出されたクラスは、APIを介して
アクセスされる可変値コンストラクタを呼び出し、可変
値のタイプを渡し、これにより、コンストラクタが、可
変値のタイプをプライベートタイプフィールドの中に記
憶する。

【００９０】アニメートされた値は、ユーザが作成する
ことができるある種の可変値の一例である。アニメート
された値は、あらゆるドローイング動作で使用すること
ができる。呼出しコードは、アニメートされた値(例え
ば、AnimatedColor)のインスタンスを、単にそれを構成
することによって作成する。このようにして、プリミテ
ィブAPI(例えば、DrawLine)は、タイプセーフである。
構成中、アニメーション値が時間とともに値をどのよう
に変化させるかを記述するアニメーションフラグメント
が、コンストラクタAPIに渡される。その他の種類の可
変値、例えば、定数値をカプセル化する(したがって、
実際には可変でなく、APIをより簡単にする)StaticMuta
bleValueを作成することもできる。また、表現のため、
より高レベルのシステムに結合するため、またテンプレ
ート化で使用するための可変値も存在する。

【００９１】以下は、アニメーションシステムを説明す
る一般的な例である(ただし、実際のAPIではない)。こ
のアニメーションシステムは、本発明にとって必須では
ないが、このアニメーションシステムとともに機能する
ようにパラメータ設定されたシーングラフの実施形態が
構成されるため、本明細書で説明していることに留意さ
れたい。

【００９２】

【表５】

【００９３】以下の例は、シーングラフの中でどのよう
にAnimatedValueを使用することができるかを示してい
る。

【００９４】

【表６】

【００９５】AnimatedValueは、一般に、基本値、およ
びアニメーションフラグメントのリストを含む。基本値
をアニメーションフラグメントの出力と結合して、パラ
メータ設定されたシーングラフに渡され、それを通過す
る最終値がもたらされる。フラグメントは、これを実行
するのが可能な1つのやり方に過ぎないことに留意され
たい。

【００９６】「Set」関数を使用して、アニメートされ
た値を新しいアニメーションフラグメントに設定するこ
とができる。アニメーションフラグメントは、一定であ
ることが可能な特定タイプ(例えば、カラー)の値をある
やり方でアニメートするオブジェクトと見なすことがで
きる。アニメーション値に定数を設定するため、呼出し
コードが、不変アニメーションフラグメントを、例え
ば、レッドは、常に値レッドを有するため、不変カラー
アニメーションフラグメントを使用する。アニメーショ
ンフラグメントを結合できるようにする、アニメートさ
れた値に関するより高度な関数を提供することも可能で
ある。

【００９７】このようにして、ユーザは、いつでもAnim
atedValueを、例えば、av.Set(newColorAnimationFragm
ent);を変更することができる。

【００９８】図6に一般的に示すとおり、アニメートさ
れた値600が、特定のグラフコンテナ602を分布するのに
初めて使用されたとき、そのアニメートされた値600に
対するリファレンス604が、パラメータ設定された命令
ストリーム606の中のコンテナ602の中に(またはコンテ
ナ602に関連して)記憶される。このリファレンスは、サ
ブグラフが一定であるかどうか、すなわち、アニメート
された値が、ある期間中、変化しないかどうかを判定す
るのに使用される。1つの現行の実施形態では、このリ
ファレンスは、以下に説明するとおり、値をルックアッ
プするのにも使用され、例えば、命令の中のリファレン
スが、負の数、またはその他の適切なフラグで表される
ことが可能である。また、リファレンスは、アニメート
された値の存続時間を管理するのに使用することもでき
る。さらに、次にサブグラフが一定であるという情報を
使用して、以下に一般的に説明するとおり、レンダリン
グプロセスを最適化することができる。不変のサブグラ
フには、そのサブグラフの中に可変値を全く有していな
いこと、またはアニメートされた仕方で変化する可変値
を全く有していないことが含まれる可能性がある。

【００９９】理解されるとおり、可変(アニメートされ
た)値は、グラフ構造の部分を作成しなおすことなしに
シーングラフに対する変更を行うため、シーングラフの
中にフックを挿入するための汎用メカニズムである。ア
ニメートされた値を介してシーングラフをアニメートす
ることにより、シーングラフとアニメーションエンジン
610の間の明確な分離が提供される。これは、シーング
ラフ変更が非同期式に行われるシステムで特に有益であ
る。その理由は、可変値を使用して、アニメーション結
合に対する変更をシーングラフ構造に対する変更と同期
させることができるからである。

【０１００】図7は、パラメータ設定された命令の1つの
例としての実施形態を示している。前述したとおり、ド
ローイングコンテキスト上のプリミティブドローイング
動作が、パラメータ設定された命令700を作成し、この
命令をドローイングコンテキスト(例えば、図4のドロー
イングコンテキスト416)において現在、開かれている命
令ストリームに追加する。命令700は、メモリの中のデ
ータを含み、2つの部分、ヘッダ702および本文704に論
理式に分離されていると見なすことができる。

【０１０１】図7に示すとおり、ヘッダ702は、ビットフ
ィールドを介して、パラメータ設定された命令のタイ
プ、および引数のどれがパラメータ設定されるかを指定
する。図7の例は、「ドローライン」タイプフィールド7
06、およびパラメータ記述子フィールド708で示される
とおり、パラメータ設定されたドローライン命令を示し
ている。パラメータ記述子フィールド708の中で、「100
0」2進数の中の「1」ビットが、パラメータリファレン
スフィールド710の中の命令に対する第1のパラメータ
(カラーを記述する)がパラメータ設定され、したがっ
て、レンダリング時に必要とされる場合、他の場所から
獲得される必要のある値を有することを示す。本文704
の中で、フィールドが、ヘッダの中のビットフィールド
を介して可変ではなく、一定であると定義されている場
合、その定数が、命令700の中に直接に記憶される。し
たがって、呼出しプログラムコード(例えば、アプリケ
ーション)によって一定であると定義されたラインの開
始点および終了点、ならびに幅を表すその他のフィール
ド711-713は、事前にインスタンス化された命令700の本
文704の中に記憶される。

【０１０２】パラメータが一定でない(例えば、前述し
たStaticMutableValue、またはConstantValue)場合に
は、定数の変わりにパラメータプレースホルダが記憶さ
れる。このパラメータプレースホルダは、サブグラフに
ローカルな可変値のテーブルに対する索引を参照するこ
とが可能な間接表現、可変値のよりグローバルな範囲の
テーブルに対する索引、または、場合により、可変値に
対する直接のリファレンスである。例えば、DrawLine命
令の中のMutableValueに定数を渡すため、このタイプ
は、常に一定である値を識別する。

【０１０３】一実施形態では、2つのタイプのパラメー
タプレースホルダに、アニメートされた値に関するプレ
ースホルダ、およびパラメータリファレンスに関するプ
レースホルダが含まれる。この実施形態では、異なる種
類のプレースホルダを区別するため、アニメートされた
値に関して負の数を使用し、パラメータリファレンスに
関して正の数を使用することができる。ただし、その他
のやり方(例えば、フラグなどの別個の指示子)で区別を
行うことも可能である。

【０１０４】命令をレンダリングするレンダリングプロ
セスの一環として、パラメータ設定された命令が、各パ
ラメータプレースホルダに関する実際の値とともにイン
スタンス化される。例えば、インスタンス化された命令
700_iで表されるとおり(インスタンス化された場合、様
々なラベルが、添え字「i」とともに示される)、レンダ
リング中、フィールド710の中のパラメータ設定された
命令が、フィールド710 _iの中の定数値にインスタンス化
される。完全にインスタンス化された命令700_iが、レン
ダリング中、より低いレベル、つまりデバイスに渡され
る。これは比較的直接的なインスタンス化であり、より
複雑な処理を含む可能性があることに留意されたい。

【０１０５】パラメータ設定された命令をインスタンス
化するため、プレースホルダのための値を取得するメソ
ッドが提供される。1つのメソッドは、アニメートされ
た値に関する。このメソッドでは、直接の親のグラフコ
ンテナの中で対応するアニメートされた値がルックアッ
プされる。負の数が使用されるため(パラメータリファ
レンスから区別するため、索引の負数が命令の中に記憶
される)、記憶されたアニメートされた可変値を識別す
るのに絶対値が使用される。言い換えれば、アニメート
された値でドローイングコンテキストに対してドローイ
ング動作が使用される場合、そのアニメートされた値に
対するリファレンスが、親グラフコンテナによって参照
されるテーブルの中に記憶される。次に、そのアニメー
トされた値に関するこのテーブルへの索引が、命令の中
に記憶される。負の数および正の数がプレースホルダを
区別する実施形態では、値が負である場合、その値を親
コンテナのテーブルの中でルックアップすることができ
るのことが示される。例えば、アニメートされた値を探
し出すためにその数がルックアップされ、実際の値を探
し出すためにそのアニメートされた値がルックアップさ
れる(ただし、そのような二重のルックアップなしに値
を探し出す他のやり方も実施することが可能である)。
テーブルの中のどの特定の可変値に対しても1つだけの
リファレンスが存在するように、このテーブルを最適化
するのに使用することができるメソッドが存在すること
に留意されたい。

【０１０６】パラメータリファレンス(例えば、1つの現
行の実施形態で正の整数として記憶される)の場合、レ
ンダリングに関連して以下に説明するとおり、その値
は、評価スタックフレームの中でルックアップされる。
現在、このルックアップは、アレイの中におけるパラメ
ータリファレンス索引の位置での単なるルックアップで
あることに留意されたい。本例の場合、索引は、フィー
ルド710で示される位置二(2)を示す。さらに、命令をイ
ンスタンス化する際に使用することができる複数のテー
ブルが存在する可能性があるため、パラメータ設定され
た命令の中の他のデータを使用して、どのテーブルを使
用するかを指定するのが可能であることに留意された
い。例えば、値を選択することができる複数のテーブル
が存在する場合、ビットフィールド/列挙を使用して、
その索引がどのテーブルに適用されるかを指定すること
ができる。

【０１０７】パラメータ設定されたプリミティブ命令に
加えて、変更可能なエンティティを命令ストリームの中
にフックするという概念を変換コンテナ、ならびに不透
明度、カラー、およびフィルタ、展開、イメージ処理、
セピアトーン、その他などの他の多数の特殊効果を変更
するものなどのその他のコンテナを含め、シーングラフ
プリミティブに適用することができる。例えば、変換コ
ンテナは、オフセット、回転の角、サイズ、および/ま
たはその他の仕方を含む何らかの仕方で以下のサブグラ
フの位置/座標を変換する。位置の変化とは、スクリー
ン上の場所の変化を指すことが可能であるが、回転の
角、サイズを変化させることなどの概念、および/また
は何らかの1つまたは複数の座標を変化させる実質的に
あらゆる関数を含むのも可能であることに留意された
い。可変変換コンテナは、以下のとおりであることが可
能である(ただし、このクラスは、内部のものである)。

【０１０８】

【表７】

【０１０９】以下の例は、可変変換をどのように使用す
るかを示している。

【０１１０】

【表８】

【０１１１】変換アニメーションフラグメントを介して
パラメータ設定された変換コンテナをアニメートする、
すなわち、時間とともに何らかの仕方で座標および/ま
たはその他のデータを変換することにより、変換コンテ
ナの下のサブグラフの中の内容に動きを与えることがで
きる。

【０１１２】定数値オブジェクトを使用して定数を可変
値に変換して、前述したとおり、アニメートされた値ま
たはリファレンスパラメータが扱われるのと同じ仕方で
定数が内部で扱われるのが可能であるようにする。ま
た、これは、ユーザが定数を渡すことができる最新プロ
グラミング言語(例えば、C#)の機能を活用することによ
って関数を単純化する。以下のテーブルでは、Constant
Valueが、ユーザが単にDrawLine(新しいAnimatedColorV
alue(...)、新しいPoint2D(10,10)、...)を呼び出すこ
とができるようにする暗黙のコンバータであることに留
意されたい。

【０１１３】

【表９】

【０１１４】ドローイングコンテキスト上のドローライ
ン関数を変更して可変値を引数として取ることができ
る。

【０１１５】

【表１０】

【０１１６】前述した関数は、プロトタイプをパブリッ
クボイドDrawLine(MutableColorValue、MutablePoint2D
Value、...)に変更することにより、強くタイプ付けさ
れたものになることが可能であることに留意されたい。
内部タイプ検査が、コンパイル時間中にコンパイラによ
って統計的に行われるために必要ない最新のプログラミ
ング言語のタイプシステムを活用することができる。ま
た、これにより、可変値クラス階層が変更され、例え
ば、1つの可変値の代わりに、NutableColorValueなどの
複数の形式Mutable<TYPE>Valueが存在するのが可能であ
ることに留意されたい。

【０１１７】本発明の別の態様によれば、図8は、パラ
メータ設定されたグラフコンテナを使用する例としての
シーングラフ800を示している。図8のルートコンテナ80
2は、2つの子を有する通常のグラフコンテナである。ル
ートコンテナの左の子は、パラメータ設定されたグラフ
コンテナ806をルートコンテナ800に接続するアプライノ
ード804と呼ばれる。図8に示す例では、パラメータ設定
されたグラフコンテナ806は、カラータイプの1つの引数
(テーブル807に示す)に対してパラメータ設定される。
カラータイプは、簡明にするために選択しており、実際
の実施の際には、何らかの種類のブラシタイプまたは距
離測定などのその他のタイプを代わりに使用することが
可能であることに留意されたい。

【０１１８】パラメータ設定されたグラフコンテナ806
の下のサブグラフ810は、パラメータ設定されたグラフ
コンテナ806のカラーパラメータ807を参照することが可
能である。例えば、サブグラフは、棒線画などの形状を
記述することが可能である。棒線画の胴体部分に関する
カラーを定義する変わりに、その棒線画を描くのに使用
される命令が、パラメータ設定されたグラフコンテナ80
6のカラーパラメータ807を参照する。

【０１１９】前述したとおり、棒線画を記述するパラメ
ータ設定された命令は、パラメータ設定された命令スト
リーム812-814の中に記憶される。命令ストリームは、
前述したとおり、パラメータリファレンスを含む。

【０１２０】パラメータ設定されたグラフコンテナは、
基本的に、拡張されたグラフコンテナである。ただし、
通常のグラフコンテナの機能に加えて、パラメータ設定
されたグラフコンテナは、各パラメータに関してタイプ
情報を記憶し、また、そのパラメータに対するアクセス
関数も提供する。パラメータアクセス関数を使用して、
パラメータ設定されたグラフコンテナのパラメータに対
するリファレンスを獲得し、このリファレンスが、任意
のプリミティブドローイング動作に渡されることが可能
である。パラメータ設定されたグラフコンテナの実施形
態は、通常のグラフコンテナから導出するのが可能であ
ることに留意されたい。

【０１２１】一実施形態では、パラメータ設定されたグ
ラフコンテナクラスは、以下のとおり構成される。

【０１２２】

【表１１】

【０１２３】パラメータ設定されたグラフコンテナを作
成するため、パラメータ設定されたグラフコンテナタイ
プの新しいオブジェクトが作成される。一実施形態で
は、パラメータ設定されたグラフコンテナコンストラク
タにParameterType値のアレイを渡すことにより、任意
の数のパラメータを使用してパラメータ設定されたグラ
フコンテナを作成することができる。ParameterType
は、パラメータ設定されたグラフコンテナの各パラメー
タに関する予期される引数タイプを指定する。

【０１２４】図9のシーングラフ900の例(上部の)は、以
下の適切な作成コマンドを介するなどの、3つの引数を
使用したパラメータ設定されたグラフコンテナ902の作
成を示している。 PGC PGC = new PGC(new ParameterType[] {Color, Poin
t, Float});

【０１２５】図9で見ることができるとおり、パラメー
タ設定されたグラフコンテナ902は、第1の引数としてカ
ラーを、第2の引数としてポイントを、また第3の引数と
してフロートを予期する。引数タイプは、通常、パラメ
ータ記述子テーブル904の中のパラメータ設定されたグ
ラフコンテナ(ノード)902内部に記憶される(ただし、明
確にするため、その他の図と同様に、テーブル904は、
図9のコンテナの外部にあるものとして示している)。パ
ラメータ記述子テーブル904の中に記憶されたタイプ情
報は、タイプ検査のために使用することができる。

【０１２６】パラメータのタイプは、以下のParameterT
ype列挙を介して特定することができる。

【０１２７】

【表１２】

【０１２８】パラメータ設定されたグラフコンテナ上の
パラメータを参照するため、パラメータ設定されたグラ
フコンテナ上のGetParameter関数を使用することができ
る。GetParameter関数は、可変値のインスタンスを戻
す。その可変値は、対応するパラメータを参照するのに
どのドローイング動作でも使用することができる。タイ
プ付けされた可変値が使用される場合、複数のGet<TYPE
>Parameter関数(例えば、GetColorParameter、これはMu
tableColorValueを戻す)、各タイプごとに1つの関数、
またはユーザアプリケーションがアクセスするオブジェ
クトを戻す1つの汎用関数が存在することになることに
留意されたい。各タイプごとに1つの関数を有すること
が、確認の点から好ましい。

【０１２９】パラメータは、索引を介してアドレス指定
される。例えば、図9の例に示すとおり、カラーパラメ
ータは、一(1)という索引を有し、ポイントパラメータ
は、二(2)という索引を有し、またフロートパラメータ
は、三(3)という索引を有する。したがって、以下の例
は、図9のパラメータ設定されたグラフコンテナの「ポ
イント」パラメータを記述するMutableValueのインスタ
ンスを戻す。 PGC.GetParameter(2);

【０１３０】内部で、GetParameter関数が、MutableVal
ueから導出されるParameterReferenceを作成する。

【０１３１】

【表１３】

【０１３２】この場合も、タイプ付けされた実施形態で
は、このクラスのタイプ付けされたバージョン、例え
ば、ColorParameterReference等が存在するのが可能で
あることに留意されたい。このタイプ付けされたバージ
ョンは、MutableColorValue等から継承を行うことにな
る。また、このバージョンは、可変クラスの別の例であ
ることに留意されたい。ただし、このバージョンは、内
部でだけ公開され、ユーザには見えない。

【０１３３】コンストラクタAPIが、パラメータ索引を
取ってそれを記憶する。パラメータ索引は、スタックフ
レーム上の現行の値をルックアップするのに使用され、
GetValue()関数が、パラメータ索引を戻す。このパラメ
ータを所有するパラメータ設定されたグラフコンテナに
対するリファレンスを使用して、そのパラメータ設定さ
れたグラフコンテナのサブグラフの中でだけそのパラメ
ータが使用されているのを確認することができる。

【０１３４】パラメータ設定されたグラフコンテナを分
布するため、通常のグラフコンテナに関して使用される
のと同じOpen/Closeトランザクションスキームが適用さ
れる。ただし、クライアントアプリケーションの用件に
応じて、これを調整することができる。Openコールは、
以下のとおり、通常のグラフコンテナに対するOpenコー
ルから戻されるのと同じドローイングコンテキストを戻
す。

【０１３５】

【表１４】

【０１３６】不変の引数またはアニメートされた値に加
えて、パラメータリファレンスをドローイング動作に渡
すことができる。

【０１３７】

【表１５】

【０１３８】この場合も、強くタイプ付けされた関数を
使用する実施形態では、Get<TYPE>Parameter、例えば、
GetColorParameterなどのタイプ付けされた関数が使用
される。

【０１３９】ルートコンテナをパラメータ設定されたグ
ラフコンテナ806と接続するアプライノードが、パラメ
ータ設定されたグラフコンテナ806に第1のパラメータの
ための値を提供する。類推により、パラメータ設定され
たグラフコンテナが関数またはサブルーチンとして定義
される場合、アプライノードは、パラメータを提供する
関数コールと見なすことができる。その1つまたは複数
の値を提供するため、アプライノードは、以下のとお
り、DrawContainer関数に渡される各引数のテーブル805
を含む。

【０１４０】

【表１６】

【０１４１】レンダリングパス中、valueDescriptorが
評価され、その結果がスタックフレーム上にプッシュさ
れる。図8に示した例では、アプライノード804は、カラ
ー、レッドをパラメータ設定されたグラフコンテナ806
に渡す。

【０１４２】本発明に従い、パラメータを提供する別個
のノードを有することにより、パラメータ設定されたグ
ラフコンテナ806をパラメータとして異なる値を使用し
て再使用することが可能となる。図8の例では、第2のア
プライノード816は、テーブル817からのカラー、グリー
ンを棒線画に関するパラメータ設定されたグラフコンテ
ナ806に渡す。図8の例としてのシーングラフのレンダリ
ング結果は、第1の場所における第1のレッドの棒線画、
および第2のロケーションにおける第2のグリーンの棒線
画である。変換ノード818は、アプライノード816がレン
ダリングされたとき、サブグラフの座標を変換し、第1
の場所ではなく、第2の場所において第2の棒線画の表示
を生じさせることに留意されたい。容易に理解されると
おり、そのような変更は、その他の変更とともにバッチ
処理することができ、したがって、例えば、数千のその
ような棒線画が、同時にカラー(または形状、サイズ、
位置、その他)を変更することが可能である。ノード818
は、別法では、表示されるイメージの不透明度を変更す
るアルファノード、またはイメージに対して特殊効果等
を提供する効果ノードなどの何らかの他のタイプのノー
ドであるのが可能であることに留意されたい。

【０１４３】図9は(全体として)、変換コンテナ906、お
よびパラメータ設定された命令ストリーム908および910
を含む前述の命令を使用して作成されたグラフを示して
いる。パラメータ設定されたストリーム910からパラメ
ータ記述子テーブル904への曲線の矢印が、パラメータ
設定されたグラフコンテナの第1のパラメータ(カラーフ
ィールド)を参照するドローライン命令を表している。

【０１４４】図9のモデルでは、親連鎖の中の隣接する
パラメータ設定されたグラフコンテナ902だけを参照す
るのが可能であることに留意されたい。ただし、親連鎖
の中の任意のパラメータ設定されたグラフコンテナの任
意のパラメータを参照するようにモデルを拡張するのは
簡単である。例えば、一実施形態は、参照されるパラメ
ータ設定されたグラフコンテナに対するポインタを単に
記憶することが可能である。ただし、そのようなモデル
では、パラメータリファレンスが正しく使用されている
かどうかを判定する確認は、グラフ構成段階中に幾分の
確認を行うことができないため、実施するのがそれほど
簡単ではない。それでも、効率的な確認アルゴリズムを
実装するのは簡単である。

【０１４５】ドローイングコンテキスト上でGraphConta
inerを呼び出すことによってパラメータ設定されたグラ
フコンテナをシーングラフに追加することができる。以
下の例としての擬似コードは、図9の例に示されるパラ
メータ設定されたグラフコンテナ902をどのように変換
コンテナの下のシーングラフに追加できるかを示してい
る。

【０１４６】

【表１７】

【０１４７】図10は、サンプルコードの結果のシーング
ラフ1000を示している。図10では、ルートコンテナ1002
が、変換コンテナ1004の親である。アプライノード1006
が、変換コンテナ1004とパラメータ設定されたグラフコ
ンテナ902の間に存在して、パラメータ記述子テーブル9
04によって確認されるとおり、引数のテーブル1008の中
の実際の値をパラメータ設定されたグラフコンテナのパ
ラメータに適用している。

【０１４８】また、パラメータ設定されたグラフコンテ
ナのリファレンスパラメータが、以下のとおり、別のパ
ラメータ設定されたグラフコンテナに渡されることも可
能である。

【０１４９】

【表１８】

【０１５０】ドローイングコンテキスト上のDrawContai
ner関数は、以下のとおりタイプ付けすることができ
る。 public void DrawContainer(GraphContainer, params MutableValue[] parameters); 前述したとおり、高レベルのエンジンが、レンダリング
パスを行い、レンダリングパスは、基本的に、シーング
ラフ上のウォークを含む。パラメータ設定されたシーン
グラフをレンダリングするため、評価スタックフレーム
が維持される。レンダリングパスの開始時には、評価ス
タックフレームは空である。

【０１５１】レンダリングパスは、アプライノードに到
達するたびに毎回、アプライノードの中の値記述子テー
ブルと同じサイズを有する新しいスタックフレームを作
成する。この評価スタックフレームが、評価スタック上
にプッシュされる。次に、アプライノードの値記述子テ
ーブルの各エントリに関して、その値が評価され、アプ
ライノードの中の値記述子テーブルの中で値記述子が有
していたのと同じ位置でスタックフレーム上に記憶され
る。

【０１５２】前述したとおり、現在、各値記述子テーブ
ルエントリに関する値が取得される2つの異なるインス
タンスが存在する。すなわち、パラメータリファレンス
に関するインスタンス、および可変値に関するインスタ
ンスである。パラメータリファレンスの場合、値は、パ
ラメータリファレンスの中に記憶されたパラメータ索引
において上から第2番の評価スタックフレーム上でルッ
クアップされる。パラメータ索引は、パラメータリファ
レンス上でGetValueを呼び出すことによって取得するこ
とができる。可変値の場合、その定数が、定数値として
記憶される。

【０１５３】本発明に従い、高レベルのエンジンのイン
テリジェントキャッシングメカニズムが、レンダリング
のために必要とされるプロセッサ時間およびメモリ(特
にビデオメモリ)を一般的に含むリソースの消費を抑え
る様々なメカニズムを使用するのを試みることが可能で
ある。また、パラメータ設定されたシーングラフをイン
テリジェントキャッシングメカニズムのキャッシングメ
カニズムとともに使用することも可能である。この目的
で、例えば、インテリジェントキャッシングメカニズム
が、サブグラフが不変であることを認識し、これによ
り、インテリジェントキャッシングメカニズムは、サブ
グラフをビットマップとしてレンダリングすることがで
き、次に、このビットマップがキャッシュに入れられ、
再使用されることが可能である。別の例として、テンプ
レート化されたサブグラフの同様の使用法が、同じキャ
ッシュを使用することが可能である。キャッシュは、解
像度依存であるが、必ずしもカラー依存ではないスティ
ックマンなどのイメージのタイル張りとしても使用する
のが可能であることに留意されたい。一般に、パラメー
タ設定されたシーングラフをほとんど変更することな
く、キャッシングメカニズムのほとんどを適用すること
も可能である。

【０１５４】システムを拡張する1つのやり方は、以下
のとおり、表現エンジンを使用し、表現をシステムの中
に結合する別の可変値を導入することである。

【０１５５】

【表１９】

【０１５６】GetValueコールが、表現を戻す。レンダリ
ング中、この表現が、現行のコンテキストの中で評価さ
れる。表現が複数回、使用される場合、レンダリングパ
ス中に変更が許されない限り、表現の評価をその表現自
体の上にキャッシングすることができる。

【０１５７】パラメータ設定されたシーングラフの中で
ヒット試験を提供する1つの方策は、レンダリングアル
ゴリズムと同様の仕方でパラメータ設定を追跡すること
である。パラメータ設定は、サブグラフの再使用のイン
スタンスごとにヒット試験を制御できるように拡張する
ことが可能である。この目的で、パラメータ設定された
グラフコンテナを有するシーングラフの中で、一実施形
態では、ヒット試験は、何にヒットしたかを一意的に特
定するため、ルートからグラフコンテナに至るパス全体
を戻す必要がある。代替の実施形態では、ヒット試験ノ
ードおよびヒット試験識別子の使用によってこれを回避
することができる。パラメータ設定されたコンテナは、
ヒット試験識別子を介して、すなわち、MutableTransfo
rmContainerと同様のMutableHitTestContainerを介して
パラメータ設定するのが可能であることに留意された
い。

【０１５８】図11の例としてのシーングラフ1100におい
て一般的に示されるとおり、システムは、ヒット試験識
別子を介してパラメータ設定される特別ヒット試験ノー
ド1120を使用して拡張することができる。この結果、パ
ラメータ設定されたサブグラフのすべての使用法が、ヒ
ット試験識別子を介するパラメータ設定を使用すること
により、異なる識別子を使用することが可能である。図
11に示す例では、親コンテナ1102が、自らの下に2つの
コンテナノード、Node0(1104)およびNode1(1106)を有す
る。これらのノードのそれぞれは、2つのカラー、2次元
のポイント、およびヒット試験識別子をパラメータ設定
されたグラフコンテナ1116に適用するアプライノード11
08、および1110をそれぞれ有する。例えば、カラーの1
つが、棒線画の頭を表し、別のカラーが、棒線画胴体の
残りの部分を表すことが可能である。

【０１５９】効率的なヒット試験を提供するため、パラ
メータ設定されたグラフコンテナ1116の引数のどれか
は、ヒット試験IDである。ヒット試験ノード1120が、各
ヒット試験IDをノードに関する情報、例えば、ノードの
パス情報または結合情報に関係付けるヒット試験テーブ
ルを維持する。これは、ヒット試験中にグラフのウォー
クが行われる際、必ずしも必要とされない最適化に過ぎ
ないことに留意されたい。このようにして、アプライノ
ードのどれかで現在、構成されているパラメータ設定さ
れたグラフコンテナ1116によって表される内容に関する
情報をヒット試験IDおよび関連する情報に関係付けるこ
とができる。例えば、いくつかの棒線画が同一のサブグ
ラフによって表される場合、前述したパラメータ設定さ
れたグラフコンテナを介して、ヒットするそれぞれの棒
線画を一意的に識別することができる。

【０１６０】したがって、ヒット試験は、一般に、グラ
フの中のノードを一意的に識別することができる必要が
ある。同様に、変換が、サブグラフの再使用との組み合
わせで、ノードの固有識別子を必要とする可能性があ
る。例えば変換が、1つのサブグラフに対して、別のサ
ブグラフ(さらに別のサブグラフとの関係にあることが
可能な)との関係でスケーリング(ファクタによるズー
ム)、オフセット、回転等を行うことが可能である。本
発明の実施形態は、1つの座標空間から別の座標空間に
対する次元、場所、サイズ等の相対値を使用して機能し
て、スクロール、ヒット試験、選択、その他が容易にな
るようにすることが可能である。ただし、シーングラフ
の中で再使用が存在する場合、再使用されるノードのど
のインスタンスが、相対的変換のための基礎として使用
されているかを識別するのに固有識別子が必要とされ
る。1つの解決策は、ルートからサブグラフを通りノー
ドに至るパスを使用してパラメータ設定されたグラフコ
ンテナの1つの使用を特定することである。

【０１６１】また、サブグラフを介するパラメータ設定
を使用してシステムを拡張することも可能である。以下
のMutableValueが、これを可能にする。

【０１６２】

【表２０】

【０１６３】ドローイングコンテキストに以下の関数が
追加される。 DrawGraphContainer(GraphContainerValue, params MutableValue[] parameters);

【０１６４】ドローイング動作が、GraphContainerValu
eに対するリファレンスを記憶する特別アプライノード
を挿入する。アプライノードの子を取ってレンダリング
を継続する代わりに、レンダリングアルゴリズムは、特
別アプライノード上に記憶されたGraphContainerValue
上でGetValueを呼び出すことによって子コンテナを獲得
すること以外、このレンダリングアルゴリズムは、一般
に、通常のアプライノードに関して動作するのと同じよ
うに動作する。

【０１６５】結論 以上の詳細な説明から理解することができるとおり、シ
ーングラフのための汎用パラメータ設定を提供するシス
テム、メソッド、およびアーキテクチャが提供される。
本発明は、パラメータ設定を介して、特定のシーングラ
フインスタンスにおけるリソースの効率的で柔軟性のあ
る再使用を含め、通常のシーングラフに関する多数の利
点を提供する。また、本発明は、レンダリング中にパラ
メータ設定のためにユーザコードを実行する必要性を完
全になくすため、堅牢性も得られる。その他の利益に
は、パラメータ設定が本来的なシーングラフプリミティ
ブとして実施されるので、汎用メソッドを適用してレン
ダリングプロセスを最適化することができるため、キャ
ッシュ整合性が含まれる。また、構造上の変更とパラメ
ータ設定システムを介する変更の区別を含むスケーラブ
ルな変更も、より多くのリソースを消費するが、比較的
稀である構造上の変更に比べて、パラメータ設定変更が
はるかに高速で一般的であるようにグラフィックスシス
テムを最適化することができることで、利益を提供す
る。

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

【図面の簡単な説明】

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

【図２】本発明を組み込むことができるグラフィックス
層アーキテクチャを一般的に示すブロック図である。

【図３】インテリジェントキャッシングデータ構造、お
よび図2におけるようなグラフィックス層アーキテクチ
ャの中の様々な構成要素に対するこのデータ構造の関係
を一般的に示すブロック図である。

【図４】図2などのグラフィックス層における高レベル
合成およびアニメーションエンジンとその他のレベルの
間の、一般的な制御の流れを示すブロック図である。

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

【図６】本発明の一態様によるシーングラフの中のアニ
メートされた値の概念を一般的に示すブロック図であ
る。

【図７】本発明の一態様によるレンダリングを行うため
の定数値にインスタンス化されるパラメータ設定された
命令を示す図である。

【図８】本発明の一態様によるシーングラフの中のパラ
メータ設定されたグラフコンテナの概念および使用法を
一般的に示すブロック図である。

【図９】本発明の一態様によるシーングラフの中のパラ
メータ設定されたグラフコンテナの概念および使用法を
一般的に示すブロック図である。

【図１０】本発明の一態様に従ってパラメータ設定され
たグラフコンテナをシーングラフに追加することを一般
的に示すブロック図である。

【図１１】本発明の一態様によるシーングラフの中のヒ
ット試験可能なパラメータ設定されたグラフコンテナを
一般的に示すブロック図である。

【符号の説明】

100 計算環境、オペレーティング環境 110 コンピュータ 120 処理装置 121 システムバス 130 システムメモリ 131 リードオンリーメモリ(ROM) 132 ランダムアクセスメモリ(RAM) 133 基本入出力システム(BIOS) 134、144 オペレーティングシステム 135、145、185、202 アプリケーションプログラム 136、146 プログラムモジュール 137、147 プログラムデータ 140、150、160 インターフェイス 141 ハードディスクドライブ 151 磁気ディスクドライブ 152 磁気ディスク 156 光学ディスク 161 ポインティングデバイス 162 キーボード 163 マイクロホン 164 タブレット 170 アダプタ 171 ローカルエリアネットワーク(LAN) 172 モデム 173 ワイドエリアネットワーク(WAN) 180 遠隔コンピュータ 181 メモリ記憶装置 190 ビデオインターフェイス 191 モニタ 192 タッチスクリーンインターフェイス 193 タッチスクリーンパネル 194 周辺インターフェイス 195 スピーカ 200 グラフィックス層アーキテクチャ 202 コード、アプリケーション 204 アプリケーションプログラミングインターフェイ
ス(API) 206 高レベル合成およびアニメーションエンジン 208 タイミングおよび合成アニメーション構成要素 210 低レベル合成およびアニメーションエンジン 212 グラフィックスサブシステム、グラフィックスソ
フトウェアおよびハードウェア 220 印刷コード 196、222 プリンタ 226 端末移送サーバ 228 遠隔マシン 300 構造 302 抽象装置 406 変換 410、412 基本ノード 416 描画コンテキスト 418 変更待ち行列 420 ディスプレイマネージャ 422 レンダリングスレッド 500 セグメント 402、404、408、510、512 コンテナ 516 基本要素 604 リファレンス 606 命令ストリーム 710 フィールド 804 アプライノード 900 シーングラフ 902 グラフコンテナ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ゲルハルト エー．シュナイダー アメリカ合衆国 98033 ワシントン州 カークランド 99 プレイス ノースイー スト 11430 ナンバー１ (72)発明者 ジョセフ エス．ベーダ アメリカ合衆国 98103 ワシントン州 シアトル デンスモア アベニュー ノー ス 3819 (72)発明者 アダム エム．スミス アメリカ合衆国 98033 ワシントン州 カークランド ノースイースト 92 スト リート 12310 ナンバー205 (72)発明者 ケビン ティー．ギャロ アメリカ合衆国 98072 ワシントン州 ウッディンビル 222 ウェイ ノースイ ースト 19235 (72)発明者 アシュラフ マイケル アメリカ合衆国 98052 ワシントン州 レッドモンド ノースイースト 40 スト リート 15606 キュー−363 Ｆターム(参考） 5B050 BA08 EA09 EA24

Claims (79)

【特許請求の範囲】
1. 【請求項１】 コンピュータ環境において、 トラバースされたとき、グラフィックデータを出力する
   ための命令を提供する、変更することが可能な値を有す
   る可変値に少なくとも１つが関連する複数のコンテナを
   含むシーングラフと、 前記シーングラフをトラバースして、前記可変値の現行
   の値に基づくデータを含む前記命令を提供するレンダリ
   ングメカニズムとを含むことを特徴とするシステム。
2. 【請求項２】 前記可変値が、シーングラフ要素のプロ
   パティに対応することを特徴とする請求項１に記載のシ
   ステム。
3. 【請求項３】 前記可変値が、前記コンテナによって少
   なくとも部分的に表される内容の外観の特質に対応する
   ことを特徴とする請求項１に記載のシステム。
4. 【請求項４】 前記可変値が、識別子に対応することを
   特徴とする請求項１に記載のシステム。
5. 【請求項５】 前記識別子が、ヒット試験識別子を含む
   ことを特徴とする請求項４に記載のシステム。
6. 【請求項６】 前記可変値が、前記シーングラフの中で
   表される内容の外観の特質に対応し、前記内容の少なく
   とも１つの他の外観の特質に対応する少なくとも１つの
   定数値をさらに含むことを特徴とする請求項１に記載の
   システム。
7. 【請求項７】 前記可変値が、少なくとも１つのメソッ
   ドを有するオブジェクトを含むことを特徴とする請求項
   １に記載のシステム。
8. 【請求項８】 前記可変値が、前記可変値に関する現行
   の値を戻す第１のメソッドと、前記可変値を引数として
   渡される値に設定する第２のメソッドとを含むことを特
   徴とする請求項７に記載のシステム。
9. 【請求項９】 前記可変値を変更するアプリケーション
   プログラムをさらに含むことを特徴とする請求項１に記
   載のシステム。
10. 【請求項１０】 別の可変値をさらに含み、前記可変値
    および前記別の可変値が、バッチ動作で変更されること
    を特徴とする請求項１に記載のシステム。
11. 【請求項１１】 前記可変値、および前記別の可変値
    が、各可変値に関する前記現行の値を確立する前記レン
    ダリングメカニズムによって処理される変更待ち行列の
    中に各可変値に関する値を入れることにより、バッチ動
    作で変更されることを特徴とする請求項１０に記載のシ
    ステム。
12. 【請求項１２】 前記可変値が、前記シーングラフに対
    する少なくとも１つの構造上の変更と同期で変更される
    ことを特徴とする請求項１に記載のシステム。
13. 【請求項１３】 前記シーングラフが、変数パラメータ
    のタイプを示す少なくとも１つのエントリを備えたテー
    ブルを有するパラメータ設定されたグラフコンテナを含
    むことを特徴とする請求項１に記載のシステム。
14. 【請求項１４】 前記レンダリングメカニズムが、第１
    の動作速度で実行されて低レベルの構成要素に前記命令
    を提供する高レベルの構成要素を含み、前記低レベルの
    構成要素が、第２の動作速度で実行されて、前記命令に
    基づくドローイングコマンドをグラフィックスサブシス
    テムに提供し、かつ前記第２の動作速度が、前記第１の
    動作速度より速く、また前記グラフィックスサブシステ
    ムのフレーム速度に対応することを特徴とする請求項１
    に記載のシステム。
15. 【請求項１５】 コンピュータ環境において、 １組の少なくとも１つの関数を含むインターフェースを
    シーングラフに提供するステップと、 前記インターフェースを介して、前記シーングラフのコ
    ンテナの中に可変値を含める要求を受け取り、そこでは
    前記可変値が、前記インターフェースを介して受け取ら
    れる別の要求によって変更されることが可能な値を有す
    るステップと、および前記シーングラフに対応するグラ
    フィックス命令を提供し、前記シーングラフのレンダリ
    ングを行い、そこでは前記命令が、前記可変値の現行の
    値に基づくデータを含むステップとを含むことを特徴と
    するメソッド。
16. 【請求項１６】 前記可変値の値を変更する要求を受け
    取るステップをさらに有し、前記要求が、前記可変値に
    関する新しい値に対応するデータを含むことを特徴とす
    る請求項１５に記載のメソッド。
17. 【請求項１７】 前記シーングラフをレンダリングする
    ステップが、前記新しい値を前記可変値に適用して、前
    記新しい値が前記現行の値になるようにすることを特徴
    とする請求項１５に記載のメソッド。
18. 【請求項１８】 前記新しい値を待ち行列に入れるステ
    ップをさらに含むことを特徴とする請求項１５に記載の
    メソッド。
19. 【請求項１９】 別の可変値の値を変更する別の要求を
    受け取るステップをさらに有し、そこでは前記別の要求
    が、前記別の可変値に関する別の新しい値に対応するデ
    ータを含み、および前記別の新しい値を待ち行列に入れ
    るステップをさらに有し、前記シーングラフをレンダリ
    ングするステップが、各新しい値を待ち行列から出し
    て、各新しい値をそれぞれの可変値に適用することを特
    徴とする請求項１８に記載のメソッド。
20. 【請求項２０】 前記可変値の現行の値を戻す要求を受
    け取るステップをさらに含むことを特徴とする請求項１
    ５に記載のメソッド。
21. 【請求項２１】 前記レンダリングメカニズムが、第１
    の動作速度で実行されて低レベルの構成要素に前記命令
    を提供する高レベルの構成要素を含み、 前記低レベルの構成要素を第２の動作速度で動作させ
    て、前記命令に基づくドローイングコマンドをグラフィ
    ックスサブシステムに提供するステップをさらに有し、 前記第２の動作速度が、前記第１の動作速度より速く、
    かつ前記グラフィックスサブシステムのフレーム速度に
    対応することを特徴とする請求項１５に記載のメソッ
    ド。
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. 【請求項５９】 各変数に関する第１の実際の値を判定
    するステップが、第１のアプライノードにアクセスする
    ステップを含み、各変数に関する第２の実際の値を判定
    するステップが、第２のアプライノードにアクセスする
    ステップを含むことを特徴とする請求項５６に記載のメ
    ソッド。
60. 【請求項６０】 前記１組の中の１つの変数が位置変数
    に対応し、前記位置変数に関する前記第１の実際の値と
    前記第２の実際の値が相違し、前記命令ストリームが、
    異なる位置を有する前記内容の２つのインスタンスに関
    する命令を含むことを特徴とする請求項５９に記載のメ
    ソッド。
61. 【請求項６１】 前記第１のアプライノードにおいて、
    位置変数に対応する前記１組の中の前記１つの変数の値
    を時間とともに変化させて、前記内容の第１の位置が時
    間とともに変化させるステップをさらに含むことを特徴
    とする請求項６０に記載のメソッド。
62. 【請求項６２】 コンピュータ実行可能命令を有するコ
    ンピュータ可読媒体であって、前記コンピュータ実行可
    能命令は、 自らにコンテナを追加するためのインターフェースを含
    むシーングラフを提供するステップと、 前記シーングラフにパラメータ設定されたグラフコンテ
    ナを追加する要求を受け取り、そこでは前記パラメータ
    設定されたグラフコンテナが、内容を表し、変更するこ
    とが可能な１組の少なくとも１つの変数値に対応するス
    テップと、および前記１組の中の各変数値に関する第１
    の実際の値を判定して、前記命令ストリームの中に各第
    １の実際の値に対応する第１のデータを入れ、および前
    記１組の中の各変数値に関する第２の実際の値を判定し
    て、前記命令ストリームの中に各第２の実際の値に対応
    する第２のデータを入れ、前記シーングラフからの命令
    ストリームのレンダリングを行うステップとを含むこと
    を特徴とするコンピュータ可読媒体。
63. 【請求項６３】 前記テーブルが、前記１組の中の各変
    数値に関するタイプ情報を含むことを特徴とする請求項
    ６２に記載のコンピュータ可読媒体。
64. 【請求項６４】 前記コンピュータ実行可能命令は、各
    第１の実際の値および各第２の実際の値が前記タイプ情
    報にマッチするのを確認するステップをさらに含むこと
    を特徴とする請求項６３に記載のコンピュータ可読媒
    体。
65. 【請求項６５】 各変数に関する第１の実際の値を判定
    するステップが、第１のアプライノードにアクセスする
    ステップを含み、各変数に関する第２の実際の値を判定
    するステップが、第２のアプライノードにアクセスする
    ステップを含むことを特徴とする請求項６２に記載のコ
    ンピュータ可読媒体。
66. 【請求項６６】 前記１組の中の１つの変数が位置変数
    に対応し、前記位置変数に関する前記第１の実際の値と
    前記第２の実際の値が相違し、前記命令ストリームが、
    異なる位置を有する前記内容の２つのインスタンスに関
    する命令を含むことを特徴とする請求項６５に記載のコ
    ンピュータ可読媒体。
67. 【請求項６７】 前記コンピュータ実行可能命令は、前
    記第１のアプライノードにおいて、位置変数に対応する
    前記１組の中の前記１つの変数の値を時間とともに変化
    させて、前記内容の第１の位置が時間とともに変化させ
    るステップをさらに含むことを特徴とする請求項６６に
    記載のメソッド。
68. 【請求項６８】 シーングラフのパラメータ設定された
    命令ストリームの中のグラフィックス命令に対応する命
    令タイプを示す第１のフィールドと、 前記シーングラフのレンダリング時に、前記シーングラ
    フに対応する情報からの定数値を獲得することによって
    前記定数値にインスタンス化されるパラメータ設定され
    た命令に対するプレースホルダをそれぞれが含む少なく
    とも１つのパラメータフィールドとを含むデータ構造を
    記憶していることを特徴とするコンピュータ可読媒体。
69. 【請求項６９】 前記データ構造は、前記シーングラフ
    のレンダリング時に変化しない少なくとも１つの定数フ
    ィールドをさらに含むことを特徴とする請求項６８に記
    載のコンピュータ可読媒体。
70. 【請求項７０】 前記データ構造の中の各パラメータフ
    ィールド、および前記データ構造の中の各定数フィール
    ドを示す情報を含むパラメータ記述子フィールドを前記
    データ構造がさらに含むことを特徴とする請求項６９に
    記載のコンピュータ可読媒体。
71. 【請求項７１】 前記プレースホルダが、アニメートさ
    れた値に対するホルダであり、前記シーングラフに対応
    する情報から前記定数値を獲得する処理が、親グラフコ
    ンテナからの値にアクセスする処理を含むことを特徴と
    する請求項６８に記載のコンピュータ可読媒体。
72. 【請求項７２】 前記プレースホルダが、パラメータリ
    ファレンスに対するホルダであり、前記シーングラフに
    対応する情報から前記定数値を獲得する処理が、パラメ
    ータリファレンス索引に基づいてアクセスを行う処理を
    含むことを特徴とする請求項６８に記載のコンピュータ
    可読媒体。
73. 【請求項７３】 前記プレースホルダの指示子が、前記
    プレースホルダがアニメートされた値に対するホルダで
    あるか、またはパラメータリファレンスに対するホルダ
    であるかが決定されることを特徴とする請求項６８に記
    載のコンピュータ可読媒体。
74. 【請求項７４】 第１のプロセスと第２のプロセスの間
    で通信するためのメソッドであって、 前記第１のプロセスにおいて、自らにコンテナを追加す
    るためのインターフェースを含むシーングラフを提供す
    るステップと、 前記第２のプロセスから、前記シーングラフにパラメー
    タ設定されたグラフコンテナを追加する要求を受け取
    り、前記パラメータ設定されたグラフコンテナが、内容
    を表し、変更することが可能な１組の少なくとも１つの
    変数値に対応するステップと、および前記第１のプロセ
    スにおいて、前記１組の中の各変数値に関する第１の実
    際の値を判定して、前記命令ストリームの中に各第１の
    実際の値に対応する第１のデータを入れ、および前記１
    組の中の各変数値に関する第２の実際の値を判定して、
    前記命令ストリームの中に各第２の実際の値に対応する
    第２のデータを入れ、前記シーングラフからの命令スト
    リームのレンダリングを行うことを含むことを特徴とす
    るメソッド。
75. 【請求項７５】 前記テーブルが、前記１組の中の各変
    数値に関するタイプ情報を含むことを特徴とする請求項
    ７４に記載のメソッド。
76. 【請求項７６】 各第１の実際の値および各第２の実際
    の値が前記タイプ情報にマッチするのを確認することを
    さらに含むことを特徴とする請求項７５に記載のメソッ
    ド。
77. 【請求項７７】 各変数に関する第１の実際の値を判定
    することが、第１のアプライノードにアクセスするステ
    ップをさらに有し、各変数に関する第２の実際の値を判
    定するステップが、第２のアプライノードにアクセスす
    るステップを含むことを特徴とする請求項７４に記載の
    メソッド。
78. 【請求項７８】 前記１組の中の１つの変数が位置変数
    に対応し、前記位置変数に関する前記第１の実際の値と
    前記第２の実際の値が相違し、前記命令ストリームが、
    異なる位置を有する前記内容の２つのインスタンスに関
    する命令を含むことを特徴とする請求項７７に記載のメ
    ソッド。
79. 【請求項７９】 前記第１のアプライノードにおいて、
    位置変数に対応する前記１組の中の前記１つの変数の値
    を時間とともに変化させて、前記内容の第１の位置が時
    間とともに変化するステップをさらに含むことを特徴と
    する請求項７８に記載のメソッド。