JP2008310835A

JP2008310835A - イミーディエイトモードグラフィックスのためのインテリジェントキャッシングデータ構造

Info

Publication number: JP2008310835A
Application number: JP2008251528A
Authority: JP
Inventors: Joseph S Beda; エス．ベーダジョーゼフ; Adam M Smith; エム．スミスアダム; Gerhard A Schneider; エー．シュナイダーゲルハルト; Kevin T Gallo; ティー．ギャロケビン; Ashraf A Michail; エー．マイケルアシュラフ
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2001-10-18
Filing date: 2008-09-29
Publication date: 2008-12-25
Anticipated expiration: 2022-10-18
Also published as: JP4371351B2; US7064766B2; US20030076329A1; JP4904325B2; EP1304648A3; EP1304648A2; JP2003228721A; US20060262125A1; EP1304648B1; US7477259B2

Abstract

【課題】イミーディエイトモードグラフィックスのためのインテリジェントキャッシングデータ構造を提供すること。
【解決手段】グラフィックス情報を表すオブジェクトおよびデータを介してビジュアル情報を格納するためのインテリジェントキャッシングデータ構造およびメカニズム。データ構造は、一般に、その中のビジュアル情報の分布および使用方法をインテリジェントな方式で制御するメカニズムに関連する。キャッシュデータ構造は、直接レンダリング用にトラバースすることができ、またはビジュアル情報を前処理するため別のエンティティのための命令ストリーム内にトラバースすることができる。多くのデータは、一般に、それに対する外部参照を有さず、したがってデータ構造内に格納されている、より多くの情報を、リソースを節約するように処理することができる。
【選択図】図３

Description

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

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

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

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

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

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

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

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

一言で述べると、本発明は、ビジュアル情報を格納するためのインテリジェントキャッシングデータ構造およびメカニズムを提供する。インテリジェントキャッシングデータ構造は、グラフィックス情報を表すオブジェクトとデータで満たされており、また一般に、その中のビジュアル情報を分布させ使用する方法をインテリジェントな方式で制御(たとえば、最適化)するメカニズムに関連する。

キャッシュデータ構造は、直接レンダリングのためにトラバースすることができ、(たとえば、それをビットマップにレンダリングして、ネットワークを介してウェブブラウザに送る、または、それをメモリ面にレンダリングして、レガシプログラム、システム、装置とやり取りする)、または、その中のビジュアル情報を前処理するために、より速く合成やアニメーションを実行する、より低レベルのシステムに送ることのできる命令ストリームなどにトラバースすることができる。データ構造も、ネットワークを介してリモート端末に送ったり、プリンタに送ったりするなど、別の方式で前処理することができる。

データ構造は、アプリケーションプログラムなどによって提供されたデータおよびその他の構造を有し、そのデータの多くは、一般に、それに対する外部参照を持たない。制限された識別を介する、構造に対する、このような限定「書込み専用」アクセスにより、データ構造内に格納された情報が、より多く最適化され、またはリソースを節約するなどの処理がなされる。たとえば、特にアプリケーションによる要求がなければ、データにハンドルを提供せずに、キャッシュデータ構造内のデータを、よりコンパクトなフォーマットや、たとえばビットマップやその他の後処理の結果などの、その後の繰り返し処理の必要性を減らしたりなくしたりするフォーマットなど、リソースを節約する、異なるフォーマットに変更/処理できる。

また、データ構造を更新するための、トランザクション/バッチング的なモデルが、キャッシュを介して提供される。これにより、データ構造からの読出しを中断することなく、データ構造に対する外部修正ができるようになる。またトランザクション/バッチング的なモデルにより、複数の変更をスクリーンに一度に表すこともできる。複数のコンテナに対する変更をバッチングすることにより、データ構造の異なる部分にある複数の変更が、スクリーンに一度に現れる。一代替形態では、トランザクション/バッチングモデルは、レンダリングスレッドと同期する。別の代替形態では、コンテナに受取られた変更が、そのコンテナ、場合によっては他のコンテナが閉じた後に、アトミックな方式で待ち行列に入れられる。

必要に応じて、データ構造の一部を作成または再作成するため、アプリケーション(またはその他のより高レベルの)プログラムコードをコールバックする方法およびメカニズムを提供する。このような無効化の方法により、リソースを節約および/または矯正することができる。たとえば、将来必要となる可能性のあるリソースに、必要でなければ、また実際に必要となるまで割り当てる必要がないように、無効マークを付けておくことができる。同様に、現在、データ構造の不要部分用に取っておいたリソース(たとえば、メモリ)を、対応する1つまたは複数のコンテナに無効マークを付けることによって、また後に必要となる時用に満たしておいた無効化方法およびメカニズムを介して、矯正できる。

本発明の方法およびコンピュータ実行可能命令を有するコンピュータ読取り可能媒体は、シーングラフに対応するデータを受取ることであって、データが、データに対する外部参照なしに第1の組のデータを含むことと、第1の組のデータの少なくとも一部を異なるフォーマットの変更データに変更することと、変更データをシーングラフ内に維持することとを含むことができる。コンピュータ実行可能命令を有する別の方法およびコンピュータ読取り可能媒体は、シーングラフに対応するデータを受取ることと、データがそれに対する外部参照を要求しないと判断することと、それに対する外部参照なしにシーングラフ内にデータを維持することとを含むことができる。

システムおよびコンピュータ実行可能構成要素は、受取りエンティティから独立したフォーマットのデータおよびコンテナを含むビジュアル情報を維持するメモリ内のキャッシュと、キャッシュをトラバースして、処理されたデータを提供するレンダリングメカニズムとを備えることができ、処理されたデータが受取りエンティティが理解できるフォーマットに対応し、受取りエンティティが命令ストリームを受取り、そこから可視出力を作り出す。コンピュータ実行可能命令を有する方法およびコンピュータ読取り可能媒体は、コンテナおよびデータを含むキャッシュデータ構造内にビジュアル情報を維持することと、レンダリング時に少なくとも1つのコンテナもそれに対応するビジュアル情報を提供するためには必要としない時を判断することと、コンテナに無効のマークを付けることと、コンテナを維持することに関連した少なくともいくつかのリソースを矯正することとを含むことができる。コンピュータ実行可能命令を有する別の方法およびコンピュータ読取り可能媒体は、コンテナおよびデータを含むキャッシュデータ構造内にビジュアル情報を維持することと、グラフィックス情報のために割り当てた空間を有さずに、グラフィックス情報を格納するため無効コンテナを確保しておくことと、データ構造を別のエンティティによって受取られるためのデータ内にレンダリングすることであって、無効コンテナのグラフィックス情報が必要かどうかを判断し、必要と判断した場合は、グラフィックス情報のためにリソースを割り当てることと、より高レベルのプログラムコードにコールバックして、グラフィックス情報を提供することと、グラフィックス情報を受取ることと、受取ったグラフィックス情報に対応する情報を含む別のエンティティによって受取られるためデータを出力することとを含むこととを含むことができる。

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

オペレーティング環境の例
図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と、CD ROMまたはその他の光学媒体などの、取り外し可能の不揮発性光学ディスク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に概略が示してあるように、媒体統合層アーキテクチャ200が提供される。アプリケーション、制御またはその他同様のより高レベルのプログラムコード(たとえば、オペレーティングシステム構成要素のユーザインターフェース)202が、1組のアプリケーションプログラミングインターフェース(API)204などを介して、媒体統合層アーキテクチャ200にアクセスして、グラフィカル情報にアクセス(書き込みまたは読出し)する。本明細書に記述した多くの例は、APIとインターフェースをとるアプリケーションプログラムを参照する、その他のより高レベルのプログラムコードおよび構成要素(たとえば、オペレーティングシステムのユーザインターフェース)も、本明細書に記述した、より低レベルの構成要素とインターフェースをとることができることが理解できることに留意されたい。したがって、このようなより高レベルのプログラムコードが、アプリケーションプログラムや、ユーザインターフェースなどのいずれの参照であろうとも、均等物であると考えるべきである。

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

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

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

本発明によれば、そして以下に記述するように、好ましいディスプレイツリーが、たとえば、オブジェクトおよびデータで満たされているか、その他一般に、その中のビジュアル情報の分布および使用方法をインテリジェントな方式で制御(たとえば、最適化する)メカニズムに関連する、インテリジェントキャッシングデータ構造を有する。一般的に言って、高レベル合成およびアニメーションエンジン206は、高レベルプログラムコード202とともに、ディスプレイ構造を構築し、レンダリング命令および単純なアニメーション間隔を造る構造をトラバースして、低レベル合成およびアニメーションエンジン210にパスする。高レベルコンポジッタによって生成されるレンダリング命令は、タイミングおよびアニメーション情報を含む。低レベル合成およびアニメーションエンジン210は、レンダリング命令およびアニメーション間隔をとり、次いで、グラフィックスサブシステム(たとえば、グラフィックスソフトウェアおよびハードウェア)212に供給される、シーンのアニメーション化、レンダリングおよび合成を管理する。

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

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

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

本発明に従って、高レベル合成およびアニメーションエンジン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を介してアニメーション意図（intention）などを含む、異なるデータを供給する。例示のために、やや変化するイメージを連続して再描画することによってアニメーションを実行する代りに、アプリケーションは、特定のイメージを、たとえば、固定の背景に対してある時間内にどのように移動すべきかについての命令を提供することができる。次いで、媒体統合層200は、スムーズなレンダリング方式でオートメーションを処理する。

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

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

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

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

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

本発明の一態様によれば、データ構造の変更が待ち行列などに入れられるため、データ構造を更新するためのトランザクション的な(またはバッチ的な)システムが、可能となる。その結果、コンテナを開閉した時は、コンテナを閉じるまでスクリーン上に変更が現れない。スクリーンへの変更はアトミックであり、部分的に描画したスクリーンの時間的アーティファクト(構造上の裂け目（tearing）とも呼ぶ)はない。さらに、このようなトランザクションの振る舞いが拡張されて、一度に多数のコンテナに変更が適用される。このようにして、より高レベルのコード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オブジェクトを変更する場合、システムは、その変更を発見し、それをレンダリングの出力に反映する。より現実的な例においては、識別は、テキストラインオブジェクト上自体には使用されないが、アプリケーションが、コンテナへのハンドルを保持し、上述した「Generic Parameterization for a Scene Graph」という名称の米国特許出願に記述しているように、要求のあり次第、そのコンテナをパラメータ化することによって変更することに留意されたい。それにも関わらず、データ構造の主要態様の1つに、より高レベルのコード202が、このようなこのようなオブジェクトを識別とともに作成する必要性が減少し、それによって、制御コード202によって参照される、データ構造内のポイントがより少なくて済むことになる。このことにより、データ構造がより一層最適化される。

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

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

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

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

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

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

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

データ構造を最後に歩き回ることで予想される結果には、データを直接実行して、スクリーン上に表示されるか、または最後に歩き回った最後の所にフリップされるバックバッファ上で実行されることが含まれる。その他の結果には（上述した「Multiple-Level Graphics Processing System and Method」という名称の米国特許出願に記述するように）拡張タイミングおよびアニメーション情報とともに運ばれ、より頻繁にレンダリングスレッド/プロセスにパスされるデータが含まれる。また、歩き回った結果、スクリーン捕獲またはその他の理由によりデータがビットマップ上で実行され、プリンタへ行き、またはネットワークを介し、次いでリモートマシンでの以前の結果のいずれかのために使用されるようになる。これらの結果の組み合わせも可能である。

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

コンテナ(例えば、図5のコンテナ508)は、作成された時、リソースが低いため内容がシステムによって捨て去られた時、またはより高レベルのコードがコンテナを無効にするよう直接要請した時、無効である場合がある。たとえば、より高レベルのコード202は、コンテナを作成して、そのコンテナがどこにあって、どのぐらいの大きさであるのかを定義するグラフィカルサイズを供給する。レンダリングオペレーション中、そのコンテナが無効というマークが付けられたが、必要であると判断された場合、レンダリングスレッド422は、より高レベルのコード202にコンテナ内に記入するよう要請する。レンダリングスレッド422は、より高レベルのコード202がその要請を終了するまで待つか、または必要なデータがないままレンダリングを続行する。第1の選択は理想的なものではないが、状況によっては必要となる場合がある。状況によっては、アプリケーションに、至急キャッシュに入れるべきもの、実際はキャッシュに事前に満たしておくものを、より高レベルのコード202に伝えさせるようにすることが望ましい。

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

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

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

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

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

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

低レベルコンポジッタおよびアニメータ
上述したように、高レベルエンジン206は、いくつかの目的で本発明によるキャッシングデータ構造300をインテリジェントな方式でコンパイル、および/修正することができ、そして、その出力を、ディスプレイ、印刷、ビットマップ捕捉、リモートネットワーク通信などに対する直接レンダリングを含む、可能ないくつかの受取りエンティティに適合させることができる。この出力の可能なレシーバの1つは、低レベルアニメータおよび合成エンジン210である。本発明においては必ずしも必要ではないが、低レベルアニメータの一例を、高レベルアニメータおよび合成エンジン206とともに使用されるインテリジェントキャッシングデータ構造のオペレーションの説明をするため、本明細書に記述する。しかし、これは単に一例にすぎず、その他の受取りエンティティに対しては、この出力やその他の適切にフォーマットした出力も提供できることが理解されるであろう。

低レベルアニメータおよび合成エンジン210の主な目的は、媒体統合層200の低レベルレンダリングスタックの抽象化を提供することであり、これによって、クライアントグラフィックスアプリケーションのための高フレーム速度アニメーションウィンドウ管理的なサポートの実施ネットワーク接続を介したリモートグラフィックスサービスのサポートが得られる。図6および7に示すように、低レベルアニメータおよび合成エンジン210は、レンダラ602の集合によって提供されるサービスを使用することにより、特に、多数のクライアントから受取る高フレーム速度アニメーション要求を調整する合成エンジンサーバ600として構成される(たとえば、それぞれアプリケーションに対応する)。レンダラ602は、グラフィックス合成エンジン606によって実施されるレンダリング抽象化(ビジュアルとも呼ぶ)上で働くレンダリングアクションを生成する。

低レベルアニメータおよび合成エンジン210はまた、特別のクライアント(トップレベルのビジュアルマネージャ604)が、スクリーン上のレンダリングエリアとして、クライアントアプリケーションによって使用されるビジュアルを操作できるようにすることが目的のインフラストラクチャを備える、トップレベルのビジュアル管理サポートを提供する。レンダリングスタックへの、クライアントアプリケーション202₁-202₃(図7では3つしか示していないが、いずれの数でもあり得る)レンダリングのそれぞれが、トップレベルのビジュアル(それぞれ、TLV₁-TLV₃)を所有し、トップレベルのビジュアルマネージャ604は、スクリーン上にトップレベルのビジュアルのレイアウト上にオーソリティを有するクライアントである。一般的に言って、低レベルアニメータおよび合成エンジン210は、デスクトップ上に存在するさまざまなクライアントによって放出されたコマンドストリームを、グラフィックス合成エンジン606によって消費されるグラフィックスコマンドに組み合わせることによって、デスクトップを合成する。低レベルアニメータおよび合成エンジン210はまた、ローカルマシンと同様のリモートマシン610₁-610_nのためのユーザインターフェースをプログラミングするレンダリングアーキテクチャを実施するために使用する構成要素をヘルプする。

図7は、低レベルアニメータおよび合成エンジン(サーバ)210とそのクライアントの間の相互作用を示す図である。上述したように、トップレベルのビジュアルマネージャ604もクライアントである。またこれも上述したように、低レベルアニメータおよび合成エンジン210のクライアント202₁-202₃は、高レベルコンポジッタおよびアニメーションエンジン206のインスタンスを使用して、グラフィックス構造を構築し、これらを、低レベルアニメータおよび合成エンジン210がビューされるデスクトップを合成するために使用する、グラフィックスコマンドのストリームに変換する。一実施形態では、ローカルまたはリモートマシンのいずれかで走行するクライアント(たとえば、高レベルコンポジッタ)によって出されるコマンドストリームを取り扱う、ただ1つの低レベルアニメータおよび合成エンジン210がある。

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

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

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

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

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

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

クライアントが、低レベルアニメータおよび合成エンジン210によって供給されるサービスを使用する前に、クライアントは、まず最初に、接続マネージャ710によって提供されるエントリポイントを介してエンジン210に接続する(図7)。接続マネージャ710は、クライアントサーバプロトコルのための双方向バイトストリームトランスポート層をカプセル化する通信オブジェクト(たとえば、712₁)を割り当てる。これはまた、命令ストリームを介してやって来るレンダリング命令の追跡をし、それらを正しいビジュアルに関連付ける命令リストマネージャ(たとえば、714₁)も割り当てる。

いったん接続が確立されると、クライアント202は、トップレベルビジュアルの作成を要請する。その要請に応答して、低レベルアニメータおよび合成エンジン210は、グラフィックス合成エンジン606によって提供されるサービスを使用することにより、トップレベルビジュアル(たとえば、TLV₁)を作成する。そのクライアントのために低レベルアニメータおよび合成エンジン210によって維持されるビジュアルは、ツリー構造718内で編成される。クライアントが、トップレベルビジュアルとともになされる場合は、クライアントはその破壊を要請する。ルートノード720は、デスクトップのバックグラウンドを表す特別なビジュアルであり、ルートビジュアルの子はトップレベルビジュアルであることに留意されたい。

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

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

低レベルアニメータおよび合成エンジン210はまた、トップレベルビジュアルのためのサービスを最小限に抑えるサポートもし、これも、レンダリング命令リストに関するトップレベルビジュアルマネージャ604によって供給できる。トップレベルビジュアル位置付け、サイジング、およびZオーダ(Z-order)は、ビジュアルを閉じる、および最小化するなどの、ビジュアルマネージャアクションに指定される3次元効果とともに、サポートされる。したがって、この実施形態は、主に2次元グラフィックスについて記述しているが、このシステムは、3次元グラフィックス、ビデオ、音声を含むその他の種類の媒体を格納するためにも容易に使用できる。

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

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

上述した「Generic Parameterization for a Scene Graph」という名称の米国特許出願にさらに記述するように、命令リストがパラメータ化される。これは、一般に、グラフィカルイメージの色の修正などの単純な変更については、トップレベルビジュアルマネージャ604がかかわる必要がないということである。このような場合、クライアントは、新しいパラメータ(たとえば、新しい色)を送り、デコレーションを同じ命令リストで再レンダリングするが、異なるパラメータを使用する。このことにより、それぞれのデコレーションの記述にはただ1つのコピーしか格納しないようにすることができるようになる。

図8は、クライアント/サーバ通信チャネルを実施する待ち行列801-804の論理構造を示す図である。タイミング間隔が、アニメーション化したレンダリング命令内に埋め込まれる。レンダリング時間に、低レベルアニメータおよび合成エンジン210は、現在時間をタイミング間隔とともに、レンダラにパスする。そして、レンダラは、タイミング間隔を使用して、以下に記述するように、レンダリングのために正しいパラメータを補間する。アニメーション化されたレンダリング命令は、高レベルクライアントから受取った命令コマンドに応答して、命令リストマネージャ714によって管理される。命令リストマネージャは、それを受取った時、レンダリング命令を待ち行列714に入れる。レンダリング待ち行列はZオーダであり、レンダリングパスマネージャ722は、それらを合成時間に消費する。

待ち行列時間に入れられたレンダリング命令に加えて、命令リストマネージャ714は、待ち行列801-804を空にすること、命令を待ち行列から削除すること、命令を待ち行列に追加すること、待ち行列を新しい命令リストに置き換えること、固定時間オフセットを待ち行列に適用することを含む、その他のオペレーションもサポートする。タイミング制御レンダリングの特別な例として、レンダリング命令の可視性を制御する場合がある。このような場合では、タイミング間隔を使用して、レンダリング待ち行列内の命令の生存期間を制御する。

クライアントが、ネストされたビジュアルを、その内容を適切にレンダリングするために必要としている場合、たとえば、ビデオがシーン内に存在するような場合など、いろいろな状況がある。ビデオの更新は、独立したレンダリングプロセスによって実施されるため、低レベルエンジン210は、グラフィックス合成エンジンが、ビデオおよびそれにオーバラップする幾何学を合成することに頼る。このことは、クライアントアプリケーションのトップレベルビジュアル内に入れられている新しいビジュアルを作成することによって達成される。これは、グラフィックス合成エンジンの合成パス内のビデオ更新の非同期性を隠すことになる。ビジュアルの必要性を共有するオーバーラップしている幾何学は、同じ種類のアルファの動き(ピクセル毎または透過)を有する。

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

高レベルエンジン206と低レベルエンジン210との間の通信は、命令ストリームを介して達成される。高レベルエンジン206は、より遅い頻度で、またはオンデマンドで、レンダリング命令をストリームに書き込む。低レベルエンジン210は、命令のためのストリームを読出し、シーンをレンダリングする。低レベルエンジン210はまた、共有メモリからのビットマップなどの、その他のソースからのシーンをレンダリングするのに必要となるデータを得ることができることに留意されたい。

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

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

高レベルエンジン206が走行する頻度は、均一または固定である必要はない。たとえば、高レベルエンジン206は、シーン内のアニメーションパラメータによって供給される最小間隔を越えない均一の間隔でスケジューリングできる。あるいは、高レベルエンジン206のそれぞれの走行上で計算される最小間隔を使用して、次の走行をスケジューリングし、適切な時に新しいデータが低レベルエンジン210に供給されることを確実にする。同様に、シーンおよび/またはそのアニメーション化したパラメータに、構造上の変更がなされた場合、高レベルエンジン206の頻度は、新しいシーンが正確にアニメーション化するかを確実にするために走行する頻度となる。

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

低レベルエンジン210は、高レベルエンジンの供給した間隔に基づき、瞬間アニメーションパラメータを補間し、描画命令を更新し、すべてのフレームに対してシーンをレンダリングする。低レベルエンジン210タスクは、システム上を高い優先度で走行し、そのフレームが、グラフィックスハードウェアスクリーンリフレッシュ速度でプレゼンテーションする準備を確実にする。したがって、低レベルエンジン210によって実行される補間は、一般に、線形、区分線形、3次スプライン、およびこれらの同様の速度など、単純で高速の機能に限られる。低レベルエンジン210は、ハードウェアリフレッシュ速度の積分除数である、正規頻度またはフレーム速度で走行する。低レベルエンジン210によってレンダリングされたそれぞれのフレームは、決まった数だけ表示されるか、またはグラフィックスハードウェアによってリフレッシュされる。

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

第2のトラバーサルが、レンダリングのために低レベルエンジン210に送られるシーンを記述する情報をパッケージ化する。図9に表されているように、高レベルエンジン206は、命令ブロック900を、それぞれのトップレベルビジュアル(たとえば、ウィンドウ)に対する単一のビジュアル更新ブロック902に蓄積する。前回のトラバーサルから変更されていない命令ブロックサブツリーは、付加されない。宣言アニメーション変更だけを含むサブツリーのための命令ブロックには、補間情報の変数ブロックだけが含まれる。変換とともに再位置付けされているサブツリーに対する命令ブロックは、ヘッダのみを含む。

低レベルエンジン210レンダリングスレッド(またはプロセス)は、ループ内で走行し、高フレーム速度で、理想的にはディスプレイのリフレッシュ速度で、ビジュアルをレンダリングし合成する。ループは、高レベルエンジン206から受取ったビジュアル更新ブロックを適用する。このパス上で描画されているリソースおよびウィンドウに対して補間した値が、更新される。命令ブロックの変数リスト内のそれぞれの変数については、次のフレームのための瞬間値が計算される。次いで、ループは、オフセットを介して、それが使用されている命令リスト内の場所に反復し、メモリが新しい値をコピーする。

更新されたオフスクリーンリソースがレンダリングされるが、あるいは、リソースは最初に使用された時に、レンダリングされる場合もある。それぞれのトップレベルビジュアルについての命令リストがレンダリングされ、データは、ディスプレイに「bltされ(blt-ed)」、フリップされるなど、それぞれのトップレベルビジュアルがスクリーン上で更新されるようにする。

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

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

命令リスト、変数、時間値およびアニメーション間隔は、一緒に機能する。命令リストは、レンダリングを記述し、静的値の代りに変数への参照を含む。アニメーション間隔は、短時間の間に、どのように変数の値が変わるかを記述する。

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

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

低レベルエンジン210は、移送ストリームを聞き、パケットが到着するとそれを処理する、通常優先スレッドを有する。好ましくは、レンダリングスレッドとは別のスレッドでその作業を行い、低レベルエンジン210がすべてのリフレッシュをレンダリングできることを確実にする。通信スレッドは、オペレーションコード(opcode)、高レベルエンジン識別子(ID)、オブジェクトハンドルに基づき、それぞれのパケットをパーズする。

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

結論
上述の詳細な説明からお分かりのように、最新のグラフィックスメカニズムを介して多くの利点を提供するインテリジェントキャッシングデータ構造およびメカニズムが提供される。データ構造により、リソースを節約するためにデータを変更し、バッチした変更を適用し、異なる受け取りエンティティのために異なる方式でレンダリングできるようになる。構造内のその他のデータは無効化しておき、リソースを、シーンの不要部分のために割り当てる必要のないようにするなど、キャッシュに入れられているシーンを作成している、より高レベルのコードにコールバックすることにより、必要に応じて作成することができる。

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

その中に本発明を組み込むことのできるコンピュータシステムの例を示すブロック図である。その中に本発明を組み込むことのできるアーキテクチャの例を示すブロック図である。本発明の一態様に従った、インテリジェントキャッシングデータ構造およびそのさまざまな構成要素に対する関係を示すブロック図である。本発明の一態様に従った、変更待ち行列代替物を含む、高レベル合成およびアニメーションエンジンとその他のレベルの間の、一般的な制御の流れを示すブロック図である。本発明の一態様に従った、単純なデータ構造内にキャッシュされたコンテナおよびその他のノードと、それらの関係の例を示すブロック図である。本発明の一態様に従った、他の構成要素と相互作用する低レベル合成およびアニメーションエンジンの一般的な構成要素を示すブロック図である。本発明の一態様に従った、低レベル合成およびアニメーションエンジンの一般的な構成要素を示すブロック図である。本発明の一態様に従った、低レベル合成およびアニメーションエンジンとの接続の論理構造を示すブロック図である。本発明の一態様に従って、キャッシュデータ構造から、低レベル合成およびアニメーションエンジンなどの別のエンティティにレンダリングされる情報を通信するために使用することができるデータ構造の例を示す図である。

符号の説明

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 磁気ディスク
155、156 光学ディスク
161 ポインティングデバイス
162 キーボード
163 マイクロホン
164 タブレット
170 アダプタ
171 ローカルエリアネットワーク(LAN)
172 モデム
173 ワイドエリアネットワーク(WAN)
180 リモートコンピュータ
181 メモリ記憶装置
190 ビデオインターフェース
191 モニタ
192 タッチスクリーンインターフェース
193 タッチスクリーンパネル
194 周辺インターフェース
195 スピーカ
196、222 プリンタ
200 媒体統合層アーキテクチャ
202 より高レベルのコード
204 アプリケーションプログラミングインターフェース(API)
206 高レベルエンジン、合成エンジン
208 タイミングおよび合成アニメーション構成要素
210 低レベルアニメータおよび合成エンジン
212 グラフィックスサブシステム
220 印刷コード
226 端末移送サーバ
228、610 リモートマシン
300 キャッシングデータ構造
302 抽象装置
402、404、408、510、512、518 コンテナ
406 変換
410、412 基本ノード
416 描画コンテキスト
418 変更待ち行列
420 ディスプレイマネージャ
422 レンダリングスレッド
500、502 セグメント
516 基本要素
604 ビジュアルマネージャ
606 グラフィックス合成エンジン
614 プロパティシステム
710 接続マネージャ
714 命令リストマネージャ
718 構造
720 ルートノード
722 レンダリングパスマネージャ
730 装飾
801、802、803、804 待ち行列
900 命令ブロック
1104 アニメータ

Claims

シーングラフに対応するデータを受取り、前記データは、前記データに対する外部参照なしで第1の組の前記データを含むことと、
前記第1の組のデータの少なくとも一部を、異なるフォーマットの変更データに変更することと、
前記シーングラフ内に前記変更データを維持することとを備えることを特徴とするビジュアル情報を維持する方法。
前記シーングラフ内に前記第1の組のデータを維持することと、前記シーングラフ内に前記変更データを維持した後、前記シーングラフから前記第1の組のデータの少なくとも一部を除去することとをさらに備えることを特徴とする請求項1に記載の方法。
前記第1の組のデータの少なくとも一部を変更することは、前記第1の組のデータをデータアレイ内にストリーミングすることを備えることを特徴とする請求項1に記載の方法。
前記第1の組のデータの少なくとも一部を変更することは、前記第1の組のデータを処理してビットマップにすることを備えることを特徴とする請求項1に記載の方法。
前記第1の組のデータの少なくとも一部を変更することは、前記第1の組のデータを結果に処理することと、前記結果を維持することとを備えることを特徴とする請求項1に記載の方法。
前記第1の組のデータのサブセットはテキストデータを備え、前記第1の組のデータの少なくとも一部を変更することは、データの前記サブセットを処理してグリフにすることと、前記グリフを維持することとを備えることを特徴とする請求項1に記載の方法。
シーングラフに対応するデータを受取ることは、前記データに対する外部参照を有する第2の組のデータを受取ることをさらに備えることを特徴とする請求項1に記載の方法。
前記第2の組のデータはシーングラフコンテナを含み、ハンドルを前記シーングラフコンテナに提供することをさらに備えることを特徴とする請求項7に記載の方法。
前記シーングラフをトラバースして、前記シーングラフに基づき命令ストリームを生成することをさらに備えることを特徴とする請求項1に記載の方法。
前記命令ストリームの少なくとも一部をキャッシュに入れることをさらに備えることを特徴とする請求項9に記載の方法。
シーングラフに対応するデータを受取ることであって、前記データは、前記データに対する外部参照なしで第1の組の前記データを含むことと、
前記第1の組のデータの少なくとも一部を異なるフォーマットの変更データに変更することと、
前記シーングラフ内に前記変更データを維持することとを備えるコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
前記シーングラフ内に前記第1の組のデータを維持することと、前記シーングラフ内に前記変更データを維持した後、前記シーングラフから前記第1の組のデータの少なくとも一部を除去することとを備えるさらなるコンピュータ実行可能命令を有することを特徴とする請求項11に記載のコンピュータ読取り可能媒体。
前記第1の組のデータの少なくとも一部を変更することは、前記第1の組のデータをデータアレイにストリーミングすることを備えることを特徴とする請求項11に記載のコンピュータ読取り可能媒体。
前記第1の組のデータの少なくとも一部を変更することは、前記第1の組のデータを処理してビットマップにすることを備えることを特徴とする請求項11に記載のコンピュータ読取り可能媒体。
前記第1の組のデータの少なくとも一部を変更することは、前記第1の組のデータを処理して結果にすることと、前記結果を維持することとを備えることを特徴とする請求項11に記載のコンピュータ読取り可能媒体。
前記第1の組のデータのサブセットはテキストデータを備え、前記第1の組のデータの少なくとも一部を変更することは、データの前記サブセットを処理してグリフにすることと、前記グリフを維持することとを備えることを特徴とする請求項11に記載のコンピュータ読取り可能媒体。
シーングラフに対応するデータを受取ることは、前記データに対する外部参照を有する第2の組のデータを受取ることをさらに備えることを特徴とする請求項11に記載のコンピュータ読取り可能媒体。
前記第2の組のデータはシーングラフコンテナを備え、ハンドルを前記シーングラフコンテナに提供することを備えるさらなるコンピュータ実行可能命令を有することを特徴とする請求項17に記載のコンピュータ読取り可能媒体。
前記シーングラフをトラバースして、前記シーングラフに基づき命令ストリームを生成することを備えるさらなるコンピュータ実行可能命令を有することを特徴とする請求項11に記載のコンピュータ読取り可能媒体。
前記命令ストリームの少なくとも一部をキャッシュに入れることを備えるさらなるコンピュータ実行可能命令を有することを特徴とする請求項19に記載のコンピュータ読取り可能媒体。
シーングラフに対応するデータを受取ることと、
前記データは、それに対する外部参照を必要としないことを判断することと、
それに対する外部参照なしで前記シーングラフに前記データを維持することとを備えることを特徴とするビジュアル情報を維持する方法。
前記データを変更データに変更することと、前記シーングラフ内に前記変更データを維持することとをさらに含むことを特徴とする請求項21に記載の方法。
前記データを変更することは、前記第1の組のデータをデータアレイにストリーミングすることを備えることを特徴とする請求項22に記載の方法。
前記データを変更することは、前記第1の組のデータを処理してビットマップにすることを備えることを特徴とする請求項22に記載の方法。
前記データを変更することは、前記第1の組のデータを処理して結果にすることと、前記結果を維持することとを備えることを特徴とする請求項22に記載の方法。
前記データはテキストデータを有し、前記データを変更することは、前記データを処理してグリフにすることと、前記グリフを維持することとを備えることを特徴とする請求項22に記載の方法。
前記シーングラフをトラバースして、前記シーングラフに基づき命令ストリームを生成することをさらに備えることを特徴とする請求項21に記載の方法。
前記命令ストリームの少なくとも一部をキャッシュに入れることをさらに備えることを特徴とする請求項27に記載の方法。
シーングラフに対応するデータを受取ることと、
前記データは、それに対する外部参照を必要としないことを判断することと、
それに対する外部参照なしで前記シーングラフ内に前記データを維持することとを備えるコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
前記データを変更データに変更することと、前記シーングラフ内に前記変更データを維持することとを備えるさらなるコンピュータ実行可能命令を有することを特徴とする請求項29に記載のコンピュータ読取り可能媒体。
前記データを変更することは、前記第1の組のデータをデータアレイにストリーミングすることを備えることを特徴とする請求項30に記載のコンピュータ読取り可能媒体。
前記データを変更することは、前記第1の組のデータを処理してビットマップにすることを備えることを特徴とする請求項30に記載のコンピュータ読取り可能媒体。
前記データを変更することは、前記第1の組のデータを処理して結果にすることと、前記結果を維持することとを備えることを特徴とする請求項30に記載のコンピュータ読取り可能媒体。
前記データはテキストデータを備え、前記データを変更することは、前記データを処理してグリフにすることと、前記グリフを維持することとを備えることを特徴とする請求項30に記載のコンピュータ読取り可能媒体。
前記シーングラフをトラバースして、前記シーングラフに基づき命令ストリームを生成することを備えるさらなるコンピュータ実行可能命令を有することを特徴とする請求項29に記載のコンピュータ読取り可能媒体。
前記命令ストリームの少なくとも一部をキャッシュに入れることを備えるさらなるコンピュータ実行可能命令を有することを特徴とする請求項35に記載のコンピュータ読取り可能媒体。
プロセッサとメモリとを有するシステムにおいて、
受取りエンティティから独立したフォーマットのデータとコンテナとを含むビジュアル情報を維持する前記メモリ内のキャッシュと、
前記キャッシュをトラバースして、処理されたデータを提供するレンダリングメカニズムであって、前記処理されたデータは、受取りエンティティが理解できるフォーマットに対応するレンダリングメカニズムとを備え、
前記受取りエンティティは、前記命令ストリームを受取り、そこから前記可視出力を作り出すことを特徴とする可視出力を作り出すためのシステム。
前記受取りエンティティはグラフィックスサブシステムを備え、前記レンダリングメカニズムは、前記グラフィックスサブシステムによる直接レンダリングのために前記処理されたデータを提供することを特徴とする請求項37に記載のシステム。
前記受取りエンティティが低レベルエンジンを備え、前記レンダリングメカニズムは、前記低レベルエンジンのための命令ストリームとして前記処理されたデータを提供することを特徴とする請求項37に記載のシステム。
前記低レベルエンジンは、前記命令ストリームを処理してグラフィックスサブシステムによるレンダリングのためのデータにすることを特徴とする請求項39に記載のシステム。
前記受取りエンティティは、プリンタを備えることを特徴とする請求項37に記載のシステム。
前記受取りエンティティは、ネットワーク上のリモートマシンを備えることを特徴とする請求項37に記載のシステム。
計算環境において、
コンテナおよびデータを含むキャッシュデータ構造内にビジュアル情報を維持することと、
レンダリング時に少なくとも1つのコンテナも、それに対応するビジュアル情報を提供するためには必要としない時を判断することと、
前記コンテナに無効のマークを付けることと、
前記コンテナを維持することに関連する前記リソースの少なくともいくつかを矯正することとを備えることを特徴とする方法。
前記キャッシュデータ構造を処理して、そこからの出力をレンダリングすることをさらに備えることを特徴とする請求項43に記載の方法。
前記キャッシュデータ構造を処理する間に、
1)ビジュアル情報を提供するために、今必要とされている、無効のマークを付けたコンテナを検出することと、
2)より高レベルのプログラムコードにコールバックして、前記コンテナのためにデータを提供することと、
3)前記データを受取ることとをさらに備え、
前記キャッシュからレンダリングされた前記出力は、受取った前記データに基づく出力を含むことを特徴とする請求項44に記載の方法。
前記キャッシュデータ構造の処理を終了する前に、前記より高レベルのプログラムコードから前記データを待つことをさらに備えることを特徴とする請求項45に記載の方法。
より高レベルのプログラムコードにコールバックすることは、要求を待ち行列に入れて、前記より高レベルのプログラムコードを実行するスレッドに戻すことを備えることを特徴とする請求項45に記載の方法。
コンテナおよびデータを含むキャッシュデータ構造内にビジュアル情報を維持することと、
レンダリング時に少なくとも1つのコンテナも、それに対応するビジュアル情報を提供するためには必要としない時を判断することと、
前記コンテナに無効のマークを付けることと、
前記コンテナを維持することに関連する前記リソースの少なくともいくつかを矯正することとを備えるコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
前記キャッシュデータ構造を処理して、そこからの出力をレンダリングすることを備える少なくとも1つのさらなるコンピュータ実行可能命令を有することを特徴とする請求項48に記載のコンピュータ読取り可能媒体。
前記キャッシュデータ構造を処理する間に、
1)ビジュアル情報を提供するために、今必要とされている、無効のマークを付けたコンテナを検出することと、
2)より高レベルのプログラムコードにコールバックして、前記コンテナのためにデータを提供することと、
3)前記データを受取ることとを備え、
前記キャッシュからレンダリングされた前記出力は、受取った前記データに基づく出力を備えるさらなるコンピュータ実行可能命令を有することを特徴とする請求項77に記載のコンピュータ読取り可能媒体。
前記キャッシュデータ構造の処理を終了する前に、前記より高レベルのプログラムコードから前記データを待つことを備えるさらなるコンピュータ実行可能命令を有することを特徴とする請求項50に記載のコンピュータ読取り可能媒体。
より高レベルのプログラムコードにコールバックすることは、要求を待ち行列に入れて、前記より高レベルのプログラムコードを実行するスレッドに戻すことを備えることを特徴とする請求項50に記載のコンピュータ読取り可能媒体。
計算環境において、
コンテナおよびデータを含むキャッシュデータ構造内にビジュアル情報を維持することと、
前記グラフィックス情報のために割り当てた空間を有さずに、グラフィックス情報を格納するため無効コンテナを確保しておくことと、
前記データ構造を別のエンティティによって受取られるためのデータにレンダリングすることであって、前記無効コンテナの前記グラフィックス情報が必要かどうかを判断することを含み、必要と判断した場合は、
1)前記グラフィックス情報のためにリソースを割り当てることと、
2)より高レベルのプログラムコードにコールバックして、前記グラフィックス情報を提供することと、
3)前記グラフィックス情報を受取ることと、
4)受取った前記グラフィックス情報に対応する情報を含む別のエンティティによって受取られるため前記データを出力することとを備えることを特徴とする方法。
前記無効コンテナを確保しておくことは、コンテナに無効マークを付けることと、グラフィックス情報のために割り当てた空間を矯正することとを備えることを特徴とする請求項53に記載の方法。
前記無効コンテナを確保しておくことは、前記より高レベルのプログラムコードから命令を受取って、無効コンテナを確保することを備えることを特徴とする請求項53に記載の方法。
別のエンティティによって受取られるために前記データを出力することは、前記命令ストリームを、グラフィックスサブシステムが理解できるグラフィックス情報に変換する低レベルエンジンのため命令ストリームを出力することを含むことを特徴とする請求項53に記載の方法。
前記キャッシュデータ構造の前記レンダリングを終了する前に、前記より高レベルのプログラムコードからの前記データを待つことをさらに備えることを特徴とする請求項53に記載の方法。
より高レベルのプログラムコードにコールバックすることは、要求を待ち行列に入れて、前記より高レベルのプログラムコードを実行するスレッドに戻すことを備えることを特徴とする請求項53に記載の方法。
コンテナおよびデータを含むキャッシュデータ構造内にビジュアル情報を維持することと、
前記グラフィックス情報のために割り当てた空間を有さずに、グラフィックス情報を格納するため無効コンテナを確保しておくことと、
前記データ構造を別のエンティティによって受取られるためのデータにレンダリングすることであって、前記無効コンテナの前記グラフィックス情報が必要かどうかを判断することを含み、必要と判断した場合は、
1)前記グラフィックス情報のためにリソースを割り当てることと、
2)より高レベルのプログラムコードにコールバックして、前記グラフィックス情報を提供することと、
3)前記グラフィックス情報を受取ることと、
4)受取った前記グラフィックス情報に対応する情報を含む別のエンティティによって受取られるため前記データを出力することとを備えるコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
前記無効コンテナを確保しておくことは、コンテナに無効マークを付けることと、グラフィックス情報のために割り当てた空間を矯正することとを備えることを特徴とする請求項59に記載のコンピュータ読取り可能媒体。
前記無効コンテナを確保しておくことは、前記より高レベルのプログラムコードから命令を受取って、無効コンテナを確保することを備えることを特徴とする請求項59に記載のコンピュータ読取り可能媒体。
別のエンティティによって受取られるために前記データを出力することは、命令ストリームを、グラフィックスサブシステムが理解できるグラフィックス情報に変換する低レベルエンジンのため前記命令ストリームを出力することを含むことを特徴とする請求項59に記載のコンピュータ読取り可能媒体。
前記キャッシュデータ構造の前記レンダリングを終了する前に、前記より高レベルのプログラムコードからの前記データを待つことを備えるさらなるコンピュータ実行可能命令を有することを特徴とする請求項59に記載のコンピュータ読取り可能媒体。
より高レベルのプログラムコードにコールバックすることは、要求を待ち行列に入れて、前記より高レベルのプログラムコードを実行するスレッドに戻すことを備えることを特徴とする請求項59に記載のコンピュータ読取り可能媒体。
前記レンダリングメカニズムは、前記待ち行列内にある変更情報に応答してオンデマンドで動作することを特徴とする請求項64に記載のコンピュータ読取り可能媒体。
前記レンダリングメカニズムは、固定速度で動作することを特徴とする請求項64に記載のコンピュータ読取り可能媒体。
前記レンダリングメカニズムは、第1の動作速度で実行して前記命令ストリームを低レベル構成要素に提供する高レベル構成要素を備え、前記低レベル構成要素は、第2の動作速度で動作して前記命令に基づく描画コマンドをグラフィックスサブシステムに提供し、前記第2の動作速度が前記第1の動作速度より大きく、前記グラフィックスサブシステムのフレーム速度に対応することを特徴とする請求項64に記載のコンピュータ読取り可能媒体。
受取りエンティティから独立したフォーマットのデータとコンテナとを含むビジュアル情報を維持するキャッシュと、
前記キャッシュをトラバースして、処理されたデータを提供するレンダリングメカニズムであって、前記処理されたデータは、受取りエンティティが理解できるフォーマットに対応するレンダリングメカニズムとを備え、
前記受取りエンティティは、前記命令ストリームを受取り、そこから前記可視出力を作り出す、コンピュータ実行可能構成要素を有することを特徴とするコンピュータ読取り可能媒体。
前記受取りエンティティがグラフィックスサブシステムを備え、前記レンダリングメカニズムは、前記グラフィックスサブシステムによる直接レンダリングのために前記処理されたデータを提供することを特徴とする請求項68に記載のコンピュータ読取り可能媒体。
前記受取りエンティティは低レベルエンジンを備え、前記レンダリングメカニズムは、前記低レベルエンジンのための命令ストリームとして前記処理されたデータを提供することを特徴とする請求項68に記載のコンピュータ読取り可能媒体。
前記低レベルエンジンは、前記命令ストリームを処理してグラフィックスサブシステムによるレンダリングのためのデータにすることを特徴とする請求項70に記載のコンピュータ読取り可能媒体。
前記受取りエンティティは、プリンタを備えることを特徴とする請求項68に記載のコンピュータ読取り可能媒体。
前記受取りエンティティは、ネットワーク上のリモートマシンを備えることを特徴とする請求項68に記載のコンピュータ読取り可能媒体。