JP4374590B2 - シーングラフのための汎用パラメータ設定 - Google Patents
シーングラフのための汎用パラメータ設定 Download PDFInfo
- Publication number
- JP4374590B2 JP4374590B2 JP2002304896A JP2002304896A JP4374590B2 JP 4374590 B2 JP4374590 B2 JP 4374590B2 JP 2002304896 A JP2002304896 A JP 2002304896A JP 2002304896 A JP2002304896 A JP 2002304896A JP 4374590 B2 JP4374590 B2 JP 4374590B2
- Authority
- JP
- Japan
- Prior art keywords
- variable
- value
- container
- graph
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000009877 rendering Methods 0.000 claims description 89
- 238000000034 method Methods 0.000 claims description 54
- 230000006870 function Effects 0.000 claims description 49
- 230000008859 change Effects 0.000 claims description 38
- 230000008569 process Effects 0.000 claims description 36
- 238000012545 processing Methods 0.000 claims description 32
- 230000009466 transformation Effects 0.000 claims description 32
- 238000012360 testing method Methods 0.000 claims description 30
- 238000003860 storage Methods 0.000 claims description 29
- 230000000694 effects Effects 0.000 claims description 15
- 230000010365 information processing Effects 0.000 claims 5
- 230000003796 beauty Effects 0.000 claims 1
- 239000011159 matrix material Substances 0.000 claims 1
- 230000007246 mechanism Effects 0.000 description 16
- 238000010621 bar drawing Methods 0.000 description 13
- 230000008901 benefit Effects 0.000 description 12
- 238000010586 diagram Methods 0.000 description 11
- 239000012634 fragment Substances 0.000 description 10
- 230000015572 biosynthetic process Effects 0.000 description 8
- 238000003786 synthesis reaction Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 238000011156 evaluation Methods 0.000 description 7
- 238000004422 calculation algorithm Methods 0.000 description 6
- 238000006243 chemical reaction Methods 0.000 description 6
- 230000003287 optical effect Effects 0.000 description 6
- 230000000007 visual effect Effects 0.000 description 6
- 230000002093 peripheral effect Effects 0.000 description 5
- 238000007781 pre-processing Methods 0.000 description 5
- 238000000844 transformation Methods 0.000 description 5
- 238000010276 construction Methods 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 4
- 230000005055 memory storage Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 239000003086 colorant Substances 0.000 description 3
- 230000006855 networking Effects 0.000 description 3
- 238000005457 optimization Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 230000001788 irregular Effects 0.000 description 2
- 239000000203 mixture Substances 0.000 description 2
- 239000003973 paint Substances 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000004513 sizing Methods 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 239000011800 void material Substances 0.000 description 2
- CDFKCKUONRRKJD-UHFFFAOYSA-N 1-(3-chlorophenoxy)-3-[2-[[3-(3-chlorophenoxy)-2-hydroxypropyl]amino]ethylamino]propan-2-ol;methanesulfonic acid Chemical compound CS(O)(=O)=O.CS(O)(=O)=O.C=1C=CC(Cl)=CC=1OCC(O)CNCCNCC(O)COC1=CC=CC(Cl)=C1 CDFKCKUONRRKJD-UHFFFAOYSA-N 0.000 description 1
- 241000238370 Sepia Species 0.000 description 1
- 208000003028 Stuttering Diseases 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000005094 computer simulation Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000008014 freezing Effects 0.000 description 1
- 238000007710 freezing Methods 0.000 description 1
- 230000001771 impaired effect Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000003340 mental effect Effects 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
- G06T17/005—Tree description, e.g. octree, quadtree
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T2210/00—Indexing scheme for image generation or computer graphics
- G06T2210/61—Scene description
Landscapes
- Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Computer Graphics (AREA)
- Geometry (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Processing Or Creating Images (AREA)
- Image Generation (AREA)
Description
【０００１】
本発明は、米国仮特許出願第60/330,231号(2001年10月18日出願)への優先権を請求する。本発明は、係属米国特許出願「Multiple-Level Graphics Processing System and Method」(弁護士整理番号第3140号)および係属米国特許出願「Intelligent Caching Data Structure 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 Architecture)(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、およびプログラムデータ137と同じまたは異なるもののどちらでもあり得ることに留意されたい。オペレーティングシステム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に示す論理接続は、ローカルエリアネットワーク(LAN)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、タイミングおよびアニメーション構成要素208、および低レベル合成およびアニメーションエンジン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は、たとえば、実質的にいずれかの抽象装置302などの、適切なレベルまたはそれ以下のレベルのフォーマットに、その出力を適合させる(または出力するように設計する)。たとえば、高レベルコンポジッタおよびアニメータ206は、最終的に、プリンタに、ネットワークを介していくつかのディスプレイ用遠隔端末に送信するために、または、主に本明細書の以下に記述するが、ローカルグラフィックスソフトウェアおよびハードウェア212上に存在する、より低レベルのコンポジッタおよびアニメータ210のために、コンパイルした出力を作り出すことができる。単一の高レベルコンポジッタおよびアニメータが、複数の抽象装置のためのアプリケーションの出力を処理する場合、または、高レベルコンポジッタおよびアニメータの適当なインスタンスがあって、それぞれの種類の抽象装置のためのアプリケーションの出力を処理する場合がある。たとえば、ローカルグラフィックスに1つ、プリンタに1つ、そして端末サーバに1つである。
【００３７】
さらに、高レベルコンポジッタおよびアニメータ206によって供給されるコマンドおよびその他のデータを単純化して、ハードウェアの能力および条件に一致させることができる。たとえば、ハードウェアの数が少なくなればなる程、高レベルの前処理が多く必要となる。さらにまた、たとえば、1または複数のより低いレベルにある、変化し続ける処理需要に合わせるため、高レベルの前処理量は動的である。
【００３８】
ローカルグラフィックス出力については、1機器構成において、グラフィックス層アーキテクチャ200は、高レベルコンポジッタおよびアニメータ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に示したコンテナである。コンテナ(たとえば、404)が、アプリケーションがそれのためのハンドルを保持することができるという識別を提供し、そして、アニメーションおよびテンプレーティング、ヒットテストおよびユーザデータのフックアップのために使用できる手続きパラメータを含む。しかし、本明細書に記載したコンテナは、作られる可能性のある唯一の種類のコンテナではないことに留意されたい。その他の例では、パラグラフ内にラインを格納するため、またはグリッド内に多くの子を格納するために最適化されたコンテナを含むことができる。特定の種類のコンテナでは、子に対してランダムアクセスができないものの、子コンテナは、現行の子リストをクリアすることなく、追加したり削除したりできる。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は、自由にそのラインの中身を取ることができ、アルゴリズム(たとえば、OpenType)を走行してテキストを位置付きのグリフに分割して、位置付けられたグリフデータを、生のテキストの代りに格納することができる。そのラインを描画した後は、システムは、ラインを描画するのに使用するTextLineオブジェクトへの参照を持たない、すなわち、システムが格納するデータは識別を持たない。
【００５７】
あるいは、より高レベルのコード202は、その識別をそのTextLineオブジェクトに保存するよう要請し、そのオブジェクトの参照をデータ構造内に格納するよう要求する。この方式で、より高レベルのコード202は、その後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にコンテナ内に記入するよう要請する。レンダリングスレッド422は、より高レベルのコード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 Method」(弁護士整理番号第3140号)に記載されているとおり、ドローイングコンテキストと呼ばれる一時的オブジェクトを使用してシーングラフ構造を構成することができる。以下のテーブル(C#様の擬似コードで書かれた)が、例としてのドローイングコンテキストを提供している(ただし、本明細書の例は、単純化された例であり、以下に説明するとおり可変値の使用を可能にする実際のAPIではないことに留意されたい)。
【００８０】
【表１】
【００８１】
ドローイングコンテキストは、通常、以下のテーブルの例に記載されるとおり、GraphContainer構造に対してOpen()関数を呼び出すことによってGraphContainerから獲得される。
【００８２】
【表２】
【００８３】
シーングラフを構成する1つの可能なやり方であるドローイングコンテキスト動作は、以下の例のテーブルに記載されるとおり、グラフコンテナを分布するのに使用される。
【００８４】
【表３】
【００８５】
前述したとおり、好ましくは、トランザクション様のモデルを提供し、例えば、「dv.Close();」関数を介して開かれたコンテナが閉じられるまで、動作が行われないようする。この目的で、前述したインテリジェントキャッシュにより、中間シーンのレンダリングが行われることなしに、シーングラフ構造を構成し、変更するトランザクションシステムが提供される。アニメートされた値の変更をグラフ変更と同期させるため、アニメートされた値に対する変更も、同様に扱われる。つまり、変更待ち行列418(図4)またはそれと等価のものを介してアニメートされた値に対する変更を送ることによって扱われる。非同期式の構成は、可能な1つの解決策に過ぎないことに留意されたい。例えば、シーングラフは、変更中にシーングラフをロックすることによって同期式に構成することも可能である。これは、更新が余りにも遅い場合、不規則なアニメーションまたは不規則な再ドローイングの問題につながる可能性があるが、構造上の解体が防止される。
【００８６】
したがって、可変値は、シーングラフの中の変更可能なエンティティをフックする手段をユーザに提供する。可変値の構成により、アニメーションをシステムに結合することが可能になる。
【００８７】
可変値自体は、以下の例としてのテーブルに記載されるとおり、プログラマブルエンティティ(抽象クラスなどの)である。
【００８８】
【表４】
【００８９】
MutableValueは、可変値オブジェクトの現行の値を戻すGetValueを含む関数を提供する。この関数は、各サブクラスによってオーバーライドされる必要がある。関数GetTypeを使用して可変値の中に記憶された現行の値のタイプ(例えば、パラメータがカラーを表すことを示す)が判定され、このタイプは、特定の可変値の構成中に決定され、一実施形態では、変更することができない。あらゆる導出されたクラスは、APIを介してアクセスされる可変値コンストラクタを呼び出し、可変値のタイプを渡し、これにより、コンストラクタが、可変値のタイプをプライベートタイプフィールドの中に記憶する。
【００９０】
アニメートされた値は、ユーザが作成することができるある種の可変値の一例である。アニメートされた値は、あらゆるドローイング動作で使用することができる。呼出しコードは、アニメートされた値(例えば、AnimatedColor)のインスタンスを、単にそれを構成することによって作成する。このようにして、プリミティブAPI(例えば、DrawLine)は、タイプセーフである。構成中、アニメーション値が時間とともに値をどのように変化させるかを記述するアニメーションフラグメントが、コンストラクタAPIに渡される。その他の種類の可変値、例えば、定数値をカプセル化する(したがって、実際には可変でなく、APIをより簡単にする)StaticMutableValueを作成することもできる。また、表現のため、より高レベルのシステムに結合するため、またテンプレート化で使用するための可変値も存在する。
【００９１】
以下は、アニメーションシステムを説明する一般的な例である(ただし、実際のAPIではない)。このアニメーションシステムは、本発明にとって必須ではないが、このアニメーションシステムとともに機能するようにパラメータ設定されたシーングラフの実施形態が構成されるため、本明細書で説明していることに留意されたい。
【００９２】
【表５】
【００９３】
以下の例は、シーングラフの中でどのようにAnimatedValueを使用することができるかを示している。
【００９４】
【表６】
【００９５】
AnimatedValueは、一般に、基本値、およびアニメーションフラグメントのリストを含む。基本値をアニメーションフラグメントの出力と結合して、パラメータ設定されたシーングラフに渡され、それを通過する最終値がもたらされる。フラグメントは、これを実行するのが可能な1つのやり方に過ぎないことに留意されたい。
【００９６】
「Set」関数を使用して、アニメートされた値を新しいアニメーションフラグメントに設定することができる。アニメーションフラグメントは、一定であることが可能な特定タイプ(例えば、カラー)の値をあるやり方でアニメートするオブジェクトと見なすことができる。アニメーション値に定数を設定するため、呼出しコードが、不変アニメーションフラグメントを、例えば、レッドは、常に値レッドを有するため、不変カラーアニメーションフラグメントを使用する。アニメーションフラグメントを結合できるようにする、アニメートされた値に関するより高度な関数を提供することも可能である。
【００９７】
このようにして、ユーザは、いつでもAnimatedValueを、例えば、
av.Set(newColorAnimationFragment);
を変更することができる。
【００９８】
図6に一般的に示すとおり、アニメートされた値600が、特定のグラフコンテナ602を分布するのに初めて使用されたとき、そのアニメートされた値600に対するリファレンス604が、パラメータ設定された命令ストリーム606の中のコンテナ602の中に(またはコンテナ602に関連して)記憶される。このリファレンスは、サブグラフが一定であるかどうか、すなわち、アニメートされた値が、ある期間中、変化しないかどうかを判定するのに使用される。1つの現行の実施形態では、このリファレンスは、以下に説明するとおり、値をルックアップするのにも使用され、例えば、命令の中のリファレンスが、負の数、またはその他の適切なフラグで表されることが可能である。また、リファレンスは、アニメートされた値の存続時間を管理するのに使用することもできる。さらに、次にサブグラフが一定であるという情報を使用して、以下に一般的に説明するとおり、レンダリングプロセスを最適化することができる。不変のサブグラフには、そのサブグラフの中に可変値を全く有していないこと、またはアニメートされた仕方で変化する可変値を全く有していないことが含まれる可能性がある。
【００９９】
理解されるとおり、可変(アニメートされた)値は、グラフ構造の部分を作成しなおすことなしにシーングラフに対する変更を行うため、シーングラフの中にフックを挿入するための汎用メカニズムである。アニメートされた値を介してシーングラフをアニメートすることにより、シーングラフとアニメーションエンジン610の間の明確な分離が提供される。これは、シーングラフ変更が非同期式に行われるシステムで特に有益である。その理由は、可変値を使用して、アニメーション結合に対する変更をシーングラフ構造に対する変更と同期させることができるからである。
【０１００】
図7は、パラメータ設定された命令の1つの例としての実施形態を示している。前述したとおり、ドローイングコンテキスト上のプリミティブドローイング動作が、パラメータ設定された命令700を作成し、この命令をドローイングコンテキスト(例えば、図4のドローイングコンテキスト416)において現在、開かれている命令ストリームに追加する。命令700は、メモリの中のデータを含み、2つの部分、ヘッダ702および本文704に論理式に分離されていると見なすことができる。
【０１０１】
図7に示すとおり、ヘッダ702は、ビットフィールドを介して、パラメータ設定された命令のタイプ、および引数のどれがパラメータ設定されるかを指定する。図7の例は、「ドローライン」タイプフィールド706、およびパラメータ記述子フィールド708で示されるとおり、パラメータ設定されたドローライン命令を示している。パラメータ記述子フィールド708の中で、「1000」2進数の中の「1」ビットが、パラメータリファレンスフィールド710の中の命令に対する第1のパラメータ(カラーを記述する)がパラメータ設定され、したがって、レンダリング時に必要とされる場合、他の場所から獲得される必要のある値を有することを示す。本文704の中で、フィールドが、ヘッダの中のビットフィールドを介して可変ではなく、一定であると定義されている場合、その定数が、命令700の中に直接に記憶される。したがって、呼出しプログラムコード(例えば、アプリケーション)によって一定であると定義されたラインの開始点および終了点、ならびに幅を表すその他のフィールド711-713は、事前にインスタンス化された命令700の本文704の中に記憶される。
【０１０２】
パラメータが一定でない(例えば、前述したStaticMutableValue、またはConstantValue)場合には、定数の変わりにパラメータプレースホルダが記憶される。このパラメータプレースホルダは、サブグラフにローカルな可変値のテーブルに対する索引を参照することが可能な間接表現、可変値のよりグローバルな範囲のテーブルに対する索引、または、場合により、可変値に対する直接のリファレンスである。例えば、DrawLine命令の中のMutableValueに定数を渡すため、このタイプは、常に一定である値を識別する。
【０１０３】
一実施形態では、2つのタイプのパラメータプレースホルダに、アニメートされた値に関するプレースホルダ、およびパラメータリファレンスに関するプレースホルダが含まれる。この実施形態では、異なる種類のプレースホルダを区別するため、アニメートされた値に関して負の数を使用し、パラメータリファレンスに関して正の数を使用することができる。ただし、その他のやり方(例えば、フラグなどの別個の指示子)で区別を行うことも可能である。
【０１０４】
命令をレンダリングするレンダリングプロセスの一環として、パラメータ設定された命令が、各パラメータプレースホルダに関する実際の値とともにインスタンス化される。例えば、インスタンス化された命令700iで表されるとおり(インスタンス化された場合、様々なラベルが、添え字「i」とともに示される)、レンダリング中、フィールド710の中のパラメータ設定された命令が、フィールド710iの中の定数値にインスタンス化される。完全にインスタンス化された命令700iが、レンダリング中、より低いレベル、つまりデバイスに渡される。これは比較的直接的なインスタンス化であり、より複雑な処理を含む可能性があることに留意されたい。
【０１０５】
パラメータ設定された命令をインスタンス化するため、プレースホルダのための値を取得するメソッドが提供される。1つのメソッドは、アニメートされた値に関する。このメソッドでは、直接の親のグラフコンテナの中で対応するアニメートされた値がルックアップされる。負の数が使用されるため(パラメータリファレンスから区別するため、索引の負数が命令の中に記憶される)、記憶されたアニメートされた可変値を識別するのに絶対値が使用される。言い換えれば、アニメートされた値でドローイングコンテキストに対してドローイング動作が使用される場合、そのアニメートされた値に対するリファレンスが、親グラフコンテナによって参照されるテーブルの中に記憶される。次に、そのアニメートされた値に関するこのテーブルへの索引が、命令の中に記憶される。負の数および正の数がプレースホルダを区別する実施形態では、値が負である場合、その値を親コンテナのテーブルの中でルックアップすることができるのことが示される。例えば、アニメートされた値を探し出すためにその数がルックアップされ、実際の値を探し出すためにそのアニメートされた値がルックアップされる(ただし、そのような二重のルックアップなしに値を探し出す他のやり方も実施することが可能である)。テーブルの中のどの特定の可変値に対しても1つだけのリファレンスが存在するように、このテーブルを最適化するのに使用することができるメソッドが存在することに留意されたい。
【０１０６】
パラメータリファレンス(例えば、1つの現行の実施形態で正の整数として記憶される)の場合、レンダリングに関連して以下に説明するとおり、その値は、評価スタックフレームの中でルックアップされる。現在、このルックアップは、アレイの中におけるパラメータリファレンス索引の位置での単なるルックアップであることに留意されたい。本例の場合、索引は、フィールド710で示される位置二(2)を示す。さらに、命令をインスタンス化する際に使用することができる複数のテーブルが存在する可能性があるため、パラメータ設定された命令の中の他のデータを使用して、どのテーブルを使用するかを指定するのが可能であることに留意されたい。例えば、値を選択することができる複数のテーブルが存在する場合、ビットフィールド/列挙を使用して、その索引がどのテーブルに適用されるかを指定することができる。
【０１０７】
パラメータ設定されたプリミティブ命令に加えて、変更可能なエンティティを命令ストリームの中にフックするという概念を変換コンテナ、ならびに不透明度、カラー、およびフィルタ、展開、イメージ処理、セピアトーン、その他などの他の多数の特殊効果を変更するものなどのその他のコンテナを含め、シーングラフプリミティブに適用することができる。例えば、変換コンテナは、オフセット、回転の角、サイズ、および/またはその他の仕方を含む何らかの仕方で以下のサブグラフの位置/座標を変換する。位置の変化とは、スクリーン上の場所の変化を指すことが可能であるが、回転の角、サイズを変化させることなどの概念、および/または何らかの1つまたは複数の座標を変化させる実質的にあらゆる関数を含むのも可能であることに留意されたい。可変変換コンテナは、以下のとおりであることが可能である(ただし、このクラスは、内部のものである)。
【０１０８】
【表７】
【０１０９】
以下の例は、可変変換をどのように使用するかを示している。
【０１１０】
【表８】
【０１１１】
変換アニメーションフラグメントを介してパラメータ設定された変換コンテナをアニメートする、すなわち、時間とともに何らかの仕方で座標および/またはその他のデータを変換することにより、変換コンテナの下のサブグラフの中の内容に動きを与えることができる。
【０１１２】
定数値オブジェクトを使用して定数を可変値に変換して、前述したとおり、アニメートされた値またはリファレンスパラメータが扱われるのと同じ仕方で定数が内部で扱われるのが可能であるようにする。また、これは、ユーザが定数を渡すことができる最新プログラミング言語(例えば、C#)の機能を活用することによって関数を単純化する。以下のテーブルでは、ConstantValueが、ユーザが単にDrawLine(新しいAnimatedColorValue(...)、新しいPoint2D(10,10)、...)を呼び出すことができるようにする暗黙のコンバータであることに留意されたい。
【０１１３】
【表９】
【０１１４】
ドローイングコンテキスト上のドローライン関数を変更して可変値を引数として取ることができる。
【０１１５】
【表１０】
【０１１６】
前述した関数は、プロトタイプをパブリックボイドDrawLine(MutableColorValue、MutablePoint2DValue、...)に変更することにより、強くタイプ付けされたものになることが可能であることに留意されたい。内部タイプ検査が、コンパイル時間中にコンパイラによって統計的に行われるために必要ない最新のプログラミング言語のタイプシステムを活用することができる。また、これにより、可変値クラス階層が変更され、例えば、1つの可変値の代わりに、NutableColorValueなどの複数の形式Mutable<TYPE>Valueが存在するのが可能であることに留意されたい。
【０１１７】
本発明の別の態様によれば、図8は、パラメータ設定されたグラフコンテナを使用する例としてのシーングラフ800を示している。図8のルートコンテナ802は、2つの子を有する通常のグラフコンテナである。ルートコンテナの左の子は、パラメータ設定されたグラフコンテナ806をルートコンテナ800に接続するアプライノード804と呼ばれる。図8に示す例では、パラメータ設定されたグラフコンテナ806は、カラータイプの1つの引数(テーブル807に示す)に対してパラメータ設定される。カラータイプは、簡明にするために選択しており、実際の実施の際には、何らかの種類のブラシタイプまたは距離測定などのその他のタイプを代わりに使用することが可能であることに留意されたい。
【０１１８】
パラメータ設定されたグラフコンテナ806の下のサブグラフ810は、パラメータ設定されたグラフコンテナ806のカラーパラメータ807を参照することが可能である。例えば、サブグラフは、棒線画などの形状を記述することが可能である。棒線画の胴体部分に関するカラーを定義する変わりに、その棒線画を描くのに使用される命令が、パラメータ設定されたグラフコンテナ806のカラーパラメータ807を参照する。
【０１１９】
前述したとおり、棒線画を記述するパラメータ設定された命令は、パラメータ設定された命令ストリーム812-814の中に記憶される。命令ストリームは、前述したとおり、パラメータリファレンスを含む。
【０１２０】
パラメータ設定されたグラフコンテナは、基本的に、拡張されたグラフコンテナである。ただし、通常のグラフコンテナの機能に加えて、パラメータ設定されたグラフコンテナは、各パラメータに関してタイプ情報を記憶し、また、そのパラメータに対するアクセス関数も提供する。パラメータアクセス関数を使用して、パラメータ設定されたグラフコンテナのパラメータに対するリファレンスを獲得し、このリファレンスが、任意のプリミティブドローイング動作に渡されることが可能である。パラメータ設定されたグラフコンテナの実施形態は、通常のグラフコンテナから導出するのが可能であることに留意されたい。
【０１２１】
一実施形態では、パラメータ設定されたグラフコンテナクラスは、以下のとおり構成される。
【０１２２】
【表１１】
【０１２３】
パラメータ設定されたグラフコンテナを作成するため、パラメータ設定されたグラフコンテナタイプの新しいオブジェクトが作成される。一実施形態では、パラメータ設定されたグラフコンテナコンストラクタにParameterType値のアレイを渡すことにより、任意の数のパラメータを使用してパラメータ設定されたグラフコンテナを作成することができる。ParameterTypeは、パラメータ設定されたグラフコンテナの各パラメータに関する予期される引数タイプを指定する。
【０１２４】
図9のシーングラフ900の例(上部の)は、以下の適切な作成コマンドを介するなどの、3つの引数を使用したパラメータ設定されたグラフコンテナ902の作成を示している。
PGC PGC = new PGC(new ParameterType[] {Color, Point, Float});
【０１２５】
図9で見ることができるとおり、パラメータ設定されたグラフコンテナ902は、第1の引数としてカラーを、第2の引数としてポイントを、また第3の引数としてフロートを予期する。引数タイプは、通常、パラメータ記述子テーブル904の中のパラメータ設定されたグラフコンテナ(ノード)902内部に記憶される(ただし、明確にするため、その他の図と同様に、テーブル904は、図9のコンテナの外部にあるものとして示している)。パラメータ記述子テーブル904の中に記憶されたタイプ情報は、タイプ検査のために使用することができる。
【０１２６】
パラメータのタイプは、以下のParameterType列挙を介して特定することができる。
【０１２７】
【表１２】
【０１２８】
パラメータ設定されたグラフコンテナ上のパラメータを参照するため、パラメータ設定されたグラフコンテナ上のGetParameter関数を使用することができる。GetParameter関数は、可変値のインスタンスを戻す。その可変値は、対応するパラメータを参照するのにどのドローイング動作でも使用することができる。タイプ付けされた可変値が使用される場合、複数のGet<TYPE>Parameter関数(例えば、GetColorParameter、これはMutableColorValueを戻す)、各タイプごとに1つの関数、またはユーザアプリケーションがアクセスするオブジェクトを戻す1つの汎用関数が存在することになることに留意されたい。各タイプごとに1つの関数を有することが、確認の点から好ましい。
【０１２９】
パラメータは、索引を介してアドレス指定される。例えば、図9の例に示すとおり、カラーパラメータは、一(1)という索引を有し、ポイントパラメータは、二(2)という索引を有し、またフロートパラメータは、三(3)という索引を有する。したがって、以下の例は、図9のパラメータ設定されたグラフコンテナの「ポイント」パラメータを記述するMutableValueのインスタンスを戻す。
PGC.GetParameter(2);
【０１３０】
内部で、GetParameter関数が、MutableValueから導出される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だけを参照するのが可能であることに留意されたい。ただし、親連鎖の中の任意のパラメータ設定されたグラフコンテナの任意のパラメータを参照するようにモデルを拡張するのは簡単である。例えば、一実施形態は、参照されるパラメータ設定されたグラフコンテナに対するポインタを単に記憶することが可能である。ただし、そのようなモデルでは、パラメータリファレンスが正しく使用されているかどうかを判定する確認は、グラフ構成段階中に幾分の確認を行うことができないため、実施するのがそれほど簡単ではない。それでも、効率的な確認アルゴリズムを実装するのは簡単である。
【０１４５】
ドローイングコンテキスト上でGraphContainerを呼び出すことによってパラメータ設定されたグラフコンテナをシーングラフに追加することができる。以下の例としての擬似コードは、図9の例に示されるパラメータ設定されたグラフコンテナ902をどのように変換コンテナの下のシーングラフに追加できるかを示している。
【０１４６】
【表１７】
【０１４７】
図10は、サンプルコードの結果のシーングラフ1000を示している。図10では、ルートコンテナ1002が、変換コンテナ1004の親である。アプライノード1006が、変換コンテナ1004とパラメータ設定されたグラフコンテナ902の間に存在して、パラメータ記述子テーブル904によって確認されるとおり、引数のテーブル1008の中の実際の値をパラメータ設定されたグラフコンテナのパラメータに適用している。
【０１４８】
また、パラメータ設定されたグラフコンテナのリファレンスパラメータが、以下のとおり、別のパラメータ設定されたグラフコンテナに渡されることも可能である。
【０１４９】
【表１８】
【０１５０】
ドローイングコンテキスト上のDrawContainer関数は、以下のとおりタイプ付けすることができる。
public void DrawContainer(GraphContainer,
params MutableValue[] parameters);
前述したとおり、高レベルのエンジンが、レンダリングパスを行い、レンダリングパスは、基本的に、シーングラフ上のウォークを含む。パラメータ設定されたシーングラフをレンダリングするため、評価スタックフレームが維持される。レンダリングパスの開始時には、評価スタックフレームは空である。
【０１５１】
レンダリングパスは、アプライノードに到達するたびに毎回、アプライノードの中の値記述子テーブルと同じサイズを有する新しいスタックフレームを作成する。この評価スタックフレームが、評価スタック上にプッシュされる。次に、アプライノードの値記述子テーブルの各エントリに関して、その値が評価され、アプライノードの中の値記述子テーブルの中で値記述子が有していたのと同じ位置でスタックフレーム上に記憶される。
【０１５２】
前述したとおり、現在、各値記述子テーブルエントリに関する値が取得される2つの異なるインスタンスが存在する。すなわち、パラメータリファレンスに関するインスタンス、および可変値に関するインスタンスである。パラメータリファレンスの場合、値は、パラメータリファレンスの中に記憶されたパラメータ索引において上から第2番の評価スタックフレーム上でルックアップされる。パラメータ索引は、パラメータリファレンス上でGetValueを呼び出すことによって取得することができる。可変値の場合、その定数が、定数値として記憶される。
【０１５３】
本発明に従い、高レベルのエンジンのインテリジェントキャッシングメカニズムが、レンダリングのために必要とされるプロセッサ時間およびメモリ(特にビデオメモリ)を一般的に含むリソースの消費を抑える様々なメカニズムを使用するのを試みることが可能である。また、パラメータ設定されたシーングラフをインテリジェントキャッシングメカニズムのキャッシングメカニズムとともに使用することも可能である。この目的で、例えば、インテリジェントキャッシングメカニズムが、サブグラフが不変であることを認識し、これにより、インテリジェントキャッシングメカニズムは、サブグラフをビットマップとしてレンダリングすることができ、次に、このビットマップがキャッシュに入れられ、再使用されることが可能である。別の例として、テンプレート化されたサブグラフの同様の使用法が、同じキャッシュを使用することが可能である。キャッシュは、解像度依存であるが、必ずしもカラー依存ではないスティックマンなどのイメージのタイル張りとしても使用するのが可能であることに留意されたい。一般に、パラメータ設定されたシーングラフをほとんど変更することなく、キャッシングメカニズムのほとんどを適用することも可能である。
【０１５４】
システムを拡張する1つのやり方は、以下のとおり、表現エンジンを使用し、表現をシステムの中に結合する別の可変値を導入することである。
【０１５５】
【表１９】
【０１５６】
GetValueコールが、表現を戻す。レンダリング中、この表現が、現行のコンテキストの中で評価される。表現が複数回、使用される場合、レンダリングパス中に変更が許されない限り、表現の評価をその表現自体の上にキャッシングすることができる。
【０１５７】
パラメータ設定されたシーングラフの中でヒット試験を提供する1つの方策は、レンダリングアルゴリズムと同様の仕方でパラメータ設定を追跡することである。パラメータ設定は、サブグラフの再使用のインスタンスごとにヒット試験を制御できるように拡張することが可能である。この目的で、パラメータ設定されたグラフコンテナを有するシーングラフの中で、一実施形態では、ヒット試験は、何にヒットしたかを一意的に特定するため、ルートからグラフコンテナに至るパス全体を戻す必要がある。代替の実施形態では、ヒット試験ノードおよびヒット試験識別子の使用によってこれを回避することができる。パラメータ設定されたコンテナは、ヒット試験識別子を介して、すなわち、MutableTransformContainerと同様のMutableHitTestContainerを介してパラメータ設定するのが可能であることに留意されたい。
【０１５８】
図11の例としてのシーングラフ1100において一般的に示されるとおり、システムは、ヒット試験識別子を介してパラメータ設定される特別ヒット試験ノード1120を使用して拡張することができる。この結果、パラメータ設定されたサブグラフのすべての使用法が、ヒット試験識別子を介するパラメータ設定を使用することにより、異なる識別子を使用することが可能である。図11に示す例では、親コンテナ1102が、自らの下に2つのコンテナノード、Node0(1104)およびNode1(1106)を有する。これらのノードのそれぞれは、2つのカラー、2次元のポイント、およびヒット試験識別子をパラメータ設定されたグラフコンテナ1116に適用するアプライノード1108、および1110をそれぞれ有する。例えば、カラーの1つが、棒線画の頭を表し、別のカラーが、棒線画胴体の残りの部分を表すことが可能である。
【０１５９】
効率的なヒット試験を提供するため、パラメータ設定されたグラフコンテナ1116の引数のどれかは、ヒット試験IDである。ヒット試験ノード1120が、各ヒット試験IDをノードに関する情報、例えば、ノードのパス情報または結合情報に関係付けるヒット試験テーブルを維持する。これは、ヒット試験中にグラフのウォークが行われる際、必ずしも必要とされない最適化に過ぎないことに留意されたい。このようにして、アプライノードのどれかで現在、構成されているパラメータ設定されたグラフコンテナ1116によって表される内容に関する情報をヒット試験IDおよび関連する情報に関係付けることができる。例えば、いくつかの棒線画が同一のサブグラフによって表される場合、前述したパラメータ設定されたグラフコンテナを介して、ヒットするそれぞれの棒線画を一意的に識別することができる。
【０１６０】
したがって、ヒット試験は、一般に、グラフの中のノードを一意的に識別することができる必要がある。同様に、変換が、サブグラフの再使用との組み合わせで、ノードの固有識別子を必要とする可能性がある。例えば変換が、1つのサブグラフに対して、別のサブグラフ(さらに別のサブグラフとの関係にあることが可能な)との関係でスケーリング(ファクタによるズーム)、オフセット、回転等を行うことが可能である。本発明の実施形態は、1つの座標空間から別の座標空間に対する次元、場所、サイズ等の相対値を使用して機能して、スクロール、ヒット試験、選択、その他が容易になるようにすることが可能である。ただし、シーングラフの中で再使用が存在する場合、再使用されるノードのどのインスタンスが、相対的変換のための基礎として使用されているかを識別するのに固有識別子が必要とされる。1つの解決策は、ルートからサブグラフを通りノードに至るパスを使用してパラメータ設定されたグラフコンテナの1つの使用を特定することである。
【０１６１】
また、サブグラフを介するパラメータ設定を使用してシステムを拡張することも可能である。以下のMutableValueが、これを可能にする。
【０１６２】
【表２０】
【０１６３】
ドローイングコンテキストに以下の関数が追加される。
DrawGraphContainer(GraphContainerValue,
params MutableValue[] parameters);
【０１６４】
ドローイング動作が、GraphContainerValueに対するリファレンスを記憶する特別アプライノードを挿入する。アプライノードの子を取ってレンダリングを継続する代わりに、レンダリングアルゴリズムは、特別アプライノード上に記憶された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 グラフコンテナ
本発明は、米国仮特許出願第60/330,231号(2001年10月18日出願)への優先権を請求する。本発明は、係属米国特許出願「Multiple-Level Graphics Processing System and Method」(弁護士整理番号第3140号)および係属米国特許出願「Intelligent Caching Data Structure 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 Architecture)(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、およびプログラムデータ137と同じまたは異なるもののどちらでもあり得ることに留意されたい。オペレーティングシステム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に示す論理接続は、ローカルエリアネットワーク(LAN)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、タイミングおよびアニメーション構成要素208、および低レベル合成およびアニメーションエンジン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は、たとえば、実質的にいずれかの抽象装置302などの、適切なレベルまたはそれ以下のレベルのフォーマットに、その出力を適合させる(または出力するように設計する)。たとえば、高レベルコンポジッタおよびアニメータ206は、最終的に、プリンタに、ネットワークを介していくつかのディスプレイ用遠隔端末に送信するために、または、主に本明細書の以下に記述するが、ローカルグラフィックスソフトウェアおよびハードウェア212上に存在する、より低レベルのコンポジッタおよびアニメータ210のために、コンパイルした出力を作り出すことができる。単一の高レベルコンポジッタおよびアニメータが、複数の抽象装置のためのアプリケーションの出力を処理する場合、または、高レベルコンポジッタおよびアニメータの適当なインスタンスがあって、それぞれの種類の抽象装置のためのアプリケーションの出力を処理する場合がある。たとえば、ローカルグラフィックスに1つ、プリンタに1つ、そして端末サーバに1つである。
【００３７】
さらに、高レベルコンポジッタおよびアニメータ206によって供給されるコマンドおよびその他のデータを単純化して、ハードウェアの能力および条件に一致させることができる。たとえば、ハードウェアの数が少なくなればなる程、高レベルの前処理が多く必要となる。さらにまた、たとえば、1または複数のより低いレベルにある、変化し続ける処理需要に合わせるため、高レベルの前処理量は動的である。
【００３８】
ローカルグラフィックス出力については、1機器構成において、グラフィックス層アーキテクチャ200は、高レベルコンポジッタおよびアニメータ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に示したコンテナである。コンテナ(たとえば、404)が、アプリケーションがそれのためのハンドルを保持することができるという識別を提供し、そして、アニメーションおよびテンプレーティング、ヒットテストおよびユーザデータのフックアップのために使用できる手続きパラメータを含む。しかし、本明細書に記載したコンテナは、作られる可能性のある唯一の種類のコンテナではないことに留意されたい。その他の例では、パラグラフ内にラインを格納するため、またはグリッド内に多くの子を格納するために最適化されたコンテナを含むことができる。特定の種類のコンテナでは、子に対してランダムアクセスができないものの、子コンテナは、現行の子リストをクリアすることなく、追加したり削除したりできる。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は、自由にそのラインの中身を取ることができ、アルゴリズム(たとえば、OpenType)を走行してテキストを位置付きのグリフに分割して、位置付けられたグリフデータを、生のテキストの代りに格納することができる。そのラインを描画した後は、システムは、ラインを描画するのに使用するTextLineオブジェクトへの参照を持たない、すなわち、システムが格納するデータは識別を持たない。
【００５７】
あるいは、より高レベルのコード202は、その識別をそのTextLineオブジェクトに保存するよう要請し、そのオブジェクトの参照をデータ構造内に格納するよう要求する。この方式で、より高レベルのコード202は、その後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にコンテナ内に記入するよう要請する。レンダリングスレッド422は、より高レベルのコード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 Method」(弁護士整理番号第3140号)に記載されているとおり、ドローイングコンテキストと呼ばれる一時的オブジェクトを使用してシーングラフ構造を構成することができる。以下のテーブル(C#様の擬似コードで書かれた)が、例としてのドローイングコンテキストを提供している(ただし、本明細書の例は、単純化された例であり、以下に説明するとおり可変値の使用を可能にする実際のAPIではないことに留意されたい)。
【００８０】
【表１】
ドローイングコンテキストは、通常、以下のテーブルの例に記載されるとおり、GraphContainer構造に対してOpen()関数を呼び出すことによってGraphContainerから獲得される。
【００８２】
【表２】
シーングラフを構成する1つの可能なやり方であるドローイングコンテキスト動作は、以下の例のテーブルに記載されるとおり、グラフコンテナを分布するのに使用される。
【００８４】
【表３】
前述したとおり、好ましくは、トランザクション様のモデルを提供し、例えば、「dv.Close();」関数を介して開かれたコンテナが閉じられるまで、動作が行われないようする。この目的で、前述したインテリジェントキャッシュにより、中間シーンのレンダリングが行われることなしに、シーングラフ構造を構成し、変更するトランザクションシステムが提供される。アニメートされた値の変更をグラフ変更と同期させるため、アニメートされた値に対する変更も、同様に扱われる。つまり、変更待ち行列418(図4)またはそれと等価のものを介してアニメートされた値に対する変更を送ることによって扱われる。非同期式の構成は、可能な1つの解決策に過ぎないことに留意されたい。例えば、シーングラフは、変更中にシーングラフをロックすることによって同期式に構成することも可能である。これは、更新が余りにも遅い場合、不規則なアニメーションまたは不規則な再ドローイングの問題につながる可能性があるが、構造上の解体が防止される。
【００８６】
したがって、可変値は、シーングラフの中の変更可能なエンティティをフックする手段をユーザに提供する。可変値の構成により、アニメーションをシステムに結合することが可能になる。
【００８７】
可変値自体は、以下の例としてのテーブルに記載されるとおり、プログラマブルエンティティ(抽象クラスなどの)である。
【００８８】
【表４】
MutableValueは、可変値オブジェクトの現行の値を戻すGetValueを含む関数を提供する。この関数は、各サブクラスによってオーバーライドされる必要がある。関数GetTypeを使用して可変値の中に記憶された現行の値のタイプ(例えば、パラメータがカラーを表すことを示す)が判定され、このタイプは、特定の可変値の構成中に決定され、一実施形態では、変更することができない。あらゆる導出されたクラスは、APIを介してアクセスされる可変値コンストラクタを呼び出し、可変値のタイプを渡し、これにより、コンストラクタが、可変値のタイプをプライベートタイプフィールドの中に記憶する。
【００９０】
アニメートされた値は、ユーザが作成することができるある種の可変値の一例である。アニメートされた値は、あらゆるドローイング動作で使用することができる。呼出しコードは、アニメートされた値(例えば、AnimatedColor)のインスタンスを、単にそれを構成することによって作成する。このようにして、プリミティブAPI(例えば、DrawLine)は、タイプセーフである。構成中、アニメーション値が時間とともに値をどのように変化させるかを記述するアニメーションフラグメントが、コンストラクタAPIに渡される。その他の種類の可変値、例えば、定数値をカプセル化する(したがって、実際には可変でなく、APIをより簡単にする)StaticMutableValueを作成することもできる。また、表現のため、より高レベルのシステムに結合するため、またテンプレート化で使用するための可変値も存在する。
【００９１】
以下は、アニメーションシステムを説明する一般的な例である(ただし、実際のAPIではない)。このアニメーションシステムは、本発明にとって必須ではないが、このアニメーションシステムとともに機能するようにパラメータ設定されたシーングラフの実施形態が構成されるため、本明細書で説明していることに留意されたい。
【００９２】
【表５】
以下の例は、シーングラフの中でどのようにAnimatedValueを使用することができるかを示している。
【００９４】
【表６】
AnimatedValueは、一般に、基本値、およびアニメーションフラグメントのリストを含む。基本値をアニメーションフラグメントの出力と結合して、パラメータ設定されたシーングラフに渡され、それを通過する最終値がもたらされる。フラグメントは、これを実行するのが可能な1つのやり方に過ぎないことに留意されたい。
【００９６】
「Set」関数を使用して、アニメートされた値を新しいアニメーションフラグメントに設定することができる。アニメーションフラグメントは、一定であることが可能な特定タイプ(例えば、カラー)の値をあるやり方でアニメートするオブジェクトと見なすことができる。アニメーション値に定数を設定するため、呼出しコードが、不変アニメーションフラグメントを、例えば、レッドは、常に値レッドを有するため、不変カラーアニメーションフラグメントを使用する。アニメーションフラグメントを結合できるようにする、アニメートされた値に関するより高度な関数を提供することも可能である。
【００９７】
このようにして、ユーザは、いつでもAnimatedValueを、例えば、
av.Set(newColorAnimationFragment);
を変更することができる。
【００９８】
図6に一般的に示すとおり、アニメートされた値600が、特定のグラフコンテナ602を分布するのに初めて使用されたとき、そのアニメートされた値600に対するリファレンス604が、パラメータ設定された命令ストリーム606の中のコンテナ602の中に(またはコンテナ602に関連して)記憶される。このリファレンスは、サブグラフが一定であるかどうか、すなわち、アニメートされた値が、ある期間中、変化しないかどうかを判定するのに使用される。1つの現行の実施形態では、このリファレンスは、以下に説明するとおり、値をルックアップするのにも使用され、例えば、命令の中のリファレンスが、負の数、またはその他の適切なフラグで表されることが可能である。また、リファレンスは、アニメートされた値の存続時間を管理するのに使用することもできる。さらに、次にサブグラフが一定であるという情報を使用して、以下に一般的に説明するとおり、レンダリングプロセスを最適化することができる。不変のサブグラフには、そのサブグラフの中に可変値を全く有していないこと、またはアニメートされた仕方で変化する可変値を全く有していないことが含まれる可能性がある。
【００９９】
理解されるとおり、可変(アニメートされた)値は、グラフ構造の部分を作成しなおすことなしにシーングラフに対する変更を行うため、シーングラフの中にフックを挿入するための汎用メカニズムである。アニメートされた値を介してシーングラフをアニメートすることにより、シーングラフとアニメーションエンジン610の間の明確な分離が提供される。これは、シーングラフ変更が非同期式に行われるシステムで特に有益である。その理由は、可変値を使用して、アニメーション結合に対する変更をシーングラフ構造に対する変更と同期させることができるからである。
【０１００】
図7は、パラメータ設定された命令の1つの例としての実施形態を示している。前述したとおり、ドローイングコンテキスト上のプリミティブドローイング動作が、パラメータ設定された命令700を作成し、この命令をドローイングコンテキスト(例えば、図4のドローイングコンテキスト416)において現在、開かれている命令ストリームに追加する。命令700は、メモリの中のデータを含み、2つの部分、ヘッダ702および本文704に論理式に分離されていると見なすことができる。
【０１０１】
図7に示すとおり、ヘッダ702は、ビットフィールドを介して、パラメータ設定された命令のタイプ、および引数のどれがパラメータ設定されるかを指定する。図7の例は、「ドローライン」タイプフィールド706、およびパラメータ記述子フィールド708で示されるとおり、パラメータ設定されたドローライン命令を示している。パラメータ記述子フィールド708の中で、「1000」2進数の中の「1」ビットが、パラメータリファレンスフィールド710の中の命令に対する第1のパラメータ(カラーを記述する)がパラメータ設定され、したがって、レンダリング時に必要とされる場合、他の場所から獲得される必要のある値を有することを示す。本文704の中で、フィールドが、ヘッダの中のビットフィールドを介して可変ではなく、一定であると定義されている場合、その定数が、命令700の中に直接に記憶される。したがって、呼出しプログラムコード(例えば、アプリケーション)によって一定であると定義されたラインの開始点および終了点、ならびに幅を表すその他のフィールド711-713は、事前にインスタンス化された命令700の本文704の中に記憶される。
【０１０２】
パラメータが一定でない(例えば、前述したStaticMutableValue、またはConstantValue)場合には、定数の変わりにパラメータプレースホルダが記憶される。このパラメータプレースホルダは、サブグラフにローカルな可変値のテーブルに対する索引を参照することが可能な間接表現、可変値のよりグローバルな範囲のテーブルに対する索引、または、場合により、可変値に対する直接のリファレンスである。例えば、DrawLine命令の中のMutableValueに定数を渡すため、このタイプは、常に一定である値を識別する。
【０１０３】
一実施形態では、2つのタイプのパラメータプレースホルダに、アニメートされた値に関するプレースホルダ、およびパラメータリファレンスに関するプレースホルダが含まれる。この実施形態では、異なる種類のプレースホルダを区別するため、アニメートされた値に関して負の数を使用し、パラメータリファレンスに関して正の数を使用することができる。ただし、その他のやり方(例えば、フラグなどの別個の指示子)で区別を行うことも可能である。
【０１０４】
命令をレンダリングするレンダリングプロセスの一環として、パラメータ設定された命令が、各パラメータプレースホルダに関する実際の値とともにインスタンス化される。例えば、インスタンス化された命令700iで表されるとおり(インスタンス化された場合、様々なラベルが、添え字「i」とともに示される)、レンダリング中、フィールド710の中のパラメータ設定された命令が、フィールド710iの中の定数値にインスタンス化される。完全にインスタンス化された命令700iが、レンダリング中、より低いレベル、つまりデバイスに渡される。これは比較的直接的なインスタンス化であり、より複雑な処理を含む可能性があることに留意されたい。
【０１０５】
パラメータ設定された命令をインスタンス化するため、プレースホルダのための値を取得するメソッドが提供される。1つのメソッドは、アニメートされた値に関する。このメソッドでは、直接の親のグラフコンテナの中で対応するアニメートされた値がルックアップされる。負の数が使用されるため(パラメータリファレンスから区別するため、索引の負数が命令の中に記憶される)、記憶されたアニメートされた可変値を識別するのに絶対値が使用される。言い換えれば、アニメートされた値でドローイングコンテキストに対してドローイング動作が使用される場合、そのアニメートされた値に対するリファレンスが、親グラフコンテナによって参照されるテーブルの中に記憶される。次に、そのアニメートされた値に関するこのテーブルへの索引が、命令の中に記憶される。負の数および正の数がプレースホルダを区別する実施形態では、値が負である場合、その値を親コンテナのテーブルの中でルックアップすることができるのことが示される。例えば、アニメートされた値を探し出すためにその数がルックアップされ、実際の値を探し出すためにそのアニメートされた値がルックアップされる(ただし、そのような二重のルックアップなしに値を探し出す他のやり方も実施することが可能である)。テーブルの中のどの特定の可変値に対しても1つだけのリファレンスが存在するように、このテーブルを最適化するのに使用することができるメソッドが存在することに留意されたい。
【０１０６】
パラメータリファレンス(例えば、1つの現行の実施形態で正の整数として記憶される)の場合、レンダリングに関連して以下に説明するとおり、その値は、評価スタックフレームの中でルックアップされる。現在、このルックアップは、アレイの中におけるパラメータリファレンス索引の位置での単なるルックアップであることに留意されたい。本例の場合、索引は、フィールド710で示される位置二(2)を示す。さらに、命令をインスタンス化する際に使用することができる複数のテーブルが存在する可能性があるため、パラメータ設定された命令の中の他のデータを使用して、どのテーブルを使用するかを指定するのが可能であることに留意されたい。例えば、値を選択することができる複数のテーブルが存在する場合、ビットフィールド/列挙を使用して、その索引がどのテーブルに適用されるかを指定することができる。
【０１０７】
パラメータ設定されたプリミティブ命令に加えて、変更可能なエンティティを命令ストリームの中にフックするという概念を変換コンテナ、ならびに不透明度、カラー、およびフィルタ、展開、イメージ処理、セピアトーン、その他などの他の多数の特殊効果を変更するものなどのその他のコンテナを含め、シーングラフプリミティブに適用することができる。例えば、変換コンテナは、オフセット、回転の角、サイズ、および/またはその他の仕方を含む何らかの仕方で以下のサブグラフの位置/座標を変換する。位置の変化とは、スクリーン上の場所の変化を指すことが可能であるが、回転の角、サイズを変化させることなどの概念、および/または何らかの1つまたは複数の座標を変化させる実質的にあらゆる関数を含むのも可能であることに留意されたい。可変変換コンテナは、以下のとおりであることが可能である(ただし、このクラスは、内部のものである)。
【０１０８】
【表７】
以下の例は、可変変換をどのように使用するかを示している。
【０１１０】
【表８】
変換アニメーションフラグメントを介してパラメータ設定された変換コンテナをアニメートする、すなわち、時間とともに何らかの仕方で座標および/またはその他のデータを変換することにより、変換コンテナの下のサブグラフの中の内容に動きを与えることができる。
【０１１２】
定数値オブジェクトを使用して定数を可変値に変換して、前述したとおり、アニメートされた値またはリファレンスパラメータが扱われるのと同じ仕方で定数が内部で扱われるのが可能であるようにする。また、これは、ユーザが定数を渡すことができる最新プログラミング言語(例えば、C#)の機能を活用することによって関数を単純化する。以下のテーブルでは、ConstantValueが、ユーザが単にDrawLine(新しいAnimatedColorValue(...)、新しいPoint2D(10,10)、...)を呼び出すことができるようにする暗黙のコンバータであることに留意されたい。
【０１１３】
【表９】
ドローイングコンテキスト上のドローライン関数を変更して可変値を引数として取ることができる。
【０１１５】
【表１０】
前述した関数は、プロトタイプをパブリックボイドDrawLine(MutableColorValue、MutablePoint2DValue、...)に変更することにより、強くタイプ付けされたものになることが可能であることに留意されたい。内部タイプ検査が、コンパイル時間中にコンパイラによって統計的に行われるために必要ない最新のプログラミング言語のタイプシステムを活用することができる。また、これにより、可変値クラス階層が変更され、例えば、1つの可変値の代わりに、NutableColorValueなどの複数の形式Mutable<TYPE>Valueが存在するのが可能であることに留意されたい。
【０１１７】
本発明の別の態様によれば、図8は、パラメータ設定されたグラフコンテナを使用する例としてのシーングラフ800を示している。図8のルートコンテナ802は、2つの子を有する通常のグラフコンテナである。ルートコンテナの左の子は、パラメータ設定されたグラフコンテナ806をルートコンテナ800に接続するアプライノード804と呼ばれる。図8に示す例では、パラメータ設定されたグラフコンテナ806は、カラータイプの1つの引数(テーブル807に示す)に対してパラメータ設定される。カラータイプは、簡明にするために選択しており、実際の実施の際には、何らかの種類のブラシタイプまたは距離測定などのその他のタイプを代わりに使用することが可能であることに留意されたい。
【０１１８】
パラメータ設定されたグラフコンテナ806の下のサブグラフ810は、パラメータ設定されたグラフコンテナ806のカラーパラメータ807を参照することが可能である。例えば、サブグラフは、棒線画などの形状を記述することが可能である。棒線画の胴体部分に関するカラーを定義する変わりに、その棒線画を描くのに使用される命令が、パラメータ設定されたグラフコンテナ806のカラーパラメータ807を参照する。
【０１１９】
前述したとおり、棒線画を記述するパラメータ設定された命令は、パラメータ設定された命令ストリーム812-814の中に記憶される。命令ストリームは、前述したとおり、パラメータリファレンスを含む。
【０１２０】
パラメータ設定されたグラフコンテナは、基本的に、拡張されたグラフコンテナである。ただし、通常のグラフコンテナの機能に加えて、パラメータ設定されたグラフコンテナは、各パラメータに関してタイプ情報を記憶し、また、そのパラメータに対するアクセス関数も提供する。パラメータアクセス関数を使用して、パラメータ設定されたグラフコンテナのパラメータに対するリファレンスを獲得し、このリファレンスが、任意のプリミティブドローイング動作に渡されることが可能である。パラメータ設定されたグラフコンテナの実施形態は、通常のグラフコンテナから導出するのが可能であることに留意されたい。
【０１２１】
一実施形態では、パラメータ設定されたグラフコンテナクラスは、以下のとおり構成される。
【０１２２】
【表１１】
パラメータ設定されたグラフコンテナを作成するため、パラメータ設定されたグラフコンテナタイプの新しいオブジェクトが作成される。一実施形態では、パラメータ設定されたグラフコンテナコンストラクタにParameterType値のアレイを渡すことにより、任意の数のパラメータを使用してパラメータ設定されたグラフコンテナを作成することができる。ParameterTypeは、パラメータ設定されたグラフコンテナの各パラメータに関する予期される引数タイプを指定する。
【０１２４】
図9のシーングラフ900の例(上部の)は、以下の適切な作成コマンドを介するなどの、3つの引数を使用したパラメータ設定されたグラフコンテナ902の作成を示している。
PGC PGC = new PGC(new ParameterType[] {Color, Point, Float});
【０１２５】
図9で見ることができるとおり、パラメータ設定されたグラフコンテナ902は、第1の引数としてカラーを、第2の引数としてポイントを、また第3の引数としてフロートを予期する。引数タイプは、通常、パラメータ記述子テーブル904の中のパラメータ設定されたグラフコンテナ(ノード)902内部に記憶される(ただし、明確にするため、その他の図と同様に、テーブル904は、図9のコンテナの外部にあるものとして示している)。パラメータ記述子テーブル904の中に記憶されたタイプ情報は、タイプ検査のために使用することができる。
【０１２６】
パラメータのタイプは、以下のParameterType列挙を介して特定することができる。
【０１２７】
【表１２】
パラメータ設定されたグラフコンテナ上のパラメータを参照するため、パラメータ設定されたグラフコンテナ上のGetParameter関数を使用することができる。GetParameter関数は、可変値のインスタンスを戻す。その可変値は、対応するパラメータを参照するのにどのドローイング動作でも使用することができる。タイプ付けされた可変値が使用される場合、複数のGet<TYPE>Parameter関数(例えば、GetColorParameter、これはMutableColorValueを戻す)、各タイプごとに1つの関数、またはユーザアプリケーションがアクセスするオブジェクトを戻す1つの汎用関数が存在することになることに留意されたい。各タイプごとに1つの関数を有することが、確認の点から好ましい。
【０１２９】
パラメータは、索引を介してアドレス指定される。例えば、図9の例に示すとおり、カラーパラメータは、一(1)という索引を有し、ポイントパラメータは、二(2)という索引を有し、またフロートパラメータは、三(3)という索引を有する。したがって、以下の例は、図9のパラメータ設定されたグラフコンテナの「ポイント」パラメータを記述するMutableValueのインスタンスを戻す。
PGC.GetParameter(2);
【０１３０】
内部で、GetParameter関数が、MutableValueから導出される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だけを参照するのが可能であることに留意されたい。ただし、親連鎖の中の任意のパラメータ設定されたグラフコンテナの任意のパラメータを参照するようにモデルを拡張するのは簡単である。例えば、一実施形態は、参照されるパラメータ設定されたグラフコンテナに対するポインタを単に記憶することが可能である。ただし、そのようなモデルでは、パラメータリファレンスが正しく使用されているかどうかを判定する確認は、グラフ構成段階中に幾分の確認を行うことができないため、実施するのがそれほど簡単ではない。それでも、効率的な確認アルゴリズムを実装するのは簡単である。
【０１４５】
ドローイングコンテキスト上でGraphContainerを呼び出すことによってパラメータ設定されたグラフコンテナをシーングラフに追加することができる。以下の例としての擬似コードは、図9の例に示されるパラメータ設定されたグラフコンテナ902をどのように変換コンテナの下のシーングラフに追加できるかを示している。
【０１４６】
【表１７】
図10は、サンプルコードの結果のシーングラフ1000を示している。図10では、ルートコンテナ1002が、変換コンテナ1004の親である。アプライノード1006が、変換コンテナ1004とパラメータ設定されたグラフコンテナ902の間に存在して、パラメータ記述子テーブル904によって確認されるとおり、引数のテーブル1008の中の実際の値をパラメータ設定されたグラフコンテナのパラメータに適用している。
【０１４８】
また、パラメータ設定されたグラフコンテナのリファレンスパラメータが、以下のとおり、別のパラメータ設定されたグラフコンテナに渡されることも可能である。
【０１４９】
【表１８】
ドローイングコンテキスト上のDrawContainer関数は、以下のとおりタイプ付けすることができる。
public void DrawContainer(GraphContainer,
params MutableValue[] parameters);
前述したとおり、高レベルのエンジンが、レンダリングパスを行い、レンダリングパスは、基本的に、シーングラフ上のウォークを含む。パラメータ設定されたシーングラフをレンダリングするため、評価スタックフレームが維持される。レンダリングパスの開始時には、評価スタックフレームは空である。
【０１５１】
レンダリングパスは、アプライノードに到達するたびに毎回、アプライノードの中の値記述子テーブルと同じサイズを有する新しいスタックフレームを作成する。この評価スタックフレームが、評価スタック上にプッシュされる。次に、アプライノードの値記述子テーブルの各エントリに関して、その値が評価され、アプライノードの中の値記述子テーブルの中で値記述子が有していたのと同じ位置でスタックフレーム上に記憶される。
【０１５２】
前述したとおり、現在、各値記述子テーブルエントリに関する値が取得される2つの異なるインスタンスが存在する。すなわち、パラメータリファレンスに関するインスタンス、および可変値に関するインスタンスである。パラメータリファレンスの場合、値は、パラメータリファレンスの中に記憶されたパラメータ索引において上から第2番の評価スタックフレーム上でルックアップされる。パラメータ索引は、パラメータリファレンス上でGetValueを呼び出すことによって取得することができる。可変値の場合、その定数が、定数値として記憶される。
【０１５３】
本発明に従い、高レベルのエンジンのインテリジェントキャッシングメカニズムが、レンダリングのために必要とされるプロセッサ時間およびメモリ(特にビデオメモリ)を一般的に含むリソースの消費を抑える様々なメカニズムを使用するのを試みることが可能である。また、パラメータ設定されたシーングラフをインテリジェントキャッシングメカニズムのキャッシングメカニズムとともに使用することも可能である。この目的で、例えば、インテリジェントキャッシングメカニズムが、サブグラフが不変であることを認識し、これにより、インテリジェントキャッシングメカニズムは、サブグラフをビットマップとしてレンダリングすることができ、次に、このビットマップがキャッシュに入れられ、再使用されることが可能である。別の例として、テンプレート化されたサブグラフの同様の使用法が、同じキャッシュを使用することが可能である。キャッシュは、解像度依存であるが、必ずしもカラー依存ではないスティックマンなどのイメージのタイル張りとしても使用するのが可能であることに留意されたい。一般に、パラメータ設定されたシーングラフをほとんど変更することなく、キャッシングメカニズムのほとんどを適用することも可能である。
【０１５４】
システムを拡張する1つのやり方は、以下のとおり、表現エンジンを使用し、表現をシステムの中に結合する別の可変値を導入することである。
【０１５５】
【表１９】
GetValueコールが、表現を戻す。レンダリング中、この表現が、現行のコンテキストの中で評価される。表現が複数回、使用される場合、レンダリングパス中に変更が許されない限り、表現の評価をその表現自体の上にキャッシングすることができる。
【０１５７】
パラメータ設定されたシーングラフの中でヒット試験を提供する1つの方策は、レンダリングアルゴリズムと同様の仕方でパラメータ設定を追跡することである。パラメータ設定は、サブグラフの再使用のインスタンスごとにヒット試験を制御できるように拡張することが可能である。この目的で、パラメータ設定されたグラフコンテナを有するシーングラフの中で、一実施形態では、ヒット試験は、何にヒットしたかを一意的に特定するため、ルートからグラフコンテナに至るパス全体を戻す必要がある。代替の実施形態では、ヒット試験ノードおよびヒット試験識別子の使用によってこれを回避することができる。パラメータ設定されたコンテナは、ヒット試験識別子を介して、すなわち、MutableTransformContainerと同様のMutableHitTestContainerを介してパラメータ設定するのが可能であることに留意されたい。
【０１５８】
図11の例としてのシーングラフ1100において一般的に示されるとおり、システムは、ヒット試験識別子を介してパラメータ設定される特別ヒット試験ノード1120を使用して拡張することができる。この結果、パラメータ設定されたサブグラフのすべての使用法が、ヒット試験識別子を介するパラメータ設定を使用することにより、異なる識別子を使用することが可能である。図11に示す例では、親コンテナ1102が、自らの下に2つのコンテナノード、Node0(1104)およびNode1(1106)を有する。これらのノードのそれぞれは、2つのカラー、2次元のポイント、およびヒット試験識別子をパラメータ設定されたグラフコンテナ1116に適用するアプライノード1108、および1110をそれぞれ有する。例えば、カラーの1つが、棒線画の頭を表し、別のカラーが、棒線画胴体の残りの部分を表すことが可能である。
【０１５９】
効率的なヒット試験を提供するため、パラメータ設定されたグラフコンテナ1116の引数のどれかは、ヒット試験IDである。ヒット試験ノード1120が、各ヒット試験IDをノードに関する情報、例えば、ノードのパス情報または結合情報に関係付けるヒット試験テーブルを維持する。これは、ヒット試験中にグラフのウォークが行われる際、必ずしも必要とされない最適化に過ぎないことに留意されたい。このようにして、アプライノードのどれかで現在、構成されているパラメータ設定されたグラフコンテナ1116によって表される内容に関する情報をヒット試験IDおよび関連する情報に関係付けることができる。例えば、いくつかの棒線画が同一のサブグラフによって表される場合、前述したパラメータ設定されたグラフコンテナを介して、ヒットするそれぞれの棒線画を一意的に識別することができる。
【０１６０】
したがって、ヒット試験は、一般に、グラフの中のノードを一意的に識別することができる必要がある。同様に、変換が、サブグラフの再使用との組み合わせで、ノードの固有識別子を必要とする可能性がある。例えば変換が、1つのサブグラフに対して、別のサブグラフ(さらに別のサブグラフとの関係にあることが可能な)との関係でスケーリング(ファクタによるズーム)、オフセット、回転等を行うことが可能である。本発明の実施形態は、1つの座標空間から別の座標空間に対する次元、場所、サイズ等の相対値を使用して機能して、スクロール、ヒット試験、選択、その他が容易になるようにすることが可能である。ただし、シーングラフの中で再使用が存在する場合、再使用されるノードのどのインスタンスが、相対的変換のための基礎として使用されているかを識別するのに固有識別子が必要とされる。1つの解決策は、ルートからサブグラフを通りノードに至るパスを使用してパラメータ設定されたグラフコンテナの1つの使用を特定することである。
【０１６１】
また、サブグラフを介するパラメータ設定を使用してシステムを拡張することも可能である。以下のMutableValueが、これを可能にする。
【０１６２】
【表２０】
ドローイングコンテキストに以下の関数が追加される。
DrawGraphContainer(GraphContainerValue,
params MutableValue[] parameters);
【０１６４】
ドローイング動作が、GraphContainerValueに対するリファレンスを記憶する特別アプライノードを挿入する。アプライノードの子を取ってレンダリングを継続する代わりに、レンダリングアルゴリズムは、特別アプライノード上に記憶された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 グラフコンテナ
Claims (42)
- コンピュータ環境において、コンピュータに、
１組の少なくとも１つの関数を含むインターフェースをシーングラフに提供する手段と、
前記インターフェースを介して、前記シーングラフのコンテナの中に変数を含める要求を受け取り、そこでは前記変数が、前記インターフェースを介して受け取られる別の要求によって変更されることが可能な値を有する手段と、および
前記シーングラフに対応するグラフィックス命令を提供し、前記シーングラフのレンダリングを行い、そこでは前記命令が、前記変数の現行の値に基づくデータを含む手段と、
新しい値を待ち行列に入れる手段と、
別の変数の値を変更する別の要求を受け取る手段であって、そこでは前記別の要求が、前記別の変数に関する別の新しい値に対応するデータを含む手段と、
別の新しい値を待ち行列に入れる手段として機能させ、前記シーングラフをレンダリングする手段が、各新しい値を待ち行列から出して、各新しい値をそれぞれの変数に適用することを特徴とするプログラム。 - 前記コンピュータに、さらに、前記変数の値を変更する要求を受け取る手段として機能させ、前記要求が、前記変数に関する新しい値に対応するデータを含むことを特徴とする請求項１に記載のプログラム。
- 前記コンピュータに、前記シーングラフをレンダリングする手段として機能させ、前記新しい値を前記変数に適用して、前記新しい値が前記現行の値になるようにすることを特徴とする請求項１に記載のプログラム。
- 前記コンピュータに、別の変数の値を変更する別の要求を受け取る手段であって、そこでは前記別の要求が、前記別の変数に関する別の新しい値に対応するデータを含み、および前記別の新しい値を待ち行列に入れる手段としてさらに機能させ、前記シーングラフをレンダリングする手段が、各新しい値を待ち行列から出して、各新しい値をそれぞれの変数に適用することを特徴とする請求項１に記載のプログラム。
- 前記変数の現行の値を戻す要求を受け取るステップをさらに含むことを特徴とする請求項１に記載のプログラム。
- 前記シーングラフをレンダリングする手段が、第１の動作速度で実行されて低レベルの構成要素に前記命令を提供する高レベルの構成要素を含み、
前記シーングラフをレンダリングする手段はさらに前記低レベルの構成要素を第２の動作速度で動作させて、前記命令に基づくドローイングコマンドをグラフィックスサブシステムに提供し、
前記第２の動作速度が、前記第１の動作速度より速く、かつ前記グラフィックスサブシステムのフレーム速度に対応することを特徴とする請求項１に記載のプログラム。 - 前記変数が、前記コンテナによって表される内容の位置に対応し、
前記コンピュータに前記変数の値を時間とともに変化させる一続きの要求を受け取る手段としてさらに機能させ、
各要求が、前記変数に関する新しい位置の値に対応するデータを含むことを特徴とする請求項１に記載のプログラム。 - 前記変数が、前記コンテナによって表される内容の外観に対応し、
前記コンピュータに前記変数の値を変更する少なくとも１つの要求を受け取る手段として機能させ、
各要求が、前記変数に関する新しい外観値に対応するデータを含むことを特徴とする請求項１に記載のプログラム。 - コンピュータに、
シーングラフに対する１組の少なくとも１つの関数を含むインターフェースを提供する手段と、
前記インターフェースを介して、前記シーングラフのコンテナの中に変数を含める要求を受け取り、そこでは前記変数が、前記インターフェースを介して受け取られる別の要求によって変更されることが可能な値を有する手段と、および
前記シーングラフに対応するグラフィックス命令を提供し、前記シーングラフのレンダリングを行い、そこでは前記命令が、前記変数の現行の値に基づくデータを含む手段と、
前記コンピュータに前記変数の値を変更する要求を受け取る手段であって、前記要求が、前記変数に関する新しい値に対応するデータを含む手段と、
前記新しい値および別の新しい値を待ち行列に入れる手段と
してさらに機能させ、前記シーングラフをレンダリングする手段が、各新しい値を待ち行列から出して、各新しい値をそれぞれの変数に適用することを特徴とするプログラムを記録したコンピュータ可読媒体。 - 前記シーングラフをレンダリングする手段が、第１の動作速度で実行されて低レベルの構成要素に前記命令を提供する高レベルの構成要素を含み、
前記プログラムは、前記コンピュータに、
前記低レベルの構成要素を第２の動作速度で動作させて、前記命令に基づくドローイングコマンドをグラフィックスサブシステムに提供する手段として機能させ、前記第２の動作速度が、前記第１の動作速度より速く、かつ前記グラフィックスサブシステムのフレーム速度に対応することを特徴とする請求項９に記載のコンピュータ可読媒体。 - 前記変数が、前記コンテナによって表される内容の位置に対応し、
前記プログラムは、前記コンピュータに、
前記変数の値を時間とともに変化させる一続きの要求を受け取る手段としてさらに機能させ、
各要求が、前記変数に関する新しい位置の値に対応するデータを含むことを特徴とする請求項９に記載のコンピュータ可読媒体。 - 前記変数が、前記コンテナによって表される内容の外観に対応し、
前記プログラムは、前記コンピュータに、
前記変数の値を変更する少なくとも１つの要求を受け取る手段としてさらに機能させ、
各要求が、前記変数に関する新しい外観値に対応するデータを含むことを特徴とする請求項９に記載のコンピュータ可読媒体。 - コンピュータ環境において、
トラバースされたとき、データを出力するための１組の命令を提供する複数のコンテナを含むシーングラフおよび変更することが可能な１組の少なくとも１つの変数値に対応するパラメータ設定されたグラフコンテナを記憶した記憶手段と、
前記変数値に関する実際の値を判定し、前記実際の値に対応するデータを前記１組の命令の中に入れる処置を行うことを含めて、前記シーングラフのトラバースを行う情報処理手段とを含み、
前記記憶手段はさらに、可変変換コンテナに接続されて、前記変換コンテナが、変数を介して時間とともにアニメートされる、または変更されるようになされたパラメータ設定されたサブシーングラフをさらに記憶したことを特徴とするシステム。 - 前記１組の少なくとも１つの変数値が、前記パラメータ設定されたグラフコンテナに関連するテーブルの中に維持されることを特徴とする請求項１３に記載のシステム。
- 前記テーブルが、前記１組の中の各変数値に関するタイプ情報を含むことを特徴とする請求項１４に記載のシステム。
- 前記パラメータ設定されたグラフコンテナが、前記１組の中の各変数値に関するタイプ情報に関連することを特徴とする請求項１３に記載のシステム。
- 少なくとも１つのタイプが、前記パラメータ設定されたグラフコンテナによって表される内容のプロパティに対応することを特徴とする請求項１３に記載のシステム。
- 少なくとも１つのタイプが、前記パラメータ設定されたグラフコンテナによって表される内容の外観に対応することを特徴とする請求項１３に記載のシステム。
- 少なくとも１つのタイプが、前記パラメータ設定されたグラフコンテナによって表される内容の識別に対応することを特徴とする請求項１３に記載のシステム。
- 少なくとも１つのタイプが、前記パラメータ設定されたグラフコンテナによって表される内容の位置に対応することを特徴とする請求項１３に記載のシステム。
- 前記パラメータ設定されたグラフコンテナが、前記１組の中の各変数値に関するタイプ情報に関連し、また少なくとも１つのタイプが、前記パラメータ設定されたグラフコンテナによって表される内容に関するヒット試験識別子に対応することを特徴とする請求項１３に記載のシステム。
- 前記記憶手段は、アプライノードおよびパラメータ設定されたノードをさらに記憶し、前記アプライノードが、前記パラメータ設定されたノードによって使用されるための少なくとも１つの値を提供することを特徴とする請求項１３に記載のシステム。
- 前記記憶手段は、前記アプライノードに関連する変換ノードをさらに記憶し、前記変換ノードが、前記パラメータ設定されたグラフコンテナによって表される内容の位置を変更するように構成されることを特徴とする請求項２２に記載のシステム。
- 前記記憶手段は、前記アプライノードに関連する変換ノード、およびアニメーションエンジンをさらに記憶し、前記変換ノードが、前記アニメーションエンジンからのデータに基づいて前記パラメータ設定されたグラフコンテナによって表される内容の位置を変更するように構成され、前記アニメーションエンジンが、時間とともに前記データを変更して、前記内容が時間とともに位置を変化させるようにすることを特徴とする請求項２２に記載のシステム。
- 前記記憶手段は、前記アプライノードに関連する効果ノードをさらに記憶し、前記効果ノードが、前記パラメータ設定されたグラフコンテナによって表される内容の効果を変更するように構成されることを特徴とする請求項２２に記載のシステム。
- 前記記憶手段は、前記アプライノードに関連する効果ノードをさらに記憶し、前記システムは、アニメーションエンジンをさらに有し、前記効果ノードが、前記アニメーションエンジンからのデータに基づいて前記パラメータ設定されたグラフコンテナによって表される内容を変更するように構成され、前記アニメーションエンジンが、時間とともに前記データを変更して、前記内容が時間とともに外観を変化させるようにすることを特徴とする請求項２２に記載のシステム。
- 前記変数値に関する別の実際の値を維持する別のアプライノードをさらに含み、
前記情報処理手段が、前記別のアプライノードにアクセスして、前記１組の命令の中に出力する別の実際の値を決定することを特徴とする請求項２２に記載のシステム。 - 前記記憶手段は、前記変数値に関するリファレンスを維持する別のアプライノードをさらに記憶し、
前記情報処理手段が、前記リファレンスにアクセスして、前記１組の命令の中に出力する別の実際の値を決定することを特徴とする請求項２２に記載のシステム。 - 前記パラメータ設定されたサブシーングラフが、アプライノードを介して可変変換コンテナに接続されることを特徴とする請求項２８に記載のシステム。
- 前記記憶手段は、可変変換コンテナに接続されて、前記変換コンテナが、外部のパラメータ設定されたコンテナから受け取られた値を介して時間とともにアニメートされる、または変更されるようになされたパラメータ設定されたサブシーングラフをさらに記憶したことを特徴とする請求項１３に記載のシステム。
- 前記パラメータ設定されたサブシーングラフが、アプライノードを介して可変変換コンテナに接続されることを特徴とする請求項３０に記載のシステム。
- 前記記憶手段が第１のアプライノードおよび第２のアプライノードをさらに含むシステムであって、
前記第１のアプライノードが、前記変数値に関する実際の値を維持し、また前記第２のアプライノードが、前記変数値に関する別の実際の値を維持し、前記情報処理手段が、前記第１のアプライノードにアクセスして前記実際の値を判定し、かつ前記第２のアプライノードにアクセスして前記別の実際の値を判定し、かつ前記１組の命令の中に前記別の実際の値に対応する別のデータを入れて、前記データおよび前記別のデータを有する同一の１組の命令の中で前記パラメータ設定されたグラフコンテナを再使用することができるようにすることを特徴とする請求項１３に記載のシステム。 - 前記情報処理手段が、第１の動作速度で実行されて低レベルの構成要素に前記１組の命令を提供する高レベルの構成要素を含み、前記低レベルの構成要素が、第２の動作速度で実行されて、前記命令に基づくドローイングコマンドをグラフィックスサブシステムに提供し、また前記第２の動作速度が、前記第１の動作速度より速く、かつ前記グラフィックスサブシステムのフレーム速度に対応することを特徴とする請求項１３に記載のシステム。
- 前記記憶手段は、アルファコンテナをさらに記憶し、サブシーングラフを変更することができるようにアルファ値が変数に付加されることを特徴とする請求項１３に記載のシステム。
- グラフィックス命令を出力するためのプログラムであって、コンピュータに、
自らにコンテナを追加するためのインターフェースを含むシーングラフを提供する手段と、
前記シーングラフにパラメータ設定されたグラフコンテナを追加する要求を受け取り、そこでは前記パラメータ設定されたグラフコンテナが、内容を表し、変更することが可能な１組の少なくとも１つの変数値に対応する手段と、および
前記１組の中の各変数値に関する第１の実際の値を判定して、命令ストリームの中に各第１の実際の値に対応する第１のデータを入れ、および前記１組の中の各変数値に関する第２の実際の値を判定して、前記命令ストリームの中に各第２の実際の値に対応する第２のデータを入れ、前記シーングラフからの前記命令ストリームのレンダリングを行う手段として機能させ、
前記各変数に関する第１の実際の値を判定する処理が、第１のアプライノードにアクセスする処理を含み、前記各変数に関する第２の実際の値を判定する処理が、第２のアプライノードにアクセスする処理を含み、
前記１組の中の１つの変数が位置変数に対応し、前記位置変数に関する前記第１の実際の値と前記第２の実際の値が相違し、前記命令ストリームが、異なる位置を有する前記内容の２つのインスタンスに関する命令を含み、
前記プログラムは、前記コンピュータに、さらに、前記第１のアプライノードにおいて、位置変数に対応する前記１組の中の前記１つの変数の値を時間とともに変化させて、前記内容の第１の位置が時間とともに変化させる手段として機能させることを特徴とするプログラム。 - 前記１組の中の各変数値に関するタイプ情報を含むテーブルが前記コンピュータの記憶デバイスに格納されることを特徴とする請求項３５に記載のプログラム。
- プログラムを記録したコンピュータ可読媒体であって、前記プログラムは、コンピュータに、
自らにコンテナを追加するためのインターフェースを含むシーングラフを提供する手段と、
前記シーングラフにパラメータ設定されたグラフコンテナを追加する要求を受け取り、そこでは前記パラメータ設定されたグラフコンテナが、内容を表し、変更することが可能な１組の少なくとも１つの変数値に対応する手段と、および
前記１組の中の各変数値に関する第１の実際の値を判定して、命令ストリームの中に各第１の実際の値に対応する第１のデータを入れ、および前記１組の中の各変数値に関する第２の実際の値を判定して、前記命令ストリームの中に各第２の実際の値に対応する第２のデータを入れ、前記シーングラフからの前記命令ストリームのレンダリングを行う手段として機能させ、
前記１組の中の１つの変数が位置変数に対応し、前記位置変数に関する前記第１の実際の値と前記第２の実際の値が相違し、前記命令ストリームが、異なる位置を有する前記内容の２つのインスタンスに関する命令を含み、
前記プログラムは、前記コンピュータに、第１のアプライノードにおいて、位置変数に対応する前記１組の中の前記１つの変数の値を時間とともに変化させて、前記内容の第１の位置が時間とともに変化させる手段としてさらに機能させることを特徴とするコンピュータ可読媒体。 - テーブルが、前記１組の中の各変数値に関するタイプ情報を含むことを特徴とする請求項３７に記載のコンピュータ可読媒体。
- 前記プログラムは前記コンピュータに、各第１の実際の値および各第２の実際の値が前記タイプ情報にマッチするのを確認する手段としてさらに機能させることを特徴とする請求項３８に記載のコンピュータ可読媒体。
- 第１のプロセスと第２のプロセスの間で通信するためのプログラムであって、コンピュータに、
前記第１のプロセスにおいて、自らにコンテナを追加するためのインターフェースを含むシーングラフを提供する手段と、
前記第２のプロセスから、前記シーングラフにパラメータ設定されたグラフコンテナを追加する要求を受け取り、前記パラメータ設定されたグラフコンテナが、内容を表し、変更することが可能な１組の少なくとも１つの変数値に対応する手段と、および
前記第１のプロセスにおいて、前記１組の中の各変数値に関する第１の実際の値を判定して、前記命令ストリームの中に各第１の実際の値に対応する第１のデータを入れ、および前記１組の中の各変数値に関する第２の実際の値を判定して、命令ストリームの中に各第２の実際の値に対応する第２のデータを入れ、前記シーングラフからの前記命令ストリームのレンダリングを行う手段として機能させ、
前記１組の中の１つの変数が位置変数に対応し、前記位置変数に関する前記第１の実際の値と前記第２の実際の値が相違し、前記命令ストリームが、異なる位置を有する前記内容の２つのインスタンスに関する命令を含み、
前記プログラムは前記コンピュータに、さらに第１のアプライノードにおいて、位置変数に対応する前記１組の中の前記１つの変数の値を時間とともに変化させて、前記内容の第１の位置を時間とともに変化させる手段として機能させることを特徴とするプログラム。 - 前記１組の中の各変数値に関するタイプ情報を含むテーブルが前記コンピュータの記憶デバイスに格納されることを特徴とする請求項４０に記載のプログラム。
- 前記コンピュータに、各第１の実際の値および各第２の実際の値が前記タイプ情報にマッチするのを確認する手段としてさらに機能させることを特徴とする請求項４１に記載のプログラム。
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US33023101P | 2001-10-18 | 2001-10-18 | |
| US60/330,231 | 2001-10-18 | ||
| US10/184,796 US6919891B2 (en) | 2001-10-18 | 2002-06-27 | Generic parameterization for a scene graph |
| US10/184,796 | 2002-06-27 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003162733A JP2003162733A (ja) | 2003-06-06 |
| JP2003162733A5 JP2003162733A5 (ja) | 2005-12-02 |
| JP4374590B2 true JP4374590B2 (ja) | 2009-12-02 |
Family
ID=26880480
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002304896A Expired - Fee Related JP4374590B2 (ja) | 2001-10-18 | 2002-10-18 | シーングラフのための汎用パラメータ設定 |
Country Status (3)
| Country | Link |
|---|---|
| US (2) | US6919891B2 (ja) |
| EP (1) | EP1304655A3 (ja) |
| JP (1) | JP4374590B2 (ja) |
Families Citing this family (72)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1430666B1 (en) * | 2001-09-27 | 2005-08-31 | Matsushita Electric Industrial Co., Ltd. | Transmission method, sending device and receiving device |
| US7443401B2 (en) * | 2001-10-18 | 2008-10-28 | Microsoft Corporation | Multiple-level graphics processing with animation interval generation |
| US7064766B2 (en) | 2001-10-18 | 2006-06-20 | Microsoft Corporation | Intelligent caching data structure for immediate mode graphics |
| US6919891B2 (en) | 2001-10-18 | 2005-07-19 | Microsoft Corporation | Generic parameterization for a scene graph |
| US7619633B2 (en) | 2002-06-27 | 2009-11-17 | Microsoft Corporation | Intelligent caching data structure for immediate mode graphics |
| US7161599B2 (en) * | 2001-10-18 | 2007-01-09 | Microsoft Corporation | Multiple-level graphics processing system and method |
| US7417645B2 (en) * | 2003-03-27 | 2008-08-26 | Microsoft Corporation | Markup language and object model for vector graphics |
| US7088374B2 (en) * | 2003-03-27 | 2006-08-08 | Microsoft Corporation | System and method for managing visual structure, timing, and animation in a graphics processing system |
| US7486294B2 (en) * | 2003-03-27 | 2009-02-03 | Microsoft Corporation | Vector graphics element-based model, application programming interface, and markup language |
| AU2004279179B8 (en) * | 2003-03-27 | 2009-11-19 | Microsoft Technology Licensing, Llc | Visual and scene graph interfaces |
| US7126606B2 (en) * | 2003-03-27 | 2006-10-24 | Microsoft Corporation | Visual and scene graph interfaces |
| US7466315B2 (en) * | 2003-03-27 | 2008-12-16 | Microsoft Corporation | Visual and scene graph interfaces |
| US8751950B2 (en) * | 2004-08-17 | 2014-06-10 | Ice Edge Business Solutions Ltd. | Capturing a user's intent in design software |
| US7511718B2 (en) * | 2003-10-23 | 2009-03-31 | Microsoft Corporation | Media integration layer |
| US7012606B2 (en) * | 2003-10-23 | 2006-03-14 | Microsoft Corporation | System and method for a unified composition engine in a graphics processing system |
| KR100703677B1 (ko) * | 2004-01-08 | 2007-04-05 | 삼성전자주식회사 | 동적 메모리 관리 장치 및 방법 |
| US7539982B2 (en) * | 2004-05-07 | 2009-05-26 | International Business Machines Corporation | XML based scripting language |
| WO2006020001A2 (en) * | 2004-07-15 | 2006-02-23 | The Regents Of The University Of California | Fast multi-pass partitioning via priority based scheduling |
| WO2009111885A1 (en) | 2008-03-11 | 2009-09-17 | Dirtt Environmental Solutions, Ltd. | Automatically creating and modifying furniture layouts in design software |
| US7603624B2 (en) * | 2004-10-21 | 2009-10-13 | Microsoft Corporation | System and method for styling content in a graphical user interface control |
| US20060232589A1 (en) * | 2005-04-19 | 2006-10-19 | Microsoft Corporation | Uninterrupted execution of active animation sequences in orphaned rendering objects |
| US7619628B2 (en) * | 2005-06-24 | 2009-11-17 | Microsoft Corporation | Caching digital image data |
| US7535480B2 (en) * | 2005-08-24 | 2009-05-19 | Microsoft Corporation | Compositing rendering layers |
| US7441230B2 (en) | 2005-10-07 | 2008-10-21 | Lucasfilm Entertainment Company Ltd. | Method of utilizing product proxies with a dependency graph |
| US7782324B2 (en) | 2005-11-23 | 2010-08-24 | Dreamworks Animation Llc | Non-hierarchical unchained kinematic rigging technique and system for animation |
| US7868893B2 (en) * | 2006-03-07 | 2011-01-11 | Graphics Properties Holdings, Inc. | Integration of graphical application content into the graphical scene of another application |
| US7840388B2 (en) * | 2006-06-26 | 2010-11-23 | Yokogawa Electric Corporation | Engineering device |
| US7609271B2 (en) * | 2006-06-30 | 2009-10-27 | Microsoft Corporation | Producing animated scenes from still images |
| US9019300B2 (en) * | 2006-08-04 | 2015-04-28 | Apple Inc. | Framework for graphics animation and compositing operations |
| US8130226B2 (en) * | 2006-08-04 | 2012-03-06 | Apple Inc. | Framework for graphics animation and compositing operations |
| US7614003B2 (en) * | 2006-10-23 | 2009-11-03 | Adobe Systems Incorporated | Rendering hypertext markup language content |
| US8490117B1 (en) | 2006-10-23 | 2013-07-16 | Adobe Systems Incorporated | Bridging script engines |
| US8020089B1 (en) | 2006-10-23 | 2011-09-13 | Adobe Systems Incorporated | Rendering hypertext markup language content |
| US8234392B2 (en) | 2006-11-17 | 2012-07-31 | Apple Inc. | Methods and apparatuses for providing a hardware accelerated web engine |
| US20080183608A1 (en) * | 2007-01-26 | 2008-07-31 | Andrew Gavin | Payment system and method for web-based video editing system |
| US20080186307A1 (en) * | 2007-02-05 | 2008-08-07 | Yaron Leifenberg | Method and a protocol for describing procedural content for games |
| JP5010000B2 (ja) | 2007-03-15 | 2012-08-29 | ジーブイビービー ホールディングス エス．エイ．アール．エル． | シーングラフ中のパラメータのアクセス性および制御のための方法およびシステム |
| CN101647270A (zh) * | 2007-04-11 | 2010-02-10 | 汤姆森许可贸易公司 | 用于增强数字视频效果（dve）的方法和装置 |
| US20080307304A1 (en) * | 2007-06-07 | 2008-12-11 | Ernst Feiler | Method and system for producing a sequence of views |
| US8274516B2 (en) * | 2008-08-04 | 2012-09-25 | Microsoft Corporation | GPU scene composition and animation |
| US8612485B2 (en) * | 2008-08-11 | 2013-12-17 | Sony Corporation | Deferred 3-D scenegraph processing |
| US8316357B2 (en) * | 2008-09-03 | 2012-11-20 | Microsoft Corporation | Type descriptor management for frozen objects |
| US8725466B2 (en) | 2008-10-14 | 2014-05-13 | Cct International, Inc. | System and method for hybrid solid and surface modeling for computer-aided design environments |
| US8477136B2 (en) * | 2009-02-13 | 2013-07-02 | Mobitv, Inc. | Functional presentation layer in a lightweight client architecture |
| US20130069954A1 (en) * | 2009-05-29 | 2013-03-21 | David Tristram | Method of Transforming Time-Based Drawings and Apparatus for Performing the Same |
| US20130069956A1 (en) * | 2009-05-29 | 2013-03-21 | David Tristram | Transforming Time-Based Drawings |
| US20130069955A1 (en) * | 2009-05-29 | 2013-03-21 | David Tristram | Hierarchical Representation of Time |
| US20130132840A1 (en) * | 2011-02-28 | 2013-05-23 | Joaquin Cruz Blas, JR. | Declarative Animation Timelines |
| FR2974474B1 (fr) * | 2011-04-19 | 2017-11-17 | Prologue | Procedes et appareils de production et de traitement de representations de scenes multimedias |
| US9563971B2 (en) | 2011-09-09 | 2017-02-07 | Microsoft Technology Licensing, Llc | Composition system thread |
| US9342322B2 (en) | 2011-09-12 | 2016-05-17 | Microsoft Technology Licensing, Llc | System and method for layering using tile-based renderers |
| EP2584464B1 (en) * | 2011-10-18 | 2020-02-19 | BlackBerry Limited | Method of rendering a user interface |
| US9075631B2 (en) | 2011-10-18 | 2015-07-07 | Blackberry Limited | Method of rendering a user interface |
| US20130278607A1 (en) * | 2012-04-20 | 2013-10-24 | A Thinking Ape Technologies | Systems and Methods for Displaying Animations on a Mobile Device |
| US9075618B2 (en) | 2012-11-02 | 2015-07-07 | Microsoft Technology Licensing, Llc | Cross-platform data visualizations using common descriptions |
| US9224239B2 (en) | 2013-03-14 | 2015-12-29 | Dreamworks Animation Llc | Look-based selection for rendering a computer-generated animation |
| US9171401B2 (en) | 2013-03-14 | 2015-10-27 | Dreamworks Animation Llc | Conservative partitioning for rendering a computer-generated animation |
| US9589382B2 (en) | 2013-03-15 | 2017-03-07 | Dreamworks Animation Llc | Render setup graph |
| US9626787B2 (en) | 2013-03-15 | 2017-04-18 | Dreamworks Animation Llc | For node in render setup graph |
| US9811936B2 (en) | 2013-03-15 | 2017-11-07 | Dreamworks Animation L.L.C. | Level-based data sharing for digital content production |
| US9218785B2 (en) | 2013-03-15 | 2015-12-22 | Dreamworks Animation Llc | Lighting correction filters |
| US9659398B2 (en) | 2013-03-15 | 2017-05-23 | Dreamworks Animation Llc | Multiple visual representations of lighting effects in a computer animation scene |
| US9208597B2 (en) | 2013-03-15 | 2015-12-08 | Dreamworks Animation Llc | Generalized instancing for three-dimensional scene data |
| US9514562B2 (en) | 2013-03-15 | 2016-12-06 | Dreamworks Animation Llc | Procedural partitioning of a scene |
| US9230294B2 (en) | 2013-03-15 | 2016-01-05 | Dreamworks Animation Llc | Preserving and reusing intermediate data |
| DE112015006547T5 (de) * | 2015-05-19 | 2018-02-15 | Mitsubishi Electric Corporation | Benutzerschnittstellen-Einrichtung und Verfahren zum Anzeigen eines Bildschirms einer Benutzerschnittstellen-Einrichtung |
| JP7127959B2 (ja) * | 2015-12-23 | 2022-08-30 | トムテック イメージング システムズ ゲゼルシャフト ミット ベシュレンクテル ハフツング | 医療調査データをレビューするための方法及びシステム |
| US10546411B2 (en) * | 2016-03-31 | 2020-01-28 | Intel Corporation | Directed acyclic graph path enumeration with application in multilevel instancing |
| US10347043B2 (en) * | 2017-05-16 | 2019-07-09 | Apple Inc. | Core animation portals |
| US20210073429A1 (en) * | 2019-09-10 | 2021-03-11 | Apple Inc. | Object Relationship Estimation From A 3D Semantic Mesh |
| US11640708B1 (en) | 2020-04-16 | 2023-05-02 | Apple Inc. | Scene graph-based scene re-identification |
| US20220134222A1 (en) * | 2020-11-03 | 2022-05-05 | Nvidia Corporation | Delta propagation in cloud-centric platforms for collaboration and connectivity |
Family Cites Families (64)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4209852A (en) | 1974-11-11 | 1980-06-24 | Hyatt Gilbert P | Signal processing and memory arrangement |
| US5261041A (en) | 1990-12-28 | 1993-11-09 | Apple Computer, Inc. | Computer controlled animation system based on definitional animated objects and methods of manipulating same |
| US5852449A (en) * | 1992-01-27 | 1998-12-22 | Scientific And Engineering Software | Apparatus for and method of displaying running of modeled system designs |
| US5500933A (en) | 1993-04-28 | 1996-03-19 | Canon Information Systems, Inc. | Display system which displays motion video objects combined with other visual objects |
| DE69405388T2 (de) | 1993-05-10 | 1998-03-19 | Taligent Inc | Multimedia synchronisationssystem |
| US5555368A (en) | 1993-12-30 | 1996-09-10 | Taligent | Object-oriented multi-tasking view framework |
| US5912666A (en) | 1994-08-23 | 1999-06-15 | Object Technology Licensing Corp. | Object-oriented global cursor tool |
| US5986667A (en) | 1994-12-22 | 1999-11-16 | Apple Computer, Inc. | Mechanism for rendering scenes using an object drawing subsystem |
| US5930810A (en) | 1995-08-09 | 1999-07-27 | Taylor Corporation | Printing system with pre-defined user modifiable forms and local and remote printing |
| US5986675A (en) | 1996-05-24 | 1999-11-16 | Microsoft Corporation | System and method for animating an object in three-dimensional space using a two-dimensional input device |
| US6275857B1 (en) | 1996-10-30 | 2001-08-14 | Microsoft Corporation | System and method for freeing shared resources in a computer system |
| US5920325A (en) | 1996-11-20 | 1999-07-06 | International Business Machines Corporation | Prioritization of background display during animation |
| US6137499A (en) | 1997-03-07 | 2000-10-24 | Silicon Graphics, Inc. | Method, system, and computer program product for visualizing data using partial hierarchies |
| US6195694B1 (en) | 1997-03-13 | 2001-02-27 | International Business Machines Corporation | Server for reconfiguring control of a subset of devices on one or more kiosks |
| JP4726097B2 (ja) | 1997-04-07 | 2011-07-20 | エイ・ティ・アンド・ティ・コーポレーション | 適応制御を行うことができるｍｐｅｇコード化オーディオ・ビジュアル対象物をインターフェースで連結するためのシステムおよび方法 |
| US6215495B1 (en) * | 1997-05-30 | 2001-04-10 | Silicon Graphics, Inc. | Platform independent application program interface for interactive 3D scene management |
| US5924098A (en) | 1997-06-30 | 1999-07-13 | Sun Microsystems, Inc. | Method and apparatus for managing a linked-list data structure |
| US6377263B1 (en) | 1997-07-07 | 2002-04-23 | Aesthetic Solutions | Intelligent software components for virtual worlds |
| US6314470B1 (en) | 1997-07-25 | 2001-11-06 | Hewlett Packard Company | System and method for asynchronously accessing a graphics system for graphics application evaluation and control |
| US6154215A (en) * | 1997-08-01 | 2000-11-28 | Silicon Graphics, Inc. | Method and apparatus for maintaining multiple representations of a same scene in computer generated graphics |
| US6272650B1 (en) | 1998-02-03 | 2001-08-07 | Amazing Media, Inc. | System and method for disambiguating scene graph loads |
| US6243856B1 (en) | 1998-02-03 | 2001-06-05 | Amazing Media, Inc. | System and method for encoding a scene graph |
| US6075532A (en) | 1998-03-23 | 2000-06-13 | Microsoft Corporation | Efficient redrawing of animated windows |
| US6266053B1 (en) | 1998-04-03 | 2001-07-24 | Synapix, Inc. | Time inheritance scene graph for representation of media content |
| US6237092B1 (en) | 1998-05-05 | 2001-05-22 | International Business Machines Corp. | Client-server system with central application management allowing an administrator to configure user and group contexts during application configuration without relaunching the application |
| EP1090505A1 (en) | 1998-06-26 | 2001-04-11 | General Instrument Corporation | Terminal for composing and presenting mpeg-4 video programs |
| US6731314B1 (en) | 1998-08-17 | 2004-05-04 | Muse Corporation | Network-based three-dimensional multiple-user shared environment apparatus and method |
| US6487565B1 (en) * | 1998-12-29 | 2002-11-26 | Microsoft Corporation | Updating animated images represented by scene graphs |
| US6411297B1 (en) | 1999-03-03 | 2002-06-25 | Discreet Logic Inc. | Generating image data |
| US6714201B1 (en) | 1999-04-14 | 2004-03-30 | 3D Open Motion, Llc | Apparatuses, methods, computer programming, and propagated signals for modeling motion in computer applications |
| US6986101B2 (en) | 1999-05-06 | 2006-01-10 | International Business Machines Corporation | Method and apparatus for converting programs and source code files written in a programming language to equivalent markup language files |
| DE19932630C2 (de) * | 1999-07-13 | 2003-12-04 | Perkin Elmer Bodenseewerk Zwei | Einheit für eine Plasma-Atomisierungsvorrichtung mit Plasma-Gaszuführeinrichtung, Probenzerstäubereinrichtung und Probeninjektionseinrichtung |
| US6707456B1 (en) | 1999-08-03 | 2004-03-16 | Sony Corporation | Declarative markup for scoring multiple time-based assets and events within a scene composition system |
| US6765571B2 (en) | 1999-09-24 | 2004-07-20 | Sun Microsystems, Inc. | Using a master controller to manage threads and resources for scene-based rendering |
| US7184038B2 (en) | 1999-09-24 | 2007-02-27 | Sun Microsystems, Inc. | Using render bin parallelism for rendering scene graph based graphics data |
| US6538656B1 (en) | 1999-11-09 | 2003-03-25 | Broadcom Corporation | Video and graphics system with a data transport processor |
| US7546577B2 (en) | 1999-12-06 | 2009-06-09 | Axiomatic Design Software, Inc. | Method and apparatus for producing software |
| JP2001273520A (ja) | 2000-03-23 | 2001-10-05 | Famotik Ltd | マルチメディアドキュメント統合表示システム |
| US6751655B1 (en) * | 2000-04-18 | 2004-06-15 | Sun Microsystems, Inc. | Method and apparatus for transport of scenegraph information across a network |
| US6717599B1 (en) | 2000-06-29 | 2004-04-06 | Microsoft Corporation | Method, system, and computer program product for implementing derivative operators with graphics hardware |
| WO2002013002A2 (en) | 2000-08-04 | 2002-02-14 | Intrinsic Graphics, Inc. | Development of graphics hardware and software |
| US6675230B1 (en) | 2000-08-22 | 2004-01-06 | International Business Machines Corporation | Method, system, and program for embedding a user interface object in another user interface object |
| US6910044B2 (en) | 2000-09-20 | 2005-06-21 | Sap Aktiengesellschaft | Method and apparatus for structuring, maintaining, and using families of data |
| US6732109B2 (en) | 2001-01-31 | 2004-05-04 | The Eon Company | Method and system for transferring information between a user interface and a database over a global information network |
| US7069503B2 (en) | 2001-06-04 | 2006-06-27 | Murata Kikai Kabushiki Kaisha | Device and program for structured document generation data structure of structural document |
| US7305011B2 (en) | 2001-06-14 | 2007-12-04 | International Business Machines Corporation | Periodic broadcast and location of evolving media content with application to seminar and stroke media |
| US7161599B2 (en) | 2001-10-18 | 2007-01-09 | Microsoft Corporation | Multiple-level graphics processing system and method |
| US7064766B2 (en) | 2001-10-18 | 2006-06-20 | Microsoft Corporation | Intelligent caching data structure for immediate mode graphics |
| US6919891B2 (en) | 2001-10-18 | 2005-07-19 | Microsoft Corporation | Generic parameterization for a scene graph |
| US7055092B2 (en) | 2001-12-05 | 2006-05-30 | Canon Kabushiki Kaisha | Directory for multi-page SVG document |
| US20030110297A1 (en) | 2001-12-12 | 2003-06-12 | Tabatabai Ali J. | Transforming multimedia data for delivery to multiple heterogeneous devices |
| US20040110490A1 (en) | 2001-12-20 | 2004-06-10 | Steele Jay D. | Method and apparatus for providing content to media devices |
| KR100453225B1 (ko) | 2001-12-26 | 2004-10-15 | 한국전자통신연구원 | 3차원 가상 현실 구현을 위한 클라이언트 시스템과 이를이용한 가상 현실 구현 방법 |
| US7076332B2 (en) | 2002-01-18 | 2006-07-11 | National Instruments Corporation | System and method for invoking execution of a sequence of operations that includes motion control, machine vision, and data acquisition (DAQ) functionality |
| AU2003202131A1 (en) | 2002-02-04 | 2003-09-02 | Mobileaware Technologies Limited | Document transformation |
| WO2004008316A2 (en) | 2002-07-11 | 2004-01-22 | Raytheon Company | System and method for asynchronous storage and playback of a system state |
| WO2004008303A2 (en) | 2002-07-12 | 2004-01-22 | Raytheon Company | Scene graph based display for desktop applications |
| US20040216139A1 (en) | 2002-08-21 | 2004-10-28 | Rhoda Merlin A. | System controlling test/measurement devices on a network using markup language documents and methods thereof |
| US7240346B2 (en) | 2002-11-13 | 2007-07-03 | Microsoft Corporation | Method and system for accessing drawing resources |
| US7088374B2 (en) | 2003-03-27 | 2006-08-08 | Microsoft Corporation | System and method for managing visual structure, timing, and animation in a graphics processing system |
| US7126606B2 (en) | 2003-03-27 | 2006-10-24 | Microsoft Corporation | Visual and scene graph interfaces |
| US7412455B2 (en) | 2003-04-30 | 2008-08-12 | Dillon David M | Software framework that facilitates design and implementation of database applications |
| US8051389B2 (en) | 2003-08-26 | 2011-11-01 | Hewlett-Packard Development Company, L.P. | Methods of displaying resources of overlapping but separate hierarchies |
| US7012606B2 (en) | 2003-10-23 | 2006-03-14 | Microsoft Corporation | System and method for a unified composition engine in a graphics processing system |
-
2002
- 2002-06-27 US US10/184,796 patent/US6919891B2/en not_active Expired - Lifetime
- 2002-10-16 EP EP02023046A patent/EP1304655A3/en not_active Withdrawn
- 2002-10-18 JP JP2002304896A patent/JP4374590B2/ja not_active Expired - Fee Related
-
2005
- 2005-06-23 US US11/165,756 patent/US7265756B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003162733A (ja) | 2003-06-06 |
| US6919891B2 (en) | 2005-07-19 |
| EP1304655A3 (en) | 2005-11-16 |
| US7265756B2 (en) | 2007-09-04 |
| US20030132937A1 (en) | 2003-07-17 |
| EP1304655A2 (en) | 2003-04-23 |
| US20050243090A1 (en) | 2005-11-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4374590B2 (ja) | シーングラフのための汎用パラメータ設定 | |
| JP4371351B2 (ja) | イミーディエイトモードグラフィックスのためのインテリジェントキャッシングデータ構造 | |
| JP4371350B2 (ja) | 多重レベル・グラフィックス処理システムおよび方法 | |
| US7619633B2 (en) | Intelligent caching data structure for immediate mode graphics | |
| US7012606B2 (en) | System and method for a unified composition engine in a graphics processing system | |
| RU2324229C2 (ru) | Визуальный и пространственный графические интерфейсы | |
| JP4796499B2 (ja) | 映像およびシーングラフインターフェイス | |
| US7548237B2 (en) | System and method for managing visual structure, timing, and animation in a graphics processing system | |
| JP2004295857A (ja) | ベクターグラフィック用のマークアップ言語およびオブジェクトモデル |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051017 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051017 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20051017 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080328 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20080626 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20080701 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20080725 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20080730 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080828 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20081028 |
|
| RD13 | Notification of appointment of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7433 Effective date: 20090130 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20090130 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090225 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20090306 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090324 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090624 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090731 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20090803 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090828 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4374590 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120918 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120918 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130918 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |