JP4290477B2 - ベクターグラフィック用のマークアップ言語およびオブジェクトモデル - Google Patents

Description

本発明は、一般にはコンピュータシステムに関し、より詳細には、コンピュータシステムによって表示するグラフィック情報およびその他のビデオ情報の処理に関する。

現在、コンピュータシステムにおける従来のイミーディエイトモードモデルによるグラフィックへのアクセスが限界に達しつつあるが、この理由の１つは、メモリおよびバスの速度がメインプロセッサおよび／またはグラフィックプロセッサの発達に見合うように上がらなかったことにある。一般に、フレームを準備する現在の（例えばＷＭ＿ＰＡＩＮＴ）モデルは、複雑なグラフィック効果が求められる際にハードウェアのリフレッシュ速度についていくのにあまりに多くのデータ処理を必要としている。その結果、従来のグラフィックモデルで複雑なグラフィック効果を試みると、視覚効果として知覚される変化が次のフレームに間に合うように完了されずに、この変化が別のフレームにわたって付加され、視覚的に目立つ望ましくない結果を生じさせることがある。

米国特許出願１０／１８４，７９５、米国特許出願１０／１８４，７９６、米国特許出願１０／１８５，７７５（それぞれ本発明の関連出願である２００２年６月２７日付けの同時継続出願）には、グラフィック出力を制御する新しいモデルが記載されている。この新モデルは、グラフィック処理技術のいくつかの顕著な改良点を提供する。例えば米国特許出願１０／１８４，７９５は一般に複数レベルからなるグラフィック処理システムおよび方法を対象とし、ここでは、（例えばオペレーティングシステムの）より高水準のコンポーネントが、低水準のコンポーネントに単純化したデータ構造および／またはグラフィックコマンドを受け渡すために、シーングラフ（scene graph）を構築し、アニメーションパラメータを更新し、シーングラフのデータ構造をトラバースするという計算的に集約的な局面を比較的低い動作速度で行う。高水準の処理によりデータが大幅に単純化されるので、低水準コンポーネントは、グラフィックスサブシステムのフレームリフレッシュレートに相当する速度のような（高水準コンポーネントに比べて）より速い速度で動作して、データを処理してグラフィックスサブシステムへの一定の出力データとすることができる。アニメーションを使用する場合は変化を加えてシーン全体を描き直す必要がなく、低水準の処理により必要に応じてパラメータ間隔を補間して、レンダリング時にフレームごとにわずかに変化したシーンを提供し、なめらかなアニメーションを提供する瞬時値を得ることができる。

また、米国特許出願１０／１８４，７９６には、グラフィックを描画しようとするプログラムコード（例えばアプリケーションプログラムまたはオペレーティングシステムコンポーネント）がシーングラフ記述の特定面を選択的に変更し、他の面はそのままにしておくことができるように、変わりやすい（アニメーション）値とパラメータ化したグラフコンテナを提供するパラメータ化されたシーングラフが記載されている。プログラムコードは、シーングラフのすでに構築された部分を、ことによると異なるパラメータで再使用することもできる。よく理解できるように、パラメータ化および／または既存のシーングラフ部分の再使用を介して、表示アイテムの外観を容易に変えられることにより、全グラフィック処理効率において相当の利益が得られる。

米国特許出願１０／１８５，７７５には、オブジェクトおよびデータを介してシーングラフに視覚情報を格納するためのキャッシング（caching）データ構造とそれに関連する機構が記載されている。このデータ構造は概して、そのように構造中の視覚情報を居住させ使用するかをインテリジェント（理知的）に制御する機構と関連付けられる。例えば、アプリケーションプログラムによって特別に要求されない限り、データ構造に格納された情報の大半には外部参照がなく、それによりその情報を最適化するか、その他の形で処理することが可能になる。よく理解できるように、この結果効率と資源の節減が得られる。例えばキャッシュデータ構造中のデータを処理して、ビットマップやその他の後処理結果などのよりコンパクトなフォーマットおよび／または後に行う反復的な処理の必要性が低減する別のフォーマットで処理ことができる。

上述の改良によりグラフィック処理技術において相当の恩恵が得られるが、プログラムがこの改良されたグラフィックモデルとそれに関連するその他の改良点を簡単な形で効果的に使用するための方法がなお必要とされる。必要とされるのは、こうした改良されたグラフィックモデルによって提供される多くの機能とグラフィック処理能力をプログラムが利用し、それにより複雑なグラフィックスを効率的に出力するための包括的でありながら単純な方法である。

簡潔に述べると、本発明は、要素（エレメント）オブジェクトモデルと、プログラムコードの開発者がグラフィックスを生成するシーングラフデータ構造と一貫性をもってインタフェースを取れる形でその要素オブジェクトモデルにアクセスするためのベクターグラフィックのマークアップ言語とを提供する。ベクターグラフィックマークアップ言語は、要素オブジェクトモデルを介してベクターグラフィックを表現するための交換フォーマットを備える。解釈時に、マークアップは要素ツリーの要素を含むデータに構文解析され、そのデータがシーングラフデータ構造のオブジェクトに変換される。要素ツリーレベルでは、プロパティシステムおよびプレゼンタシステムが提供されて、継承の特性とイベンティングを含む豊かなプログラム化可能機能を提供し、シーン設計者は可能性としては複雑なシーンを簡単に設計できるようになる。一般に、ベクターグラフィック要素は、形状要素と、シーングラフオブジェクトモデルのシーングラフオブジェクトと相関する画像（イメージ）要素およびビデオ要素を含むその他の要素とに相当する。ベクターグラフィック要素のプロパティ（特性）およびその他のリソースも、シーングラフオブジェクトモデルの同様のプロパティおよびリソースと相互に関連する。

したがって、ベクターグラフィックシステムは要素レベルでプログラミングすることができ、ここではページ／画面（screen）中の残りのプログラム化可能要素と同じレベルの要素として各描画形状が表され、プレゼンタシステム、イベント、およびプロパティとの対話を可能にする。ベクターグラフィックシステムはリソースレベルにプログラミングするための機構も提供し、これによりシーン設計者は基本的に、要素ツリーとプレゼンタシステムとプログラムをショートカット（shortcut）て、シーングラフデータ構造とのインタフェースを取るビジュアルＡＰＩ層に直接プログラムすることができる。この結果、要素レベルのプログラム化可能性はいくらか失われるものの、適切なオブジェクトを出力するより効率的で軽量の方法が得られる。一実装では、タイプ「ビジュアルブラシ」の塗りつぶしがプログラムされた場合、パーサー（構文解析ツール）はリソースレベルデータをもって直接ＡＰＩ層を呼び出して、対応するビジュアルペイントオブジェクト（これも要素オブジェクトモデルとシーングラフオブジェクトモデルとの相関関係である）を作成することができる。この２段階（two-tiered）システムでは、要素レベルのベクターグラフィックは構文解析されて作成後の要素となり、これは後にオブジェクトに変換することが必要であり、一方リソースレベルのベクターグラフィックが構文解析され、効率的な方式で直接格納される。同時に、リソースレベルのデータまたはそれによって作成されたオブジェクトは、要素ツリーの要素および部分から参照することができる。このためにビジュアルペイント要素を含む要素に名前を付けることができる。したがって、シーン設計者は、必要に応じて効率とプログラム化のバランスをとることができる。

要素クラスの階層には、形状クラス、画像クラス、ビデオクラス、およびキャンバスクラスが含まれる。形状クラスの要素には、矩形、ポリライン、多角形、パス、線、および楕円が含まれる。各要素は、塗りつぶし（プロパティ）データ、ストロークデータ、クリッピングデータ、変換データ、フィルタ効果データ、およびマスクデータを含むか、それらと関連付けることができる。形状は、形状を描画するのに必要とされるペンおよびブラシを構築するのに使用される、継承された、かつカスケード型のプレゼンテーションプロパティを用いて描画された（シーングラフオブジェクトモデルの）ジオメトリ（幾何学図形）に対応する。画像クラスは形状に比べて特殊性があり、より多くのラスタグラフィックデータを含むことができ、一方ビデオクラスは、表示された要素内でビデオ（あるいは同様のマルチメディア）を再生することを可能にする。キャンバスクラスは、形状のコンテナとして機能し、形状を軽量に保持することができる。

一実装では、一般には要素レベルの要素を要素ツリー／プロパティシステムに付加し、その要素にプレゼンタを付加するパーサー／トランスレータによってマークアップコードを解釈する。そしてプレゼンタシステムは、プレゼンタが付加された要素ツリーを受け取り、（１つのビルダを介して）データをオブジェクトに変換し、シーングラフとのインタフェースを取りシーングラフオブジェクトを作成するビジュアルＡＰＩ層を呼び出す。
このマークアップ言語は、単純なストリングフォーマットまたは複合オブジェクト表記（複合プロパティ構文）を含む、要素を記述する独自の方式を提供する。単純なストリングフォーマットのために、パーサー／トランスレータおよび／またはプレゼンタシステムが、ストリングを適切なビジュアルＡＰＩオブジェクトに変換するタイプコンバータを使用する。塗りつぶしの属性が複雑で単一のストリングに収まらない場合は、マークアップ中でインラインとしてよい複合プロパティ構文を使用してプロパティセットを記述する。要素レベルとＡＰＩレベル間で同じレンダリングモデルを共有するのでオブジェクトの多くが同じになり、これにより構文解析／変換が極めて効率的になり、その他の利点も得られる。リソースインスタンスも他の場所に配置することができ（例えばマークアップあるいはファイル中）、名前によって参照することができる。このように、シーン設計者は、複合プロパティ構文によって記述された要素を含めて、要素ツリーの要素をシーンを通じて再使用することができる。

この他の恩恵および利点は、以下の詳細な説明を図面と併せて読むことにより明らかになろう。

例示的動作環境
図１は、本発明を実装することができる適切なコンピューティングシステム環境１００の一例である。コンピューティングシステム環境１００は適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能性の範囲について何らの限定を示唆するものではない。またコンピューティング環境１００は、例示的動作環境１００に示す構成要素の任意の１つまたは組み合わせに関連する依存性または必要性を有するものとも解釈すべきでない。

本発明は、数多くの他の汎用または特殊目的のコンピューティングシステム環境または構成で動作することができる。本発明に使用するのに適している可能性があるよく知られるコンピューティングシステム、環境、および／または構成の例には、これらに限定しないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能なたて家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上述のシステムまたはデバイスのいずれを含む分散コンピューティング環境などがある。

本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令との一般的な関連において説明することができる。一般に、プログラムモジュールには、特定タスクを行うか、あるいは特定の抽象データ型を実行するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。本発明は、通信ネットワークを通じてつながれた遠隔の処理装置によってタスクを行う分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、メモリ記憶装置を含むローカルおよびリモート両方のコンピュータ記憶媒体にプログラムモジュールを置くことができる。

図１を参照すると、本発明を実施する例示的システムは、コンピュータ１１０の形態の汎用コンピューティングデバイスを含む。コンピュータ１１０の構成要素には、これらに限定しないが、処理装置１２０、システムメモリ１３０、およびシステムメモリを含む各種のシステム構成要素を処理装置１２０に結合するシステムバス１２１とが含まれている。システムバス１２１は、各種のバスアーキテクチャの任意のものを使用したメモリバスまたはメモリコントローラ、ペリフェラルバス、およびローカルバスを含む数タイプのバス構造のいずれでもよい。例として、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）バス、およびメザニンバスとも称されるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスが含まれるが、これらに限定しない。

コンピュータ１１０は通例各種のコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０がアクセスすることができる任意の利用可能媒体でよく、揮発性および不揮発性の媒体、取り外し可能および取り外し不能媒体が含まれる。これに限定しないが、例としてコンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術に実装された揮発性および不揮発性の媒体、取り外し可能および取り外し不能の媒体を含む。コンピュータ記憶媒体には、これらに限定しないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、あるいは、所望の情報の記憶に用いることができ、コンピュータ１１０によるアクセスが可能な任意の他の媒体が含まれる。通信媒体は、通例、搬送波または他の搬送機構などの変調データ信号にコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを実施し、任意の情報伝達媒体を含む。用語「変調データ信号」とは、信号中に情報を符号化するような方式でその特性の１つまたは複数を設定または変化させた信号を意味する。例として、通信媒体には、配線ネットワークまたは直接配線接続などの配線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれるが、これらに限定しない。上記の媒体のいずれの組み合わせもコンピュータ可読媒体の範囲に含めるべきである。

システムメモリ１３０には、読み取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体が含まれる。起動時などにコンピュータ１１０内の要素間の情報転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は、通例ＲＯＭ１３１に記憶される。ＲＡＭ１３２は通例、処理装置１２０から即座にアクセス可能な、かつ／または現在処理装置１２０によって操作中のデータおよび／またはプログラムモジュールを含む。これらに限定しないが、例として、図１にはオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示している。

コンピュータ１１０は、他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。単なる例として、図１には、取り外し不能、不揮発性の磁気媒体の読み取りまたは書き込みを行うハードディスクドライブ１４１、取り外し可能、不揮発性の磁気ディスク１５２の読み取りまたは書き込みを行う磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭや他の光媒体などの取り外し可能、不揮発性の光ディスク１５６の読み取りまたは書き込みを行う光ディスクドライブ１５５を示す。例示的動作環境で使用できるこの他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体には、これらに限定しないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４１は通例、インタフェース１４０などの取り外し不能のメモリインタフェースを通じてシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通例、インタフェース１５０など取り外し可能なメモリインタフェースによってシステムバス１２１に接続される。

上記で説明し、図１に示すドライブとそれらに関連付けられたコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピュータ１１０のその他のデータの記憶を提供する。例えば図１では、ハードディスクドライブ１４１にオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７の格納が示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じものでも、異なるものでもよいことに留意されたい。ここではオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、それらが少なくとも異なるコピーであることを表すために異なる参照符号を付けている。ユーザは、タブレット（電子デジタイザ）１６４、マイクロフォン１６３、キーボード１６２、および一般にはマウス、トラックボール、あるいはタッチパッドと称するポインティングデバイス１６１などの入力装置を通じてコンピュータ１１０にコマンドと情報を入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらおよび他の入力装置は、システムバスに結合されたユーザ入力インタフェース１６０を通じて処理装置１２０に接続することが多いが、パラレルポート、ゲームポート、あるいはユニバーサルシリアルバス（ＵＳＢ）など他のインタフェースおよびバス構造によって接続することも可能である。モニタ１９１または他タイプの表示装置も、ビデオインタフェース１９０などのようなインタフェースを介してシステムバス１２１に接続される。モニタ１９１は、タッチスクリーンインタフェース１９２などのようなインタフェースを介して手書きなどのデジタル化された入力をコンピュータシステム１１０に入力することが可能なタッチスクリーンパネル１９３などと一体化してもよい。モニタおよび／またはタッチスクリーンパネルは、タブレットタイプのパーソナルコンピュータのように、コンピューティングデバイス１１０が組み込まれた筐体（ハウジング）に物理的に結合することができ、その場合は基本的にタッチスクリーンパネル１９３がタブレット１６４として機能することに留意されたい。さらに、コンピューティングデバイス１１０などのコンピュータは、スピーカ１９５やプリンタ１９６など他の周辺出力装置も含むことができ、それらは出力周辺インタフェース１９４などを通じて接続することができる。

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

ＬＡＮネットワーキング環境で使用する場合、コンピュータ１１０はネットワークインタフェースまたはアダプタ１７０を通じてＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は通例、インターネットなどのＷＡＮ１７３を通じて通信を確立するためのモデム１７２またはその他の手段を含む。モデム１７２は内蔵型でも外付け型でもよく、ユーザ入力インタフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０との関連で図示したプログラムモジュール、またはその一部は遠隔のメモリ記憶装置に格納することができる。これに限定しないが、例として図１ではリモートアプリケーションプログラム１８５がメモリ装置１８１に常駐していることが示されている。図のネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段を使用できることは理解されよう。

グラフィックアーキテクチャ
本発明の一態様は、概して、アプリケーションやオペレーティングシステムコンポーネントなどのプログラムコードが、システムディスプレイにグラフィック出力をレンダリングするために描画命令またはその他の情報（例えば画像ビットマップ）をグラフィックコンポーネントに伝達できるようにすることを対象とする。このために、本発明は、マークアップ言語とともに、形状要素およびその他の要素の１セット、グループ化および合成システム、およびオブジェクトモデル中の一般的なプロパティシステムとの統合を提供することで、プログラムが、データ構造、描画プリミティブ（コマンド）およびその他のグラフィック関連データをシーングラフに居住できるようにする。処理するとそのシーングラフは画面に表示されたグラフィック（画像）となる。

図２は、本発明を実施することができる概して階層アーキテクチャ２００を表す。図２に表すように、プログラムコード２０２（例えばアプリケーションプログラムやオペレーティングシステムコンポーネントなど）は、画像化２０４を介して、ベクターグラフィック要素２０６を介して、および／またはビジュアルアプリケーションプログラミングインタフェース（ＡＰＩ）層２１２に直接置かれた関数／メソッド呼び出しを介して、１つまたは複数の各種の方法でグラフィックデータを出力するように構築することができる。ＡＰＩ層との直接の対話については上述の文献にさらに記載されている（例えば、米特許出願、”visual and scene Graph Interface”）。

概して、画像化２０４は、例えばビットマップなどの画像をロードし、編集し、保存する機構をプログラムコード２０２に提供する。それら画像はシステムの他の部門によっても使用することができ、またプリミティブ描画コードを使用して直接画像に描画する方法もある。

本発明の一態様によれば、ベクターグラフィック要素２０６は、オブジェクトモデルの残りの部分との整合性を保ちながら、グラフィックを描画する別の方法（下記）を提供する。ベクターグラフィック要素２０６はマークアップ言語によって作成することができ、要素／プロパティシステム２０８およびプレンゼンタシステム２１０は、ベクターグラフィック要素２０６を処理してビジュアルＡＰＩ層２１２に対する適切な呼び出しを行う。下記で図２６を参照して説明するが、一般に、ベクターグラフィック要素２０６は構文解析されて、シーングラフがそこから描画されるオブジェクトモデルのオブジェクトとなり、このオブジェクトは、要素／プロパティシステム２０８およびプレゼンタシステム２１０を介して要素レベルを通じてシーングラフへ提供するか、あるいはリソースレベルでより効率的な形で提供することができる。これについても後述する。

一実装では、グラフィック層アーキテクチャ２００は高水準の合成およびアニメーションエンジン２１４を含み、このエンジンはキャッシングデータ構造２１６を含むか、あるいはその他の形で関連付けられる。キャッシングデータ構造２１６は、下記のように、定義されたオブジェクトモデルに従って管理される階層的に構成されたオブジェクトからなるシーングラフを含む。概して、ビジュアルＡＰＩ層２１２は、プログラムコード２０２（およびプレゼンタシステム２１０）にキャッシングデータ構造２１６とのインタフェースを与え、オブジェクトを作成し、オブジェクトを開閉してオブジェクトにデータを提供するなどの能力が含まれる。すなわち高水準の合成およびアニメーションエンジン２１４は統合されたメディアＡＰＩ層２１２を公開し、開発者はこれによりグラフィックおよびグラフィック情報を表示する媒体についての意図を表し、基礎プラットフォームに十分な情報を提供することができ、プラットフォームはプログラムコードのためにハードウェア使用を最適化することができる。例えば、基礎プラットフォームは、キャッシング、リソースのネゴシエーション、および媒体の統合を受け持つ。

一実装では、高水準の合成およびアニメーションエンジン２１４は、命令ストリームおよび可能性としては他のデータ（例えばビットマップへのポインタ）を、高速な低水準の合成およびアニメーションエンジン２１８に渡す。本明細書で使用する場合、用語「高水準」および「低水準」は他のコンピューティングシナリオで使用されるものと同様の意味であり、一般には、あるソフトウェアコンポーネントがより高いコンポーネントに対して低いほどそのコンポーネントはハードウェアに近づく。したがって、例えば、高水準の合成およびアニメーションエンジン２１４から送られるグラフィック情報は、低水準の合成およびアニメーションエンジン２１８で受け取ることができ、低水準のエンジンではその情報を使用してハードウェア２２２を含むグラフィックサブシステムにグラフィックデータを送る。

高水準の合成およびアニメーションエンジン２１４はプログラムコード２０２と連動して、プログラムコード２０２によって提供されるグラフィックシーンを表すシーングラフを構築する。例えば、描画する各項目を描画命令によってロードすることができ、システムはその項目をシーングラフデータ構造２１６にキャッシュすることができる。下記で述べるように、このデータ構造２１６および描画内容を指定するにはいくつかの様々な方式がある。さらに、高水準の合成およびアニメーションエンジン２１４はタイミングおよびアニメーションシステム２２０と統合して、宣言型（あるいは他の形）のアニメーション制御（例えばアニメーションの間隔）とタイミング制御を提供する。このアニメーションシステムでは、例えば要素プロパティレベル２０８、ビジュアルＡＰＩ層２１２の内部、およびその他リソースのうち任意のものを含めて、基本的にシステム中のどこへでもアニメーション値を渡せることに留意されたい。タイミングシステムは、要素レベルおよびビジュアルレベルで公開される。

低水準の合成およびアニメーションエンジン２１８は、シーンの合成、アニメーション化、およびレンダリングを管理し、それをグラフィックサブシステム２２２に提供する。低水準のエンジン２１８は、複数アプリケーションのシーンのレンダリングを構成し、レンダリングコンポーネントを用いて実際のグラフィックのレンダリングを画面に実施する。ただし、場合によっては、レンダリングの一部をより高いレベルで行うことが必要、かつ／または好都合である場合もあることに留意されたい。例えば、より低水準の層が複数アプリケーションからの要求にサービス（奉仕）するのに対して、より高水準の層はアプリケーション単位でインスタンス化され、これのより、時間を要するレンダリングあるいはアプリケーション固有のレンダリングをより高いレベルで行い、ビットマップに対する参照をより低水準の層に渡す画像化機構２０４を介して可能になる。

シーングラフオブジェクトモデル
下記で述べるように、レンダリングモデルは、より高水準でコントロールベースのベクターグラフィック要素２０６と、シーングラフデータ構造２１６で使用される、ビジュアルＡＰＩ層２１２によって作成されたより低水準のオブジェクトとによって共有される。これにより、本発明の高水準の要素と低水準のオブジェクト間に相当な量の相互関係が得られる。以下でシーングラフオブジェクトモデルの一実装について説明する。

図３および図４に、それぞれビジュアルと称する基礎オブジェクトを含む例示的なシーングラフ３００および４００を示す。一般に、ビジュアルは、ユーザに対する仮想表面（仮想サーフェース）を表し、ディスプレイ上の視覚的な表現を有するオブジェクトからなる。図５に表すように、基礎クラスのビジュアルは他のビジュアルタイプに基本機能を提供し、すなわち、ビジュアルクラス５００は、ビジュアルタイプ（例えば５０１〜５０６）が派生する抽象的な基礎クラスである。

図３に表すように、最上位レベル（すなわちルート）のビジュアル３０２はビジュアルマネージャオブジェクト３０４に接続され、ビジュアルマネージャオブジェクト３０４も、プログラムコードに対してグラフィックデータが出力されるウィンドウ（ＨＷｎｄ）３０６または同様の単位との関係を（例えばハンドルを介して）有する。ビジュアルマネージャ（ＶｉｓｕａｌＭａｎａｇｅｒ）３０４は、そのウィンドウ３０６への最上位レベルのビジュアル（およびそのビジュアルの任意の子）の描画を管理する。図６に、ここに記載するグラフィックシステムのオブジェクトモデルの他オブジェクト６２０の１セットの１つとしてビジュアルマネージャを示している。

描画するには、ビジュアルマネージャ３０４はディスパッチャ３０８によりスケジュールされたようにシーングラフを処理（例えばトラバースまたは送信）し、グラフィック命令およびその他のデータをそれに対応するウィンドウ３０６について低水準コンポーネント２１８（図２）に提供する。これについては概説される（例えば、米国特許出願１０／１８４，７９５、米国特許出願１０／１８４，７９６、米国特許出願１０／１８５，７７５（それぞれ本発明の関連出願である２００２年６月２７日付けの同時継続出願）参照）。通例、シーングラフの処理はディスパッチャ３０８により、より低水準のコンポーネント２１８および／またはグラフィックサブシステム２２２のリフレッシュ速度に比べて相対的に低い速度でスケジュールされる。図３には、最上位（ルート）ビジュアル３０２の下に階層的に配置された幾つかの子ビジュアル３１０〜３１５を示しているが、このうちの一部にはそれぞれ、描画コンテクスト３１６、３１７（一時的な性質であることを表すために破線の枠で示している）を介して、例えば描画プリミティブやその他のビジュアルを含む関連付けられた命令リスト３１８および３１９がポピュレートされている。ビジュアルは、次のビジュアルクラスの例に示すように他のプロパティ情報も含むことができる。

変換プロパティによって設定される変換は、ビジュアルの部分グラフの座標系を定義する。変換前の座標系を変換前座標系と呼び、変換後の座標系を変換後座標系と呼ぶ。ここで、変換をともなうあるビジュアルは、変換ノードを親として有するビジュアルに相当する。図７に変換の一例を概略的に示し、ビジュアルに対する変換前座標系と変換後座標系を識別している。ビジュアルの変換を得る、または設定するのに、Ｔｒａｎｓｆｏｒｍ（変換）プロパティを使用することができる。

座標変換は、あたかもビットマップ中で行う場合のように均一な方法であらゆるものに適用できることに留意されたい。これは変換が常にビットマップに適用されるという意味ではなく、レンダリングされるものが等しく変換の影響を受けることを意味することに留意されたい。例として、ユーザが１インチ（２．５４ｃｍ）幅の先の丸いペンで円を描画し、その円に２のＸ方向のスケールを適用する場合、ペンの幅は左と右では２インチ（５．０８ｃｍ）になり、上部と下部ではわずか１インチ（２．５４ｃｍ）になる。これは時に、（ジオメトリ（幾何学図形）だけに影響するスケルトンまたはジオメトリスケールに対して）合成またはビットマップ変換と呼ばれる。図８Ａはスケーリング変換を表したものであり、左に未変換の画像８００を示し、不均一のスケールをかけた変換後の画像８０２を右に示している。図８Ｂはスケーリング変換を表したものであり、未変換の画像８００を左に示し、ジオメトリスケーリングをかけた変換後画像８０４を右に示している。

ビジュアルの座標変換に関しては、ＴｒａｎｓｆｏｒｍＴｏＤｅｓｃｅｎｄａｎｔ（子孫への変換）が基準ビジュアルから子孫ビジュアルへと点（ポイント）を変換する。点は、基準ビジュアルの変換後の座標空間から、子孫ビジュアルの変換後の座標空間へと変換される。ＴｒａｎｓｆｏｒｍＦｒｏｍＤｅｓｃｅｎｄａｎｔ（子孫からの変換）は、子孫ビジュアルから親チェーンを遡り基準ビジュアルへと点を変換する。点は、子孫ビジュアルの変換後の座標空間から、基準ビジュアルの変換後の座標空間へと変換される。ＣａｌｃｕｌａｔｅＢｏｕｎｄｓ（境界の計算）メソッドは、変換後の座標空間におけるビジュアル内容のバウンディングボックスを戻す。座標変換中にビジュアルに対する変換をどのように解釈するかについて、より具体的な指定が可能な代替バージョンのＡＰＩがある可能性があることに留意されたい。例えば、基準ビジュアルおよび子孫ビジュアルに対する変換は考慮に入れても、入れなくともよい。したがって、この代替法では４つのオプションがあることになる。例えば、座標は、変換前の空間から変換前の空間へ、変換前の空間から変換後の空間へ、変換後の空間から変換前の空間へ、そして変換後の空間から変換後の空間に変換することができる。これと同じ概念はヒットテストにも当てはまり、例えばヒットテストは変換前または変換後の変換座標空間で開始することができ、ヒットテストの結果は、変換前の座標空間または変換後の座標空間における結果とすることができる。

クリッププロパティは、ビジュアルのクリッピング領域を設定（および入手）する。任意のジオメトリ（ジオメトリクラスについては下記で図１２を参照して説明する）をクリッピング領域として使用することができ、そのクリッピング領域を変換後の座標空間に付け加える。一実装では、クリッピング領域のデフォルト設定はヌル、すなわちクリッピングなしであり、これは（−∞、−∞）から（＋∞、＋∞）までの無限の大きなクリッピング矩形と考えることができる。

Ｏｐａｃｉｔｙ（不透明）プロパティは、ビジュアルの不透明度値を入手／設定し、不透明度値および選択されたブレンドモードに基づいてビジュアルの内容を描画サーフェース上でブレンドする。ＢｌｅｎｄＭｏｄｅ（混合モード）プロパティは、使用するブレンドモードの設定（または入手）に使用することができる。例えば不透明度（アルファ）値は０．０から１．０の間に設定することができ、線形のアルファブレンディングをモードとして設定する。例えば、色＝アルファ値＊前景色＋（１．０−アルファ値）＊背景色）となる。例えば、ぼかし、モノクロといった特殊効果プロパティなど他のサービスをビジュアル中に含めることができる。

各種サービス（変換、不透明度、クリッピングを含む）は描画コンテクスト上にプッシュおよびポップすることができ、またプッシュ／ポップ操作は、ポップ呼び出しがプッシュ呼び出しと一致するのであれば入れ子にすることができる。例えば、ＰｕｓｈＴｒａｎｓｆｏｒｍ（．．．）；ＰｕｓｈＯｐａｃｉｔｙ（．．．）；ＰｏｐＴｒａｎｓｆｏｒｍ（．．．）は、ＰｏｐＴｒａｎｓｆｏｒｍ呼び出しの前に,ＰｏｐＯｐａｃｉｔｙを呼び出す必要があるので無効（illegal）である。

ＰｕｓｈＴｒａｎｓｆｏｒｍメソッドは変換をプッシュする。以降の描画操作は、プッシュされた変換について実行される。ＰｏｐＴｒａｎｓｆｏｒｍは、対応する揃いのＰｕｓｈＴｒａｎｓｆｏｒｍの呼び出しによってプッシュされた変換をポップする。
void PushTransform(Transform transform);
void PushTransform(Matrix matrix);
void PopTransform();

同様にＰｕｓｈＯｐａｃｉｔｙメソッドは不透明度値をプッシュする。以降の描画操作は、指定された不透明度値で一時的なサーフェース上にレンダリングされ、その後シーンに合成される。ＰｏｐＯｐａｃｉｔｙは、対応するＰｕｓｈＯｐａｃｉｔｙの呼び出しによってプッシュされた不透明度をポップする。
void PushOpacity(float opacity);
void PushOpacity(NumberAnimationBase opacity);
void PopOpacity();

ＰｕｓｈＣｌｉｐメソッドはクリッピングジオメトリをプッシュする。以降の描画操作はそのジオメトリに合わせてクリッピングされる。クリッピングは変換後の空間に適用される。ＰｏｐＣｌｉｐは、対応するＰｕｓｈＣｌｉｐの呼び出しによってプッシュされたクリッピング領域をポップする。
void PushClip(Geometry clip);
void PopClip();

プッシュ操作は、ポップ操作がプッシュと対応するのであれば任意で入れ子にできることに留意されたい。例えば、次は有効である。

ヒットテストは変換後の座標空間で行われ、例えばペンやマウスのクリックが検出されたときにヒットする、各ヒットテストが可能なビジュアルの識別に戻る。このインタフェースの代替バージョンでは、ヒットテストを開始するビジュアルに相対的な変換前の座標空間でヒットテストを開始できるようにすることができる。ヒットしたビジュアルは、右から左に深さ優先の順序で戻される。ヒットテストは各種のフラグで制御することができ、このフラグには、ビジュアルがヒットテスト可能であるかどうかを判定する（デフォルトは真）ＨｉｔＴｅｓｔａｂｌｅと、ビジュアルがヒットしたときにヒットテストを中止するかどうか、すなわちあるビジュアルがヒットし、そのビジュアルのＨｉｔＴｅｓｔＦｉｎａｌプロパティが真である場合に、ヒットテストを中止し、その時点までに収集された結果を戻すかどうかを判定する（デフォルトは偽）ＨｉｔＴｅｓｔＦｉｎａｌとが含まれる。別のフラグはＨｉｔＴｅｓｔＩｇｎｏｒｅＣｈｉｌｄｒｅｎであり、これは、ビジュアルにヒットテストを行う際にビジュアルの子を考慮すべきかどうかを判定する（デフォルトは偽）。

ＰｒｏｘｙＶｉｓｕａｌは、シーングラフに複数回追加することが可能なビジュアルである。ＰｒｏｘｙＶｉｓｕａｌによって参照されるビジュアルはいずれもルートから複数のパスで到達することができるので、リードサービス（ＴｒａｎｓｆｏｒｍＴｏＤｅｓｃｅｎｄａｎｔ、ＴｒａｎｓｆｏｒｍＦｒｏｍＤｅｓｃｅｎｄａｎｔ、およびＨｉｔＴｅｓｔ）は、ＰｒｏｘｙＶｉｓｕａｌを通じては働かない。基本的には任意のビジュアルからそのビジュアルツリーのルートへの標準的なパスが１つあり、そのパスはＰｒｏｘｙＶｉｓｕａｌを含まない。

図５に表すようにオブジェクトモデルには各種タイプのビジュアルが定義され、これにはＣｏｎｔａｉｎｅｒＶｉｓｕａｌｓ５０１、ＤｒａｗｉｎｇＶｉｓｕａｌｓ５０２、ＶａｌｉｄａｔｉｏｎＶｉｓｕａｌｓ５０３、ＳｕｒｆａｃｅＶｉｓｕａｌｓ５０４、およびＨｗｎｄＶｉｓｕａｌｓ５０５が含まれる。次の表に、ＤｒａｗｉｎｇＶｉｓｕａｌのメソッド例を挙げる。

ＤｒａｗｉｎｇＶｉｓｕａｌは、グラフィック内容（例えば線、テキスト（文字）、画像など）のコンテナである。ＤｒａｗｉｎｇＶｉｓｕａｌにビジュアルを追加することが可能であるが、実装によっては許されないことに留意されたい。ＤｒａｗｉｎｇＶｉｓｕａｌ５０２はＯｐｅｎメソッドを含み、このメソッドは、下記で述べるように例えば他のビジュアルや描画プリミティブをＤｒａｗｉｎｇＶｉｓｕａｌに居住させるのに使用することのできるＩＤｒａｗｉｎｇＣｏｎｔｅｘｔを戻す。一実装では、同じく下記で述べる様々な理由から、ＤｒａｗｉｎｇＶｉｓｕａｌはその描画コンテクストを居住させるのに一度だけしか開くことができない。言い換えると、このようなＤｒａｗｉｎｇＶｉｓｕａｌは不変である。ＤｒａｗｉｎｇＶｉｓｕａｌを居住させると、ＤｒａｗｉｎｇＶｉｓｕａｌは例えば描画コンテクストでＣｌｏｓｅメソッドを使用して閉じられる。Ｏｐｅｎの呼び出しによりビジュアルの内容（子）をすべてクリアすることができるが、代替の一実装では、現在のビジュアルに付加するような形でその現在のビジュアルを開くＡｐｐｅｎｄメソッドが提供されることに留意されたい。換言すると、ＯｐｅｎＦｏｒＡｐｐｅｎｄの呼び出しは、ＤｒａｗｉｎｇＶｉｓｕａｌの現在の内容がオープン時にクリアされない点を除いてはＯｐｅｎと同様に働く。

次に示すのは、描画コンテクストを使用してビジュアルを居住させる一例である。

一般に、ＶａｌｉｄａｔｉｏｎＶｉｓｕａｌ５０３は、プログラムコードがそのポピュレートを必要とするときではなく、システムがそれを埋めることを要求したときにポピュレートされる点を除いては概念的にＤｒａｗｉｎｇＶｉｓｕａｌに類似する。例えば、米国特許出願１０／１８５，７７５に記載されているように、高水準のコンポジションおよびアニメーションエンジン２１４（図２）は、シーングラフの一部が見えない状態であるときなど、リソースが必要とされる際には、シーングラフデータを無効にすることができる。例えば、一部の部分がスクロールされてディスプレイから消える、クリッピングされるなどの場合である。無効にしたシーングラフデータが後に必要となった場合は、呼び出されたプログラムコード２０２を呼び戻してそのシーングラフの無効部分を再描画（有効に）する。このために、典型的な慣用シナリオの１つは、プログラムコードがＶａｌｉｄａｔｉｏｎＶｉｓｕａｌをサブクラス化し、ＯｎＶａｌｉｄａｔｅメソッドをオーバーライドするものである。システムがＯｎＶａｌｉｄａｔｅメソッドを呼び出すと描画コンテクストが渡され、プログラムはその描画コンテクストを使用してＶａｌｉｄａｔｉｏｎＶｉｓｕａｌを再度居住させる。

下記の例に、例えばある色で線を描画するものなど単純なＶａｌｉｄａｔｉｏｎＶｉｓｕａｌを実装する一方法を示す。線の色はＳｅｔＣｏｌｏｒを呼び出すことによって変更することができる。ＶａｌｉｄａｔｉｏｎＶｉｓｕａｌの更新を強制するために、ＳｅｔＣｏｌｏｒはＩｎｖａｌｉｄａｔｅを呼び出して、グラフィックサブシステムにＶａｌｉｄａｔｉｏｎＶｉｓｕａｌを再度有効にさせる。

次の例は、ＶａｌｉｄａｔｉｏｎＶｉｓｕａｌの使用法を示す。

図４に、ＣｏｎｔａｉｎｅｒＶｉｓｕａｌとＤｒａｗｉｎｇＶｉｓｕａｌがシーングラフ中で関連付けられ、描画プリミティブの形態での関連付けられたデータを（例えば対応する描画コンテクストに）有するシーングラフの例４００を示す。ＣｏｎｔａｉｎｅｒＶｉｓｕａｌはビジュアルのコンテナであり、ＣｏｎｔａｉｎｅｒＶｉｓｕａｌは互いに入れ子にすることができる。ＣｏｎｔａｉｎｅｒＶｉｓｕａｌの子は、ＶｉｓｕａｌＣｏｎｔａｉｎｅｒの子プロパティから戻されるＶｉｓｕａｌＣｏｌｌｅｃｔｉｏｎを用いて操作することができる。ＶｉｓｕａｌＣｏｌｌｅｃｔｉｏｎ中のビジュアルの順序によってそのビジュアルのレンダリング順序が決まり、すなわち、ビジュアルは最低のインデックスから最高のインデックスへと後ろから前へとレンダリングされる（ペインティングの順序）。例えば、あるコンテナビジュアルの下に赤、緑、青の矩形を階層的に表す３つの描画ビジュアルに適切なパラメータがある場合、以下に示すコードにより３つの矩形が（右下へと平行移動して）描画され、赤い矩形が背面に、緑の矩形が中間に、そして青い矩形が前面に描画されることとなる。

図５に表すように、別のタイプのビジュアルオブジェクトはＳｕｒｆａｃｅＶｉｓｕａｌ５０４である。一般には、図３に表すように、ＳｕｒｆａｃｅＶｉｓｕａｌオブジェクト３１５は、プログラムコード２０２（図２）がアクセス可能なインメモリサーフェース（ビットマップ）３２２を参照する。クライアントプログラムコード２０２は自身のサーフェースメモリを供給するか、またはサーフェースオブジェクトによりメモリを割り当てるように要求することができる。

プログラムコード２０２は、ＳｕｒｆａｃｅＶｉｓｕａｌを開いて描画コンテクスト３２３を得るオプションを有し、プログラムコード２０２はその描画コンテクストにピクセルデータ３２４などを書き込み、そのピクセルを直接サーフェースに置くことができる。図３ではこれをサーフェースオブジェクト３２２と、描画コンテクスト３２３（一時的な性質であることを表すために破線の枠で表している）と、ピクセルデータ３２４とを結ぶ破線で表している。

プログラムコード２０２は、サーフェースビジュアルマネージャ３３０を作成し、ビジュアルの部分グラフ３３２にＳｕｒｆａｃｅＶｉｓｕａｌ３１５を関連付けるオプションも有する。図３ではこのオプションをサーフェースオブジェクト３２２とサーフェースビジュアルマネージャ３３０を結ぶ破線で表している。同じく図３に示すように、ビジュアル部分グラフ３３２は他のサーフェースビジュアルを入れ子にできることに留意されたい。サーフェースビジュアルマネージャ３３０（図６の１セット６００に他オブジェクトの１タイプとしても示している）は、ビジュアル部分グラフ３３２をウォーク（走査）してＳｕｒｆａｃｅＶｉｓｕａｌビットマップ３２２を更新する。さらに、このトラバースはディスパッチャ３０８によってスケジュールされ、また効率のためにこのビットマップ３２２の更新頻度を調整するように抑制（ｔｈｒｏｔｔｌｅ）できることにも留意されたい。サーフェースビジュアルマネージャ３３０は、最上位レベルのビジュアルマネージャ３０２がシーングラフの残りの部分をウォークするたびに、かつ／またはそれと同じ割合でビジュアル部分グラフ３２２をトラバースしなくともよい。

したがって図９Ａから９Ｃを参照してさらに説明するように、サーフェースに関して、このグラフィックモデルは一般に、サーフェースへのビジュアルのセットの合成、即時モードによるサーフェースへのベクトルおよびビットマッププリミティブのレンダリング、デスクトップまたは別のサーフェースへのサーフェースの合成、およびサーフェースリスト中のどのサーフェースを使用してそこへの合成および描画を行うかの制御を可能にする。サーフェースリストは、ビジュアルまたはグラフィック描画あるいはその両方の合成を格納するのに使用される物理（システムまたはビデオ）メモリの１つまたは複数のサーフェース（すなわちフレーム／バッファ）の集合として定義される。サーフェースリストのサーフェースの１つを描画および／または合成が行われる現在のバックバッファに設定することができ、サーフェースリストのサーフェースの１つを別のレンダリングターゲット上に合成するのに用いる現在のプライマリまたはフロントバッファとして設定する。

サーフェースはいくつかの方式で使用することができる。例として図９Ａにサーフェースへの合成を示す。図９Ａでは、サーフェースビジュアルマネージャオブジェクト９００が、ビジュアルツリー９０４のレンダリングターゲットとしてのサーフェースリスト９０２を結び付けている。各合成サイクルの期間に、現在のところサーフェースリストのアクティブなバックバッファとして機能しているサーフェースリストのサーフェース中にビジュアルを合成する。合成されるサーフェースには、インプロセスの合成シナリオのために、クライアント／高水準の合成エンジン２１４（図２）によって所有されるサーフェースや、クライアントがビットを必要とせず、低水準の合成エンジン２１８がサーフェースを別のレンダリングターゲット上に合成するためにそのビットを必要とするシナリオで低水準の合成エンジン２１８によって所有されるサーフェース、あるいはクライアントがサーフェースビットへのアクセスを必要とするが、低水準の合成エンジン２１８も他の合成作業のためにそのサーフェースを必要とするシナリオのクロスプロセスサーフェースが含まれる可能性がある。

合成は、ビジュアルマネージャに付随するタイミングサービスによって制御される。タイミングサービスの一例は、次の例のように使用することが可能な手動モードである。

サーフェースを使用する別の方法は、コンテクストを介して即時モードでサーフェース上にレンダリングを行うものである。ビジュアル（サーフェースビジュアル）にサーフェースリストを付加することにより、現在そのサーフェースリストのためのアクティブなバックバッファとして機能しているサーフェースリストのサーフェースに即時モードでレンダリングすることが可能になる。上述のように、このレンダリングは、サーフェースビジュアルから描画コンテクストを入手し、そのコンテクストに描画コマンドを実行することによって行う。描画コンテクストを入手するとサーフェースがロックされ、そのサーフェースには他の合成操作を行えなくなることに留意されたい。各描画コマンドは直ちに実行され、ベクトルおよび他のサーフェースをそのサーフェースに描画（ブレンド：混合）することができる。ただしそのサーフェースに他のビジュアルを描画することはできず、代わりに、上述のように（図９Ａなど）そのサーフェースにビジュアルマネージャを関連付けることにより他のビジュアルをそのサーフェース中に合成することができる。

サーフェースの別の使用は、別のレンダリングターゲット上にサーフェースを合成する場合である。このために、サーフェースリストがサーフェースビジュアルに付随されるとそのサーフェースをビジュアルツリーにノードとして加えることができ、現在プライマリまたはフロントバッファとして機能しているサーフェースリストのサーフェースを別のサーフェースまたはデスクトップに合成することができる。これを図９Ｂと次の例に示す。

図９Ｃにサーフェースへの／サーフェースからのライブ（live）の合成を表し、ここではサーフェースリストのバックバッファサーフェースへの合成と、サーフェースリストのフロントバッファサーフェースからの（例えばデスクトップへの）合成とが同時に行われるように、上述の機能を組み合わせている。ティアリング（ｔｅａｒｉｎｇ）として知られる望ましくないビデオ効果を除去するために、サーフェースリストは、フロントバッファサーフェースとバックバッファサーフェースの少なくとも２つのサーフェースを持つべきことに留意されたい。図９Ｃで用いるサーフェースは恐らくは低水準エンジン２１８によって所有されるものであるか、あるいは低水準エンジン２１８における合成をより良好に行わせるクロスプロセスサーフェースである。

次のコンストラクタの例に示すように、サーフェースは独立したオブジェクトとして構築される。

構築するとサーフェースおよび／またはサーフェースリストは、サーフェースビジュアルオブジェクトまたはビジュアルマネージャオブジェクトに付随することができる。

さらにサーフェースはデコーダからデータを得ることができ、かつ／または特定のファイルフォーマットに書き出すためにそれが持つデータをエンコーダに送ることができる。サーフェースはまた、効果インタフェースからデータを受け取ることができ、効果インタフェースにデータを送ることもできる。サーフェースは、サポートされるサーフェースフォーマットタイプのフルセットから任意のピクセルフォーマットに構築されることができる。ただし指定されたピクセルフォーマットにはいくらかの調整を行うことができ、例えば、指定されたピクセルフォーマットが１ピクセル当たり３２ビット未満である場合には、そのフォーマットは１ピクセルにつき３２ビットに昇格される。元のフォーマットでのサーフェースにビットが要求されるときには、フォーマット変換フィルタを使用してそのサーフェースを要求されたピクセルフォーマットのバッファにコピーする。

図５に戻ると、さらに別のビジュアルはＨｗｎｄＶｉｓｕａｌ５０５であり、これはＷｉｎ３２の子ＨＷｎｄをシーングラフ中に配置する。より詳細には、レガシー（遺物）プログラムは今なお、従来のグラフィック技術に基づいて子ＨＷｎｄ（など）に描画するＷＭ＿ＰＡＩＮＴメソッド（など）を介して動作している。この新しいグラフィック処理モデルでそのようなプログラムをサポートするために、図１０Ａに表すように、ＨｗｎｄＶｉｓｕａｌは、Ｈｗｎｄをシーングラフに含め、親のビジュアルの位置が変更されるのに従って移動することを可能にする。ただし、既存のＨｗｎｄに伴う制限の結果、レンダリング時に、子Ｈｗｎｄは他のウィンドウの上に置くことしかできず、上述の他のビジュアルのように回転、あるいはスケーリングすることができない。図１０Ｂに表すように、いくらかのクリッピングは可能であり、図１０Ｂでは、その親ビジュアルに対する相対的な移動の際にＨＷｎｄの表示された矩形がクリッピングされていることを破線で示している。

この他のタイプのビジュアル５０６も実行可能であり、本オブジェクトモデルはこれから開発される他のビジュアルに拡張が可能である。例えば図１１に表すように、階層化されたビジュアル１１００により、アプリケーション開発者は複数のデータストリームを介してビジュアル中の情報を個別に制御することが可能になり、単一のデータストリームを有するビジュアルに比べてより精緻な制御の細分性（granularity）が得られる。同様の制御細分性は、単一の親ビジュアルの下に別個の（例えば３つの）子ビジュアルを待たせることによって達成することができるが、それにはプログラムコードが複数のビジュアルを操作することが必要となり、それは複数の層への索引（インデックス）を有する単一階層ビジュアルを操作するのに比べて複雑であることに留意されたい。

例として図１１では背景データ、内容データ、および輪郭データが単一階層ビジュアルに含まれているが、それぞれ例えば０、１、または２のレイヤ値でインデックスを付けるようにすることで互いに分離されている。層（レイヤ）は、どちらかの端に連結（ｔａｃｋ）するなどで挿入することができ、かつ／または削除することができ、階層化の順序（例えば図のように左から右）によって表示の際のＺオーダが間接的に定義される。セキュリティのために、子の内容データおよび階層ビジュアル中のその他のデータは列挙できないことに留意されたい。

この他のタイプのビジュアルには、コンテナビジュアルとリダイレクトされた子ＨＷｎｄビジュアルが含まれ、後者では内容がビットマップに描画され、サーフェースビジュアルに組み込まれる。３次元ビジュアルは、２次元世界と３次元世界の連結を可能にし、例えば３次元世界の中のビューを有する２次元のビジュアルを介してカメラ様のビューが可能である。

リソースオブジェクトの多くは一旦作成されると不変であり、すなわちそれらは一旦作成されると、スレディング（threading）の問題を単純化する、他のリソースオブジェクトによる破損を防止する、要素およびＡＰＩとの対話を単純化するなどの、各種の理由から変更することができない。これにより一般にシステムが単純化されることに留意されたい。ただし、そのようなオブジェクトが可変であるシステムにすることは可能であるが、例えば依存関係グラフの管理が必要になることに留意されたい。例えば、そのようなオブジェクトが可変であるシステムにすることは可能であるが、プログラムコードがあるビジュアル上のクリップセットを変更した場合には、そのビジュアルを再度レンダリングする必要が生じ、したがって通知／登録の機構が必要になり、例えば、あるビジュアルに新らたなクリップが割り当てられた場合には、そのビジュアルは通知（例えばクリップ変更通知）のためにそれ自体をそのクリップで登録する。したがって、一実施形態では単純化のためにリソースオブジェクトは不変であるとする。

これらのリソースオブジェクトは、オブジェクトを作成する単純で一般的な方法であるコンストラクタ（構文、構造体）を用いて定義するか、または後述のようにコンパニオンビルダオブジェクトを使用して定義することができる。例えばＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈを作成するには（ブラシオブジェクトについては下記で説明する）、コンストラクタを使用することができる。
Brush MyBrush = new SolidColorBrush(Colors.Red);

ユーザはＢｒｕｓｈｅｓクラスの静的メンバを使用して所定の色の１セットを得ることもできる。

不変オブジェクトは変更することができないので、オブジェクトを有効に変更するには、ユーザは新しいオブジェクトを作成し、古いオブジェクトをその新しいオブジェクトに置き換える必要がある。このためにシステム中のリソースオブジェクトの多くはビルダパターンを利用することができ、この場合には可変なコンパニオンクラスであるビルダクラスを用いて不変オブジェクトを作成する。ユーザは、ビルダに設定されたパラメータを映す（mirror）不変オブジェクトを作成し、そのオブジェクトについての新しいビルダを作成し、不変オブジェクトからそのビルダを初期化する。ユーザはその後必要に応じてビルダを変更する。これらを一旦行うと、ユーザはビルダを変更し、それを再使用して別の不変オブジェクトを作成することにより、新しいオブジェクトを構築することができる。セットプロパティを有する不変オブジェクトを備えることが望ましく、また不変オブジェクトは変更することができず、プロパティ変更イベントを発生させることによって置き換えることしかできないことに留意されたい。

したがって、上述のようにコンストラクタを使用してＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈを作成する代わりに、ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈＢｕｉｌｄｅｒを使用することができる。
SolidColorBrushBuilder MyBuilder = new
SolidColorBrushBuilder();
MyBuilder.Color = Colors.Red;
Brush MyBrush = MyBuilder.ToBrush();

静的な値をとる大半のオブジェクトはアニメーションオブジェクト（動画オブジェクト）をとることもできる。例えば、ＤｒａｗｉｎｇＣｏｎｔｅｘｔでは、円の中心にＰｏｉｎｔＡｎｉｍａｔｉｏｎＢａｓｅをとるＤｒａｗＣｉｒｃｌｅに対するオーバーライド（指定変更）がある。このようにしてユーザはプリミティブレベル（基本レベル）で豊かなアニメーション情報を指定することができる。リソースオブジェクトには、基本値に加えてアニメーションコレクション（集合）が存在する。これらは合成され、それによりユーザが上記の例をアニメーションにしたい場合は、ブラシを構築する前に次の例のラインを指定することができる。
MyBuilder.ColorAnimation.Add(new ColorAnimation(...));

アニメーションパラメータを有するオブジェクトもそのアニメーションパラメータが静的であるため、やはり不変であることに留意されたい。ただしシーングラフを処理する（例えばトラバースする）と、アニメーションパラメータの意味は時間とともに変化し、動きのついた静的でないデータの外観を与える。

上述のように、ビジュアルは、Ｇｅｏｍｅｔｒｙ、ＩｍａｇｅＤａｔａ、およびＶｉｄｅｏＤａｔａを含む各種の描画プリミティブ（基本要素）を各自の描画コンテクストに居住させることにより描画を行うことができる。さらに、このスタック全体を通じて共有されるリソースとクラスの１セットがある。これにはＰｅｎｓ、Ｂｒｕｓｈｅｓ、Ｇｅｏｍｅｔｒｙ、Ｔｒａｎｓｆｏｒｍｓ、およびＥｆｆｅｃｔｓが含まれる。ＩＤｒａｗｉｎｇＣｏｎｔｅｘｔは、ＤｒａｗｉｎｇＶｉｓｕａｌ、ＶａｌｉｄａｔｉｏｎＶｉｓｕａｌを居住させるのに使用できる描画操作の１セットを公開する。ＩＤｒａｗｉｎｇＣｏｎｔｅｘｔに対する基本インタフェースであるＩＳｕｒｆａｃｅＤｒａｗｉｎｇＣｏｎｔｅｘｔは、ＳｕｒｆａｃｅＶｉｓｕａｌを居住させるのに使用することができる。すなわち描画コンテクストは描画操作の１セットを公開し、各描画操作に、引数として定数を受け取るメソッドと、引数としてアニメータを受け取るメソッドの２つのメソッドがある。

ＤｒａｗＬｉｎｅメソッドは、指定されたＰｅｎ（ペン）で始点からストップまで線を描画する。

ＤｒａｗＲｏｕｎｄｅｄＲｅｃｔａｎｇｌｅメソッドは、指定されたＢｒｕｓｈ（ブラシ）とペンとで角が丸い矩形を描画する。ブラシとペンはヌルでよい。

ＤｒａｗＧｅｏｍｅｔｒｙメソッドは、指定されたブラシとペンでパス（経路）を描画する。ブラシとペンはヌルでよい。

ＤｒａｗＲｅｃｔａｎｇｌｅメソッドは、指定されたブラシとペンで矩形を描画する。ブラシとペンはヌルでよい。

ＤｒａｗＳｕｒｆａｃｅメソッドはサーフェースを描画する。

Ｇｅｏｍｅｔｒｙは、ストロークまたは塗りつぶしのないベクターグラフィックスケルトンを定義するタイプのクラスである（図１２）。各ジオメトリオブジェクトは、単純な形（ＬｉｎｅＧｅｏｍｅｔｒｙ、ＥｌｌｉｐｓｅＧｅｏｍｅｔｒｙ、ＲｅｃｔａｎｇｌｅＧｅｏｍｅｔｒｙ）、複雑な単一の形状（ＰａｔｈＧｅｏｍｅｔｒｙ）、あるいは指定の組合せ操作（例えば結合、交差など）を有するような形状のリストＧｅｏｍｅｔｒｙＬｉｓｔである。これらのオブジェクトは、図１２に表すようにクラス階層を形成する。

図１３に表すように、ＰａｔｈＧｅｏｍｅｔｒｙはＦｉｇｕｒｅ（図形）オブジェクトの集合である。順に各Ｆｉｇｕｒｅオブジェクトは、その図形の形状を実際に定義する１つまたは複数のＳｅｇｍｅｎｔ（セグメント）オブジェクトからなる。Ｆｉｇｕｒｅは、線分の集合を定義するＧｅｏｍｅｔｒｙの下位セクションである。この線分の集合は、２次元のＳｅｇｍｅｎｔオブジェクトの連結された単一のシリーズ（一連）である。Ｆｉｇｕｒｅは、定義された領域を持つ閉じた形状か、または単に曲線を定義するが囲まれた領域は定義しない連結されたＳｅｇｍｅｎｔのシリーズである。

ＰａｔｈＧｅｏｍｅｔｒｙの塗りつぶされた領域は、それらのＦｉｌｌｅｄプロパティ（属性）が真（true）に設定されている、含まれるＦｉｇｕｒｅを取り出し、ＦｉｌｌＭｏｄｅを適用して閉じた領域に決定することによって定義される。ＦｉｌｌＭｏｄｅの列挙では、Ｇｅｏｍｅｔｒｙに含まれるＦｉｇｕｒｅオブジェクトの交差領域をどのように組み合わせて、最終的なＧｅｏｍｅｔｒｙ領域を形成するかを指定することに留意されたい。「代替（Ａｌｔｅｒｎａｔｅ）」規則では、概念的にある点から無限まで任意の方向に光線を描画し、その形状の線分がその光線と交差する場所を調べることにより、その点がキャンバスの内側にあるかどうかを判定する。カウントゼロから開始し、ある線分が左から右へと光線と交差するたびに１を加え、パス線分が右から左に光線と交差するたびに１を引くことにより、交差の回数を数えた後にその結果がゼロであれば点はパスの外側にあることになる。それ以外の場合点は内側にある。「ワインディング（Ｗｉｎｄｉｎｇ）」規則は、キャンバス上のある点が内側にあるかどうかを判定するものであり、概念的にある点から無限まで任意の方向に光線を描画し、その光線が交差する所与の形状からのパス線分の数を数えることによって機能する。その数が奇数である場合はその点は内側にあり、偶数であればその点は外側にあることになる。

図１４に表すように、ジオメトリ（例えば矩形）を描画する際には下記のようにブラシまたはペンを指定することができる。さらに、ペンオブジェクトはブラシオブジェクトも有する。ブラシオブジェクトはある面をどのようにグラフィック的に塗りつぶすかを定義するもので、ブラシオブジェクトのクラス階層がある。これを図１４では、矩形とブラシ命令を含むビジュアルおよびパラメータを処理した結果得られる、塗りつぶされた矩形１４０２によって表している。

下記で説明するように、一部のタイプのＢｒｕｓｈ（グラデーションや９グリッドなど）はそれ自身をサイズで分類している。使用する際にはそれらのブラシのサイズをバウンディングボックスから入手し、例えばＢｒｕｓｈのＧｒａｄｉｅｎｔＵｎｉｔｓ／ＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓをＯｂｊｅｃｔＢｏｕｎｄｉｎｇＢｏｘに設定する場合には、描画するプリミティブのバウンディングボックスを使用する。それらのプロパティをＵｓｅｒＳｐａｃｅＯｎＵｓｅに設定した場合は、座標空間を使用する。

Ｐｅｎオブジェクトは、次の例に表すように、Ｗｉｄｔｈ、ＬｉｎｅＪｏｉｎ、ＬｉｎｅＣａｐ、ＭｉｔｅｒＬｉｍｉｔ、ＤａｓｈＡｒｒａｙ、およびＤａｓｈＯｆｆｓｅｔのプロパティと一緒にＢｒｕｓｈを持ち続ける。

上記のように、本発明のグラフィックオブジェクトモデルはＢｒｕｓｈオブジェクトモデルを含み、これは概ね平面をピクセルで覆うという概念を対象とする。ブラシタイプの例を図１５の階層に表し、これはＢｒｕｓｈの基本クラスの下に、ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ、ＧｒａｄｉｅｎｔＢｒｕｓｈ、ＩｍａｇｅＢｒｕｓｈ、ＶｉｓｕａｌＢｒｕｓｈ（ビジュアルを参照することができる）、およびＮｉｎｅＧｒｉｄＢｒｕｓｈを含む。ＧｒａｄｉｅｎｔＢｒｕｓｈはＬｉｎｅａｒＧｒａｄｉｅｎｔオブジェクトおよびＲａｄｉａｌＧｒａｄｉｅｎｔオブジェクトを含む。上述のように、Ｂｒｕｓｈオブジェクトは不変である。

次にＢｒｕｓｈＢｕｉｌｄｅｒクラスの例を示す。

Ｂｒｕｓｈオブジェクトは、使用の際にそれらがどのように座標系に関係するか、および／またはそれらを用いる形状のバウンディングボックスにどのように関係するかを認識することができることに留意されたい。一般に、サイズなどの情報は、そのブラシを描画するオブジェクトから推測することができる。より詳細には、ブラシタイプの多くは、各自のパラメータの一部を指定するために座標系を使用する。この座標系は、ブラシを適用する形状の単純なバウンディングボックスに相対的に定義するか、あるいはそのブラシを使用する際にアクティブである座標空間に相対的なものにすることができる。これらをそれぞれＯｂｊｅｃｔＢｏｕｎｄｉｎｇＢｏｘモード、ＵｓｅｒＳｐａｃｅＯｎＵｓｅモードと称する。

ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈオブジェクトは、特定された平面を一様な色（ベタ一色）で塗りつぶす。その色のアルファ成分がある場合は、Ｂｒｕｓｈの基本クラスにある対応する不透明度の属性と乗法的な（ｍｕｌｔｉｐｌｉｃａｔｉｖｅ）形で組み合わせる。次に示すのはＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈオブジェクトの一例である。

ＧｒａｄｉｅｎｔＢｒｕｓｈオブジェクトあるいは単にグラデーション（色勾配）は、グラデーション状の塗りつぶしを提供し、ある種の数列（progression）に従って色を指定するグラデーションのストップ（stop）の１セットを指定することにより描画される。グラデーションは、ガンマ２．２ＲＧＢ色空間のグラデーションストップ間に線形の補間を行うことによって描画され、他のガンマまたは他の色空間（ＨＳＢ、ＣＭＹＫなど）での補間も可能な代替法である。２タイプのグラデーションオブジェクトには、線形グラデーションと放射グラデーションが含まれる。

一般に、グラデーションはグラデーションのストップのリストで構成される。このグラデーションのストップはそれぞれ色（およびそれに含まれるアルファ値）とオフセットを含む。グラデーションのストップが指定されない場合は、ブラシは指定されたブラシが全くないかのように一様の透明な黒として描画される。指定されたグラデーションのストップが１つだけある場合、ブラシは指定された１色で一様な色として描画される。他のリソースクラスと同様に、グラデーションのストップクラス（例を下の表に挙げる）は不変である。

また、次の例に示すように集合クラスもある。

下の表に表すように、ＧｒａｄｉｅｎｔＳｐｒｅａｄＭｅｔｈｏｄは、指定されたベクトルまたは空間の外側にどのようにグラデーションを描画するかを指定する。３つの値があり、これには、末端の色（最初の色と最後の色）を使用して残りの空間を塗りつぶすパッド（ｐａｄ）、ストップを逆の順序で繰り返し再実行して空間を反復的に塗りつぶすｒｅｆｌｅｃｔ（反射）、および空間が塗りつぶされるまで順にストップを繰り返すｒｅｐｅａｔ（繰り返し）がある。

図１６にＧｒａｄｉｅｎｔＳｐｒｅａｄＭｅｔｈｏｄの例を示す。各形態は、白からグレーへと変化する線形グラデーションを有する。実線はグラデーションベクトルを表す。

ＬｉｎｅａｒＧｒａｄｉｅｎｔは、ベクトルに沿った線形グラデーションのブラシを指定する。個々のストップは、そのベクトルに沿った色のストップを指定する。次の表に一例を示す。

ＲａｄｉａｌＧｒａｄｉｅｎｔは、プログラミングモデルの点では線形グラデーションと同様である。ただし、線形グラデーションがグラデーションベクトルを定義する始点とストップを有するのに対し、放射グラデーションは、円と、グラデーションの振る舞いを定義する焦点を有する。円はグラデーションのストップを定義し、すなわち１．０のグラデーションストップはその円での色を定義する。焦点はグラデーションの中心を定義する。０．０のグラデーションストップは、焦点での色を定義する。

図１７に、白からグレーに変化する放射グラデーションを示す。外側の円はグラデーションの円を表し、点は焦点を表す。このグラデーション例ではＳｐｒｅａｄＭｅｔｈｏｄがＰａｄに設定されている。

図１５に表す別のブラシオブジェクトは、ＶｉｓｕａｌＢｒｕｓｈオブジェクトである。概念的に、ＶｉｓｕａｌＢｒｕｓｈは、反復されるタイル張り方式での塗りつぶしとしてビジュアルを描画する方式を提供する。ビジュアルペイントオブジェクトは、下記のようにマークアップ言語がリソースレベルで直接ＡＰＩ層に働きかける機構も提供する。図１４ではこのような塗りつぶしの一例を、単一の円形状１４２０を指定するビジュアル（および任意の子ビジュアル）を参照するビジュアルブラシによって表しており、その円形状が矩形１４２２を埋めている。このようにＶｉｓｕａｌＢｒｕｓｈオブジェクトはビジュアルを参照してそのブラシをどのように描画するかを定義することができ、ビジュアルのあるタイプの複数の使用を取り込む。このようにしてプログラムは任意のグラフィック「メタファイル」を使用して、ブラシまたはペンを介してある領域を埋めることができる。これは任意のグラフィックを記憶し、使用するための圧縮された形態なので、グラフィックリソースとして機能する。次にＶｉｓｕａｌＢｒｕｓｈオブジェクトの一例を示す。

ＶｉｓｕａｌＢｒｕｓｈの内容には本質的な制限がなく、無限の平面を効果的に記述する。その内容は各自の座標空間に存在し、ＶｉｓｕａｌＢｒｕｓｈで埋められる空間が適用時のローカル座標空間になる。その内容空間は、ＶｉｅｗＢｏｘ、ＶｉｅｗＰｏｒｔ、Ａｌｉｇｎｍｅｎｔ、およびＳｔｒｅｔｃｈのプロパティに基づいてローカル空間にマッピングされる。ＶｉｅｗＢｏｘは内容空間で指定され、その矩形はＶｉｅｗＰｏｒｔ（ＯｒｉｇｉｎプロパティとＳｉｚｅプロパティを介して指定される）の矩形にマッピングされる。

ＶｉｅｗＰｏｒｔは最終的に内容が描画される位置を定義し、そのＢｒｕｓｈの基本タイルを生成する。ＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓの値がＵｓｅｒＳｐａｃｅＯｎＵｓｅである場合には、ＯｒｉｇｉｎおよびＳｉｚｅのプロパティは適用時のローカル空間におけるものとみなされる。代わりに、ＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓの値がＯｂｊｅｃｔＢｏｕｎｄｉｎｇＢｏｘである場合は、ＯｒｉｇｉｎおよびＳｉｚｅは座標空間にあるものとみなされ、０，０がブラシ済みのオブジェクトのバウンディングボックスの左上隅になり、１，１が同じボックスの右下隅になる。例えば１００，１００から２００，２００に描画されたＲｅｃｔａｎｇｌｅＧｅｏｍｅｔｒｙを塗りつぶすとする。このような例では、ＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓがＵｓｅｒＳｐａｃｅＯｎＵｓｅである場合に、１００，１００のＯｒｉｇｉｎと１００，１００のＳｉｚｅによって内容領域全体が記述されることになる。ＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓがＯｂｊｅｃｔＢｏｕｎｄｉｎｇＢｏｘである場合には、０，０のＯｒｉｇｉｎと１，１のＳｉｚｅによって内容領域全体が記述される。Ｓｉｚｅが空である場合、このＢｒｕｓｈでは何もレンダリングされない。

ＶｉｅｗＢｏｘは内容空間中に指定される。この矩形は、ＡｌｉｇｎｍｅｎｔプロパティとＳｔｒｅｔｃｈプロパティによる決定に従ってＶｉｅｗＰｏｒｔ内に収まるように変形される。Ｓｔｒｅｔｃｈがなしの場合は、内容にスケーリング（拡大・縮小）は適用されない。ＳｔｒｅｃｈがＦｉｌｌの場合には、ＶｉｅｗＢｏｘはＶｉｅｗＰｏｒｔと同じサイズになるようにＸ、Ｙの両方で別個にスケーリングされる。ＳｔｒｅｃｈがＵｎｉｆｏｒｍまたはＵｎｉｆｏｒｍＴｏＦｉｌｌである場合は、論理は同様であるが、ＸとＹの範囲が均一にスケーリングされ、内容の縦横比を維持する。ＳｔｒｅｔｃｈがＵｎｉｆｏｒｍである場合、ＶｉｅｗＢｏｘは、ＶｉｅｗＰｏｒｔのサイズと等しい、より制約された範囲になるようにスケーリングされる。ＳｔｒｅｔｃｈがＵｎｉｆｏｒｍＴｏＦｉｌｌである場合、ＶｉｅｗＢｏｘは、ＶｉｅｗＰｏｒｔのサイズと等しい、より制約されない範囲になるようにスケーリングされる。すなわち、ＵｎｉｆｏｒｍとＵｎｉｆｏｒｍＴｏＦｉｌｌはともに縦横比を維持するが、ＵｎｉｆｏｒｍはＶｉｅｗＢｏｘ全体がＶｉｅｗＰｏｒｔ内に入る（可能性としてはＶｉｅｗＢｏｘに覆われないＶｉｅｗＰｏｒｔの部分を残して）ようにし、ＵｎｉｆｏｒｍＴｏＦｉｌｌは、（可能性としてはＶｉｅｗＢｏｘの一部をＶｉｅｗＰｏｒｔの外側に出して）ＶｉｅｗＰｏｒｔ全体をＶｉｅｗＢｏｘで埋めるようにする。ＶｉｅｗＢｏｘが空である場合、Ｓｔｒｅｔｃｈは適用されない。それでも位置合わせは行われ、「点の」ＶｉｅｗＢｏｘを配置することに留意されたい。

図１８に、様々なストレッチ（伸縮）設定によってレンダリングしたグラフィックの単一のタイル１８００の表現を示し、これにはストレッチを「なし」にセットした場合のタイル１８００が含まれる。タイル１８０２はストレッチを「Ｕｎｉｆｏｒｍ」（均一）に設定した場合の表現であり、タイル１８０４はストレッチを「ＵｎｉｆｏｒｍＴｏＦｉｌｌ」（満杯に均一）に設定した場合であり、タイル１８０６はストレッチを「Ｆｉｌｌ」（満杯）に設定した場合の表現である。

（ＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓに基づいて）ＶｉｅｗＰｏｒｔが決定され、（Ｓｔｒｅｔｃｈに基づいて）ＶｉｅｗＢｏｘのサイズが決定されると、ＶｉｅｗＢｏｘをＶｉｅｗＰｏｒｔの中に配置する必要がある。ＶｉｅｗＢｏｘがＶｉｅｗＰｏｒｔと同じサイズである場合（ＳｔｒｅｔｃｈがＦｉｌｌであるか、また他の３つのＳｔｒｅｔｃｈ値の１つにより偶然同じサイズになった場合）は、ＶｉｅｗＰｏｒｔと同一になるようにＶｉｅｗＢｏｘをＯｒｉｇｉｎに配置する。それ以外の場合はＨｏｒｉｚｏｎｔａｌＡｌｉｇｎｍｅｎｔとＶｅｒｔｉｃａｌＡｌｉｇｎｍｅｎｔを検討する。これらのプロパティに基づいて、ＶｉｅｗＢｏｘをＸおよびＹ両方の範囲で位置合わせする。ＨｏｒｉｚｏｎｔａｌＡｌｉｇｎｍｅｎｔがＬｅｆｔである場合は、ＶｉｅｗＢｏｘの左端がＶｉｅｗＰｏｒｔの左端に置かれる。それがＣｅｎｔｅｒである場合は、ＶｉｅｗＢｏｘの中心がＶｉｅｗＰｏｒｔの中心に置かれ、Ｒｉｇｈｔである場合はそれらの右端が一致する。このプロセスをＹ方向の範囲で繰り返す。

ＶｉｅｗＢｏｘが（０，０，０，０）である場合には未設定とみなし、それによりＣｏｎｔｅｎｔＵｎｉｔｓを検討する。ＣｏｎｔｅｎｔＵｎｉｔｓがＵｓｅｒＳｐａｃｅＯｎＵｓｅである場合は、スケーリングまたはオフセットは行われず、変換を行わずに内容がＶｉｅｗＰｏｒｔに描画される。ＣｏｎｔｅｎｔＵｎｉｔｓがＯｂｊｅｃｔＢｏｕｎｄｉｎｇＢｏｘである場合は、内容の原点をＶｉｅｗＰｏｒｔ Ｏｒｉｇｉｎに位置合わせし、そのオブジェクトのバウンディングボックスの幅と高さにより内容をスケーリングする。

ＶｉｓｕａｌＢｒｕｓｈで空間を塗りつぶす際は、上述のように内容がＶｉｅｗＰｏｒｔ内にマッピングされ、ＶｉｅｗＰｏｒｔにクリッピングされる。これにより塗りつぶしのための基本タイルが形成され、空間の残りの部分はＢｒｕｓｈのＴｉｌｅＭｏｄｅに基づいて埋められる。最後に、設定されている場合は、Ｂｒｕｓｈの変換が適用されるが、これはすべての他のマッピング、スケーリング、オフセッティングなどの後に行われる。

ＴｉｌｅＭｏｄｅの列挙は、ある空間をそのＢｒｕｓｈで塗りつぶすか、あるいはどのように塗りつぶすかを記述するのに使用される。タイル化が可能なＢｒｕｓｈにはタイル矩形が定義されており、そのタイルは塗りつぶす空間内に基本位置を有する。空間の残りは、ＴｉｌｅＭｏｄｅ値に基づいて塗りつぶされる。図１９に、「Ｎｏｎｅ」１９００、「Ｔｉｌｅ」１０９２、「ＦｌｉｐＸ」１９０４、「ＦｌｉｐＹ」１９０６、および「ＦｌｉｐＸＹ」１９０８を含む、各種のＴｉｌｅＭｏｄｅ設定によるグラフィック例の表現を示す。様々なグラフィック例の中で一番左上のタイルが基本タイルである。

図２０に、このブラシのピクセルを生成するプロセスを表す。図２０に記載した論理はこの論理を実施する可能な１つの方法に過ぎないことに留意されたく、より効率的な方法を含めて他の方法が実行可能であることを理解されたい。例えば、タイルを描画し、かつキャッシュしておいて反復のたびに内容を描画しないなど、より効率的なデータ処理方法があることが考えられる。ただし図２０には単純な説明を示している。

一般には、パターンの内容を描画するたびに、新しい座標系が作成される。各反復の原点とオフセットは、ＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓおよびＴｒａｎｓｆｏｒｍのプロパティを通じてフィルタリングされたＯｒｉｇｉｎ（原点）およびＳｉｚｅのプロパティによって指定される。

座標枠はＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓプロパティに基づいて設定される。このために、ステップ２０００でＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓプロパティがＵｓｅｒＳｐａｃｅＯｎＵｓｅである場合には、ステップ２００２を介してそのブラシを使用した時点における現在の座標枠を開始座標枠とする。これに代わり、そのプロパティがＯｂｊｅｃｔＢｏｕｎｄｉｎｇＢｏｘの場合は、ステップ２００４に表すようにそのブラシを適用するジオメトリのバウンディングボックスを使用して、バウンディングボックスの左上隅が（０，０）に、バウンディングボックスの左下隅が（１，１）にマッピングされるように新しい座標枠を設定する。いずれの場合も、ステップ２００６で、その座標枠にＴｒａｎｓｆｏｒｍプロパティを適用し、基本的にはそれによりグリッド（格子）を定義する。

図２１は、ＶｉｓｕａｌＢｒｕｓｈ中のタイル用に定義されたＶｉｓｕａｌＢｒｕｓｈグリッドを表す。第１の円は単純なグリッドであり、第２の円は、４７度のＸ方向にＳｋｅｗ（傾き）をかけたＴｒａｎｓｆｏｒｍ（変更）を有する。

ステップ２００８で、図２２に表すようにグリッドの各セルにビジュアルを描画し、ここでのビジュアルは適当なデータを描画したものとする。ステップ２０１０でＶｉｅｗＢｏｘが指定される場合は、ステップ２０１２を介してＶｉｅｗＢｏｘ、Ｓｔｒｅｔｃｈ、ＨｏｒｉｚｏｎｔａｌＡｌｉｇｎ、およびＶｅｒｔｉｃａｌＡｌｉｇｎの属性によって指定されるようにグリッドセル内にビジュアルを収める。ＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓプロパティおよびＴｒａｎｓｆｏｒｍのプロパティを使用して、ビジュアルがグリッドボックス中に整列するように変換を補正する。

ＶｉｅｗＢｏｘが指定されない場合は、ステップ２０１４で内容を描画するために新しい座標系を開設する。

座標枠は、その原点が、描画する特定のグリッドセルの原点になるように設定する。

ステップ２０１８で、そのタイルがセルの範囲の外側で描画されないようにＳｉｚｅプロパティに基づいてクリップを適用する。ＯｒｉｇｉｎおよびＳｉｚｅは、ＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓプロパティに基づいて適宜修正される。

次いでＳｏｕｒｃｅＵｎｉｔｓプロパティに基づいて座標系を修正する。このために、ステップ２０２０でＳｏｕｒｃｅＵｎｉｔｓプロパティがＯｂｊｅｃｔＢｏｕｎｄｉｎｇＢｏｘである場合には、ステップ２０２２でふさわしいスケーリング変換を適用し、それ以外の場合はＵｓｅｒＳｐａｃｅＯｎＵｓｅになり、新しい変換は適用されない。ステップ２０２４でＴｒａｎｓｆｏｒｍプロパティを適用し、ステップ２０２６で内容を描画する。

サイズの部分がゼロである場合には何も描画されず、Ｓｔｒｅｔｃｈが「Ｎｏｎｅ」の場合には、新しい座標枠の１単位が古い座標枠の１単位と等しくなるようにビューボックスの変換が設定されることに留意されたい。変換は基本的に、位置合わせの属性とＶｉｅｗＢｏｘのサイズに基づいたオフセットになる。上述のように、ステップ２０１０および２０１２で、Ｓｔｒｅｔｃｈのプロパティと位置合わせのプロパティは、指定されたＶｉｅｗＢｏｘがあるときにのみ適用される。ＶｉｅｗＢｏｘは内容に対して新しい座標系を指定し、Ｓｔｒｅｔｃｈはどのようにそれらの内容をＶｉｅｗＢｏｘ内にマッピングするかを指定するのを助ける。位置合わせのオプションは、内容ではなくＶｉｅｗＢｏｘの位置を合わせる。したがって、例えばビューボックスが「０ ０ １０ １０」に設定され、−１０、−１０に何かが描画され、左上隅に位置を合わせる場合、それはクリッピングされて消えることになる。

図１５に戻ると、ＩｍａｇｅＢｒｕｓｈはＶｉｓｕａｌＢｒｕｓｈの特殊なケースと考えることができる。プログラムはビジュアルを作成し、そのビジュアルに画像を入れ、それをＶｉｓｕａｌＢｒｕｓｈに付加することができるが、これを行うためのＡＰＩはわずらわしく煩雑になる可能性がある。必須の内容座標枠はないので、ＶｉｅｗＢｏｘおよびＣｏｎｔｅｎｔＵｎｉｔｓのプロパティメンバはもはや適用されない。

ＮｉｎｅＧｒｉｄＢｒｕｓｈは、サイズに基づいて画像がゆがめられる点を除いてはＩｍａｇｅＢｒｕｓｈに非常によく似る。基本的にＮｉｎｅＧｒｉｄＢｒｕｓｈはカスタムタイプのＳｔｒｅｔｃｈと考えてよく、ここでは画像の特定部分がストレッチするが、他の部分（例えば輪郭）はストレッチしない。したがってＩｍａｇｅＢｒｕｓｈ中の画像のＳｉｚｅは単純なスケーリングを行わせるが、ＮｉｎｅＧｒｉｄＢｒｕｓｈは所望のサイズまでの不均一なスケーリングを生じさせる。ブラシを適用するときにスケーリングを行わない領域の単位（ユニット）はユーザ単位（ユニット）になり、すなわち、（ＮｉｎｅＧｒｉｄＢｒｕｓｈに存在する場合には）ＣｏｎｔｅｎｔＵｎｉｔｓがＵｓｅｒＵｎｉｔｓＯｎＵｓｅに設定されることになる。ＢｒｕｓｈのＴｒａｎｓｆｏｒｍプロパティを効果的に使用することができる。境界メンバ（構成部分）は画像の端から数に含めることに留意されたい。

例として図２３に、第１のインスタンス２３０２から第２のインスタンス２３０４に拡大した、４タイプの領域を含む９グリッドの画像を表す。図２３に表すように、輪郭を同一に保つために領域「ａ」は水平方向に拡大し、領域「ｂ」は垂直方向に拡大し、領域「ｃ」は水平方向と垂直方向に拡大し、領域「ｄ」はサイズが変化しない。

先に概説したように本発明のグラフィックオブジェクトモデルはＴｒａｎｓｆｏｒｍオブジェクトモデルを含み、これは、Ｔｒａｎｓｆｏｒｍの基本クラスの下に図２４の階層に表す変換タイプを含む。変換を作り出すこの様々なタイプのコンポーネント（構成要素）は、ＴｒａｎｓｆｏｒｍＬｉｓｔ、ＴｒａｎｓｌａｔｅＴｒａｎｓｆｏｒｍ、ＲｏｔａｔｅＴｒａｎｓｆｏｒｍ、ＳｃａｌｅＴｒａｎｓｆｏｒｍ、ＳｋｅｗＴｒａｎｓｆｏｒｍ、およびＭａｔｒｉｘＴｒａｎｓｆｏｒｍを含むことができる。個々のプロパティはアニメーション（動画化）にすることができ、例えばプログラム開発者はＲｏｔａｔｅＴｒａｎｓｆｏｒｍのＡｎｇｌｅプロパティをアニメーションにすることができる。

２Ｄ（２次元）計算のための行列は３ｘ３の行列として表される。必要とされる変換には、３ｘ３の完全な行列ではなく６つの値のみが必要とされる。これらの値に次のように名前を付け、定義する。

行列に点を乗算すると、その点が新しい座標系から１つ前の座標系に変換される。

変換は任意のレベルまで入れ子にすることができる。新しい変換を適用する際には、常にその変換は現在の変換行列にその変換を後ろからの乗算法（post-multiplying）でした場合と同じになる。

ＡＰＩ中の大半の個所ではＭａｔｒｉｘを直接には受け取らず、代わりにアニメーションをサポートするＴｎｒａｓｆｏｒｍクラスを使用する。

ベクターグラフィックのためのマークアップ言語およびオブジェクトモデル
本発明の一態様によれば、ユーザプログラムおよびツールが、ＡＰＩ層２１２（図２）の詳細についての特定の知識を必要とせずにシーングラフデータ構造２１６と対話することを可能にするマークアップ言語と要素オブジェクトモデルが提供される。一般には、ベクターグラフィックマークアップ言語が提供されるが、これは交換フォーマットと、要素オブジェクトモデルを介してベクターグラフィックを表現するためのマークアップベースの単純なオーサリングフォーマット（authoring format）を備える。この言語を介してマークアップ（例えばＨＴＭＬまたはＸＭＬタイプの内容）をプログラミングすることができる。そしてシーングラフを構築するには、このマークアップを構文解析し、変換して上述のような適切なビジュアルＡＰＩ層オブジェクトにする。このより高い動作レベルでは、要素ツリー、プロパティシステム、およびプレゼンタシステムが提供されて複雑なことの大半を処理し、シーン設計者が可能性としては複雑なシーンを簡単に設計できるようになる。

一般にベクターグラフィックシステムは、形状および他の要素の１セット、一般的なプロパティシステムとの統合、グループ化および合成システム、および２段（要素レベルおよびリソースレベル）アプローチ（手法）を提供し、それによりユーザは、柔軟性と性能の必要性を釣り合わせてプログラミングを行うことができる。本発明の一態様に沿えば、ベクターグラフィックを扱う要素オブジェクトモデルは、シーングラフのオブジェクトモデルと相互関係を持つ。すなわちベクターグラフィックシステムとビジュアルＡＰＩ層は要素オブジェクトモデルレベルのリソースの１セットを共有し、例えばビジュアルＡＰＩで描画を行う際にＢｒｕｓｈオブジェクトを使用するが、それはＳｈａｐｅ（形状）の塗りつぶしプロパティのタイプでもある。このように、シーングラフオブジェクトと相互関係がある要素を備えることに加えて、このマークアップ言語はいくつかのプリミティブリソース（例えばブラシ、変換など）をビジュアルＡＰＩ層と共有する。ベクターグラフィックシステムはビジュアルＡＰＩ層のアニメーション機能も公開および拡張し、これは諸レベル間で大部分が共有される。

さらに下記で説明するように、ベクターグラフィックシステムは、様々なプロファイル、または要素レベルとリソースレベルを含む様々なレベルに対してプログラムすることができる。要素レベルでは、ページ／画面中の残りのプログラム可能な要素と同じレベルにある要素として各描画形状を表す。これは、それらの形状が、プレゼンタシステム、イベント、およびプロパティと完全に対話することを意味する。リソースレベルでは、ベクターグラフィックシステムは、従来のグラフィックメタファイルと同様に純粋なリソースフォーマットで動作する。リソースレベルは効率的であるが、カスケード型のプロパティ、イベンティング、および細密なプログラミング可能性に対するサポートは多少制限される。したがってシーン設計者は、必要に応じて効率とプログラム可能性のバランスを取るだけの力量を有する。

本発明の一態様によれば、一実装ではリソースレベルのマークアップをＶｉｓｕａｌＢｒｕｓｈとして表現する点で、リソースレベルにおけるベクターグラフィックシステムもビジュアルＡＰＩ層との相互関係を持つ。リソースマークアップを構文解析すると、ビジュアルオブジェクトが生成される。このビジュアルオブジェクトは、形状、コントロール、および要素レベルでのその他の要素によって使用できるＶｉｓｕａｌＢｒｕｓｈ中にセットされる。

図２５は、要素クラスの階層２５００を表したものである。本発明のマークアップ言語オブジェクトモデルのクラスは影を付けた枠で表しており、これには形状クラス２５０２、画像クラス２５０４、ビデオクラス２５０６、およびキャンバスクラス２５０８が含まれる。形状クラスの要素には、矩形２５１０、ポリライン２５１２、多角形（ポリゴン）２５１４、パス（経路）２５１６、線２５１８、および楕円２５２０が含まれる。実装によっては図２５の破線の枠２５２２で示すように円の要素がない場合があるが、ここでは各種の例を挙げるために円の要素２５２２を記載するｔこととしたことに留意されたい。各要素は、塗りつぶし（プロパティ）データ、ストロークデータ、クリッピングデータ、変換データ、フィルタ効果データ、およびマスクデータを含むか、あるいはこれらと関連付けることができる。

下記で説明するように、形状は、継承されたカスケード型のプレゼンテーションプロパティによって描画されたジオメトリ（幾何学形状）に対応する。プレゼンテーションプロパティは、形状を描画するのに必要なペンとブラシを構築するのに用いられる。一実装では、形状は他のコントロール要素と同じように完全なプレゼンタである。ただし他の実装では、キャンバスクラス２５０８を形状のコンテナとして提供することができ、形状はキャンバス要素内にあるときのみ描画することができる。例えば、形状を軽量に保つために、形状にはプレゼンタを付加できないようにすることができる。代わりにキャンバスにプレゼンタが付加され、形状を描画する。キャンバス要素については下記でより詳細に説明する。

同じく下記で説明するように、画像クラスは形状よりも具体的であり、例えば複雑である可能性がある輪郭データを含むことができる。例えば、輪郭は上部ではある一色を指定し、両側では別の一色を指定し、可能性としては様々な太さを指定し、その他のプロパティを設定することができる。画像、あるいはテキストやビデオなど同様のボックス型要素には、位置、サイズ、回転、および目盛りを設定することができる。画像およびビデオの要素は、キャンバス要素の外側に存在し、外側に示すことができ、またＢｏｘｅｄＥｌｅｍｅｎｔから継承して、例えばその要素から背景、輪郭、およびパッディングのサポートを得られることに留意されたい。

ビデオ要素は、ビデオ（または同様のマルチメディア）を表示されている要素内で再生することを可能にする。ベクターグラフィックシステムはこのようにして、テキスト、２Ｄグラフィック、３Ｄグラフィック、アニメーション、ビデオ、静止画像、オーディオを含むマルチメディアにわたってシームレスに一貫性のあるＡＰＩ層とのマークアップインタフェースを提供する。これにより、設計者は、あるメディアを操作して、アプリケーションおよびドキュメントに他の媒体を容易に組み込むことができる。ベクターグラフィックシステムは、他の要素と同じ方法でマルチメディアをアニメーションにすることも可能にし、これによっても設計者は個々の媒体タイプそれぞれの本質的な独自性を犠牲にすることなく、他の要素と同じようにマルチメディアを使用することができる。例えば、設計者は、異なるメディアタイプにわたり、回転、スケーリング、アニメーション化、描画、合成、およびその他の効果に同じネーミングスキーマを使用することができ、これにより設計者は非常に豊かなアプリケーションを容易に作成することができ、またその下に非常に効率的なレンダリングと合成の実装を構築することが可能になる。

図２６に、マークアップコード２６０２をパーサー／トランスレータ２６０４によって解釈する一実装を示す。一般に、パーサー／トランスレータ２６０４は要素ツリー／プロパティシステム２０８（図２にも示す）に要素を付加し、それらの要素にプレゼンタを付加する。次いでプレゼンタシステム２１０は、プレゼンタが付加された要素ツリー２０８を受け取り、データをオブジェクトに変換し、ビジュアルＡＰＩ層２１２を呼び出す。すべての要素を変換する必要はなく、プレゼンタが付加された要素だけを変換すればよいことに留意されたい。

一般に、要素は、プロパティシステム、イベンティングおよびレイアウト／プレゼンテーションシステムに参加する要素層のオブジェクトである。パーサーはタグを見つけ、そのタグが要素またはリソースオブジェクトを定義する助けとなるかどうかを判定する。ＶｉｓｕａｌＢｒｕｓｈの特殊なケースでは、例えば複合プロパティ構文に現れるか否かなど、そのタグが現れるコンテクストに応じて、同じタグが要素として、またはリソースオブジェクトとして解釈される可能性がある。

本発明の一態様によれば、マークアップ言語は、単純なストリングフォーマットまたは複雑なオブジェクト表記を含めて、リソースを記述する独自の方法を提供する。単純なストリングフォーマットの場合、パーサー／トランスレータ２６０４は、ストリングを適切なビジュアルＡＰＩオブジェクトに変換するタイプコンバータ２６０８を使用する。例として次のマークアップラインでは、タイプコンバータ２６０８を介してＦｉｌｌプロパティ値をブラシオブジェクトに変換することができる。

容易に理解できるように、このような単純なパラメータストリングを持つタグベースのマークアップのインラインラインをブラシオブジェクトに変換するのは簡単であり、シーン設計者が形状とその属性をシーンに追加する単純な方法を提供する。

ただし、場合によっては塗りつぶし属性が複雑で単一のストリングに収まらないことがある。そのような状況ではマークアップ中でインラインにすることが可能な複合プロパティ構文を使用してこのプロパティを設定する。例えば、次の複合プロパティ構文は、一様の一色ではなくグラデーションで円を塗りつぶし、様々なグラデーションストップ（範囲は０から１の間）で色を指定する。

マークアップ中でインラインに存在する以外に、リソースインスタンスは別の場所に置くこともでき（例えばマークアップやファイル中に置くことができ、ファイルはローカルでも、リモートネットワーク内にあって適宜ダウンロードしてもよい）、名前（例えばテキスト名、参照またはその他の適切な識別子）によって参照することができる。このようにしてシーン設計者は、複合プロパティ構文によって記述された要素を含めて、あるシーンにわたって要素ツリーの要素を再利用することができる。

パーサーは、必要に応じてタイプコンバータ２６０８にアクセスし、指定されたパラメータをオブジェクトプロパティと照合することにより複合プロパティ構文のマークアップを処理し、それによりシーン設計者にとっての複雑なものを処理する。このようにパーサーはオブジェクトをセットアップするだけでなく、オブジェクトに属性も設定する。オブジェクトは不変なので、パーサーは実際にはオブジェクトを作成するビルダをインスタンス化していることに留意されたい。

同じレンダリングモデルを要素レベルとＡＰＩレベルで共有するので、オブジェクトの多くは基本的に同一である。これにより構文解析／変換が極めて効率的になり、また異なるタイプのプログラミング言語（例えばＣ＃様の言語）が、マークアップから各自の構文への変換、またその逆の変換を容易に行うことができるようになる。図２６に表すように、別のそのようなプログラミング言語２６１０が要素ツリー２０８に要素を追加することができ、あるいは直接ビジュアルＡＰＩ層２１２とインタフェースを取れることに留意されたい。

同じく図２６に示すように、本発明の一態様によれば、要素レベルとリソースレベルのプログラミングに同じマークアップ２６０２を使用することができる。上述のように、要素レベルは、シーン設計者に、完全なプログラミング可能性、継承を提供するプロパティシステム（例えばスタイルシート様の機能）の使用、およびイベンティング（これにより、例えばユーザ入力イベントに応答してその外観、位置などを変えるコードを要素に付加することができる）を与える。ただし、本発明は、シーン設計者が基本的に要素ツリーとプレゼンタシステムをショートカットして、直接ビジュアルＡＰＩ層にプログラミングすることができるリソースレベルの機構も提供する。要素レベルの機能を必要としない多くのタイプの静的な形状、画像などに対しては、これにより適切なオブジェクトを出力するためのより効率的で軽量の方法が提供される。このために、パーサーは「ビジュアルブラシ」タイプの塗りつぶしがあるときにはそれを認識し、リソースレベルのデータ２６１２をもってＡＰＩ層２１２を直接呼び出してオブジェクトを作成する。換言すると、図２２に表すように、要素レベルのベクターグラフィックは構文解析されて作成後の要素になり、この要素は後にオブジェクトに変換する必要があり、一方リソースレベルのベクターグラフィックは構文解析され、効率的な形で直接格納される。

例として、次のマークアップはＬｉｎｅａｒＧｒａｄｉｅｎｔオブジェクトのオブジェクトモデルから直接導出されたものであり、外側の円をＶｉｓｕａｌＢｒｕｓｈで塗りつぶす。そのＶｉｓｕａｌＢｒｕｓｈの内容は内部のマークアップによって定義される。この構文は各種のブラシ、変換、およびアニメーションを表すのに一般的に使用されることに留意されたい。

このビジュアルブラシで塗りつぶされたオブジェクトは効率的に格納されるが、図２６に概略的に表すように、リソースレベルのデータ（またはそれによって作成されたオブジェクト）は、要素ツリー２０８の要素および部分によって参照できることに留意されたい。このために、それらのビジュアルブラシリソースには名前を付けて（例えば名前、参照、またはその他の適切な識別子で）、複合プロパティ構文を介して記述された他のリソースと同様に参照することができる。

キャンバスの説明に移ると、先に代替の実装で述べたように形状は軽量に保つことができ、したがってキャンバスに含めることが求められる場合がある。この代替実装では、内容をレンダリングする際は、関連付けられた座標系を有する、デバイスに依存する無限のキャンバスにレンダリングする。したがってキャンバス要素は、絶対座標に従って内容を配置することができる。キャンバス要素は任意選択でビューポートを定義することができ、ビューポートは、クリッピング、変換、好ましい縦横比、およびそのビューポートを親の空間にマッピングする方法を指定する。設定されたビューポートがない場合、キャンバス要素は描画プリミティブのグループ化だけを指定し、変換、不透明度、およびその他の合成の属性を設定することができる。

次に示すのはサンプルキャンバスのマークアップの例である。

一実装では、単位なしで座標を指定するとその座標は９６分の１インチ（２．５４ｃｍ）の「論理ピクセル」とみなされ、上の例では線の長さは２００ピクセルになる。座標以外のプロパティには、幅、高さ、水平方向および垂直方向の位置合わせ、およびＶｉｅｗＢｏｘ（矩形タイプ。デフォルトは未設定または（０，０，０，０）で、調整を行わないことを意味し、ストレッチおよび位置合わせのプロパティは無視される）が含まれる。上記で図１８〜２０を参照して概説したように他のプロパティにはストレッチが含まれ、このプロパティは無指定時には元のサイズを維持するが、１）縦横比を維持せず、上端／左／幅／高さによって設定される範囲を埋めるように内容をスケーリングするｆｉｌｌを指定する、２）上端／左／幅／高さによって設定される範囲に画像が収まるまでサイズを均等にスケーリングするｕｎｉｆｏｒｍを指定する、または３）上端／左／幅／高さによって設定される範囲を埋めるようにサイズを均等にスケーリングし、必要に応じてクリッピングするＵｎｉｆｏｒｍＴｏＦＩｌｌを指定することができる。

より低水準のオブジェクトモデルとさらに相互関係が生じるように、変換プロパティは要素の子に新しい座標枠を設定し、一方クリッププロパティはデフォルトのクリッピングパスをもつバウンディングボックスとして定義された内容をキャンバス上に描画できる領域を制限し、ＺＩｎｄｅｘプロパティは、パネル内の入れ子になったキャンバス要素のレンダリング順序を指定するのに使用することができる。

Ｖｉｅｗｂｏｘは、例えばビューポートの範囲と原点を定義し直すことにより、内容に新しい座標系を指定する。Ｓｔｒｅｔｃｈは、その内容をどのようにビューポートにマッピングするかを指定するのを助ける。ＶｉｅｗＢｏｘ属性の値は、例えば空白および／またはコンマで区切られた４つの「単位のない」数のリスト＜ｍｉｎ−ｘ＞、＜ｍｉｎ−ｙ＞、＜ｗｉｄｔｈ＞、および＜ｈｅｉｇｈｔ＞であり、タイプＲｅｃｔである。Ｖｉｅｗｂｏｘ矩形は、バウンディングボックスにマッピングするユーザ空間に矩形を指定する。これは、スケールＸおよびスケールＹの挿入と同様に作用する。ストレッチのプロパティ（「ｎｏｎｅ」以外が選択された場合）は、グラフィックの縦横比を維持するための追加的な制御を提供する。所与の要素の子孫に追加的な変換を適用して指定された効果を実現する。

上記の例では、各ストレッチ規則による上記のマークアップサンプルでの矩形の実際の結果は次のようになる。

キャンバスに変換がある場合、それは基本的に上記の（例えばツリー中でＶｉｅｗＢｏｘへのマッピングが適用される。このマッピングは、形状だけでなく例えばボックス、テキストなどキャンバス中の要素をいずれもストレッチすることに留意されたい。さらに、ビューボックスを指定した場合、キャンバスはもはやその内容に合わせてサイズを決定せずに、指定されたサイズになることに留意されたい。ｙ方向の幅とｙ方向の高さも指定される場合は、ストレッチ／位置合わせのプロパティを使用してビューボックスを指定された幅および高さに収める。

オブジェクトモデル中の要素にはそれぞれ「クリップ」属性を適用することができる。一部の要素、とりわけ形状には、これは共通言語の実行時プロパティとして直接公開されるのに対し、その他（例えば大半のコントロール）ではこのプロパティはＤｙｎａｍｉｃＰｒｏｐｅｒｔｙを介して設定される。

一般にクリッピングパスは内容を描画できる領域を限定するが、これを概略的に図２７に表しており、この図ではクリッピングしていないフォーム２７０２と、クリッピングパスを指定したフォーム２７０４（破線がクリッピングパスを表す）にボタンを示している。概念的には、現在アクティブなクリッピングパスによって境界が定められた領域の外側にある描画部分はいずれも描画されない。クリッピングパスは、クリッピングパスの外側のピクセルはアルファ値がゼロの黒であり、クリッピングパスの内側のピクセルはアルファ値が１の白であるマスクと考えることができる（例外としてはシルエット（輪郭）の縁に沿ったアンチエイリアシングが考えられる）。

クリッピングパスはＧｅｏｍｅｔｒｙオブジェクトにより、インラインか、より一般的にはリソースセクション中に定義される。クリッピングパスは、次の例に示すように要素の「Ｃｌｉｐ」プロパティを使用して用いられるか、かつ／または参照される。

Ｃｌｉｐをアニメーションにするのは、変換をアニメーションにするのと同様であることに留意されたい。

パスは、「Ｇｅｏｍｅｔｒｙ」データと、Ｆｉｌｌ、Ｓｔｒｏｋｅ、ＳｔｒｏｋｅＷｉｄｔｈなどのレンダリングプロパティをＰａｔｈ要素に指定することによって描画される。パスのマークアップの例は次のように指定する。

パス「Ｄａｔａ」のストリングはＧｅｏｍｅｔｒｙタイプである。描画パスを指定するよりも冗長で完全な方法は、上述のように複合プロパティ構文を介するものである。（次の例のような）マークアップは、上述のＧｅｏｍｅｔｒｙビルダクラスに直接供給される。

パスデータストリングは、次のパスデータストリングの文法を記述する表記を使用しても記述される。

次に示すのは、この表記を使用して記述したパスデータストリング情報である（一実装では、ここで要素レベルのプロパティの代わりにＦｉｌｌＭｏｄｅを指定できることに留意されたい）。

画像要素（図２５）は、完全なファイルの内容は現在のユーザ座標系中の所与の矩形にレンダリングされることを示す。画像（画像タグによって示される）は、次の例に示すように、ＰＮＧやＪＰＥＧなどのラスタ画像ファイル、またはＭＩＭＥタイプで「ｉｍａｇｅ／ｗｖｇ」のファイルを参照することができる。

次の表に、画像のいくつかのプロパティ例についての情報を提供する。

上述のように、形状は、継承されたカスケード型のプレゼンテーションプロパティを用いて描画されたジオメトリに対応する。次の表に、上記の基本的な形状要素（矩形、楕円、線、ポリライン、多角形）の形状プロパティの例を挙げる。これらの基本形状は、ストロークプロパティ、塗りつぶしプロパティを持ち、クリップパスとして使用され、継承の特性があり、要素レベルおよびリソースレベルの両方に適用できることに留意されたい。

次に示すのは、矩形のマークアップ構文の一例である。

矩形は、オブジェクトモデル中に以下のプロパティを有する（矩形は読み取り／書き込みであり、デフォルト値はゼロに等しく、継承をサポートし、要素レベルおよびリソースレベルの両方に適用できることに留意されたい）。

次に示すのは円のマークアップ構文の一例である。

円はオブジェクトモデル中に以下のプロパティを有する（円は読み取り／書き込みであり、デフォルト値はゼロに等しく、継承をサポートし、要素レベルおよびリソースレベルの両方に適用できることに留意されたい）。

次に示すのは楕円のマークアップ構文の一例である。

楕円はオブジェクトモデル中に以下のプロパティを有する（楕円は読み取り／書き込みであり、デフォルト値はゼロに等しく、継承をサポートし、要素レベルおよびリソースレベルの両方に適用できることに留意されたい）。

次に示すのは線のマークアップ構文の一例である。

線はオブジェクトモデル中に以下のプロパティを有する（線は読み取り／書き込みであり、デフォルト値はゼロに等しく、継承をサポートし、要素レベルおよびリソースレベルの両方に適用できることに留意されたい）。

「ポリライン」は、連結された直線線分の１セットを定義する。通例「ポリライン」は開いた形状を定義する。

次に示すのはポリラインのマークアップ構文の一例である。

ポリラインはオブジェクトモデル中に以下のプロパティを有する（線は読み取り／書き込みであり、デフォルト値はヌルに等しく、継承をサポートし、要素レベルおよびリソースレベルの両方に適用できることに留意されたい）。

多角形（ポリゴン）要素は、連結された直線線分の１セットからなる閉じた形状を定義する。次に多角形のマークアップ構文の一例を示す。

多角形はオブジェクトモデル中に次のプロパティを有する（線は読み取り／書き込みであり、デフォルト値はヌルに等しく、継承をサポートし、要素レベルおよびリソースレベルの両方に適用できることに留意されたい）。

「ポリライン」および「多角形」の要素中で点を指定する文法は、次の表記で記述する。

次に記すのは、上の表記を使用した「ポリライン」および「多角形」要素中での点の指定である。

結論
上述の詳細な説明から分かるように、シーングラフとインタフェースを取る各種の機構にプログラムコードを提供するシステム、方法、および要素／オブジェクトモデルが提供される。このシステム、方法、およびオブジェクトモデルは、使用が容易でありながら強力で柔軟性と拡張性を有する。

本発明には様々な修正および代替の構成を行うことができるが、特定の例示的な実施形態を図示し、上記で詳細に説明した。ただし本発明をここに開示する特定の形態に限定する意図はなく、本発明の精神および範囲に該当するすべての修正、代替構成、および均等物を包含する意図である。ことを理解されたい。

本発明を組み込むことが可能な例示的コンピュータシステムを示すブロック図である。 本発明を組み込むことが可能なグラフィック層アーキテクチャを概略的に示すブロック図である。 本発明の一態様による、ビジュアルのシーングラフと、シーングラフをトラバースしてグラフィックコマンドおよび他のデータを提供することによりシーングラフを処理する付随するコンポーネントとを示す図である。 本発明の一態様によって構築されたバリディーションビジュアル、描画ビジュアル、および付随する描画プリミティブからなるシーングラフを示す図である。 本発明の一態様によるオブジェクトモデルのビジュアルクラスを示す図である。 本発明の一態様によるオブジェクトモデルの各種の他のオブジェクトを示す図である。 本発明の一態様によるビジュアルのデータの変換を示す図である。 本発明の一態様によるジオメトリスケールによるビジュアルデータの変換を示す図である。 本発明の一態様による不均一スケールによるビジュアルデータ変換を示す図である。 本発明の一態様によるサーフェースビジュアルオブジェクトおよび他のビジュアルおよびコンポーネントのブロック図である。 本発明の一態様によるサーフェースビジュアルオブジェクトおよび他のビジュアルおよびコンポーネントのブロック図である。 本発明の一態様によるサーフェースビジュアルオブジェクトおよび他のビジュアルおよびコンポーネントのブロック図である。 本発明の一態様によるＨＷｎｄビジュアルオブジェクトを示す図である。 本発明の一態様によるＨＷｎｄビジュアルオブジェクトを示す図である。 本発明の一態様による階層化ビジュアルオブジェクトを示す図である。 本発明の一態様によるオブジェクトモデルのジオメトリクラスを示す図である。 本発明の一態様によるＰａｔｈＧｅｏｍｅｔｒｙ構造を示す図である。 本発明の一態様による、プリミティブによって生成されるグラフィック例を示すビジュアルのシーングラフおよび描画プリミティブを示す図である。 本発明の一態様によるオブジェクトモデルのブラシクラスを示す図である。 本発明の一態様による線形グラデーションブラシオブジェクト中のデータから生成されるレンダリングされたグラフィックを示す図である。 本発明の一態様による放射グラデーションブラシオブジェクト中のデータから生成されるレンダリングされたグラフィックを示す図である。 本発明の一態様による様々なストレッチ値から生成されるレンダリングされたグラフィックを示す図である。 本発明の一態様による様々なタイル値から生成されるレンダリングされたグラフィックを示す図である。 本発明の一態様による、ブラシオブジェクトを含むビジュアルを解釈してグラフィックを生成する論理を概説する流れ図である。 本発明の一態様による、ビジュアルブラシオブジェクト中のデータから生成されるグリッドおよび変換後のグリッドを示す図である。 本発明の一態様による、ビジュアルから描画されたレンダリング後のグラフィックを中に示したグリッドおよび変換後のグリッドを示す図である。 本発明の一態様による、レンダリングされた９グリッドのブラシオブジェクトを示す図である。 本発明の一態様によるオブジェクトモデルの変換クラスを示す図である。 本発明の一態様による要素オブジェクトモデルの要素クラスを示す図である。 本発明の一態様による、マークアップ言語コードを解釈してビジュアルＡＰＩ層とのインタフェースを取るコンポーネントを示す図である。 本発明の一態様によるジオメトリパスを介したクリッピングを示す図である。

符号の説明

１００ コンピューティングシステム環境
１１０、１８０ コンピュータ
１２０ 処理装置
１２１ システムバス
１３０ システムメモリ
１３１ ＲＯＭ
１３２ ＲＡＭ
１３３ ＢＩＯＳ
１３４、１４４ オペレーティングシステム
１３５、１４５、１８５ アプリケーションプログラム
１３６、１４６ 他のプログラムモジュール
１３７、１４７ プログラムデータ
１４０、１５０ インタフェース
１４１ ハードディスクドライブ
１５１ 磁気ディスクドライブ
１５２ 磁気ディスク
１５５ 光ディスクドライブ
１５６ 光ディスク
１６０ ユーザ入力インタフェース
１６１ ポインティングデバイス
１６２ キーボード
１６３ マイクロフォン
１６４ タブレット
１７０ ネットワークインタフェース（アダプタ）
１７１ ＬＡＮ
１７２ モデム
１７３ ＷＡＮ
１８１ メモリ記憶装置
１９０ ビデオインタフェース
１９１ モニタ
１９２ タッチスクリーンインタフェース
１９３ タッチスクリーンパネル
１９４ 出力周辺インタフェース
１９５ スピーカ
１９６ プリンタ
２００ 階層アーキテクチャ
２０２ プログラムコード
２０４ 画像化
２０６ ベクターグラフィック要素
２０８ 要素／プロパティシステム
２１０ プレゼンタシステム
２１２ ビジュアルＡＰＩ層
２１４、２１８ 合成およびアニメーションエンジン
２１６ データ構造
２２０ タイミングおよびアニメーションシステム
２２２ ハードウェア
３００、４００ シーングラフ
５００ ビジュアルクラス
３０２、３１０、３１５、５０１、５０２、５０３、５０４、５０５、５０６、１１００ ビジュアル
３０４ ビジュアルマネージャオブジェクト
３０６ Ｈｗｎｄ
３０８ ディスパッチャ
３１５ サーフェースビジュアル
３１６、３１７、３２３ 描画コンテクスト
３１８、３１９ 命令リスト
３２２ メモリサーフェース（ビットマップ）
３２４ ピクセルデータ
３３０ サーフェースビジュアルマネージャ
３３２ 部分グラフ
５０５ Ｈｗｎｄビジュアル
６２０ オブジェクト
８００、８０２、８０４ 画像
９００ サーフェースビジュアルマネージャオブジェクト
９０２ サーフェースリスト
９０４ ビジュアルツリー
１４２０ 円形状
１４２２ 矩形
１８００、１８０２、１８０４、１８０６ タイル
２３０２、２３０４ インスタンス
２５００ 階層
２５０２、２５０４、２５０６、２５０８ クラス
２５１０、２５１２、２５１４、２５１６、２５１８、２５２０、２５２２ 要素
２６０２ マークアップコード
２６０４ パーサー／トランスレータ
２６０８ タイプコンバータ
２６１０ プログラミング言語
２６１２ データ
２７０２、２７０４ フォーム

Claims (27)

1. プロセッサとメモリとディスプレイとを有するコンピューティング環境において、コンピュータにより表示可能なグラフイックスを作成するためのコンピュータにより実現されるシステムにおいて、
   高レベルの合成及びアニメーション・エンジンと低レベルのエンジンと、前記高レベルエンジンはアプリケーションごとの基礎の上にインスタント化されていて、低レベルエンジンは複数のアプリケーションからの要求に対してサービスするものであり、
   ストリング・フォーマットとオブジェクト・ノーテーションとを含むグラフイックス命令を有するマークアップ言語と、前記オブジェクト・ノーテーションはグラフイックス要素クラスからのグラフイックス要素を含み、
   グラフイックス・オブジェクト・モデルと、前記グラフイックス・オブジェクト・モデルは、
   グラフイックス・コンテンツのコンテイナであり、他のビジュアル・タイプのためのベース機能を提供して、そこからの他のビジュアル・タイプが導出されるベース・クラス・ビジュアル・オブジェクトと、
   ビジュアルのためのコンテイナであり、そして他のコンテイナ・ビジュアル・オブジェクトを含むことができるコンテイナ・ビジュアル・オブジェクトと、
   グラフイック・コンテンツのためのコンテイナであるドローイング・ビジュアル・オブジェクトと
   シェイプ・クラスと、イメージ・クラスと、ビデオ・クラスと、キャンバス・クラスとを含んだグラフイックス要素クラスと、前記要素クラスは一般プロパティ・システムと統合されていて、とを含み、
   ストリング・フォーマットのグラフイックス命令をビジュアル・アプリケーション・プログラミング・インタフェース（ＡＰＩ）オブジェクトに変換するように構成されたタイプコンバータと、
   パーサー／トランスレータと、前記パーサー／トランスレータは、
   ａ）グラフイックス命令を解釈し、前記グラフイックス命令はダイレクト・コード・コール、オブジェクト・モデル・コード・コール、及びマークアップ言語を使用して書かれたグラフイックス命令を含み、
   ｂ）前記タイプコンバータにアクセスし、前記タイプコンバータはストリング・フォーマットのグラフイックス命令をビジュアルＡＰＩオブジェクトに変換するように構成されていて、
   ｃ）マークアップ・コードを解釈し、マークアップ・コードを解釈する際、要素ツリーにグラフイックス要素クラスの要素を追加する、
   ように構成されていて、
   グラフイックス要素ツリーをビジュアルＡＰＩへのコールへ翻訳するように構成されたプレゼンテンター・システムと、
   ビジュアルＡＰＩと、前記ビジュアルＡＰＩは、
   ａ）前記プレゼンテンター・システムとインタフェースし、前記パーサー／トランスレータとインタフェースし、そしてプログラミング言語からダイレクト・コード・コールとインタフェースし、
   ｂ）前記プレゼンテンター・システムからの要求に応答し、前記パーサー／トランスレータがシーングラフ内でシーンを生成するように構成されていて、そして
   ディスプレイ・インタフェースが前記シーングラフ内でグラフイックス・オブジェクトの表示を容易にするように構成されていることを特徴とするシステム。
2. 前記要素オブジェクトモデルの前記要素は、前記シーングラフオブジェクトモデルの前記オブジェクトと相互関係を持つことを特徴とする請求項１に記載のシステム。
3. 前記マークアップ・コードは、要素プロパティを定義するストリングを含むインラインテキストを含み、前記トランスレータは、前記ストリングをオブジェクトプロパティに変換するタイプコンバータに連絡することを特徴とする請求項１に記載のシステム。
4. 前記マークアップ・コードは、プロパティ構文を有するインラインテキストを含み、前記プロパティ構文はベクター・グラフイックス・オブジェクトの複数の属性を指定することを特徴とする請求項１に記載のシステム。
5. 前記インラインテキストは、前記マークアップ・コード中の他の位置で参照される参照によって識別されることを特徴とする請求項４に記載のシステム。
6. 前記インラインテキストは、ファイルを参照する参照によって識別されることを特徴とする請求項４に記載のシステム。
7. 前記インラインテキストは、ネットワーク内の遠隔位置からダウンロードすることが可能なファイルに対応する参照によって識別されることを特徴とする請求項４に記載のシステム。
8. 前記マークアップ・コードは、グラフィックリソースに対応する複合プロパティ構文からなるインラインテキストを含むことを特徴とする請求項１に記載のシステム。
9. 前記グラフィックリソースはビジュアルブラシオブジェクトを記述し、前記パーサー／トランスレータは、複合プロパティ構文によって記述された前記要素に対応するビジュアルペイントオブジェクトを生成する前記ビジュアルアプリケーションインタフェース層に直接連絡するために、リソースレベルデータを提供することを特徴とする請求項８に記載のシステム。
10. 前記リソースレベルデータは、前記マークアップ・コード中の他の位置で参照される参照によって識別されることを特徴とする請求項９に記載のシステム。
11. 前記リソースレベルデータは、ファイルを参照する参照によって識別されることを特徴とする請求項９に記載のシステム。
12. 前記リソースレベルデータは、ネットワーク内の遠隔位置からダウンロードすることが可能なファイルを参照する参照によって識別されることを特徴とする請求項９に記載のシステム。
13. 前記グラフイックス・オブジェクト・モデルの要素の１つは、画像要素からなることを特徴とする請求項１に記載のシステム。
14. 前記形状要素はポリライン要素からなることを特徴とする請求項１に記載のシステム。
15. 前記形状要素は多角形要素からなることを特徴とする請求項１に記載のシステム。
16. 前記形状要素はパス要素からなることを特徴とする請求項１に記載のシステム。
17. 前記形状要素は線要素からなることを特徴とする請求項１に記載のシステム。
18. 前記形状要素は楕円要素からなることを特徴とする請求項１に記載のシステム。
19. 前記形状要素は円要素からなることを特徴とする請求項１に記載のシステム。
20. 前記形状要素は塗りつぶしプロパティデータを含むことを特徴とする請求項１に記載のシステム。
21. 前記形状要素はストロークプロパティデータを含むことを特徴とする請求項１に記載のシステム。
22. 前記形状要素はクリッピングプロパティデータを含むことを特徴とする請求項１に記載のシステム。
23. 前記形状要素は変換プロパティデータを含むことを特徴とする請求項１に記載のシステム。
24. 前記形状要素は効果データを含むことを特徴とする請求項１に記載のシステム。
25. 前記形状要素は不透明データを含むことを特徴とする請求項１に記載のシステム。
26. 前記形状要素はブレンドモードデータを含むことを特徴とする請求項１に記載のシステム。
27. 前記トランスレータは、前記オブジェクトを作成する少なくとも１つのビルダのインスタンス化を要求することを特徴とする請求項１に記載のシステム。

Images