ベクトルグラフィックスのためのマークアップ言語およびオブジェクトモデル
要素オブジェクトモデル、およびプログラムコード開発者がグラフィックスを生成するためにシーングラフデータ構造と一貫してインターフェースできるように、その要素オブジェクトモデルを使用するためのベクトルグラフィックスマークアップ言語。ベクトルグラフィックスの要素オブジェクトモデルは、一般に、シーングラフのシーングラフオブジェクトモデルと相関する、形状要素ならびに画像およびビデオ要素を含む他の要素に対応する。マークアップは、シーングラフデータ構造のオブジェクトに変換される要素ツリー内の要素を含むデータに解析することができる。他のマークアップは、シーングラフオブジェクトを作成するデータおよび呼出しに直接変換することができる。マークアップ言語は、マークアップ内の他の場所での再使用を可能にする、命名できる単純な文字列フォーマットまたは複雑なプロパティ構文を含む要素を記述する独特の方法を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピュータシステムに関し、より詳細には、コンピュータシステムで表示するためのグラフィックおよび他のビデオ情報の処理に関する。
【背景技術】
【０００２】
コンピュータシステム上のグラフィックスにアクセスする従来の即時モードモデルは限界に達してきている。その原因の一部は、メモリおよびバスのスピードが主プロセッサおよび／またはグラフィックスプロセッサの進歩に遅れをとっていることである。一般に、フレームを作成するための現在の（たとえばＷＭ＿ＰＡＩＮＴ）モデルでは、複雑なグラフィックス効果が望まれる場合に、ハードウェアのリフレッシュ速度に遅れないために大量のデータを処理する必要がある。結果として、従来のグラフィックスモデルで複雑なグラフィックス効果が試される場合、結果的に次のフレームで遅れずに視覚効果が知覚されるように変更を完了する代わりに、異なるフレームにわたって変更が追加される場合があり、視覚的にかつ顕著に望ましくない結果となる。
【０００３】
グラフィックス出力を制御するための新しいモデルが記載されており（たとえば、特許文献１、２、３、４、５、および６を参照）、本発明の譲受人に譲渡され、参照により本明細書に組み込まれている。この新しいモデルは、グラフィックス処理技術においていくつかの重要な改良点を提供するものである。たとえば、複数レベルのグラフィックス処理のシステムおよび方法を対象としているものもあり（たとえば、特許文献１参照）、（たとえば、オペレーティングシステムの）より高いレベルのコンポーネントが、簡略化されたデータ構造および／またはグラフィックスコマンドを低いレベルのコンポーネントに渡すために、シーングラフの構築、アニメーションパラメータの更新、およびシーングラフのデータ構造のトラバースという、相対的に遅い動作速度で集中的に計算が行われる態様を実行する。高いレベルの処理がデータを大幅に簡略化することから、低いレベルのコンポーネントは、グラフィックスサブシステムのフレームのリフレッシュ速度に対応する速度など、（高いレベルのコンポーネントに比べて）より高速に動作し、データをグラフィックスサブシステム用の定常出力データに処理することが可能である。アニメーションが使用される場合、低いレベルの処理は、変更に伴ってシーン全体を書き直すことなく、必要に応じてレンダリング時にわずかに変更されたシーンをフレームごとに提供する瞬間値を取得するためにパラメータ間隔を補間し、平滑なアニメーションを提供することができる。
【０００４】
可変（アニメーション化された）値を提供するパラメータ化されたシーングラフと、グラフィックスを描画しようとするプログラムコード（たとえば、アプリケーションプログラムまたはオペレーティングシステムコンポーネント）が、他のアスペクトはそのままでシーングラフ記述の一定のアスペクトを選択的に変更できるようにパラメータ化されたグラフコンテナとが記載されている（たとえば、特許文献２を参照）。プログラムコードは、異なるパラメータを使用する可能性のある、シーングラフのうちのすでに構築された部分を再使用することもできる。パラメータ化を介して表示されたアイテムの外観を容易に変更する機能、および／またはシーングラフの既存の部分の再使用は、グラフィックス処理効率全体を大きく改善することが理解されよう。
【０００５】
シーングラフ内のオブジェクトおよびデータを介して映像情報を格納するための、キャッシュデータ構造および関連機構が、全体として記載されている（たとえば、特許文献３を参照）。データ構造は一般に、その中の映像情報がどのように読み込み（ｐｏｐｕｌａｔｅ）および使用されるかを知的に制御する機構に関連付けられる。たとえば、アプリケーションプログラムが特に要求しない限り、データ構造内に格納されたほとんどの情報はそれに対する外部参照を持たないため、この情報を最適化するかまたはその他の方法で処理することができる。これによって効率性とリソースの保存性が与えられ、たとえばキャッシュデータ構造内のデータを、よりコンパクトであり、かつ／または、ビットマップまたは他の後処理結果などの後続の反復的な処理が少ない異なるフォーマットに処理可能であることが理解されよう。
【０００６】
上記の改良点はグラフィックス処理技術に大きな恩恵を与えるものであるが、依然として、この改良されたグラフィックスモデルおよびその他の関連する改良点を簡単な方法で効果的に使用するためのプログラムが求められている。
【０００７】
【特許文献１】米国特許出願第１０／１８４７９５号明細書
【特許文献２】米国特許出願第１０／１８４７９６号明細書
【特許文献３】米国特許出願第１０／１８５７７５号明細書
【特許文献４】米国特許出願第１０／４０１７１７号明細書
【特許文献５】米国特許出願第１０／４０２３２２号明細書
【特許文献６】米国特許出願第１０／４０２２６８号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
改良されたグラフィックスモデルによって提供される多くの特徴およびグラフィックス処理機能を利用し、それによって複雑なグラフィックスおよび視聴覚データを効率的な方法で出力するための、包括的かつ簡単なプログラム用のモデルが必要とされている。
【課題を解決するための手段】
【０００９】
簡潔に言えば、本発明は、要素オブジェクトモデル（ｅｌｅｍｅｎｔ ｏｂｊｅｃｔ ｍｏｄｅｌ）と、プログラムコード開発者がシーングラフデータ構造と常時インターフェースしてグラフィックスを作成できるように、その要素オブジェクトモデルにアクセスするためのベクトルグラフィックスマークアップ言語とを提供するものである。ベクトルグラフィックスマークアップ言語は、要素オブジェクトモデルを介してベクトルグラフィックスを表現するための交換フォーマットを備える。マークアップ言語は、解釈される場合、シーングラフデータ構造のオブジェクトに変換される要素ツリー内の要素を含むデータに解析される。要素ツリーレベルでは、多くをプログラム可能にする、継承の特徴およびイベンティング（ｅｖｅｎｔｉｎｇ）を含むプロパティシステムおよびレイアウトシステムが提供され、起こり得る複雑なシーン（ｓｃｅｎｅ）をシーン設計者が簡単に設計できるようにしている。一般にベクトルグラフィックス要素は、シーングラフオブジェクトモデルのシーングラフオブジェクトと相互に関連する画像およびビデオ要素を含む、形状要素と他の要素とに対応する。ベクトルグラフィックス要素のプロパティおよび他のリソースは、シーングラフオブジェクトモデルの同様のプロパティおよびリソースとも相互に関連している。
【００１０】
ベクトルグラフィックスシステムは、要素レベルまでプログラミングすることが可能であり、それぞれの描画形状はページ／スクリーン内の残りのプログラム可能な要素と同レベルの要素として表されるため、レイアウトシステム、イベント、およびプロパティと対話することができる。ベクトルグラフィックスシステムは、リソースレベルまでプログラミングするための機構も提供するものである。これによってシーン設計者は、要素ツリーおよびレイアウトシステムを本質的にショートカットし、ならびにシーングラフデータ構造と対話する映像ＡＰＩレイヤまで直接プログラミングすることができる。これにより、適切なオブジェクトを出力するためのより効率の良い軽量の方法が提供されるが、要素レベルの一部はプログラムできなくなる。一実施態様では、「映像ブラシ（ｖｉｓｕａｌ ｂｒｕｓｈ）」型の塗りつぶし（ｆｉｌｌ）がプログラミングされると、パーサ（ｐａｒｓｅｒ）はリソースレベルデータを備えたＡＰＩレイヤを直接呼び出して、（同じく要素オブジェクトモデルとシーングラフオブジェクトモデルとの間の相関である）対応する映像ペイントオブジェクトを作成することができる。この２層システムでは、要素レベルベクトルグラフィックスは後でオブジェクトに変換する必要のある作成済み要素に解析され、リソースレベルベクトルグラフィックスは効率的な方法で解析されて直接保存される。同時に、リソースレベルデータまたはそれによって作成されたオブジェクトは、要素ごとおよび要素ツリーの部分ごとに参照することができる。このために、映像ペイント要素を含む要素に命名することができる。したがってシーン設計者は、必要に応じて効率性とプログラム可能性との釣り合いをとることができる。
【００１１】
要素クラス階層には、形状（Shape）クラス、画像（Image）クラス、ビデオ（Video）クラス、およびキャンバス（Canvas）クラスが含まれる。形状クラスの要素には、矩形、線分群、多角形、軌跡、線分、および楕円が含まれる。各要素は、塗りつぶし（プロパティ）データ、ストロークデータ、クリッピングデータ、変形データ、フィルタ効果データ、およびマスクデータを含むか、またはこれらに関連付けることができる。形状は、形状を描画するのに必要なペンおよびブラシの構築に使用される継承およびカスケードされた提示プロパティで描画された、（シーングラフオブジェクトモデルの）ジオメトリに対応する。画像クラスは形状クラスよりも特異的であり、より多くのラスタグラフィカルデータを含むことが可能であって、ビデオクラスは表示された要素の中でビデオ（または同様のマルチメディア）を再生させることができる。キャンバスクラスは、形状を軽量に保つために形状用のコンテナとして動作することが可能である。
【００１２】
一実施態様では、一般に要素レベルの要素を要素ツリー／プロパティシステムに追加しそれらの要素にデータを付加するパーサ／トランスレータによって、マークアップコードが解釈される。その後レイアウトシステムは、付加されたプレゼンタと共に要素ツリーを取得し、（ビルダを介して）データをオブジェクトに変換して、シーングラフとインターフェースする映像ＡＰＩレイヤを呼び出し、シーングラフオブジェクトを作成する。
【００１３】
マークアップ言語は、単純な文字列フォーマットまたは複雑なオブジェクト表記法（複雑なプロパティ構文）を含む、要素を記述するための明確な方法を提供する。単純な文字列フォーマットの場合、パーサ／トランスレータおよび／またはレイアウトシステムは、文字列を適切な映像ＡＰＩオブジェクトに変換するために、型変換器を使用する。塗りつぶし属性が複雑すぎて単一の文字列に組み込まれない場合、マークアップでは線分の内側である可能性のある複雑なプロパティ構文がプロパティセットを記述するために使用される。同じレンダリングモデルが要素レベルとＡＰＩモデルで共用されるため、オブジェクトの多くが同じであり、解析／変換はかなり効率的なものとなり、他の利点を提供している。リソースインスタンスはどこか他の場所（たとえばマークアップまたはファイル）にも位置し、名前によって参照することができる。この方法では、シーン設計者は、複雑なプロパティ構文によって記述される要素を含む要素ツリー内の要素をシーン全体にわたって再使用することができる。
【００１４】
他の利得および利点は、図面に関して以下の詳細な説明を読めば明らかとなろう。
【発明を実施するための最良の形態】
【００１５】
（例示的なオペレーティング環境）
図１は、本発明が実施可能である、適したコンピューティングシステム環境１００の一例を示す図である。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲に関していかなる制限をも示唆することを意図するものではない。さらにコンピューティング環境１００は、例示的オペレーティング環境１００内に示されたいずれのコンポーネントまたはコンポーネントの組合せに関しても、いかなる依存性または要件を有するものとも解釈されるべきではない。
【００１６】
本発明は、多数の他の汎用または特定用途向けのコンピューティングシステム環境または構成を使用して動作可能である。本発明で使用するのに適する可能性のある、よく知られたコンピューティングシステム、環境、および／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、タブレット装置、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能な市販の電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたは装置のいずれかを含む分散コンピューティング環境、およびその他が含まれるが、これらに限定されるものではない。
【００１７】
本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令との全体的な関連において説明することができる。一般に、プログラムモジュールにはルーチン、プログラム、オブジェクト、コンポーネント、データ構造、などが含まれ、特定のタスクを実行するかまたは特定の抽象データ型を実施する。本発明は、タスクが通信ネットワークを介してリンクされたリモート処理装置によって実行される、分散コンピューティング環境でも実施可能である。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよびリモート双方のコンピュータ記憶媒体に配置することができる。
【００１８】
図１を参照すると、本発明を実施するための例示的システムには、コンピュータ１１０の形の汎用コンピューティング装置が含まれる。コンピュータ１１０のコンポーネントは、処理装置１２０と、システムメモリ１３０と、システムメモリを含む様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１とを含むことができるが、これらに限定されるものではない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含む、いくつかの種類のバス構造のうちのいずれであってもよい。例を挙げると、こうしたアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）バス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれるが、これらに限定されるものではない。
【００１９】
コンピュータ１１０は、通常、様々なコンピュータ読取り可能な媒体を含む。コンピュータ読取り可能な媒体は、コンピュータ１１０によってアクセス可能な揮発性および不揮発性媒体、ならびに取外し可能および固定の両方の媒体を含む、任意の使用可能な媒体とすることが可能である。例を挙げると、コンピュータ読取り可能な媒体はコンピュータ記憶媒体および通信媒体を含むことができるが、これらに限定されるものではない。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、または他のデータなどの、情報を記憶するための任意の方法または技術で実施された揮発性および不揮発性、取外し可能および固定の、両方の媒体を含む。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、あるいは所望の情報を記憶するために使用可能でありコンピュータ１１０がアクセス可能な任意の他の媒体が含まれるが、これらに限定されるものではない。通信媒体は、通常、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、または搬送波または他の移送機構などの被変調データ信号中の他のデータを具体化し、任意の情報送達媒体を含むものである。「被変調データ信号」という用語は、信号内の情報を符号化するような方法で、その特性のうちの１つまたは複数が設定または変更された信号を意味する。例を挙げると、通信媒体には、有線ネットワークまたはダイレクトワイヤード接続などの有線媒体と、音波、ＲＦ、赤外線、および他の無線媒体などの無線媒体とが含まれるが、これらに限定されるものではない。上記のうちの任意の組合せも、コンピュータ読取り可能な媒体の範囲に含まれるものとする。
【００２０】
システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。コンピュータ１１０内の要素間での起動時などの情報転送に役立つ基本ルーチンを含む基本入力／出力システム１３３（ＢＩＯＳ）は、通常、ＲＯＭ１３１に格納される。ＲＡＭ１３２は、通常、処理装置１２０が即時にアクセス可能であり、かつ／または現在動作中である、データおよび／またはプログラムを含む。例を挙げると、図１にはオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７が示されているが、これらに限定されるものではない。
【００２１】
コンピュータ１１０は、他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体を含むこともできる。単なる例として、図１には、固定の不揮発性磁気媒体からの読取りまたはこれへの書込みを行うハードディスクドライブ１４１と、取外し可能な不揮発性磁気ディスク１５２からの読取りまたはこれへの書込みを行う磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭまたは他の光媒体などの取外し可能な不揮発性光ディスク１５６からの読取りまたはこれへの書込みを行う光ディスクドライブ１５５が示されている。例示的なオペレーティング環境で使用可能な他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、などが含まれるが、これらに限定されるものではない。ハードディスクドライブ１４１は、通常、インターフェース１４０などの固定のメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取外し可能メモリインターフェースによってシステムバス１２１に接続される。
【００２２】
上記で考察し、図１に示すドライブおよびそれらの関連するコンピュータ記憶媒体は、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、およびコンピュータ１１０に関する他のデータのストレージを提供するものである。たとえば図１では、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納しているものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであるかまたは異なるかの、いずれであってもよいことに留意されたい。本明細書では、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともこれらが異なるコピーであることを示すために異なる番号が与えられている。ユーザは、タブレット（電子ディジタイザ）１６４、マイクロフォン１６３、キーボード１６２、および、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などの入力装置を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、スキャナ、またはその他を含むことができる。これらおよび他の入力装置は、システムバスに結合されたユーザ入力インターフェース１６０を介して処理装置１２０に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することも可能である。モニタ１９１または他の種類のディスプレイ装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１は、タッチスクリーンインターフェースなどのインターフェースを介してコンピュータシステム１１０に手書き入力するなどの、デジタル化された入力を行うことのできる、タッチスクリーンパネルまたはその他と一体型にすることも可能である。モニタおよび／またはタッチスクリーンパネルは、タブレット型のパーソナルコンピュータの場合などのように、コンピューティングデバイス１１０が組み込まれたハウジングに物理的に結合可能であり、ここでタッチスクリーンパネルは本質的にタブレット１６４として働くことに留意されたい。さらに、コンピューティングデバイス１１０などのコンピュータは、出力周辺インターフェース１９４またはその他を介して接続可能なスピーカ１９５およびプリンタ１９６などの他の周辺出力装置も含むことができる。
【００２３】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般的なネットワークノードとすることが可能であり、通常は、コンピュータ１１０に関して上記で述べた要素の多くまたはすべてを含むが、図１にはメモリ記憶装置１８１のみが記載されている。図１に示された論理接続には、ローカル絵リアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークを含むこともできる。こうしたネットワーキング環境は、オフィス、企業規模コンピュータネットワーク、イントラネット、およびインターネットで普及している。
【００２４】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０はネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介した通信を確立するためのモデム１７２または他の手段を含む。モデム１７２は内蔵型または外付けが可能であり、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化環境では、コンピュータ１１０に関して示されたプログラムモジュールまたはその一部を、リモートのメモリ記憶デバイスに格納することができる。例を挙げると、図１にはリモートアプリケーションプログラム１８５がメモリ装置１８１に常駐しているように示されているが、これらに限定されるものではない。図示されたネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段が使用可能であることを理解されよう。
【００２５】
（グラフィックスアーキテクチャ）
本発明の一態様は、一般に、アプリケーションまたはオペレーティングシステムコンポーネントなどのプログラムコードが、システムディスプレイ上にグラフィック出力をレンダリングするために、描画命令および他の情報（たとえば画像ビットマップ）をグラフィックスコンポーネントに送ることができるようにすることを対象としている。このため本発明は、プログラムがデータ構造、描画プリミティブ（コマンド）、および他のグラフィックス関連データと共にシーングラフを読み込めるようにするマークアップ言語ならびに形状要素および他の要素のセット、グループ化および複合化システム、ならびにオブジェクトモデルにおける一般的なプロパティシステムとの統合を提供するものである。処理が実行されると、シーングラフはスクリーン上にグラフィックスを表示することになる。
【００２６】
図２は、本発明が実施可能な、全体的なレイヤードアーキテクチャ２００を示す図である。図２に示されるように、プログラムコード２０２（たとえばアプリケーションプログラムまたはオペレーティングシステムコンポーネントなど）を開発して、画像化機構２０４を介すること、ベクトルグラフィック要素２０６を介すること、および／または映像アプリケーションプログラミングインターフェース（ＡＰＩ）レイヤ２１２に直接配置された機能／メソッド呼出しを介することを含む、１つまたは複数の様々な方法で、グラフィックスデータを出力することができる。ＡＰＩレイヤとの直接対話については、前述の「Ｖｉｓｕａｌ ａｎｄ Ｓｃｅｎｅ Ｇｒａｐｈ Ｉｎｔｅｒｆａｃｅｓ」という名称の同時係属出願により詳細に記載されている。
【００２７】
一般に、画像化機構２０４は、たとえばビットマップなどの画像のロード、編集、および保存のための機構をプログラムコード２０２に提供するものである。これらの画像はシステムの他の部分が使用することも可能であり、画像に直接描画するためにプリミティブ描画コードを使用する方法もある。
【００２８】
本発明の一態様によれば、ベクトルグラフィックス要素２０６は、オブジェクトモデルの残りの部分に適合する、グラフィックスを描画するための他の方法を提供する（以下で説明）。ベクトルグラフィック要素２０６はマークアップ言語を介して作成することが可能であり、要素／プロパティシステム２０８およびレイアウトシステム２１０はこれを処理して、映像ＡＰＩレイヤ２１２を適切に呼び出す。以下で説明するように、一般にベクトルグラフィック要素２０６は、シーングラフが描画される元となるオブジェクトモデルのオブジェクトに解析され、これを、要素／プロパティシステム２０８およびレイアウトシステム２１０を介した要素レベルを介してシーングラフに提供するか、またはリソースレベルでのより効率的な方法で提供することが可能であり、これについても以下で説明する。
【００２９】
一実施態様では、グラフィックスレイヤアーキテクチャ２００には高いレベルの合成およびアニメーションエンジン２１４が含まれ、これがキャッシュデータ構造２１６を含むかまたは他の方法でこれに関連付けられる。キャッシュデータ構造２１６は、以下で説明するように、定義済みオブジェクトモデルに従って管理される階層上に配置構成されたオブジェクトを備えたシーングラフを含む。一般に、映像ＡＰＩレイヤ２１２は、オブジェクトの作成、オブジェクトにデータを提供するためのオブジェクトのオープンおよびクローズなどの機能を含む、キャッシュデータ構造２１６へのインターフェースをプログラムコード２０２（およびレイアウトシステム２１０）に提供する。つまり、高いレベルの合成およびアニメーションエンジン２１４は、開発者が、グラフィックス情報を表示するためにグラフィックスおよび媒体に関する意図を表現し、基礎となるプラットフォームがプログラムコードに対するハードウェアの使用を最適化できるようにプラットフォームに十分な情報を提供する際に使用できる統一媒体ＡＰＩレイヤ２１２を公開する。たとえば基礎となるプラットフォームは、キャッシュ、リソースの折衝（ｎｅｇｏｔｉａｔｉｏｎ）、および媒体の統合に関する責務を負うことになる。
【００３０】
一実施態様では、高いレベルの合成およびアニメーションエンジン２１４は、命令ストリームおよび可能な他のデータ（たとえばビットマップを指すポインタ）を高速の低いレベルの合成およびアニメーションエンジン２１８に渡す。「高いレベル」および「低いレベル」という用語が本明細書で使用される場合、他のコンピューティングシナリオで使用される場合と同様に、一般に、高いレベルのコンポーネントに比べてソフトウェアコンポーネントが低いレベルであるほど、そのコンポーネントはハードウェアに近くなる。したがって、たとえば高いレベルの合成およびアニメーションエンジン２１４から送られたグラフィックス情報を、低いレベルの合成およびアニメーションエンジン２１８で受け取ることが可能であり、ハードウェア２２２を含むグラフィックスサブシステムにグラフィックスデータを送信する際にその情報が使用される。
【００３１】
高いレベルの合成およびアニメーションエンジン２１４はプログラムコード２０２と共に、プログラムコード２０２によって提供されたグラフィックスシーンを表すためのシーングラフを構築する。たとえば、描画されるそれぞれのアイテムを描画命令と共にロードすることが可能であり、システムはこれをシーングラフデータ構造２１６にキャッシュすることができる。以下で説明するように、このデータ構造２１６および何を描画するかを指定するにはいくつかの様々な方法がある。さらに、高いレベルの合成およびアニメーションエンジン２１４は、タイミングおよびアニメーションシステム２２０と統合し、宣言（または他の）アニメーション制御（たとえばアニメーション間隔）およびタイミング制御を提供する。アニメーションシステムは、本質的にアニメーション値を、たとえば要素プロパティレベル２０８、映像ＡＰＩレイヤ２１２の内部、および任意の他のリソース内を含む、システム内のどこにでも渡せるようにするものであることに留意されたい。タイミングシステムは、要素レベルおよび映像レベルで公開される。
【００３２】
低いレベルの合成およびアニメーションエンジン２１８はシーンの合成、アニメーション、およびレンダリングを管理し、その後これがグラフィックスサブシステム２２２に提供される。低いレベルのエンジン２１８は、複数のアプリケーションのシーンについてレンダリングを合成し、レンダリングコンポーネントを使用して、スクリーンへのグラフィックスの実際のレンダリングを実施する。しかし、時には、一部のレンダリングはより高いレベルで発生することが必要かつ／または有利な場合があることに留意されたい。たとえば、複数アプリケーションからのサービス要求が低レイヤになるほど、アプリケーションごとのインスタンス生成がより高レイヤになり、これによって、画像化機構２０４を介して、時間のかかるまたはアプリケーション特有のレンダリングが高いレベルで実行され、ビットマップへの参照が低レイヤに渡される可能性がある。
【００３３】
（シーングラフオブジェクトモデル）
以下で説明するように、レンダリングモデルは、高いレベル、コントロールベースのベクトルグラフィックス要素２０６と、シーングラフデータ構造２１６で使用される映像ＡＰＩレイヤ２１２によって作成された低いレベルのオブジェクトによって共用される。これによって、本発明の高いレベルの要素と低いレベルのオブジェクトとの間にかなりの相関関係がもたらされる。次に、シーングラフオブジェクトモデルの一実施態様について説明する。
【００３４】
本発明は、グラフィックスおよびレンダリングサービスへのいくつかのレイヤのアクセスを提供するものである。トップレイヤでは、ベクトルグラフィックスが、本発明のオブジェクトモデルでの使用が簡単であること、容易に再使用できること、および同様のシステムのユーザには一般によく知られていることを含む、ＸＭＬベースグラフィックスのマークアップでは一般的ないくつかの利点を提供する。オブジェクトは、それらの要素に関する属性または複雑なプロパティのどちらか一方として公開されたプロパティを備えるマークアップ要素として使用可能である。
【００３５】
本発明は、Visualオブジェクトの使用によってグラフィックスコンテンツをレンダリングするものである。この基礎となるVisualレイヤはいくつかの方法で使用可能である。プログラマは、コード内で直接Visualにアクセス可能であり、オブジェクトモデルを使用してプログラミング可能であり、本発明の一態様に従って、ＸＭＬベースのマークアップが使用可能である。
【００３６】
予め定義されたベクトル形状は、PolygonおよびPath要素と同様にベクトルグラフィックスで使用可能であり、Canvas、Dock Panel、およびFlow Panelなどのレイアウト要素内に格納される。Canvas要素は、親空間内に要素を絶対的に配置するための手段を提供する。Canvasおよびその子形状の場合、スクリーン座標用のデフォルトの測定単位は、装置に依存しないピクセルである。DockPanelおよびFlowPanelは、いくつかのサイズおよび位置合わせプロパティ、ならびに境界線をまたがるコントロールを提供する。
【００３７】
ベクトルグラフィックスは、ＳＶＧのユーザにはよく知られたいくつかの定義済みベクトルグラフィックス形状を提供する。これらの要素はShapeクラスを継承し、Ellipse（楕円）、Line（線分）、Path（軌跡）、Polygon（多角形）、およびRectangle（矩形）を含む。これらの要素は、座標および頂点を指定するためのStrokeおよびStrokeThickness、Fill、ならびにデータ属性を含む、いくつかの一般的な属性をShapeから継承する。開発者は、変形を適用することによって形状を傾斜、回転、変換、および縮尺することもできる。
【００３８】
Line要素は、便利な一例を提供するものである。以下の例では、始点および終点、ストロークの色および幅、ならびに線分端部での丸めキャッピング（ｒｏｕｎｄｅｄ ｃａｐｐｉｎｇ）用の座標を指定する。
【００３９】
【表１】
【００４０】
形状の中央をCenterXおよびCenterYプロパティで定義することによって、楕円が作成される。焦点を指定する代わりに、RadiusXおよびRadiusYプロパティを設定することによって、楕円の範囲が設定される。ベクトルグラフィックスで円を描画する場合、開発者はRadiusXとRadiusYの値が等しい楕円を指定することができる。
【００４１】
【表２】
【００４２】
Pathオブジェクトは、オープンまたはクローズどちらかの、曲線および複雑な形状を描画する手段を提供する。Pathは、Shapeクラスから継承したオブジェクト上で使用可能なプロパティを公開するが、曲線を記述するためにより複雑なパラメータを開発者に指定させることもできる。開発者は、Data内で特殊な構文を使用して軌跡データを指定すること、またはPathGeometryおよびPathGeometryオブジェクトを使用して個々の軌跡セグメントを指定することを含み、マークアップ内で様々な方法で軌跡を使用することができる。
【００４３】
Data属性に提供される座標ペアおよび線分の内側パラメータは、線分セグメント、ベジェ曲線、および様々な他の軌跡の仕様を指定することができる。以下の例は、２つの下位の軌跡を定義するPath要素を示すものである。
【００４４】
【表３】
【００４５】
Data属性文字列は、Ｍで示された「ｍｏｖｅｔｏ」コマンドで始まり、Canvasの座標系において軌跡の始点を確立する。Pathデータパラメータは大文字と小文字を区別する。大文字のＭは新規の現在位置に関する絶対位置を示す。小文字のｍは相対座標を示す。第１の下位の軌跡は、２つの制御位置（１００，２５）および（４００，３５０）を使用して描画される、（１００，２００）で始まり（４００，１７５）で終わる３次ベジェ曲線である。この下位の軌跡は、Data属性文字列内のＣコマンドで示される。ここでも、大文字のＣは絶対軌跡を示し、小文字のｃは相対軌跡を示すことになる。
【００４６】
第２の下位の軌跡は、絶対水平「ｌｉｎｅｔｏ」コマンドＨで始まり、先行する下位の軌跡の終点（４００，１７５）から新しい終点（２８０，１７５）まで描画される線分を指定するものである。これは水平「ｌｉｎｅｔｏ」コマンドであるため、指定される値はｘ軸座標である。
【００４７】
より詳細な構文を使用してマークアップ内の軌跡データを指定することも可能であり、これは、開発者が複雑なプロパティを指定し、マークアップをより読みやすくするという利点を有する場合がある。この場合、PathGeometryオブジェクトを使用して、円弧および曲線などの複雑な形状を作成することができる。PathGeometryオブジェクトは１つまたは複数のPathFigureオブジェクトからなり、各PathFigureは異なる「図」または形状を表す。各PathFigureは、それ自体が１つまたは複数のPathSegmentオブジェクトからなり、それぞれが図または形状の接続された部分を表す。セグメント型には、LineSegment、BezierSegment、およびArcSegmentが含まれる。
【００４８】
以下のコードは、PathGeometryおよびPathfigureを使用することによって軌跡データを指定するものであり、PathFigureにいくつかのセグメントが加えられて１つの形状を形成する。この場合、セグメントはPathFigureオブジェクトのSegmentsプロパティを使用して加えられる。このマークアップは、４つのベジェ曲線を作成する。PathFigureの第１のセグメントはStartSegmentであることに留意されたい。
【００４９】
【表４−１】
【００５０】
【表４−２】
【００５１】
ベクトルグラフィックス形状は、それらのStrokeおよびFillの色を指定するために、Brushオブジェクトの様々な属性を公開する。以下の例では、CanvasおよびEllipse要素に関してこれらの属性を指定する。色プロパティに有効な入力は、キーワードまたは１６進カラー値のどちらでも可能であることに留意されたい。
【００５２】
【表５】
【００５３】
別の方法として、開発者は、複雑なプロパティ構文およびSolidColorBrushクラスを使用して色を指定することができる。より複雑な構文を使用してプロパティを指定することは、プロパティシートを備えたグラフィックスマークアップを再使用する場合、または同じ色の形状プロパティをアニメーション化するために、必要となる。
【００５４】
【表６】
【００５５】
この不規則な線分群の形状は、StrokeおよびFillプロパティに予め定義されたカラー値を使用する。FillOpacityプロパティは、この場合はわずかに透明（不透明度０．８）にすることによって塗りつぶす色に影響を与えるため、任意の基礎となる色と調和する。
【００５６】
【表７】
【００５７】
形状に対してソリッドカラーの塗りつぶしおよび背景を指定する場合とまったく同様に、勾配（ｇｒａｄｉｅｎｔ）を指定することも可能である。以下の例は、RectangleのFill属性として水平勾配を、開始色としてBlueおよび終了色としてRedを設定するものである。
【００５８】
【表８】
【００５９】
開発者は、複雑なプロパティ表記法で勾配を指定することもできる。この表記法は、勾配のレンダリングにおいて非常に特異であり、追加のプロパティを公表する。たとえば勾配を使って形状の塗りつぶしをアニメーション化する場合、複雑な表記法が使用されることになる。以下の例では、RadialGradientBrushオブジェクトを使用してRectangleに勾配を設定する。RadialGradientBrushオブジェクトは、その半径およびそれに設定することのできる任意の変形およびアニメーションと同様に、勾配のプロパティへアクセスし、これらのプロパティはGradientBrushから継承される。GradientStopCollection集合は、開発者が複数の勾配停止を指定し、それらのオフセット（勾配の停止位置）を指定できるようにするものである。
【００６０】
【表９】
【００６１】
本発明は、ベクトルが描画する形状に標準の変形を行うものである。開発者は、静的グラフィックスとしてまたはアニメーションで、形状を傾斜させ、それらを回転させ、それらの縮尺を変更し、それらを変換（再配置）することができる。マークアップでTransformオブジェクトを使用する場合、それらをTransformDecoratorの子として指定する必要がある。
【００６２】
ScaleTransform変形は、使用可能な変形の中で最も簡単であり、要素をサイズ変更するべき係数を指定するだけで使用される。以下の例は、親Canvasの座標系のｙ軸に沿ってPolygon要素のサイズを１５０パーセント変更するものである。
【００６３】
【表１０】
【００６４】
同じTransformDecoratorオブジェクトをさらに変形するように指定する場合、TransformCollectionで囲む必要があることに留意されたい。また、各変形が解析および適用される順番によって、最終的な効果が異なる。たとえば、要素を異なるスクリーン座標に変換する前に回転させると、異なる効果を生じさせることができる。
【００６５】
以下の例では、２つの線分群要素に回転および変換が適用される。
【００６６】
【表１１】
【００６７】
これら２つの変形では、それぞれの形状の最終スクリーン位置が同じにならないことに留意されたい。回転変形を使用する場合、変形は特定要素の座標系全体を回転させる。起点を基準にした要素の位置によって、回転の効果が要素を「所定の位置で」回転させない場合がある。たとえば、ｘ軸に沿って０から２００単位に配置された要素の場合、３０度回転させると、起点を中心に描かれた半径２００の円に沿って要素を３０度回す効果がある。そのため、Transformを処理する場合、要素を起点に変換し、回転、傾斜、または縮尺の変形を加え、その後要素を最終位置に再変換する方が簡単である。
【００６８】
特定の構文を使用して、変形設定の他の変換とは無関係に、特定ポイントを中心とした回転を指定することができる。実際には、この構文は新しい起点への変換、回転、および以前の起点への再変換を指定する。ポイント（ｃｘ，ｃｙ）を中心とするｒ度の回転を指定する場合、以下の構文を使用する。
transform="rotate(rx [cx,cy])"
【００６９】
開発者は傾斜変形を使用して、一方または両方の軸に沿って形状を歪ませることができる。SkewTransformクラスは、どちらかの軸に沿って比例オフセットを指定する、AngleXおよびAngleYプロパティを提供する。
【００７０】
【表１２−１】
【００７１】
【表１２−２】
【００７２】
他の変形の場合と同様に、傾斜変形の適用効果は単に形状だけでなく座標系を傾斜させることである。したがって起点が設定されると必ず、座標系は起点から傾斜する。起点からある程度距離を有する形状で傾斜変形が行われると、「空空間」もその傾斜を反映し、要素の配置に影響を与える。同じ理由から、開発者が配置変形を適用する順番も、レンダリングされる傾斜または回転に影響を与える。
【００７３】
形状またはコントロールに色が加えられる場合は、いつでもブラシが使用される。本発明は、開発者のアプリケーションが、単純なソリッドカラーから複雑なパターンおよび画像のセットまで何でも使用してユーザインターフェース（ＵＩ）要素をペイントできるようにする、マークアップを提供する。
【００７４】
ブラシは、キャンバスに描かれた形状の内部および枠に色付けすることができる。ブラシを使用して、ＵＩを形成する任意の要素の外観を変更することもできる。以下に記載するのはBrush型の属性の一部であり、いずれのブラシも使用することができる。
Control.Background
Control.BorderBrush
Column.Background
Text.Foreground
Shape.Fill
Shape.Stroke
【００７５】
２つの主な型のブラシ、すなわちベクトルブラシおよびビットマップブラシがある。ベクトルベースのブラシには、SolidColorBrush、LinearGradientBrush、RadialGradientBrush、およびDrawingBrushが含まれる（ただしDrawingBrushはビットマップで塗りつぶされた形状を含むことができる）。ビットマップベースのブラシには、ImageBrushおよびNineGridBrushが含まれる。一般にビットマップは、領域を塗りつぶすために引伸ばしまたは縮尺された場合に品質が低下するが、ベクトルは低下しない。したがって、可能であれば必ずベクトルベースのブラシを使用すべきである。
【００７６】
基本型の塗りつぶしは、領域をソリッドカラーで塗りつぶすSolidColorBrushである。ソリッドカラーを指定するには、いくつかの方法がある。よく知られた色は、名前で選択することができる。たとえば、形状のFill属性を「Red」に設定することができる。赤、緑、および青の量を指定することにより３２ビットの色パレットから色を選択して、単一のソリッドカラーに混合することができる。３２ビットのパレットから色を指定するための形式は「#RRGGBB」であり、ここでRRは赤の相対的な量を指定する２桁の１６進数であり、GGは緑の量を指定し、BBは青の量を指定する。さらに、色は「#AARRGGBB」として指定することも可能であり、ここでAAは、色のアルファチャネル、すなわち透過性を指定する。他の配色も実行可能である。
【００７７】
以下の例で、Ellipse要素のFillは、予め定義された色名のうちの１つを使用して設定される。
【００７８】
【表１３】
【００７９】
アルファチャネルは、任意のソリッドカラーブラシに直接指定することが可能である一方で、ブラシのOpacityプロパティで指定することもできる。要素全体およびその子要素の不透明度は、UIElement.Opacityプロパティを使用して指定することができる。これらの値は、それぞれ０と１の間のDoubleとして指定される。１の値は完全に不透明であり、０の値は完全に透明である。不透明度を記述する様々な方法は累積的である。すなわち、アルファチャネルが０×７Ｆ（５０パーセント不透明）でありUIElement.Opacityプロパティが０．５（５０パーセント不透明）である場合、要素は２５パーセント不透明でペイントされる。
【００８０】
勾配ブラシとは、軸に沿って１つの色から他の色に変化する塗りつぶしのことである。ベクトルグラフィックス（Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）でサポートされている勾配には、線形勾配および放射勾配の２種類がある。
【００８１】
勾配ブラシの基本的な構築ブロックは勾配停止である。勾配停止は、勾配軸に沿って相対的なオフセットで色を指定する。勾配停止間の点の色は、２つの境界となる勾配停止によって指定された色の組合せとして、線形補間される（ｌｉｎｅａｒｌｙ ｉｎｔｅｒｐｏｌａｔｅｄ）。オフセットは、０から１までの範囲のDoubleである。以下に、勾配の例を示す。
【００８２】
勾配ブラシを持つ方法の１つは、勾配停止を明示的に指定することである。以下にその一例を示す。
【００８３】
【表１４】
【００８４】
以下の例では、LinearGradientBrushを使用して、４つの勾配停止を有するボタンの背景を線形勾配で塗りつぶす。
【００８５】
【表１５】
【００８６】
RadialGradientBrushを使用して、放射勾配で領域を塗りつぶす。放射勾配は線形勾配と同様であるが、勾配の軸は楕円の内側から外側へと存在する。放射勾配で塗りつぶされた円は、黄色の中心と緑の輪郭を有し、それらの間で色を補間することができる。以下の画像は、白から灰色への放射勾配で塗りつぶされた矩形を示すものである。外側の円は勾配円を表し、赤いドットは焦点を示す。この勾配では、SpreadMethodをPadに設定している。
【００８７】
以下の例では、Rectangle要素のFillプロパティはRadialGradientBrushを使用して設定される。放射勾配は（０．５，０．５）の焦点を有する。
【００８８】
【表１６】
【００８９】
２色のみで勾配を作成する場合、Stroke、Fill、およびBackgroundのプロパティにキーワードを使用して、表記法を簡略化することができる。以下のサンプルは、青から赤へ変化する線形勾配型の水平勾配で塗りつぶされた矩形を作成する方法を示す。
【００９０】
【表１７】
【００９１】
水平、垂直、および放射の勾配を作成するための省略された構文は、GradientType StartColor EndColorであり、ここでGradientTypeはVerticalGradient、HorizontalGradient、またはRadialGradientである。StartColorおよびEndColorは、予め定義された色名（青など）または１６進値とすることができる。
【００９２】
垂直勾配とは、始点と終点が垂直な線を形成する線形勾配のことである。同様に、水平勾配とは、始点と終点が水平な線を形成する線形勾配のことである。開発者は、構文
LinearGradient StartPoint EndPoint StartColor EndColor
を使用して彼ら自身の２色の線形勾配を明示的に記述することが可能であり、ここでStartPointおよびEndPointは開始および終了座標であって、それぞれの座標が０．１，０．１および０．５，０．５などの０から１までのｘ値とｙ値のペアとして表される。これらの値は始点または終点の相対位置を示し、０．５，０．５の終点は、塗りつぶし領域の右まで５０パーセント、領域の上部からの距離の５０パーセントで配置され、この点が形状の中央になるように位置付けられる。
【００９３】
以下の例で、Rectangle要素のFillプロパティは線形勾配を使用して明示的に設定される。
【００９４】
【表１８】
【００９５】
以下の例に、省略された構文を使用して２色の放射勾配で領域を塗りつぶす方法を示す。
【００９６】
【表１９】
【００９７】
Fill属性に加え、勾配を使用してShape要素のStrokeなどのオブジェクトの輪郭を塗りつぶすこともできる。
【００９８】
描画ブラシとは、形状またはコントロールを、他の形状およびブラシの組合せで塗りつぶすことができるようにするものである。通常のShape要素とは異なり、DrawingBrush内部のShapeは要素ツリーの中の要素ではない。その代わりに、媒体レイヤによって直接解析およびレンダリングされる。その結果、ユーザインターフェースの一部が多くの形状からなる場合、性能を大幅に向上されることができる。
【００９９】
描画ブラシはタイルブラシの一種である。ここでは、開発者が描画ブラシをどのようにコントロールして出力領域を塗りつぶすことができるかについて、追加の機能に関する情報を提供する。
【０１００】
ImageBrushは、領域をビットマップ画像で塗りつぶすものである。以下のサンプルでは、ImageBrushを使用して画像をCanvasの背景としてレンダリングする方法を示す。
【０１０１】
【表２０】
【０１０２】
画像ブラシはタイルブラシの一種である。このセクションでは、画像がどのように出力領域を塗りつぶすかをコントロールするのに開発者が使用できる追加の機能に関する情報を提供する。
【０１０３】
DrawingBrushおよびImageBrushはどちらもタイルブラシの一種である（TileBrushクラスから導出する）。したがって、開発者が領域の塗りつぶし方法をかなり詳細にコントロールすることのできる、共通の機能集合を有する。たとえば、開発者は、単に引伸ばされた画像で領域を塗りつぶすのではなく、パターンを作成する一連の画像タイルで領域を塗りつぶすことができる。
【０１０４】
タイルブラシは、コンテンツで塗りつぶされた１つまたは複数のタイルを記述するものである。ImageBrushは、そのタイルをビットマップ画像で塗りつぶすタイルブラシである。DrawingBrushは、そのタイルを描画で塗りつぶすタイルブラシである。
【０１０５】
タイルブラシは、開発者に２つのレベルのコントロールを提供するため、開発者はブラシのコンテンツがそのタイルをどのように塗りつぶすかをコントロールすることが可能であり、その開発者はブラシのタイルが領域をどのように塗りつぶすかをコントロールすることができる。デフォルト時には、タイルブラシは出力領域を単一のタイルで塗りつぶし、ブラシのコンテンツはそのタイルを塗りつぶすように引伸ばされる。開発者がこのデフォルトの挙動を上書きできるようにするプロパティの中には、Stretch、ViewPort、およびViewBoxのプロパティがある。（図１８を参照しながら以下でも説明する）Stretchプロパティは、ブラシのコンテンツがそのタイルをどのように塗りつぶすかを定義する。ViewPortはブラシのタイルのサイズおよび位置を定義し、ViewBoxプロパティはブラシのコンテンツのサイズおよび位置を決定する。
【０１０６】
Stretchプロパティは、タイルブラシのコンテンツがそのタイルを塗りつぶすためにどのように引伸ばされるかをコントロールする。Stretchプロパティは、Stretch列挙法で定義された以下の値を受け入れる。
None: ブラシのコンテンツはタイルを塗りつぶすために引伸ばされない。
Fill: ブラシのコンテンツはタイルに合うように縮尺される。コンテンツの高さおよび幅は別個に縮尺されるため、コンテンツのオリジナルのアスペクト比が保持されない可能性がある。すなわち、出力タイルを完全に塗りつぶすために、ブラシのコンテンツが歪められる場合がある。
Uniform: ブラシのコンテンツは、タイル内に完全にはまるように縮尺される。コンテンツのアスペクト比は保持される。
UniformToFill: ブラシのコンテンツは出力領域を完全に塗りつぶすように縮尺される一方で、コンテンツのオリジナルのアスペクト比は保持される。
【０１０７】
HorizontalAlignmentおよびVerticalAlignmentプロパティは、タイルブラシのコンテンツがそのタイル内でどのように位置合わせされるかを決定する。HorizontalAlignmentプロパティは、HorizontalAlignment列挙法で定義された、Left、Center、およびRightの値を受け入れる。VerticalAlignmentプロパティは、VerticalAlignment列挙法で定義された、Top、Center、およびBottomの値を受け入れる。
【０１０８】
ViewPortプロパティは、ブラシのタイルのサイズおよび位置を決定する。ViewPortUnitsプロパティは、ViewPortが絶対座標または相対座標のどちらを使用して指定されるかを決定する。相対座標の場合、出力領域のサイズに比例する。ポイント（０，０）は出力領域の左上コーナを表し、（１，１）は出力領域の右下コーナを表す。ViewPortプロパティが絶対座標を使用するように指定するためには、ViewPortUnitsプロパティをAbsoluteに設定する。
【０１０９】
以下の例では、幅および高さが１００であり、その左上コーナが（０，０）にあるタイルが、画像を使用して作成される。
【０１１０】
【表２１】
【０１１１】
ブラシのコンテンツのサイズおよび位置は、ViewBoxプロパティを使用して指定することができる。タイルブラシのタイルが出力領域を完全に塗りつぶしていない場合、そのTileModeプロパティが残りの出力領域をどのように塗りつぶすかを指定する。TileModeプロパティは、TileMode列挙法で定義された以下の値を受け入れる。
None: 基本タイルのみが描画される。
Tile: 基本タイルが描画され、残りの領域は、１つのタイルの右縁が次のタイルの左縁に隣接し、下と上も同様に隣接するように、基本タイルを反復することによって塗りつぶされる。
FlipX: Tileと同様であるが、タイルの交互の列が水平に反転される。
FlipY: Tileと同様であるが、タイルの交互の行が垂直に反転される。
FlipXY: FlipXおよびFlipYの組合せ。
【０１１２】
様々なタイリングモードについて、図１９を参照しながら以下で説明する。
【０１１３】
図１７を参照しながら以下で説明するNineGridBrushは、領域をビットマップ画像で塗りつぶすという点が画像ブラシと非常によく似ている。しかし、NineGridBrushでは、画像は４本の境界によって９つの領域またはグリッドに分けられる。詳細な情報については、NineGridBrushのページを参照されたい。
【０１１４】
図３および４はそれぞれ、Visualと呼ばれる基本オブジェクトを含むシーングラフ３００および４００の例を示す図である。映像オブジェクトまたは単に映像は、線分、テキスト、および画像などのグラフィカルコンテンツ用のコンテナである。図５のVisualクラスのオブジェクト継承で示されるように、グラフィカルコンテンツを直接含まないが子Drawing Visualオブジェクトを含むContainerVisualを含む、いくつかの異なる映像オブジェクトがある。子Drawing Visualオブジェクトは、他のDrawingVisualオブジェクトではなく、ContainerVisualに追加される。これによって開発者は、全体の描画コンテキストを再作成およびその後の再レンダリングすることなく、個々の映像オブジェクトのプロパティを変更および設定することが可能であり、同時に、コンテナオブジェクトのクリッピングおよび変形プロパティにアクセスすることもできる。ContainerVisualオブジェクトは入れ子にすることができる。
【０１１５】
DrawingVisualとは、グラフィカルコンテンツを格納することのできるVisualのことである。このVisualはいくつかの描画方法を公開する。DrawingVisualの子オブジェクトは、ゼロベースまたはｚオーダの空間で編成される。RetainedVisualとは、描画に使用できる「保持された命令ストリーム」を導入するVisualのことである。簡単に言うと、RetainedVisualは、開発者が映像のコンテンツを保持し、必要なときだけこれを再描画できるようにするものである。RetainedVisualはDrawingVisualと同様に、RenderOpenを呼び出すことおよび戻されたDrawingContextを描画に使用することによって、命令的に使用することができる。RetainedVisualは、妥当性検査コールバック機能およびInvalidateVisualメソッドを提供する。妥当性検査機能を使用するために、ユーザは、RetainedVisualまたはそれから導出されたクラスでIRetainedRenderインターフェースを実施する。
【０１１６】
図５に戻ると、さらに他の映像HwndVisual 505があり、これは従来のＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎ３２（登録商標）のコントロールまたはウィンドウを、シーングラフの映像シーン内で子映像としてホストするために使用される映像である。より具体的に言えば、依然として古いプログラムが、以前のグラフィックス技術に基づいて子HWnd（または同様のもの）を描画するWM_PAINTメソッド（または同様のもの）を介して動作することになる。こうしたプログラムを新しいグラフィックス処理モデルでサポートするために、HwndVisualはHwndがシーングラフ内に格納され、親映像の再配置に従って移動されるようにすることができる。２次元世界と３次元世界を接続することのできる３次元（３Ｄ）映像などの、他の型の映像も実現可能であり、たとえばカメラのようなビューが２次元映像を介して３次元世界にビューを入れることが可能である。
【０１１７】
図３に示されるように、映像マネージャ３０４は、映像ツリーを媒体に接続するオブジェクトを備える。映像マネージャは、映像データ構造（ルート映像３０２）とそのデータのレンダリング先である対象との間に保持された接続を確立し、その２つの相違点を追跡する機能を提供する。映像マネージャ３０４はウィンドウメッセージを受け取り、描画座標内の１つのポイントを装置座標に変形するための方法、およびその逆を提供する。
【０１１８】
典型的なアプリケーションは、前述のように（たとえば、特許文献４参照）「ＸＡＭＬ」でレイアウトを定義することによって、さらにまた何らかの描画オペレーションをＣ＃で指定することによって、グラフィックスを描画することができる。開発者は、Shape要素を作成するか、またはプリミティブを備えたGeometryクラスを使用して幾何学形状を描画することができる。以下のシナリオでは、コードはCanvasの下にあるVisualでの楕円の描画を実演する。
【０１１９】
【表２２】
【０１２０】
代わりに開発者は、映像ＡＰＩを使用してVisualに直接描画することができる（そうでなければLayout要素を介してアクセスされることになる）。
【０１２１】
DrawingVisualオブジェクトのコンテンツをレンダリングするために、通常、アプリケーションはDrawingVisualでRenderOpenメソッドを呼び出す。RenderOpenはDrawingContextを戻し、アプリケーションはこれを使用して描画オペレーションを実行することができる。Visualのコンテンツを消去する場合、アプリケーションはDrawingContextでCloseを呼び出す。アプリケーションがCloseを呼び出すと、その後DrawingContextは使用できなくなる。
【０１２２】
以下のコードは、楕円形状ではなくGeometryオブジェクトを使用して、DrawingVisualに楕円（前の例と同じ楕円）を描画するものである。この例では、DrawingVisualを作成し、DrawingVisualのDrawingContextを取得し、DrawingContextのDrawGeometryメソッドを呼び出して楕円を描画する。開発者は、この場合はウィンドウであるトップレベルオブジェクトの映像ツリーに、Visualを追加する必要があることに留意されたい。
【０１２３】
【表２３】
【０１２４】
以下の例は、同様の楕円をContainerVisualに追加することによって、前の例にさらに構築するものであり、この例はわかりやすくするために冗長であることに留意されたい。ContainerVisualを使用すると、シーンオブジェクトを編成する際に役立ち、開発者がヒットテストまたは妥当性検査（RetainedVisualオブジェクト）を実行するために、Visualオブジェクトを通常の描画コンテンツから分離し、コンテンツの不必要な再描画を最小限に抑えることができる。
【０１２５】
【表２４−１】
【０１２６】
【表２４−２】
【０１２７】
【表２４−３】
【０１２８】
RetainedVisualはDrawingVisualと似ているが、映像コンテンツの選択的な再描画が可能である。その名前が示唆するように、RetainedVisualはコンテンツを媒体上で複数出現させるために保持することができる。また、コールバックおよび妥当性検査機能も提供する。この機能は、コンテンツの再レンダリングを介して開発者により多くのコントロールを提供することで、レンダリングの実行を助けることができる。
【０１２９】
基本レベルでは、ユーザはRetainedVisualをDrawingVisualとほとんど同様に作成および使用することが可能であり、すなわちユーザはRenderOpenを呼び出してDrawingContextを取得することができる。別法として、ユーザはRetainedVisualでIRetainedRenderインターフェースを実施することができる。そのように実行することにより、ユーザは、グラフィックスシステムがRenderBoundsプロパティに設定された値をIRetainedVisual.Render呼出しでレンダリングされるコンテンツの境界として確実に使用できるようにする。
【０１３０】
シーンをレンダリングする場合、グラフィックスシステムは任意の子Visualを検査することになる。RenderBoundsプロパティの値が、シーンをレンダリングする際に特定のVisualのコンテンツが必要となることを示す場合、システムはIRetainedVisual.Renderを呼び出してVisualのコンテンツを塗りつぶし、すでにメモリ内にある任意のコンテンツを置き換えることになる。アプリケーションは、InvalidateVisualを呼び出して、Visualからコンテンツを直接フラッシュする（ｆｌｕｓｈ）こともできる。アプリケーションがRetainedVisualでIRetainedRenderを実施しなかった場合、InvalidateVisualへのいずれの呼出しも例外処理を実行することになる。
【０１３１】
以下のコードは、RetainedVisualでIRetainedRenderを実施し、それに描画するクラスをインスタンス化するものである。
【０１３２】
【表２５】
【０１３３】
映像ＡＰＩは、本発明のグラフィックスシステムの残りの部分と同様に管理されたＡＰＩであり、強力なタイピングおよびガーベッジ集合を含む管理されたコードの典型的な機能を使用する。また、レンダリングのためのハードウェア加速機能も利用する。既存の管理されていないアプリケーションを使用して作業を行う開発者に対処するために、映像ＡＰＩは、本グラフィックスシステムとＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）のＧｒａｐｈｉｃｓ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ（ＧＤＩ）ベースのレンダリングサービスとの間に限られた相互運用性を提供する。
【０１３４】
この相互運用性により、開発者は、本発明の描画およびレンダリングに基づいたHwnd Visualオブジェクト、書込み制御、およびテーマ化を使用して、映像認識アプリケーションでＧＤＩベースのウィンドウをホストするが、依然として古いＧＤＩアプリケーションで動作し、ハードウェア加速およびカラーモデルを含む新しいレンダリング機能を利用するようにＧＤＩ ＨＷＮＤベースのアプリケーションを修正することができる。
【０１３５】
HwndVisualは、Ｗｉｎ３２コンテンツを映像認識アプリケーションでホストできるようにするものである。図５に示されるように、HwndVisualはContainerVisualを継承する。ＧＤＩと新しい描画モデルとを同じHwndVisualで混合できないことに留意されたい。代わりに、この映像は、制限された範囲の古いコントロールにはより役立つ可能性がある。以下の例では、HwndVisualでコントロールを作成することおよびそれを映像ツリーに追加することを実演する。
【０１３６】
【表２６】
【０１３７】
他のオブジェクトの場合と同様に、開発者は、Visualでいったんホストされると変形および他のプロパティの変更をコントロールに適用することが可能である。
【０１３８】
【表２７】
【０１３９】
図３に示されるように、トップレベル（またはルート）のVisual３０２は映像マネージャオブジェクト３０４に接続され、これは（たとえばハンドルを介して）、ウィンドウ（Hwnd）３０６またはプログラムコード用にグラフィックデータが出力される同様の単位との関係も有する。映像マネージャ３０４は、トップレベルのVisual（およびそのVisualの任意の子）のそのウィンドウ３０６への描画を管理する。図６は、本明細書に記載されたグラフィックスシステムのオブジェクトモデルにおけるオブジェクトの集合６００のうちの１つとしての映像マネージャを示す図である。
【０１４０】
描画する際、映像マネージャ３０４は、前述の米国特許出願に全体として記載されたように、ディスパッチャ３０８がスケジュールしたようにシーングラフを処理（たとえば、トラバースまたは伝送）し、低いレベルのコンポーネント２１８（図２）へのグラフィックス命令および他のデータをその対応するウィンドウ３０６に提供する。シーングラフの処理は、通常、低いレベルのコンポーネント２１８および／またはグラフィックスサブシステム２２２のリフレッシュ速度よりも比較的遅い速度で、ディスパッチャ３０８によってスケジュールされることになる。
【０１４１】
図３は、トップレベル（ルート）Visual３０２の下に階層状に配置構成された、いくつかの子Visual３１０〜３１４を示す図であり、その一部は、たとえば命令リストおよび他のVisualを含む関連するそれぞれの命令リスト３１８および３１９と共に、（その一時的な性質を表すために破線の四角で示された）描画コンテキスト３１６、３１７を介して読み込まれたように表されている。Visualは他のプロパティ情報を含むこともできる。一般に、基本映像クラスでのほとんどのアクセスは、IVisualインターフェースを介して行われ、Visualは図５に示されるようにDependencyObjectから導出される。他の描画プリミティブの中で、命令リストはImageDataへの参照を含むことができる。その後、そのImageDataは、描画コンテキストをそれから取得することによって、またはSurfaceVisualRender（あるいはImageDataVisualRendererと名付けられた）を有することによって、直接変更／更新することができる。
【０１４２】
Visualは、クリップ、不透明度、ならびに、ゲットメソッドを介して設定および／または読み取ることのできる可能な他のプロパティを提供することによって、サービスを提供する。さらにVisualは、どのようにヒットテストに参加するかをコントロールするフラグを有する。Showプロパティを使用してVisualが表示／非表示となり、たとえばｆａｌｓｅの場合Visualは不可視であり、そうでない場合Visualは可視である。さらに、これらのオブジェクト（映像ＡＰＩレイヤのVisualかまたは要素レイヤの要素）は、階層状に存在する。座標系はこの階層を下に向かって継承される。この場合、親は、レンダリングする軌跡を修正してその親の子に適用させる座標変形を強要することができる。
【０１４３】
Visual用の変形は、そのVisualへの接続上にある。つまり、親のIVisualインターフェース上で[Get|Set]ChildTransformを介して設定される。
【０１４４】
座標変形は、あたかもビットマップに対して行なわれるかのように、一様な方法であらゆるものに適用可能であることに留意されたい。これは、変形は常にビットマップに適用されるが、レンダリングされるものが等しく変形の影響を受けることを意味するものでないことに留意されたい。例を挙げると、ユーザが１インチ（約２．５４ｃｍ）幅の丸いペンを使用して円を描画し、Ｘ方向にその円の２倍のスケールを適用した場合、ペンは左右は２インチ（約５．０８ｃｍ）幅、上下は１インチ（約２．５４ｃｍ）幅のみとなる。これは、時に（ジオメトリのみに影響を与えるスケルトンまたはジオメトリスケールとは対照的に）合成またはビットマップ変形と呼ばれることがある。図８に、非変形画像８００を左側に示し、非均一スケールの変形済み画像８０２を右側に表すスケーリング変形を示す。図９には、非変形画像８００を左側に示し、ジオメトリスケーリングの変形済み画像９０４を右側に示すスケーリング変形を示す。
【０１４５】
映像の座標変形に関して、TransformToDescendantはポイントを基準映像から下位映像へと変形する。ポイントは、基準映像の変形後座標空間から下位映像の変形後座標空間へと変形される。TransformFromDescendantは、ポイントを下位映像から親チェーンを上方に基準映像まで変形する。ポイントは、下位映像の変形後座標空間から基準映像の変形後座標空間へと変形される。ユーザは、下位へおよび下位から、ならびにいずれかの任意映像からおよび任意映像への、行列を取得することができる。Visualのコンテンツの境界ボックスを決定するために使用できる２つのプロパティ、すなわち下位の境界ボックスであるDescendantBounds、およびコンテンツの境界であるContentBoundsが使用可能である。これらにUnionを適用すると、全体の境界が与えられる。
【０１４６】
クリッププロパティは、Visualのクリッピング領域を設定（および取得）する。任意のGeometry（Geometryクラスは図１０に示されている）をクリッピング領域として使用することが可能であり、クリッピング領域は変形後座標空間で適用される。一実施態様では、クリッピング領域に関するデフォルト設定はｎｕｌｌ、すなわちクリッピングなしであり、これは無限大のクリッピング矩形（−∞，−∞）から（＋∞，＋∞）とみなすことができる。
【０１４７】
不透明度プロパティは、Visualのコンテンツが不透明度値および選択された混合モードに基づいて描画表面で混ぜ合わされるように、Visualの不透明度値を取得／設定する。BlendModeプロパティを使用して、使用される混合モードを設定（または取得）することができる。たとえば、不透明度（アルファ）値は０．０から０．１の間に設定し、線形アルファ混合を、たとえば、Color = alpha * foreground color + (1.0-alpha)*background color)のモードとして設定することができる。たとえば、ぼかし、モノクロなどの特殊効果プロパティなどの他のサービスを、Visualに含めることができる。
【０１４８】
（変形、不透明度、およびクリップを含む）様々なサービスを描画コンテンツ上でプッシュ（ｐｕｓｈ）およびポップ（ｐｏｐ）させることが可能であり、プッシュ／ポップオペレーションは、各プッシュ呼出しに対して適切なポップ呼出しがある限り、入れ子にすることができる。
【０１４９】
PushTransformメソッドは、変形をプッシュする。後続の描画オペレーションは、プッシュされた変形を基準にして実行される。ポップ呼出しは、以下のように、合致するPushTransform呼出しによってプッシュされた変形をポップする。
【０１５０】
【表２８】
【０１５１】
同様に、PushOpacityメソッドは、不透明度値をプッシュする。後続の描画オペレーションは、指定された不透明度値を使用して一時表面上でレンダリングされ、シーンに合成される。Pop( )は、以下のように、合致するPushOpacity呼出しによってプッシュされた不透明度をポップする。
【０１５２】
【表２９】
【０１５３】
PushClipメソッドは、クリッピングジオメトリをプッシュする。後続の描画オペレーションはジオメトリにクリップされる。クリッピングは、変形後空間に適用される。Pop( )は、以下のように、合致するPushClip呼出しによってプッシュされたクリッピング領域をポップする。
【０１５４】
【表３０】
【０１５５】
プッシュオペレーションは、ポップオペレーションがプッシュと合致する限り、任意に入れ子にできることに留意されたい。たとえば、以下は有効である。
【０１５６】
【表３１】
【０１５７】
ProxyVisualは、シーングラフ、たとえばContainer Visualの下に、複数回追加することのできるVisualである。ProxyVisualによって参照される任意のVisualには、ルートからの複数のパスを通すことが可能であるため、読取りサービス（TransformToDescendent、TransformFromDescendent、およびHitTest）はProxyVisualを介して動作しない。実際のところ、任意のVisualから映像ツリーのルートへの標準パスが１つあり、そのパスはいずれのProxyVisualも含まない。
【０１５８】
図４に、ContainerVisualおよびDrawingVisual（およびその他）がシーングラフ内で関連しており、（たとえば対応する描画コンテキスト内に）命令リストの形の関連するデータを有するシーングラフ４００の一例を示す。ContainerVisualはVisual用のコンテナであり、ContainerVisualは互いに入れ子にすることができる。ContainerVisualの子は、ContainerVisualを実施するIVisualインターフェース上のメソッドを介して操作することができる。VisualCollection内のVisualの順序が、Visualがレンダリングされる順番を決定するものであり、すなわち、Visualは最下位のインデックスから最高位のインデックスへと、後ろから前へレンダリングされる（ペインティング順序）。
【０１５９】
前述のように、Visualは、Geometry、ImageSource、およびMediaDataを含む様々な描画プリミティブと共に、その描画コンテキストを読み込むことによって描画することができる。さらに、このスタック全体を通じて共用されるリソースおよびクラスの集合がある。これには、Pen、Brush、Geometry、Transform、およびEffectが含まれる。DrawingContext抽象クラスは、DrawingVisual、ValidationVisual、ImageDataなどを読み込むために使用できる描画オペレーションの集合を公開する。言い換えれば、DrawingContext抽象クラスは描画オペレーションの集合を公開し、各描画オペレーションについて、定数を引数として取る方法とアニメータを引数として取る方法の２つがある。
【０１６０】
Geometryは、ストロークまたは塗りつぶしなしでベクトルグラフィックススケルトンを定義するクラスの一種である（図１０）。各Geometryオブジェクトは単純な形状（LineGeometry、EllipseGeometry、RectangleGeometry）、複雑な単一形状（PathGeometry）、または組合せオペレーション（たとえば合併、交差など）が指定されたこうした形状のリストGeometryCollectionである。これらのオブジェクトは、図１０に示されるようなクラス階層を形成する。
【０１６１】
図１１に示すように、PathGeometryは、Figureオブジェクトの集合である。ここでは、それぞれのFigureオブジェクトが、実際に図の形状を定義する１つまたは複数のSegmentオブジェクトからなる。Figureとは、セグメント集合を定義するGeometryのサブセクションである。このセグメント集合は、単一の関連した一連の２次元Segmentオブジェクトシリーズである。Figureは、領域が定義されたクローズ形状、または曲線は定義するが領域はクローズでない接続された一連のSegmentのみの、いずれかが可能である。
【０１６２】
図１２に示されるように、ジオメトリ（たとえば矩形）を描画する場合、以下で説明するようにブラシまたはペンを指定することができる。さらに、PenオブジェクトはBrushオブジェクトも有する。Brushオブジェクトはグラフィックで平面を塗りつぶす方法を定義するものであり、クラス階層のBrushオブジェクトがある。これを図１２に、矩形およびブラシの命令およびパラメータを含む映像が処理されると、結果として生じる塗りつぶされた矩形１２０２として示す。Penオブジェクトは、以下で説明するように、BrushならびにWidth、LineJoin、LineCap、MiterLimit、DashArray、およびDashOffsetに関するプロパティ上で保持される。さらに以下で説明するように、（勾配および９グリッドなどの）Brush型の中には、それ自体でサイズを決めるものもある。これらのBrushが使用される場合、そのサイズは境界ボックスから取得される。たとえば、Brush用のGradientUnits／DestinationUnitsがRelativeToBoundingBoxに設定されている場合、描画されているプリミティブの境界ボックスが使用される。これらのプロパティがAbsoluteに設定された場合、座標空間が使用される。
【０１６３】
本発明のグラフィックスオブジェクトモデルには、Brushオブジェクトモデルが含まれ、これは一般に平面をピクセルでカバーするという概念を対象としている。Brush型の例は、図１３でBrush基本クラスの下に階層状に示されており、GradientBrush、NineGridBrush、SolidColorBrush、およびTileBrushが含まれる。GradientBrushには、LinearGradientおよびRadialGradientのオブジェクトが含まれる。DrawingBrushおよびImageBrushはTileBrushから導出される。クラスの代替の配置構成が実現可能であり、たとえばTileBrushからImageBrush、VisualBrush、VideoBrush、NineGridBrush、およびDrawingBrushを導出することができる。Brushオブジェクトは、それらが使用される場合に座標系にどのように関係するか、および／またはそれらが使用される形状の境界ボックスにそれらがどのように関係するかを認識できることに留意されたい。一般に、サイズなどの情報は、ブラシが描画されるオブジェクトから推測することができる。より詳細には、Brush型の多くがそれらのパラメータの一部を指定する際に座標系を使用する。この座標系は、Brushが適用される形状の単純な境界ボックスを基準に定義するか、またはブラシが使用される時点でアクティブな座標空間を基準に定義することが可能である。これらはそれぞれ、RelativeToBoundingBoxモードおよびAbsoluteモードとして知られている。
【０１６４】
SolidColorBrushオブジェクトは、識別された平面をソリッドカラーで塗りつぶす。色のアルファコンポーネントがある場合、これは、倍加する方法でBrush基本クラスの対応する不透明度属性と組み合わされる。以下に、SolidColorBrushオブジェクトの例を示す。
【０１６５】
【表３２】
【０１６６】
GradientBrushオブジェクトまたは単にGradientは勾配塗りつぶしを行い、何らかの進行に沿って色を指定する勾配停止の集合を指定することによって描画されるものである。Gradientは、ガンマ２．２ＲＧＢ色空間で勾配停止間の線形補間を実行することによって描画されるが、代わりに他のガンマまたは他の色空間（ＨＳＢ、ＣＭＹＫなど）を介した補間を実行することもできる。この２つの型のGradientオブジェクトには、線形勾配および放射勾配が含まれる。
【０１６７】
一般に、Gradientは勾配停止のリストからなる。これらの勾配停止は、それぞれ色（アルファ値が含まれる）およびオフセットを含む。指定された勾配停止がない場合、ブラシは、あたかもブラシがまったく指定されていないかのように濃淡のない透明な黒として描画される。勾配停止が１つだけ指定された場合、ブラシは１色だけ指定されたソリッドカラーとして描画される。「Ｃｈａｎｇｅａｂｌｅ Ｃｌａｓｓ ａｎｄ Ｐａｔｔｅｒｎ ｔｏ Ｐｒｏｖｉｄｅ Ｓｅｌｅｃｔｉｖｅ Ｍｕｔａｂｉｌｉｔｙ ｉｎ Ｃｏｍｐｕｔｅｒ Ｐｒｏｇｒａｍｍｉｎｇ Ｅｎｖｉｒｏｎｍｅｎｔｓ」という名称の米国特許出願に記載されているように、勾配停止クラス（下記の表の例）は他のリソースクラスと同様に変更可能クラスから導出されるため、選択的に可変である。
【０１６８】
Gradientは勾配停止の集合を指定することによって描画される。これらの勾配停止は、何らかの連続した色を指定する。現在サポートされている勾配には２つの型、すなわち線形勾配および放射勾配がある。Gradientは、指定された色空間内の勾配停止間で補間を実行することによって描画される。
【０１６９】
Gradientは、勾配停止のリストからなる。これらの勾配停止はそれぞれ、色（アルファ値が含まれる）およびオフセットを含む。指定された勾配停止がない場合、ブラシは（あたかもブラシがまったく指定されていないかのように）透明として描画される。勾配停止が１つだけ指定された場合、ブラシは１色だけ指定されたソリッドカラーとして描画される。０から１の範囲内（０．０．．．１．０）のオフセットを備えた任意の勾配停止が考慮の対象とされ、最大の停止は（−∞．．．０．０］、最小の停止は［１．０．．．＋∞）である。考慮の対象とされる停止の集合に０から１の範囲外にある停止が含まれる場合、暗黙の停止として０（および／または１）が導出され、これがこの停止で発生することになる補間された色を表す。さらに、２つまたはそれ以上の停止が同じオフセットで設定される場合、そのオフセットで（補間済みでない）ハード遷移が発生する。停止が追加される順序によって、このオフセットでの挙動が決められ、追加される最初の停止はそのオフセットの前の有効な色であり、設定される最後の停止はこの停止の後の有効な色であり、このオフセットでのいずれの追加の停止も無視される。
【０１７０】
このクラスは、他のリソースクラスと同様にChangeableである。
【０１７１】
【表３３】
【０１７２】
SolidColorBrushと同様に、これはChangeablesをアニメーション集合内に入れ子にする。
【０１７３】
GradientSpreadMethod 列挙法は、指定されたベクトルまたは空間の外で勾配がどのように描画されるべきかを指定する。可能な値には、末端（最初および最後）の色を使用して残りの空間が塗りつぶされるPadと、停止を逆の順序で繰り返し再生して空間が塗りつぶされるReflectと、停止を順番に繰り返して空間が塗りつぶされるRepeatの、３つの値が含まれる。この型のプロパティのデフォルト値はPadである。
【０１７４】
【表３４】
【０１７５】
図１４および１５は、いくつかのGradientSpreadMethodの例（たとえ色でなくグレースケールの場合であっても）を提供する。各形状が、白からグレーに移行する線形勾配を有する。実線が勾配ベクトルを表す。
【０１７６】
一般に、LinearGradientBrushを使用して領域を線形勾配で塗りつぶす。線形勾配とは、線分に沿って勾配を定義するものである。線形勾配のStartPointおよびEndPointプロパティによって、線分の末端が定義される。デフォルト時には、線形勾配のStartPointは（０，０）であって領域の左上コーナが塗りつぶされ、そのEndPointは（１，１）であって領域の右下コーナが塗りつぶされる。図１５に示されるように、デフォルトの値を使用すると、結果として生じる勾配の色は斜めの軌跡に沿って補間される。本明細書では、勾配の補間軌跡をハイライト表示するために、勾配の始点および終点から形成された黒い線分が追加されている。
【０１７７】
ColorInterpolationMode列挙法は、勾配内の色に対して補間モードを定義する。PhysicallyLinearGamma10およびPerceptuallyLinearGamma22の２つのオプションがある。
【０１７８】
【表３５】
【０１７９】
これは抽象基本クラスである。
【０１８０】
【表３６】
【０１８１】
Changeablesの項で説明したように、GradientBrushはそのGradientStopsプロパティそれ自体がChangeablesを保持するので、Changeablesに関して複合型である。これは、GradientBrushが、保護されたメソッドMakeUnchangeableCore( )とPropagateEventHandler( )、ならびにChangeableサブクラスが実施するCloneCore( )とを実施する必要があることを意味する。たとえば集合を構成するGradientStopsの無効な組合せがある場合、ValidateObjectState( )を実施するように選択することもできる。
【０１８２】
LinearGradientは、ベクトルに沿って線形勾配ブラシを指定する。個々の停止は、そのベクトルに沿ってカラーストップを指定する。
【０１８３】
【表３７−１】
【０１８４】
【表３７−２】
【０１８５】
LinearGradient用のマークアップは、０および１のオフセットで２つのカラーストップを使用してLinearGradientを指定することが可能である。「LinearGradient」バージョンが使用される場合、それぞれ始点および終点が指定される。「HorizontalGradient」が使用される場合、始点は０，０に設定され、終点は１，０に設定される。「VerticalGradient」が使用される場合、始点は０，０に設定され、終点は０，１に設定される。これらの場合、RelativeToBoundingBoxというデフォルトのMappingModeが使用される。
【０１８６】
RadialGradientは、プログラミングモデルでは線形勾配と同様である。しかし、線形勾配は勾配ベクトルを定義するための始点および終点を有するのに対して、放射勾配は勾配の挙動を定義するための円ならびに焦点を有する。円は勾配の終点を定義しており、言い換えれば、１．０の勾配停止は円の周囲の色を定義する。焦点は勾配の中心を定義する。０．０の勾配停止は焦点の色を定義する。図１６は、白からグレーへと（グレースケールで）進むRadialGradientを表す。外側の円は勾配円を表し、中実のドットは焦点を示す。この勾配は、SpreadMethodがPadに設定されている。
【０１８７】
【表３８−１】
【０１８８】
【表３８−２】
【０１８９】
RadialGradient用のマークアップは、それぞれ０および１のオフセットで２つのカラーストップを使用してRadialGradientを指定することが可能である。デフォルトの半径が０．５である場合、RelativeToBoundingBoxというデフォルトのMappingModeが使用される。
【０１９０】
【表３９】
【０１９１】
TileBrushは、タイルを記述する論理とタイルが領域を塗りつぶす際に使用する手段とを含む抽象基本クラスである。TileBrushのサブクラスはコンテンツを含み、無限の平面を塗りつぶす方法を論理的に定義する。
【０１９２】
Stretch列挙法を使用して、ViewBox（ソース座標空間）をViewPort（宛先座標空間）にマッピングする方法を記述する。これはTileBrushで使用される。
【０１９３】
【表４０】
【０１９４】
図１８に、引伸ばし（ｓｔｒｅｔｃｈ）の例を示す。これらの例では、コンテンツは左／上に位置合わせをされる。
【０１９５】
TileMode列挙法を使用して、Tileで空間を塗りつぶすのか、およびどの様に塗りつぶすのかを記述する。TileBrushは、基本Tileが（ViewPortによって指定される）場所を定義する。残りの空間はTileMode値に基づいて塗りつぶされる。
【０１９６】
【表４１】
【０１９７】
図１９は、TileModeの例を提供する。各例の一番左上のタイルが基本タイルである。これらの例は、None、Tile、FlipX、FlipY、およびFlipXYを表す。
【０１９８】
VerticalAlignment列挙法を使用して、コンテナ内でコンテンツを垂直に配置する方法を記述する。
【０１９９】
【表４２】
【０２００】
HorizontalAlignment列挙法を使用して、コンテナ内でコンテンツを水平に配置する方法を記述する。
【０２０１】
【表４３】
【０２０２】
TileBrushプロパティは、タイル（ViewBox）となる無限の平面の矩形部分を選択し、塗りつぶされる領域内の基本タイルとなる宛先矩形（ViewPort）を記述する。残っている宛先領域は、TileModeプロパティに基づいて塗りつぶされることになり、これが残っている空間を塗りつぶすためにオリジナルタイルが複製されるのか、およびどの様に複製されるのかを制御する。
【０２０３】
【表４４−１】
【０２０４】
【表４４−２】
【０２０５】
TileBrushのコンテンツには固有の境界がなく、無限の平面を効果的に記述する。これらのコンテンツは、それ自身の座標空間内に存在し、TileBrushによって塗りつぶされている空間は適用時のローカル座標空間である。コンテンツ空間は、ViewBox、ViewPort、Alignment、およびStretchのプロパティに基づいてローカル空間にマッピングされる。ViewBoxはコンテンツ空間内に指定され、この矩形はViewPort矩形にマッピングされる。
【０２０６】
ViewPortは、コンテンツが最終的に描画される場所を定義し、このBrush用の基本タイルを作成する。ViewPortUnitsの値がAbsoluteである場合、ViewPortの値は適用時にローカル空間内にあるものとみなされる。代わりに、ViewPortUnitsの値がRelativeToBoundingBoxである場合、ViewPortの値は座標空間内にあるものとみなされ、０，０はペイントされているオブジェクトの境界ボックスの左／上コーナであり、１，１は同じボックスの右／下コーナである。たとえば、１００，１００から２００，２００まで描画されたRectangleGeometryが塗りつぶされていると考えてみる。次に、ViewPortUnitsがAbsoluteである場合、ViewPort（１００，１００，１００，１００）がコンテンツ領域全体を記述することになる。ViewPortUnitsがRelativeToBoundingBoxである場合、ViewPort（０，０，１，１）がコンテンツ領域全体を記述することになる。ViewPortのSizeが空であり、StretchがNoneでない場合、このBrushは何もレンダリングしない。
【０２０７】
ViewBoxは、コンテンツ空間内に指定される。この矩形は、AlignmentプロパティおよびStretchプロパティによって決定されたViewPort内に収まるように変形される。Stretchがnoneの場合、コンテンツには何の縮尺も適用されない。StretchがFillの場合、ViewBoxはViewPortと同じサイズになるようにXおよびYの両方で別個に縮尺される。StretchがUniformまたはUniformToFillの場合、論理は同じであるが、XおよびYの寸法は均一に縮尺され、コンテンツのアスペクト比を保持する。StretchがUniformの場合、ViewBoxは、ViewPortのサイズに等しい、より多くの制約付き寸法を有するように縮尺される。StretchがUniformToFillの場合、ViewBoxはViewPortのサイズに等しい、より少ない制約付き寸法を有するように縮尺される。別の見方をすると、UniformとUniformToFillはどちらもアスペクト比を保持するが、UniformはViewBox全体がViewPort内にあることを保証し（場合によっては、ViewPortの一部がViewBoxによって覆われない状態で残る）、UniformToFillはViewPort全体がViewBoxによって塗りつぶされることを保証する（場合によっては、ViewBoxの一部がViewPortの外にはみ出る）。ViewBoxの領域が空の場合、Stretchは適用されない。それでも位置合わせは発生することになり、「ポイント」ViewBoxを位置付けることになる。
【０２０８】
いったんViewPortが（ViewPortUnitsに基づいて）決定され、ViewBoxの宛先サイズが（Stretchに基づいて）決定されると、ViewBoxをViewPort内に位置付ける必要がある。ViewBoxがViewPortと同じサイズの場合（StretchがFillの場合、または他の３つのStretch値のうちの１つに偶然に生じただけの場合）、ViewBoxはViewPortと同じになるようにOriginに位置付けられる。そうでない場合、HorizontalAlignmentおよびVerticalAlignmentが考慮の対象となる。これらのプロパティに基づいて、ViewBoxにＸおよびＹの両方の寸法で位置合わせを行う。HorizontalAlignmentがLeftの場合、ViewBoxの枠の左側がViewPortの枠の左側に位置付けられることになる。これがCenterの場合、ViewBoxの中心がViewPortの中心に位置付けられることになり、Rightの場合、枠の右側が合致することになる。Ｙ寸法についてもこのプロセスが繰り返される。
【０２０９】
ViewBoxがEmptyの場合は、未設定とみなされる。未設定の場合、ContentUnitsが考慮の対象となる。ContentUnitsがAbsoluteの場合、縮尺またはオフセットは発生せず、コンテンツは変形なしでViewPortに描画される。ContentUnitsがRelativeToBoundingBoxの場合、コンテンツの起点とViewPort Originとの位置合わせを行い、コンテンツはオブジェクトの境界ボックスの幅および高さによって縮尺される。
【０２１０】
空間がTileBrushで塗りつぶされる場合、コンテンツは上記のようにViewPortにマッピングされ、ViewPortにクリッピングされる。これによって塗りつぶし用の基本タイルが形成され、残りの空間のはBrushのTileModeに基づいて塗りつぶされる。設定が行われている場合、Brushの変形が適用されるが、これは他のマッピング、縮尺、オフセットなどの後に行われる。
【０２１１】
VisualBrushとは、Visualによってコンテンツが指定されるTileBrushである。このBrushを使用して複雑なパターンを作成でき、またはこれを使用してシーンの他の部分のコンテンツの追加のコピーを描画することができる。
【０２１２】
【表４５】
【０２１３】
ImageBrushは、ImageDataによって指定されたコンテンツを有するTileBrushである。このBrushを使用して空間をImageで塗りつぶすことができる。
【０２１４】
【表４６】
【０２１５】
VideoBrushは、VideoDataによって指定されたコンテンツを有するTileBrushである。このBrushを使用して空間をVideoで塗りつぶすことができる。
【０２１６】
【表４７】
【０２１７】
NineGridBrushは、オブジェクトの境界ボックスを常にそのコンテンツ画像で塗りつぶすブラシであり、画像の引伸ばしは映像スケールを介してのみ実施されるものではない。Imageソースは４本の境界によって９つの矩形に分けられる（したがってNineGridと名付けられる）。これら９つの領域のそれぞれに存在する画像のコンテンツは、オブジェクト境界ボックスを塗りつぶすまで０、１、または２の寸法で縮尺される。各セクションが縮尺される寸法を図で見ることが可能であって、図１７はNineGridの概念を表すものであり、第１のインスタンス１７０２から第２のインスタンス１７０４に拡大され、Top、Left、Bottom、およびRightの境界によって定義される９つのグリッドを示す４つの型がある。各グリッドスクエア内の矢印は、それらのコンテンツがViewPortサイズに合致するように引伸ばされる寸法を示している。
【０２１８】
上記の９つのグリッド領域に加えて、オプションの「１０番目」のグリッドがある。これは、ViewPortの中心に位置する縮尺されない追加の画像の形を取る。これを使用して、ボタンなどの中心に形状を配置することができる。この「１０番目のグリッド」はグリフと呼ばれ、GlyphImageDataプロパティによって公開される。
【０２１９】
【表４８−１】
【０２２０】
【表４８−２】
【０２２１】
境界のメンバは、画像の枠から画像ピクセル単位でカウントに入れることに留意されたい。
【０２２２】
Penは、空間／Geometryをストロークで描く方法を記述したBrushおよび他のパラメータを取るオブジェクトである。概念上、PenはGeometryからストローク領域を作成する方法を記述する。Geometryの枠、PenのThickness、PenLineJoin、PenLineCap、などに基づいて新しい領域が作成される。いったんこの領域が作成されると、Brushで塗りつぶされる。
【０２２３】
【表４９−１】
【０２２４】
【表４９−２】
【０２２５】
PenLineCapは、ストローク線分の端部を描画する方法を決定する。
【０２２６】
【表５０】
【０２２７】
PenDashCapは、破線状のストローク線分における各ダッシュの端部を描画する方法を決定する。
【０２２８】
【表５１】
【０２２９】
PenLineJoinは、線分をストロークで描く際にジョイントを描画する方法を決定する。
【０２３０】
【表５２】
【０２３１】
DashArraysクラスは、一般的なよく知られた破線スタイルにアクセスする静的プロパティを備える。
【０２３２】
【表５３】
【０２３３】
図１３に示された他のBrushオブジェクトがVisualBrushオブジェクトである。VisualBrushとは、Visualによってコンテンツが指定されるTileBrushである。このBrushを使用して複雑なパターンを作成するか、またはこれを使用してシーンの他の部分のコンテンツの追加コピーを描画することができる。
【０２３４】
【表５４】
【０２３５】
概念上、VisualBrushは、塗りつぶしとして繰り返されるタイル様式でVisualを描画する方法を提供する。これは、図１２では、単一の円形状１２２０を指定するVisual（および任意の子Visual）を参照する映像ブラシによって表され、その円形状が矩形１２２２を塗りつぶしている。したがってVisualBrushオブジェクトは、そのブラシが描画されることになる方法を定義するためにVisualを参照することが可能であり、これは一種のVisualの複数使用を導入することになる。この方法では、プログラムは任意のグラフィックス「メタファイル」を使用して、ブラシまたはペンを介して領域を塗りつぶすことができる。これは任意のグラフィックスを格納および使用するための圧縮された形式であるため、グラフィックスリソースを提供する。
【０２３６】
一実施態様では、VisualBrushのコンテンツには固有の境界がなく、無限の平面を効果的に記述する。これらのコンテンツはそれら自体の座標空間内に存在し、VisualBrushが塗りつぶしている空間が適用時のローカル座標空間である。コンテンツ空間は、ViewBox、ViewPort、Alignments、およびStretchのプロパティに基づいてローカル空間にマッピングされる。ViewBoxはコンテンツ空間内に指定され、この矩形がViewPort（OriginおよびSizeプロパティを介して指定されたように）矩形にマッピングされる。
【０２３７】
ViewPortは、コンテンツが最終的に描画されることになる場所を定義し、このブラシ用の基本タイルを作成する。DestinationUnitsの値がUserSpaceOnUseである場合、OriginおよびSizeプロパティは適用時にローカル空間にあるものとみなされる。その代わりにDestinationUnitsの値がObjectBoundingBoxである場合、OriginおよびSizeは座標空間にあるものとみなされ、０，０はブラシ処理されているオブジェクトの境界ボックスの左／上コーナであり、１，１は同じボックスの右／下コーナである。たとえば、１００，１００から２００，２００まで描画されたRectangleGeometryを塗りつぶしていると考えてみる。こうした例では、DestinationUnitsがUserSpaceOnUseである場合、１００，１００のOriginおよび１００，１００のSizeがコンテンツ領域全体を記述することになる。DestinationUnitsがObjectBoundingBoxである場合、０，０のOriginおよび１，１のSizeがコンテンツ領域全体を記述することになる。Sizeが空の場合、このブラシは何もレンダリングしない。
【０２３８】
ViewBoxはコンテンツ空間内に指定される。この矩形が、AlignmentプロパティおよびStretchプロパティによって決められたViewPort内に収まるように変形される。Stretchがnoneの場合、コンテンツには縮尺が適用されない。StretchがFillの場合、ViewBoxはViewPortと同じサイズになるようにＸおよびＹで別々に縮尺される。StretchがUniformまたはUniformToFillの場合、論理は同様であるが、ＸおよびＹの寸法が均一に縮尺されてコンテンツのアスペクト比が保持される。StretchがUniformの場合、ViewBoxは、ViewPortのサイズに等しい、より多くの制約付き寸法を有するように縮尺される。StretchがUniformToFillの場合、ViewBoxは、ViewPortのサイズに等しい、より少ない制約付き寸法を有するように縮尺される。言い換えれば、UniformおよびUniformToFillはどちらもアスペクト比を保持するが、UniformはViewBox全体がViewPort内にあることを保証し（場合によっては、ViewPortの一部がViewBoxによって覆われていない状態で残り）、UniformToFillはViewPort全体がViewBoxによって塗りつぶされることを保証する（場合によっては、ViewBoxの一部がViewPortの外にはみ出る）。ViewBoxが空の場合、Stretchは適用されない。それでも位置合わせは発生することになり、「ポイント」ViewBoxを位置付けることになることに留意されたい。
【０２３９】
図１８は、様々な引伸ばし設定でレンダリングされたグラフィックスの単一タイル１８００を示す図であり、引伸ばしが「none」に設定されたときのタイル１８００が含まれている。タイル１８０２は引伸ばしが「Uniform」に設定された場合、タイル１８０４は引伸ばしが「UniformToFill」に設定された場合、およびタイル１８０６は引伸ばしが「Fill」に設定された場合を表す。
【０２４０】
いったんViewPortが（DestinationUnitsに基づいて）決定され、ViewBoxのサイズが（Stretchに基づいて）決定されると、ViewBoxをViewPort内に位置付ける必要がある。ViewBoxがViewPortと同じサイズの場合（StretchがFillであるか、または他の３つのStretch値のうちの１つに偶然に生じただけの場合）、ViewBoxはViewPortと同じになるようにOriginに位置付けられる。そうでない場合、HorizontalAlignmentおよびVerticalAlignmentが考慮の対象となる。これらのプロパティに基づいて、ViewBoxにＸおよびＹの両方の寸法で位置合わせを行う。HorizontalAlignmentがLeftの場合、ViewBoxの枠の左側がViewPortの枠の左側に位置付けられることになる。これがCenterの場合、ViewBoxの中心がViewPortの中心に位置付けられることになり、Rightの場合、枠の右側が合致することになる。Ｙ寸法についてもこのプロセスが繰り返される。
【０２４１】
ViewBoxが（０，０，０，０）の場合は未設定とみなされ、これによってContentUnitsが考慮の対象となる。ContentUnitsがUserSpaceOnUseの場合、縮尺またはオフセットは発生せず、コンテンツは変形なしにViewPortに描画される。ContentUnitsがObjectBoundingBoxの場合、コンテンツの起点がViewPort Originと位置合わせされ、コンテンツはオブジェクトの境界ボックスの幅および高さによって縮尺される。
【０２４２】
空間をVisualBrushで塗りつぶす場合、コンテンツは上記のようにViewPortにマッピングされ、ViewPortにクリッピングされる。これによって塗りつぶし用の基本タイルが形成され、BrushのTileModeに基づいて残りの空間が塗りつぶされる。最後に、Brushの変形が設定されていればこれが適用されるが、これは他のすべてのマッピング、縮尺、オフセットなどの後に実行される。
【０２４３】
TileMode列挙法を使用して、空間がそのBrushによって塗りつぶされるかどうか、およびその方法を記述する。タイル処理が可能なBrushにはタイル矩形が定義されており、このタイルは塗りつぶされる空間内に基本位置を有する。残りの空間はTileMode値に基づいて塗りつぶされる。図１９は、様々なTileMode設定のグラフィックス例を示した図であり、「None」１９００、「Tile」１０９２、「FlipX」１９０４、「FlipY」１９０６、および「FlipXY」１９０８が含まれる。様々なグラフィックス例の中の一番左上のタイルが基本タイルを備えるものである。
【０２４４】
図２０は、VisualBrush内のタイル用に定義されたVisualBrushグリッドを表す図である。第１の円は単純なグリッドであり、第２の円はＸ方向に４７のSkewで変形されたものである。図２１はこれを画像で塗りつぶした図である。
【０２４５】
図１３に戻ると、タイルブラシから画像ブラシが導出され、タイル処理することができる。NineGridBrushは、画像がサイズに基づいて歪められることを除いて、ImageBrushと非常によく似ている。本質的には、NineGridBrushはStretchのカスタム型と考えられ、画像の一定部分は引伸ばされるが、他の部分（たとえば境界）は引伸ばされない。したがって、ImageBrushでは画像のサイズは単純な縮尺を実行し、NineGridBrushは所望のサイズまで不均一な縮尺を実行することになる。ブラシが適用される場合、縮尺されない領域に対する単位はユーザ単位であり、これはContentUnits（NineGridBrush用に存在する場合）がUserUnitsOnUseに設定されることになることを意味する。BrushのTransformプロパティを有効に使用することができる。境界のメンバは、画像の枠からカウントに入れることに留意されたい。
【０２４６】
上記で概説したように、本発明のグラフィックスオブジェクトモデルにはTransformオブジェクトモデルが含まれ、これは図７の階層でTransform基本クラスの下に表された変形の型を含むものである。変形を構成するこれらの異なる型のコンポーネントは、TransformList、TranslateTransform、RotateTransform、ScaleTransform、SkewTransform、およびMatrixTransformを含むことができる。個々のプロパティをアニメーション処理することが可能であり、たとえばプログラム開発者はRotateTransformのAngleプロパティをアニメーション処理することができる。
【０２４７】
２Ｄ計算用の行列が３×３行列として表される。変形が必要な場合、３×３行列すべてではなく６つの値のみが必要とされる。これらは以下のように命名され、および定義される。
【０２４８】
【表５５】
【０２４９】
行列とポイントを掛け合わせると、そのポイントが新しい座標系から前の座標系に変形される。
【０２５０】
【表５６】
【０２５１】
変形は何重にも入れ子にすることができる。新しい変形が適用される場合は必ず、現在の変形行列に後から掛け合わせたものと同じになる。
【０２５２】
【表５７】
【０２５３】
ＡＰＩ内のほとんどの場所は直接行列を取らないが、代わりにアニメーションをサポートするTransformクラスを使用する。
【０２５４】
【表５８−１】
【０２５５】
【表５８−２】
【０２５６】
【表５８−３】
【０２５７】
（ベクトルグラフィックス用のマークアップ言語およびオブジェクトモデル）
本発明の一態様によれば、ＡＰＩレイヤ２１２（図２）の詳細に関する特定の知識を必要とすることなく、ユーザプログラムおよびツールがシーングラフデータ構造２１６と対話できるようにするために、マークアップ言語および要素オブジェクトモデルが提供される。一般に、交換フォーマット、ならびに要素オブジェクトモデルを介してベクトルグラフィックスを表現するための単純なマークアップベースのオーサリングフォーマットを備えた、ベクトルグラフィックスマークアップ言語が提供される。この言語を介して、マークアップ（たとえばＨＴＭＬまたはＸＭＬ型のコンテンツ）をプログラムすることができる。そこで、シーングラフを構築するため、前記で説明したように、マークアップは解析され、適切な映像ＡＰＩレイヤオブジェクトに変換される。この高位のオペレーティングレベルで、かなりの複雑さを処理するために要素ツリー、プロパティシステム、およびレイアウトシステムが提供され、シーン設計者が複雑なシーンを簡単に設計できるようになっている。
【０２５８】
一般に、ベクトルグラフィックスシステムは、形状および他の要素の集合、一般的なプロパティシステムとの統合、グループ化および複合化システム、ならびに、ユーザが柔軟性および性能のニーズに合致する方法でプログラミング可能なような２層（要素レベルおよびリソースレベル）方式を提供する。ベクトルグラフィックスを処理するための要素オブジェクトモデルは、本発明の一態様を維持しながら、シーングラフオブジェクトモデルと相関関係にある。つまり、ベクトルグラフィックスシステムおよび映像ＡＰＩレイヤは、要素オブジェクトモデルレベルでリソースの集合を共用するものであり、たとえば、映像ＡＰＩで描画する際にはBrushオブジェクトが使用され、これはShapeでのFillプロパティ型でもある。したがってマークアップ言語は、シーングラフオブジェクトと相関する要素を有することに加えて、いくつかのプリミティブリソース（たとえばブラシ、変形など）を映像ＡＰＩレイヤと共用する。さらにベクトルグラフィックスシステムは、レベル間で幅広く共用される映像ＡＰＩレイヤのアニメーション機能も公開し、および拡張する。
【０２５９】
さらに以下で説明するように、ベクトルグラフィックスシステムは、要素レベルおよびリソースレベルを含む異なるプロファイルまたはレベルでプログラミングすることができる。要素レベルでは、それぞれの描画形状が、ページ／スクリーン内の残りのプログラム可能な要素と同じレベルの要素として表される。これは、形状が、レイアウトシステム、イベント、およびプロパティとフル方式で対話することを意味する。リソースレベルでは、ベクトルグラフィックスシステムは従来のグラフィックスメタファイルと同様に純粋なリソースフォーマットで動作する。リソースレベルは効率的であるが、カスケードプロパティ、イベンティング、および微細なプログラミングについてのサポートは限定的である。したがってシーン設計者は、必要に応じて効率性とプログラム可能性との釣り合いを取ることができる。
【０２６０】
リソースレベルのベクトルグラフィックスシステムは、本発明の一態様を維持しながら、一実施態様においてリソースレベルマークアップがVisualBrushとして表されるという点で、映像ＡＰＩレイヤとも相関関係にある。リソースマークアップが解析される際に、映像オブジェクトが作成される。映像オブジェクトは、形状、コントロール、および他の要素が要素レベルで使用可能なVisualBrushに設定される。
【０２６１】
図２２は、要素クラスの階層２２００を示す図である。本発明のマークアップ言語オブジェクトモデルのクラスは影付きボックスで表され、形状クラス２５０２、画像クラス２５０４、ビデオクラス２２０６、およびキャンバスクラス２２０８が含まれる。形状クラスの要素には、矩形２２１０、線分群２２１２、多角形２２１４、軌跡２２１６、線分２２１８、および楕円２２２０が含まれる。一部の実施では、図２２の破線ボックス２２２２で示されるような円要素が存在しない場合があるが、本明細書では様々な例を示す目的で円要素２２２２について説明する。各要素は、塗りつぶし（プロパティ）データ、ストロークデータ、クリッピングデータ、変形データ、フィルタ効果データ、およびマスクデータを含むか、またはこれらに関連付けられることができる。
【０２６２】
以下で説明するように、形状は、継承およびカスケードされた提示プロパティで描画されるジオメトリに対応する。提示プロパティは、形状を描画するために必要なペンおよびブラシを構築する際に使用される。一実施態様では、形状は他のコントロール要素と同様にフルプレゼンタ（ｆｕｌｌ ｐｒｅｓｅｎｔｅｒ）である。ただし他の実施では、キャンバスクラス２５０８を形状用のコンテナとして提供することが可能であり、形状はキャンバス要素内にある場合にのみ描画することができる。たとえば、形状を軽量に保つために、形状にプレゼンタを付加することができない場合がある。代わりに、キャンバスが付加プレゼンタを有し、形状を描画する。キャンバス要素については、以下でより詳細に説明する。
【０２６３】
後述するように、画像クラスは形状よりも特異であり、たとえば複雑な場合のある境界データを含むことができる。たとえば、境界は上側は１色、両側は異なる色を指定し、様々な厚さを指定することおよび他のプロパティを設定することができる。画像、あるいはテキストまたはビデオなどの同様のボックスで囲まれた要素に対して、位置、サイズ、回転、および縮尺を設定することができる。画像およびビデオ要素は、キャンバス要素の外側に存在し、および表示することが可能であり、たとえばその要素から背景、境界、およびパッドサポートを取得するために、BoxedElementから継承することもできることに留意されたい。
【０２６４】
ビデオ要素は、表示された要素の中でビデオ（または同様のマルチメディア）を再生させることができるものである。この方法では、ベクトルグラフィックスシステムは、テキスト、２Ｄグラフィックス、３Ｄグラフィックス、アニメーション、ビデオ、静止画像、および音声を含むマルチメディアを横切ってシームレスに一貫した、ＡＰＩレイヤへのマークアップインターフェースを提供する。これによって設計者は、１つの媒体で作業を行い、他の媒体をアプリケーションおよび文書に容易に一体化させることを習得することができる。ベクトルグラフィックスシステムは、他の要素と同じ方法でマルチメディアをアニメーション化させることも可能であり、設計者はここでも、個々の媒体型の中核を成す固有性を失わせることなく他の要素と同様にマルチメディアを使用することが可能である。たとえば設計者は、回転、縮尺、アニメーション化、描画、合成、および他の効果に対して、異なる媒体型にまたがって同じ命名方式を使用することが可能であり、これによって設計者は、非常に豊富なアプリケーションを容易に作成すること、ならびに非常に効率的なレンダリングおよび合成の実施をその下に構築することができる。
【０２６５】
図２３に、マークアップコード２３０２がパーサ／トランスレータ２３０４によって解釈される一実施態様を示す。一般に、パーサ／トランスレータ２３０４は、要素ツリー／プロパティシステム２０８（図２にも示される）に要素を追加し、それらの要素にプレゼンタを付加する。その後、レイアウトシステム２１０は付加されたプレゼンタと共に要素ツリー２１０を取得し、そのデータをオブジェクトおよび映像ＡＰＩレイヤ２１２への呼出しに変換する。変換する必要があるのはすべての要素ではなく、プレゼンタが付加されたもののみであることに留意されたい。
【０２６６】
一般にマークアップはオブジェクトに分解され、通常、ＸＡＭＬマークアップに関するＸＭＬ方式がマークアップファイルの上位で以下のように宣言される。
【０２６７】
【表５９】
【０２６８】
たとえば<Path>タグが使用される場合、パーサはこの方式を使用して関連する名前空間（たとえば、System.Windows.Shapes）を検索し、オブジェクトを分解および構築する。
【０２６９】
一般に、要素とは、プロパティシステム、イベンティング、およびレイアウト／提示システムに加わっている要素レイヤ内のオブジェクトのことである。パーサはタグを見つけ、それらのタグが要素またはリソースオブジェクトの定義に役立つかどうかを判別する。特別なVisualBrushの場合、それらのタグが現れる場所の状況に応じて、たとえば複雑なプロパティ構文内に現れるか否かに応じて、同じタグを要素として解釈するか、またはリソースオブジェクトとして解釈することもできる。
【０２７０】
本発明の一態様によれば、マークアップ言語は、単純な文字列フォーマットまたは複雑なオブジェクト表記法を含むリソースを記述する独特の方法を提供する。単純な文字列フォーマットの場合、パーサ／トランスレータ２３０４は、型変換器２３０８を使用して文字列を適切な映像ＡＰＩオブジェクトに変換する。例を挙げると、型変換器２３０８を介して、以下のマークアップ行でFillプロパティ値をBrushオブジェクトに変換することができる。
【０２７１】
【表６０】
【０２７２】
容易に理解できるように、こうした単純なパラメータの文字列を備えたタグベースのマークアップの線分の内側行をBrushオブジェクトに変換するのは簡単であり、形状およびその属性をシーンに追加する単純な方法をシーン設計者に提供する。
【０２７３】
しかしながら、Fill属性が複雑すぎて単一の文字列に入らない場合がある。こうした状況では、マークアップで線分の内側である可能性のある複雑なプロパティ構文を使用して、このプロパティを設定する。たとえば以下の複雑なプロパティ構文は、ソリッドカラーではなく勾配で円を塗りつぶすものであり、様々な勾配停止（０から１までの範囲が可能）で色を指定する。
【０２７４】
【表６１】
【０２７５】
マークアップで線分の内側であることに加えて、リソースインスタンスはどこにでも（たとえば、ローカルであるか、またはリモートネットワーク上にあり適切にダウンロード可能な、マークアップまたはファイル内に）配置することが可能であり、名前（たとえば、テキスト名、参照または他の好適な識別子）で参照することができる。この方法の場合、シーン設計者は、複雑なプロパティ構文で記述された要素を含む要素ツリー内の要素を、シーン全体にわたって再使用することができる。
【０２７６】
パーサは、必要に応じて型変換器２３０８にアクセスすること、さらに指定されたパラメータをオブジェクトプロパティと付き合わせることによって、複雑なプロパティ構文内のマークアップを処理し、これによってシーンの設計が容易になる。したがってパーサは、オブジェクトをセットアップするだけではなく、オブジェクト上の属性も設定する。オブジェクトは不変であるため、パーサはオブジェクトを作成するために実際にビルダをインスタンス化することに留意されたい。
【０２７７】
同じレンダリングモデルが要素レベルとＡＰＩレベルの間で共用されるため、多くのオブジェクトが本質的に同じである。これによって解析／変換がかなり効率的になり、様々な種類のプログラミング言語（たとえば、Ｃ＃のような言語）が、マークアップからそれ自体の構文への変換およびその逆への変換を容易に実行できるようになる。図２３に表されているように、こうした他のプログラミング言語２３１０は、要素ツリー２０８に要素を追加するか、または映像ＡＰＩレイヤ２１２と直接インターフェースできることに留意されたい。
【０２７８】
図２３にも示されているように、また本発明の一態様によれば、同じマークアップ２３０２を使用して、要素レベルおよびリソースレベルでプログラミングすることができる。前述のように要素レベルは、完全なプログラミングが可能であり、継承（たとえばスタイルシートのような機能）を提供するプロパティシステムの使用と、（たとえばそれによって要素が、ユーザの入力イベントに応答して外観、位置などを変更するためにコードを付加することができる）イベンティングとを、シーン設計者に与える。しかし本発明は、リソースレベルの機構も提供しており、シーン設計者はこれを使用して、本質的に要素ツリーをショートカットし、システムおよびプログラムを映像ＡＰＩレイヤに直接レイアウトすることができる。要素レベルの機能を必要としない多くの型の静的形状、画像、および同様のものの場合、これによって、適切なオブジェクトを出力するためのより効率の良い軽量な方法が提供される。このためパーサは、「映像ブラシ」型の塗りつぶしが存在する場合を認識し、リソースレベルデータ２３１２を備えたＡＰＩレイヤ２１２を直接呼び出して、オブジェクトを作成する。つまり、図２２に示されるように、要素レベルのベクトルグラフィックスは作成済みの要素に解析され、これを後にオブジェクトに変換する必要がある一方で、リソースレベルのベクトルグラフィックスは解析された後、効率的な方法で直接格納される。
【０２７９】
例を挙げると、以下のマークアップはLinearGradientオブジェクト用のオブジェクトモデルから直接導出され、VisualBrushで外側の円を塗りつぶす。そのVisualBrushのコンテンツは内側のマークアップによって定義される。この構文は、一般に、様々なブラシ、変形、およびアニメーションを表すために使用されることに留意されたい。
【０２８０】
【表６２】
【０２８１】
これらの映像ブラシ塗りつぶしオブジェクトが効率的に格納される一方で、図２３に全体として示されるように、リソースレベルデータ（またはそれによって作成されたオブジェクト）は要素および要素ツリー２０８の一部によって参照できることに留意されたい。このため、これらの映像ブラシリソースは、複雑なプロパティ構文を介して記述された他のリソースと同様に、（たとえば名前、参照、または他の好適な識別子を使用して）命名および参照することができる。
【０２８２】
次にキャンバスについて説明すると、上記で代替の一実施態様で述べたように、形状は軽量に維持することが可能であるため、キャンバスに格納する必要がある場合がある。この代替実施では、コンテンツはレンダリングされる場合に、関連する座標系を有する装置に依存しない無限のキャンバス上にレンダリングされる。キャンバス要素は、絶対座標に従ってコンテンツを位置付けることができる。キャンバス要素は任意で、クリッピング、変形、好ましいアスペクト比、およびViewPortを親空間にマッピングする方法を指定するViewPortを定義することができる。確立されたViewPortがない場合、キャンバス要素は描画プリミティブのグループ化のみを指定し、変形、不透明度、および他の合成属性をセットアップすることができる。
【０２８３】
以下にキャンバスについてのマークアップ例を示す。
【０２８４】
【表６３】
【０２８５】
一実施態様では、座標が単位なしで指定された場合、９６分の１インチ（約０．０２６ｃｍ）の「論理ピクセル」とみなされ、上記の例では、線分の長さは２００ピクセルとなることに留意されたい。他のプロパティには座標に加えて、幅、高さ、水平および垂直の位置合わせ、ならびにViewBox（Rect型、デフォルト値は未設定または（０，０，０，０）、すなわち調整されない、ならびに引伸ばしおよび位置合わせプロパティは無視される）が含まれる。図１８〜２０を参照しながら上記で概説したように、他のプロパティには引伸ばしが含まれ、これが指定されない場合、オリジナルサイズを保持するか、１）アスペクト比が保持されず、上／左／幅／高さによって確立された境界を塗りつぶすようにコンテンツが縮尺されるFillを指定する、２）上／左／幅／高さによって確立された境界に画像が収まるまでサイズを均一に縮尺するUniformを指定する、あるいは３）上／左／幅／高さによって確立された境界を塗りつぶすようにサイズを均一に縮尺し、必要に応じてクリッピングするUniformToFillを指定することができる。
【０２８６】
より低いレベルのオブジェクトモデルとさらに相関させるために、変形プロパティは要素の子に対して新しい座標フレームを確立するが、クリッププロパティは、キャンバス上にコンテンツを描画できる範囲を境界ボックスとして定義されたデフォルトのクリッピングする軌跡によって制約する。ZIndexプロパティを使用して、パネル内の入れ子にされたキャンバス要素のレンダリング順序を指定することができる。
【０２８７】
ViewBoxは、たとえばViewPortの範囲および起点を再定義することによって、コンテンツ用の新しい座標系を指定する。引伸ばしは、これらのコンテンツをViewPortにマッピングする方法を指定する際に役立つ。ViewBox属性の値は、たとえば空白および／またはカンマによって分けられた４つの「単位なし」数<min-x>、<min-y>、<width>、および<height>のリストであり、Rect型である。ViewBox rectは、ユーザ空間内に境界ボックスにマッピングする矩形を指定する。これは、scaleXおよびscaleYを挿入するのと同じ働きをする。引伸ばしプロパティ（オプションがNone以外の場合）は、グラフィックスのアスペクト比を保持するための追加の制御を提供する。指定された効果を達成するために、所与の要素の下位に対して追加の変形が適用される。
【０２８８】
上記の例では、各引伸ばし規則の下での上のマークアップサンプルでの矩形の効果的な結果は以下のようになる。
【０２８９】
【表６４】
【０２９０】
キャンバス上で変形がある場合、本質的には上の（たとえばツリー内の）ViewBoxへのマッピングが適用される。このマッピングにより、形状だけでなくキャンバス内のいずれかの要素、たとえばボックス、テキストなどが引伸ばされることに留意されたい。さらに、ViewBoxが指定された場合、キャンバスはもはやそのコンテンツをサイズ変更せず、指定のサイズを有することにも留意されたい。y-widthおよびy-heightも指定された場合、ViewBoxは引伸ばし／位置合わせプロパティを使用して指定された幅および高さに合わせられる。
【０２９１】
オブジェクトモデル内の要素は、それぞれ「Clip」属性を適用することができる。一部の要素、特に形状では、これは一般的な言語ランタイムプロパティとして直接公開されるが、他の要素（たとえばほとんどのコントロール）では、このプロパティはDynamicPropertyを介して設定される。
【０２９２】
概略的に図２４に示されるように、一般にクリッピングする軌跡は、コンテンツが描画できる領域を制限するものであり、この図では、クリッピングされていない形２４０２と、クリッピングする軌跡が指定された形２４０４（破線がクリッピングする軌跡を表す）でボタンが示されている。概念上は、現在アクティブなクリッピングする軌跡で境界付けられた領域の外部にある描画の部分は、いずれも描画されない。クリッピングする軌跡はマスクとみなすことが可能であり、クリッピングする軌跡の外にあるピクセルは黒であってアルファ値０を備え、クリッピングする軌跡の中にあるピクセルは白であってアルファ値１を備える（シルエットの枠に沿ったアンチエイリアス（ａｎｔｉ−ａｌｉａｓｉｎｇ）は例外とする）。
【０２９３】
クリッピングする軌跡は、線分の内側またはより一般的にはリソースセクション内のいずれかで、Geometryオブジェクトによって定義される。クリッピングする軌跡は、以下の例に示されるように、要素上の「Clip」プロパティを用いて使用し、および／または参照される。
【０２９４】
【表６５】
【０２９５】
クリップのアニメーション化は変形のアニメーション化と同様であることに留意されたい。
【０２９６】
【表６６】
【０２９７】
軌跡は、「Geometry」データならびにFill、Stroke、およびStrokeWidthなどのレンダリングプロパティをPath要素上に指定することによって描画される。軌跡のマークアップの例は以下のように指定される。
【０２９８】
【表６７】
【０２９９】
軌跡「Data」文字列はGeometry型である。描画される軌跡を指定するためのより冗長かつ完全な方法は、前述のように複雑なプロパティ構文を介することである。マークアップ（以下の例のような）は、前述のGeometryビルダクラスへ直接送られる。
【０３００】
【表６８】
【０３０１】
軌跡データ文字列用の文法を記述するための以下の表記法を使用して、軌跡データ文字列も記述される。
【０３０２】
【表６９】
【０３０３】
この表記法で記述された軌跡データ文字列情報の例を、以下に示す（一実施態様では、要素レベルのプロパティの代わりにFillModeを指定できることに留意されたい）。
【０３０４】
【表７０−１】
【０３０５】
【表７０−２】
【０３０６】
【表７０−３】
【０３０７】
【表７０−４】
【０３０８】
【表７０−５】
【０３０９】
【表７０−６】
【０３１０】
画像要素（図２５）は、完全なファイルのコンテンツが現在のユーザ座標系内の所与の矩形にレンダリングされることを示す。画像（画像タグで示される）は、以下の例で示すようにＰＮＧまたはＪＰＥＧなどのラスタ画像ファイル、またはＭＩＭＥ型の「image/wvg」を備えたファイルを表示することができる。
【０３１１】
【表７１】
【０３１２】
以下の表は、画像用のプロパティ例の一部に関する情報を提供するものである。
【０３１３】
【表７２−１】
【０３１４】
【表７２−２】
【０３１５】
前述のように、形状は、継承およびカスケードされた提示プロパティで描画された幾何学形状に対応する。以下の表は、前述の基本形状要素（Rectangle、Ellipse、Line、Polyline、Polygon）用の形状プロパティの例を示すものである。これらの基本形状は、ストロークプロパティ、塗りつぶしプロパティを有し、クリッピングする軌跡として使用され、継承特徴を有し、要素とリソースの両方のレベルに適用可能であることに留意されたい
。
【０３１６】
【表７３−１】
【０３１７】
【表７３−２】
【０３１８】
矩形用のマークアップ構文の例を以下に示す。
【０３１９】
【表７４】
矩形とは、オブジェクトモデル内に以下のプロパティを有するものである（矩形は読取り／書込みされ、ゼロに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３２０】
【表７５】
【０３２１】
円用のマークアップ構文の例を以下に示す。
【０３２２】
【表７６】
【０３２３】
円とは、オブジェクトモデル内に以下のプロパティを有するものである（円は読取り／書込みされ、ゼロに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３２４】
【表７７】
【０３２５】
楕円用のマークアップ構文の例を以下に示す。
【０３２６】
【表７８】
【０３２７】
楕円とは、オブジェクトモデル内に以下のプロパティを有するものである（楕円は読取り／書込みされ、ゼロに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３２８】
【表７９】
【０３２９】
線分用のマークアップ構文の例を以下に示す。
【０３３０】
【表８０】
【０３３１】
線分とは、オブジェクトモデル内に以下のプロパティを有するものである（線分は読取り／書込みされ、ゼロに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３３２】
【表８１】
【０３３３】
「Polyline」は接続された直線セグメントの集合を定義する。通常、「Polyline」は開いた形状を定義する。
【０３３４】
線分群用のマークアップ構文の例を以下に示す。
【０３３５】
【表８２】
【０３３６】
線分群とは、オブジェクトモデル内に以下のプロパティを有するものである（線分は読取り／書込みされ、ｎｕｌｌに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３３７】
【表８３】
【０３３８】
Polygon要素は、接続された直線セグメントの集合を備えた閉じた形状を定義する。多角形用のマークアップ構文の例を以下に示す。
【０３３９】
【表８４】
【０３４０】
多角形とは、オブジェクトモデル内に以下のプロパティを有するものである（線分は読取り／書込みされ、ｎｕｌｌに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３４１】
【表８５】
【０３４２】
「Polyline」および「Polygon」要素でポイントを指定するための文法は、以下の表記法で記述される。
【０３４３】
【表８６】
【０３４４】
上記の表記法を使用した「Polyline」および「Polygon」要素でのポイントの指定について、以下に記載する。
【０３４５】
【表８７−１】
【０３４６】
【表８７−２】
【０３４７】
（結論）
前述の詳細な説明からわかるように、シーングラフとインターフェースするための様々な機構をプログラムコードに提供するシステム、方法、および要素／オブジェクトモデルが提供される。当該システム、方法、およびオブジェクトモデルは使用が簡単であり、さらに強力、柔軟、かつ拡張可能である。
【０３４８】
本発明には様々な修正および代替構造が可能であるが、図面にはその例示的実施形態が示されており、上記で詳細に説明してきた。しかし、開示された特定の形式に本発明を限定する意図はなく、逆に、本発明の精神および範囲内にあるすべての修正、代替構造、および等価物をカバーすることを意図するものであることを理解されたい。
【図面の簡単な説明】
【０３４９】
【図１】本発明を組み込むことが可能な例示的なコンピュータシステムを表すブロック図である。
【図２】本発明を組み込むことが可能なグラフィックレイヤアーキテクチャを全体として表すブロック図である。
【図３】本発明の一態様に従って、グラフィックスコマンドおよび他のデータを提供するために、シーングラフをトラバースすることなどによりシーングラフを処理するためのＶｉｓｕａｌおよび関連するコンポーネントのシーングラフを示す図である。
【図４】本発明の一態様に従って構築された、妥当性検査映像、描画映像、および関連する命令リストのシーングラフを示す図である。
【図５】本発明の一態様に従った、オブジェクトモデルの映像クラスを示す図である。
【図６】本発明の一態様に従った、オブジェクトモデルの様々な他のオブジェクトを示す図である。
【図７】本発明の一態様に従った、変形クラス階層を示す図である。
【図８】本発明の一態様に従った、ジオメトリスケールでの映像データの変形を示す図である。
【図９】本発明の一態様に従った、不均一スケールでの映像データの変形を示す図である。
【図１０】本発明の一態様に従った、ジオメトリクラスのオブジェクトモデルを示す図である。
【図１１】本発明の一態様に従った、PathGeometry構造を示す図である。
【図１２】本発明の一態様に従った、プリミティブによって作成されたグラフィックスの例を示す映像および命令リストのシーングラフを示す図である。
【図１３】本発明の一態様に従った、オブジェクトモデルのブラシクラスを示す図である。
【図１４】本発明の一態様に従った、線形勾配ブラシオブジェクト内のデータから生じたレンダリングされたグラフィックスを示す図である。
【図１５】本発明の一態様に従った、線形勾配ブラシオブジェクト内のデータから生じたレンダリングされたグラフィックスを示す図である。
【図１６】本発明の一態様に従った、放射勾配ブラシオブジェクト内のデータから生じたレンダリングされたグラフィックスを示す図である。
【図１７】本発明の一態様に従った、レンダリングされた９グリッドブラシオブジェクトを示す図である。
【図１８】本発明の一態様に従った、様々な引伸ばし値を有することから生じたレンダリングされたグラフィックスを示す図である。
【図１９】本発明の一態様に従った、様々なタイル値を有することから生じたレンダリングされたグラフィックスを示す図である。
【図２０】本発明の一態様に従った、映像ブラシオブジェクト内のデータから生じたグリッドおよび変形グリッドを示す図である。
【図２１】本発明の一態様に従った、映像から描画されたレンダリングされたグラフィックスを有するグリッドおよび変形グリッドを示す図である。
【図２２】本発明の一態様に従った、要素オブジェクトモデルの要素クラスを示す図である。
【図２３】本発明の一態様に従った、映像ＡＰＩレイヤとインターフェースするためにマークアップ言語コードを解釈するためのコンポーネントを示す図である。
【図２４】本発明の一態様に従った、ジオメトリ軌跡を介したクリッピングを示す図である。
【技術分野】
【０００１】
本発明は、一般にコンピュータシステムに関し、より詳細には、コンピュータシステムで表示するためのグラフィックおよび他のビデオ情報の処理に関する。
【背景技術】
【０００２】
コンピュータシステム上のグラフィックスにアクセスする従来の即時モードモデルは限界に達してきている。その原因の一部は、メモリおよびバスのスピードが主プロセッサおよび／またはグラフィックスプロセッサの進歩に遅れをとっていることである。一般に、フレームを作成するための現在の（たとえばＷＭ＿ＰＡＩＮＴ）モデルでは、複雑なグラフィックス効果が望まれる場合に、ハードウェアのリフレッシュ速度に遅れないために大量のデータを処理する必要がある。結果として、従来のグラフィックスモデルで複雑なグラフィックス効果が試される場合、結果的に次のフレームで遅れずに視覚効果が知覚されるように変更を完了する代わりに、異なるフレームにわたって変更が追加される場合があり、視覚的にかつ顕著に望ましくない結果となる。
【０００３】
グラフィックス出力を制御するための新しいモデルが記載されており（たとえば、特許文献１、２、３、４、５、および６を参照）、本発明の譲受人に譲渡され、参照により本明細書に組み込まれている。この新しいモデルは、グラフィックス処理技術においていくつかの重要な改良点を提供するものである。たとえば、複数レベルのグラフィックス処理のシステムおよび方法を対象としているものもあり（たとえば、特許文献１参照）、（たとえば、オペレーティングシステムの）より高いレベルのコンポーネントが、簡略化されたデータ構造および／またはグラフィックスコマンドを低いレベルのコンポーネントに渡すために、シーングラフの構築、アニメーションパラメータの更新、およびシーングラフのデータ構造のトラバースという、相対的に遅い動作速度で集中的に計算が行われる態様を実行する。高いレベルの処理がデータを大幅に簡略化することから、低いレベルのコンポーネントは、グラフィックスサブシステムのフレームのリフレッシュ速度に対応する速度など、（高いレベルのコンポーネントに比べて）より高速に動作し、データをグラフィックスサブシステム用の定常出力データに処理することが可能である。アニメーションが使用される場合、低いレベルの処理は、変更に伴ってシーン全体を書き直すことなく、必要に応じてレンダリング時にわずかに変更されたシーンをフレームごとに提供する瞬間値を取得するためにパラメータ間隔を補間し、平滑なアニメーションを提供することができる。
【０００４】
可変（アニメーション化された）値を提供するパラメータ化されたシーングラフと、グラフィックスを描画しようとするプログラムコード（たとえば、アプリケーションプログラムまたはオペレーティングシステムコンポーネント）が、他のアスペクトはそのままでシーングラフ記述の一定のアスペクトを選択的に変更できるようにパラメータ化されたグラフコンテナとが記載されている（たとえば、特許文献２を参照）。プログラムコードは、異なるパラメータを使用する可能性のある、シーングラフのうちのすでに構築された部分を再使用することもできる。パラメータ化を介して表示されたアイテムの外観を容易に変更する機能、および／またはシーングラフの既存の部分の再使用は、グラフィックス処理効率全体を大きく改善することが理解されよう。
【０００５】
シーングラフ内のオブジェクトおよびデータを介して映像情報を格納するための、キャッシュデータ構造および関連機構が、全体として記載されている（たとえば、特許文献３を参照）。データ構造は一般に、その中の映像情報がどのように読み込み（ｐｏｐｕｌａｔｅ）および使用されるかを知的に制御する機構に関連付けられる。たとえば、アプリケーションプログラムが特に要求しない限り、データ構造内に格納されたほとんどの情報はそれに対する外部参照を持たないため、この情報を最適化するかまたはその他の方法で処理することができる。これによって効率性とリソースの保存性が与えられ、たとえばキャッシュデータ構造内のデータを、よりコンパクトであり、かつ／または、ビットマップまたは他の後処理結果などの後続の反復的な処理が少ない異なるフォーマットに処理可能であることが理解されよう。
【０００６】
上記の改良点はグラフィックス処理技術に大きな恩恵を与えるものであるが、依然として、この改良されたグラフィックスモデルおよびその他の関連する改良点を簡単な方法で効果的に使用するためのプログラムが求められている。
【０００７】
【特許文献１】米国特許出願第１０／１８４７９５号明細書
【特許文献２】米国特許出願第１０／１８４７９６号明細書
【特許文献３】米国特許出願第１０／１８５７７５号明細書
【特許文献４】米国特許出願第１０／４０１７１７号明細書
【特許文献５】米国特許出願第１０／４０２３２２号明細書
【特許文献６】米国特許出願第１０／４０２２６８号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
改良されたグラフィックスモデルによって提供される多くの特徴およびグラフィックス処理機能を利用し、それによって複雑なグラフィックスおよび視聴覚データを効率的な方法で出力するための、包括的かつ簡単なプログラム用のモデルが必要とされている。
【課題を解決するための手段】
【０００９】
簡潔に言えば、本発明は、要素オブジェクトモデル（ｅｌｅｍｅｎｔ ｏｂｊｅｃｔ ｍｏｄｅｌ）と、プログラムコード開発者がシーングラフデータ構造と常時インターフェースしてグラフィックスを作成できるように、その要素オブジェクトモデルにアクセスするためのベクトルグラフィックスマークアップ言語とを提供するものである。ベクトルグラフィックスマークアップ言語は、要素オブジェクトモデルを介してベクトルグラフィックスを表現するための交換フォーマットを備える。マークアップ言語は、解釈される場合、シーングラフデータ構造のオブジェクトに変換される要素ツリー内の要素を含むデータに解析される。要素ツリーレベルでは、多くをプログラム可能にする、継承の特徴およびイベンティング（ｅｖｅｎｔｉｎｇ）を含むプロパティシステムおよびレイアウトシステムが提供され、起こり得る複雑なシーン（ｓｃｅｎｅ）をシーン設計者が簡単に設計できるようにしている。一般にベクトルグラフィックス要素は、シーングラフオブジェクトモデルのシーングラフオブジェクトと相互に関連する画像およびビデオ要素を含む、形状要素と他の要素とに対応する。ベクトルグラフィックス要素のプロパティおよび他のリソースは、シーングラフオブジェクトモデルの同様のプロパティおよびリソースとも相互に関連している。
【００１０】
ベクトルグラフィックスシステムは、要素レベルまでプログラミングすることが可能であり、それぞれの描画形状はページ／スクリーン内の残りのプログラム可能な要素と同レベルの要素として表されるため、レイアウトシステム、イベント、およびプロパティと対話することができる。ベクトルグラフィックスシステムは、リソースレベルまでプログラミングするための機構も提供するものである。これによってシーン設計者は、要素ツリーおよびレイアウトシステムを本質的にショートカットし、ならびにシーングラフデータ構造と対話する映像ＡＰＩレイヤまで直接プログラミングすることができる。これにより、適切なオブジェクトを出力するためのより効率の良い軽量の方法が提供されるが、要素レベルの一部はプログラムできなくなる。一実施態様では、「映像ブラシ（ｖｉｓｕａｌ ｂｒｕｓｈ）」型の塗りつぶし（ｆｉｌｌ）がプログラミングされると、パーサ（ｐａｒｓｅｒ）はリソースレベルデータを備えたＡＰＩレイヤを直接呼び出して、（同じく要素オブジェクトモデルとシーングラフオブジェクトモデルとの間の相関である）対応する映像ペイントオブジェクトを作成することができる。この２層システムでは、要素レベルベクトルグラフィックスは後でオブジェクトに変換する必要のある作成済み要素に解析され、リソースレベルベクトルグラフィックスは効率的な方法で解析されて直接保存される。同時に、リソースレベルデータまたはそれによって作成されたオブジェクトは、要素ごとおよび要素ツリーの部分ごとに参照することができる。このために、映像ペイント要素を含む要素に命名することができる。したがってシーン設計者は、必要に応じて効率性とプログラム可能性との釣り合いをとることができる。
【００１１】
要素クラス階層には、形状（Shape）クラス、画像（Image）クラス、ビデオ（Video）クラス、およびキャンバス（Canvas）クラスが含まれる。形状クラスの要素には、矩形、線分群、多角形、軌跡、線分、および楕円が含まれる。各要素は、塗りつぶし（プロパティ）データ、ストロークデータ、クリッピングデータ、変形データ、フィルタ効果データ、およびマスクデータを含むか、またはこれらに関連付けることができる。形状は、形状を描画するのに必要なペンおよびブラシの構築に使用される継承およびカスケードされた提示プロパティで描画された、（シーングラフオブジェクトモデルの）ジオメトリに対応する。画像クラスは形状クラスよりも特異的であり、より多くのラスタグラフィカルデータを含むことが可能であって、ビデオクラスは表示された要素の中でビデオ（または同様のマルチメディア）を再生させることができる。キャンバスクラスは、形状を軽量に保つために形状用のコンテナとして動作することが可能である。
【００１２】
一実施態様では、一般に要素レベルの要素を要素ツリー／プロパティシステムに追加しそれらの要素にデータを付加するパーサ／トランスレータによって、マークアップコードが解釈される。その後レイアウトシステムは、付加されたプレゼンタと共に要素ツリーを取得し、（ビルダを介して）データをオブジェクトに変換して、シーングラフとインターフェースする映像ＡＰＩレイヤを呼び出し、シーングラフオブジェクトを作成する。
【００１３】
マークアップ言語は、単純な文字列フォーマットまたは複雑なオブジェクト表記法（複雑なプロパティ構文）を含む、要素を記述するための明確な方法を提供する。単純な文字列フォーマットの場合、パーサ／トランスレータおよび／またはレイアウトシステムは、文字列を適切な映像ＡＰＩオブジェクトに変換するために、型変換器を使用する。塗りつぶし属性が複雑すぎて単一の文字列に組み込まれない場合、マークアップでは線分の内側である可能性のある複雑なプロパティ構文がプロパティセットを記述するために使用される。同じレンダリングモデルが要素レベルとＡＰＩモデルで共用されるため、オブジェクトの多くが同じであり、解析／変換はかなり効率的なものとなり、他の利点を提供している。リソースインスタンスはどこか他の場所（たとえばマークアップまたはファイル）にも位置し、名前によって参照することができる。この方法では、シーン設計者は、複雑なプロパティ構文によって記述される要素を含む要素ツリー内の要素をシーン全体にわたって再使用することができる。
【００１４】
他の利得および利点は、図面に関して以下の詳細な説明を読めば明らかとなろう。
【発明を実施するための最良の形態】
【００１５】
（例示的なオペレーティング環境）
図１は、本発明が実施可能である、適したコンピューティングシステム環境１００の一例を示す図である。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲に関していかなる制限をも示唆することを意図するものではない。さらにコンピューティング環境１００は、例示的オペレーティング環境１００内に示されたいずれのコンポーネントまたはコンポーネントの組合せに関しても、いかなる依存性または要件を有するものとも解釈されるべきではない。
【００１６】
本発明は、多数の他の汎用または特定用途向けのコンピューティングシステム環境または構成を使用して動作可能である。本発明で使用するのに適する可能性のある、よく知られたコンピューティングシステム、環境、および／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、タブレット装置、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能な市販の電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたは装置のいずれかを含む分散コンピューティング環境、およびその他が含まれるが、これらに限定されるものではない。
【００１７】
本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令との全体的な関連において説明することができる。一般に、プログラムモジュールにはルーチン、プログラム、オブジェクト、コンポーネント、データ構造、などが含まれ、特定のタスクを実行するかまたは特定の抽象データ型を実施する。本発明は、タスクが通信ネットワークを介してリンクされたリモート処理装置によって実行される、分散コンピューティング環境でも実施可能である。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよびリモート双方のコンピュータ記憶媒体に配置することができる。
【００１８】
図１を参照すると、本発明を実施するための例示的システムには、コンピュータ１１０の形の汎用コンピューティング装置が含まれる。コンピュータ１１０のコンポーネントは、処理装置１２０と、システムメモリ１３０と、システムメモリを含む様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１とを含むことができるが、これらに限定されるものではない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含む、いくつかの種類のバス構造のうちのいずれであってもよい。例を挙げると、こうしたアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）バス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれるが、これらに限定されるものではない。
【００１９】
コンピュータ１１０は、通常、様々なコンピュータ読取り可能な媒体を含む。コンピュータ読取り可能な媒体は、コンピュータ１１０によってアクセス可能な揮発性および不揮発性媒体、ならびに取外し可能および固定の両方の媒体を含む、任意の使用可能な媒体とすることが可能である。例を挙げると、コンピュータ読取り可能な媒体はコンピュータ記憶媒体および通信媒体を含むことができるが、これらに限定されるものではない。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、または他のデータなどの、情報を記憶するための任意の方法または技術で実施された揮発性および不揮発性、取外し可能および固定の、両方の媒体を含む。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、あるいは所望の情報を記憶するために使用可能でありコンピュータ１１０がアクセス可能な任意の他の媒体が含まれるが、これらに限定されるものではない。通信媒体は、通常、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、または搬送波または他の移送機構などの被変調データ信号中の他のデータを具体化し、任意の情報送達媒体を含むものである。「被変調データ信号」という用語は、信号内の情報を符号化するような方法で、その特性のうちの１つまたは複数が設定または変更された信号を意味する。例を挙げると、通信媒体には、有線ネットワークまたはダイレクトワイヤード接続などの有線媒体と、音波、ＲＦ、赤外線、および他の無線媒体などの無線媒体とが含まれるが、これらに限定されるものではない。上記のうちの任意の組合せも、コンピュータ読取り可能な媒体の範囲に含まれるものとする。
【００２０】
システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。コンピュータ１１０内の要素間での起動時などの情報転送に役立つ基本ルーチンを含む基本入力／出力システム１３３（ＢＩＯＳ）は、通常、ＲＯＭ１３１に格納される。ＲＡＭ１３２は、通常、処理装置１２０が即時にアクセス可能であり、かつ／または現在動作中である、データおよび／またはプログラムを含む。例を挙げると、図１にはオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７が示されているが、これらに限定されるものではない。
【００２１】
コンピュータ１１０は、他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体を含むこともできる。単なる例として、図１には、固定の不揮発性磁気媒体からの読取りまたはこれへの書込みを行うハードディスクドライブ１４１と、取外し可能な不揮発性磁気ディスク１５２からの読取りまたはこれへの書込みを行う磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭまたは他の光媒体などの取外し可能な不揮発性光ディスク１５６からの読取りまたはこれへの書込みを行う光ディスクドライブ１５５が示されている。例示的なオペレーティング環境で使用可能な他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、などが含まれるが、これらに限定されるものではない。ハードディスクドライブ１４１は、通常、インターフェース１４０などの固定のメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取外し可能メモリインターフェースによってシステムバス１２１に接続される。
【００２２】
上記で考察し、図１に示すドライブおよびそれらの関連するコンピュータ記憶媒体は、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、およびコンピュータ１１０に関する他のデータのストレージを提供するものである。たとえば図１では、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納しているものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであるかまたは異なるかの、いずれであってもよいことに留意されたい。本明細書では、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともこれらが異なるコピーであることを示すために異なる番号が与えられている。ユーザは、タブレット（電子ディジタイザ）１６４、マイクロフォン１６３、キーボード１６２、および、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などの入力装置を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、スキャナ、またはその他を含むことができる。これらおよび他の入力装置は、システムバスに結合されたユーザ入力インターフェース１６０を介して処理装置１２０に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することも可能である。モニタ１９１または他の種類のディスプレイ装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１は、タッチスクリーンインターフェースなどのインターフェースを介してコンピュータシステム１１０に手書き入力するなどの、デジタル化された入力を行うことのできる、タッチスクリーンパネルまたはその他と一体型にすることも可能である。モニタおよび／またはタッチスクリーンパネルは、タブレット型のパーソナルコンピュータの場合などのように、コンピューティングデバイス１１０が組み込まれたハウジングに物理的に結合可能であり、ここでタッチスクリーンパネルは本質的にタブレット１６４として働くことに留意されたい。さらに、コンピューティングデバイス１１０などのコンピュータは、出力周辺インターフェース１９４またはその他を介して接続可能なスピーカ１９５およびプリンタ１９６などの他の周辺出力装置も含むことができる。
【００２３】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般的なネットワークノードとすることが可能であり、通常は、コンピュータ１１０に関して上記で述べた要素の多くまたはすべてを含むが、図１にはメモリ記憶装置１８１のみが記載されている。図１に示された論理接続には、ローカル絵リアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークを含むこともできる。こうしたネットワーキング環境は、オフィス、企業規模コンピュータネットワーク、イントラネット、およびインターネットで普及している。
【００２４】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０はネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介した通信を確立するためのモデム１７２または他の手段を含む。モデム１７２は内蔵型または外付けが可能であり、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化環境では、コンピュータ１１０に関して示されたプログラムモジュールまたはその一部を、リモートのメモリ記憶デバイスに格納することができる。例を挙げると、図１にはリモートアプリケーションプログラム１８５がメモリ装置１８１に常駐しているように示されているが、これらに限定されるものではない。図示されたネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段が使用可能であることを理解されよう。
【００２５】
（グラフィックスアーキテクチャ）
本発明の一態様は、一般に、アプリケーションまたはオペレーティングシステムコンポーネントなどのプログラムコードが、システムディスプレイ上にグラフィック出力をレンダリングするために、描画命令および他の情報（たとえば画像ビットマップ）をグラフィックスコンポーネントに送ることができるようにすることを対象としている。このため本発明は、プログラムがデータ構造、描画プリミティブ（コマンド）、および他のグラフィックス関連データと共にシーングラフを読み込めるようにするマークアップ言語ならびに形状要素および他の要素のセット、グループ化および複合化システム、ならびにオブジェクトモデルにおける一般的なプロパティシステムとの統合を提供するものである。処理が実行されると、シーングラフはスクリーン上にグラフィックスを表示することになる。
【００２６】
図２は、本発明が実施可能な、全体的なレイヤードアーキテクチャ２００を示す図である。図２に示されるように、プログラムコード２０２（たとえばアプリケーションプログラムまたはオペレーティングシステムコンポーネントなど）を開発して、画像化機構２０４を介すること、ベクトルグラフィック要素２０６を介すること、および／または映像アプリケーションプログラミングインターフェース（ＡＰＩ）レイヤ２１２に直接配置された機能／メソッド呼出しを介することを含む、１つまたは複数の様々な方法で、グラフィックスデータを出力することができる。ＡＰＩレイヤとの直接対話については、前述の「Ｖｉｓｕａｌ ａｎｄ Ｓｃｅｎｅ Ｇｒａｐｈ Ｉｎｔｅｒｆａｃｅｓ」という名称の同時係属出願により詳細に記載されている。
【００２７】
一般に、画像化機構２０４は、たとえばビットマップなどの画像のロード、編集、および保存のための機構をプログラムコード２０２に提供するものである。これらの画像はシステムの他の部分が使用することも可能であり、画像に直接描画するためにプリミティブ描画コードを使用する方法もある。
【００２８】
本発明の一態様によれば、ベクトルグラフィックス要素２０６は、オブジェクトモデルの残りの部分に適合する、グラフィックスを描画するための他の方法を提供する（以下で説明）。ベクトルグラフィック要素２０６はマークアップ言語を介して作成することが可能であり、要素／プロパティシステム２０８およびレイアウトシステム２１０はこれを処理して、映像ＡＰＩレイヤ２１２を適切に呼び出す。以下で説明するように、一般にベクトルグラフィック要素２０６は、シーングラフが描画される元となるオブジェクトモデルのオブジェクトに解析され、これを、要素／プロパティシステム２０８およびレイアウトシステム２１０を介した要素レベルを介してシーングラフに提供するか、またはリソースレベルでのより効率的な方法で提供することが可能であり、これについても以下で説明する。
【００２９】
一実施態様では、グラフィックスレイヤアーキテクチャ２００には高いレベルの合成およびアニメーションエンジン２１４が含まれ、これがキャッシュデータ構造２１６を含むかまたは他の方法でこれに関連付けられる。キャッシュデータ構造２１６は、以下で説明するように、定義済みオブジェクトモデルに従って管理される階層上に配置構成されたオブジェクトを備えたシーングラフを含む。一般に、映像ＡＰＩレイヤ２１２は、オブジェクトの作成、オブジェクトにデータを提供するためのオブジェクトのオープンおよびクローズなどの機能を含む、キャッシュデータ構造２１６へのインターフェースをプログラムコード２０２（およびレイアウトシステム２１０）に提供する。つまり、高いレベルの合成およびアニメーションエンジン２１４は、開発者が、グラフィックス情報を表示するためにグラフィックスおよび媒体に関する意図を表現し、基礎となるプラットフォームがプログラムコードに対するハードウェアの使用を最適化できるようにプラットフォームに十分な情報を提供する際に使用できる統一媒体ＡＰＩレイヤ２１２を公開する。たとえば基礎となるプラットフォームは、キャッシュ、リソースの折衝（ｎｅｇｏｔｉａｔｉｏｎ）、および媒体の統合に関する責務を負うことになる。
【００３０】
一実施態様では、高いレベルの合成およびアニメーションエンジン２１４は、命令ストリームおよび可能な他のデータ（たとえばビットマップを指すポインタ）を高速の低いレベルの合成およびアニメーションエンジン２１８に渡す。「高いレベル」および「低いレベル」という用語が本明細書で使用される場合、他のコンピューティングシナリオで使用される場合と同様に、一般に、高いレベルのコンポーネントに比べてソフトウェアコンポーネントが低いレベルであるほど、そのコンポーネントはハードウェアに近くなる。したがって、たとえば高いレベルの合成およびアニメーションエンジン２１４から送られたグラフィックス情報を、低いレベルの合成およびアニメーションエンジン２１８で受け取ることが可能であり、ハードウェア２２２を含むグラフィックスサブシステムにグラフィックスデータを送信する際にその情報が使用される。
【００３１】
高いレベルの合成およびアニメーションエンジン２１４はプログラムコード２０２と共に、プログラムコード２０２によって提供されたグラフィックスシーンを表すためのシーングラフを構築する。たとえば、描画されるそれぞれのアイテムを描画命令と共にロードすることが可能であり、システムはこれをシーングラフデータ構造２１６にキャッシュすることができる。以下で説明するように、このデータ構造２１６および何を描画するかを指定するにはいくつかの様々な方法がある。さらに、高いレベルの合成およびアニメーションエンジン２１４は、タイミングおよびアニメーションシステム２２０と統合し、宣言（または他の）アニメーション制御（たとえばアニメーション間隔）およびタイミング制御を提供する。アニメーションシステムは、本質的にアニメーション値を、たとえば要素プロパティレベル２０８、映像ＡＰＩレイヤ２１２の内部、および任意の他のリソース内を含む、システム内のどこにでも渡せるようにするものであることに留意されたい。タイミングシステムは、要素レベルおよび映像レベルで公開される。
【００３２】
低いレベルの合成およびアニメーションエンジン２１８はシーンの合成、アニメーション、およびレンダリングを管理し、その後これがグラフィックスサブシステム２２２に提供される。低いレベルのエンジン２１８は、複数のアプリケーションのシーンについてレンダリングを合成し、レンダリングコンポーネントを使用して、スクリーンへのグラフィックスの実際のレンダリングを実施する。しかし、時には、一部のレンダリングはより高いレベルで発生することが必要かつ／または有利な場合があることに留意されたい。たとえば、複数アプリケーションからのサービス要求が低レイヤになるほど、アプリケーションごとのインスタンス生成がより高レイヤになり、これによって、画像化機構２０４を介して、時間のかかるまたはアプリケーション特有のレンダリングが高いレベルで実行され、ビットマップへの参照が低レイヤに渡される可能性がある。
【００３３】
（シーングラフオブジェクトモデル）
以下で説明するように、レンダリングモデルは、高いレベル、コントロールベースのベクトルグラフィックス要素２０６と、シーングラフデータ構造２１６で使用される映像ＡＰＩレイヤ２１２によって作成された低いレベルのオブジェクトによって共用される。これによって、本発明の高いレベルの要素と低いレベルのオブジェクトとの間にかなりの相関関係がもたらされる。次に、シーングラフオブジェクトモデルの一実施態様について説明する。
【００３４】
本発明は、グラフィックスおよびレンダリングサービスへのいくつかのレイヤのアクセスを提供するものである。トップレイヤでは、ベクトルグラフィックスが、本発明のオブジェクトモデルでの使用が簡単であること、容易に再使用できること、および同様のシステムのユーザには一般によく知られていることを含む、ＸＭＬベースグラフィックスのマークアップでは一般的ないくつかの利点を提供する。オブジェクトは、それらの要素に関する属性または複雑なプロパティのどちらか一方として公開されたプロパティを備えるマークアップ要素として使用可能である。
【００３５】
本発明は、Visualオブジェクトの使用によってグラフィックスコンテンツをレンダリングするものである。この基礎となるVisualレイヤはいくつかの方法で使用可能である。プログラマは、コード内で直接Visualにアクセス可能であり、オブジェクトモデルを使用してプログラミング可能であり、本発明の一態様に従って、ＸＭＬベースのマークアップが使用可能である。
【００３６】
予め定義されたベクトル形状は、PolygonおよびPath要素と同様にベクトルグラフィックスで使用可能であり、Canvas、Dock Panel、およびFlow Panelなどのレイアウト要素内に格納される。Canvas要素は、親空間内に要素を絶対的に配置するための手段を提供する。Canvasおよびその子形状の場合、スクリーン座標用のデフォルトの測定単位は、装置に依存しないピクセルである。DockPanelおよびFlowPanelは、いくつかのサイズおよび位置合わせプロパティ、ならびに境界線をまたがるコントロールを提供する。
【００３７】
ベクトルグラフィックスは、ＳＶＧのユーザにはよく知られたいくつかの定義済みベクトルグラフィックス形状を提供する。これらの要素はShapeクラスを継承し、Ellipse（楕円）、Line（線分）、Path（軌跡）、Polygon（多角形）、およびRectangle（矩形）を含む。これらの要素は、座標および頂点を指定するためのStrokeおよびStrokeThickness、Fill、ならびにデータ属性を含む、いくつかの一般的な属性をShapeから継承する。開発者は、変形を適用することによって形状を傾斜、回転、変換、および縮尺することもできる。
【００３８】
Line要素は、便利な一例を提供するものである。以下の例では、始点および終点、ストロークの色および幅、ならびに線分端部での丸めキャッピング（ｒｏｕｎｄｅｄ ｃａｐｐｉｎｇ）用の座標を指定する。
【００３９】
【表１】
【００４０】
形状の中央をCenterXおよびCenterYプロパティで定義することによって、楕円が作成される。焦点を指定する代わりに、RadiusXおよびRadiusYプロパティを設定することによって、楕円の範囲が設定される。ベクトルグラフィックスで円を描画する場合、開発者はRadiusXとRadiusYの値が等しい楕円を指定することができる。
【００４１】
【表２】
【００４２】
Pathオブジェクトは、オープンまたはクローズどちらかの、曲線および複雑な形状を描画する手段を提供する。Pathは、Shapeクラスから継承したオブジェクト上で使用可能なプロパティを公開するが、曲線を記述するためにより複雑なパラメータを開発者に指定させることもできる。開発者は、Data内で特殊な構文を使用して軌跡データを指定すること、またはPathGeometryおよびPathGeometryオブジェクトを使用して個々の軌跡セグメントを指定することを含み、マークアップ内で様々な方法で軌跡を使用することができる。
【００４３】
Data属性に提供される座標ペアおよび線分の内側パラメータは、線分セグメント、ベジェ曲線、および様々な他の軌跡の仕様を指定することができる。以下の例は、２つの下位の軌跡を定義するPath要素を示すものである。
【００４４】
【表３】
【００４５】
Data属性文字列は、Ｍで示された「ｍｏｖｅｔｏ」コマンドで始まり、Canvasの座標系において軌跡の始点を確立する。Pathデータパラメータは大文字と小文字を区別する。大文字のＭは新規の現在位置に関する絶対位置を示す。小文字のｍは相対座標を示す。第１の下位の軌跡は、２つの制御位置（１００，２５）および（４００，３５０）を使用して描画される、（１００，２００）で始まり（４００，１７５）で終わる３次ベジェ曲線である。この下位の軌跡は、Data属性文字列内のＣコマンドで示される。ここでも、大文字のＣは絶対軌跡を示し、小文字のｃは相対軌跡を示すことになる。
【００４６】
第２の下位の軌跡は、絶対水平「ｌｉｎｅｔｏ」コマンドＨで始まり、先行する下位の軌跡の終点（４００，１７５）から新しい終点（２８０，１７５）まで描画される線分を指定するものである。これは水平「ｌｉｎｅｔｏ」コマンドであるため、指定される値はｘ軸座標である。
【００４７】
より詳細な構文を使用してマークアップ内の軌跡データを指定することも可能であり、これは、開発者が複雑なプロパティを指定し、マークアップをより読みやすくするという利点を有する場合がある。この場合、PathGeometryオブジェクトを使用して、円弧および曲線などの複雑な形状を作成することができる。PathGeometryオブジェクトは１つまたは複数のPathFigureオブジェクトからなり、各PathFigureは異なる「図」または形状を表す。各PathFigureは、それ自体が１つまたは複数のPathSegmentオブジェクトからなり、それぞれが図または形状の接続された部分を表す。セグメント型には、LineSegment、BezierSegment、およびArcSegmentが含まれる。
【００４８】
以下のコードは、PathGeometryおよびPathfigureを使用することによって軌跡データを指定するものであり、PathFigureにいくつかのセグメントが加えられて１つの形状を形成する。この場合、セグメントはPathFigureオブジェクトのSegmentsプロパティを使用して加えられる。このマークアップは、４つのベジェ曲線を作成する。PathFigureの第１のセグメントはStartSegmentであることに留意されたい。
【００４９】
【表４−１】
【００５０】
【表４−２】
【００５１】
ベクトルグラフィックス形状は、それらのStrokeおよびFillの色を指定するために、Brushオブジェクトの様々な属性を公開する。以下の例では、CanvasおよびEllipse要素に関してこれらの属性を指定する。色プロパティに有効な入力は、キーワードまたは１６進カラー値のどちらでも可能であることに留意されたい。
【００５２】
【表５】
【００５３】
別の方法として、開発者は、複雑なプロパティ構文およびSolidColorBrushクラスを使用して色を指定することができる。より複雑な構文を使用してプロパティを指定することは、プロパティシートを備えたグラフィックスマークアップを再使用する場合、または同じ色の形状プロパティをアニメーション化するために、必要となる。
【００５４】
【表６】
【００５５】
この不規則な線分群の形状は、StrokeおよびFillプロパティに予め定義されたカラー値を使用する。FillOpacityプロパティは、この場合はわずかに透明（不透明度０．８）にすることによって塗りつぶす色に影響を与えるため、任意の基礎となる色と調和する。
【００５６】
【表７】
【００５７】
形状に対してソリッドカラーの塗りつぶしおよび背景を指定する場合とまったく同様に、勾配（ｇｒａｄｉｅｎｔ）を指定することも可能である。以下の例は、RectangleのFill属性として水平勾配を、開始色としてBlueおよび終了色としてRedを設定するものである。
【００５８】
【表８】
【００５９】
開発者は、複雑なプロパティ表記法で勾配を指定することもできる。この表記法は、勾配のレンダリングにおいて非常に特異であり、追加のプロパティを公表する。たとえば勾配を使って形状の塗りつぶしをアニメーション化する場合、複雑な表記法が使用されることになる。以下の例では、RadialGradientBrushオブジェクトを使用してRectangleに勾配を設定する。RadialGradientBrushオブジェクトは、その半径およびそれに設定することのできる任意の変形およびアニメーションと同様に、勾配のプロパティへアクセスし、これらのプロパティはGradientBrushから継承される。GradientStopCollection集合は、開発者が複数の勾配停止を指定し、それらのオフセット（勾配の停止位置）を指定できるようにするものである。
【００６０】
【表９】
【００６１】
本発明は、ベクトルが描画する形状に標準の変形を行うものである。開発者は、静的グラフィックスとしてまたはアニメーションで、形状を傾斜させ、それらを回転させ、それらの縮尺を変更し、それらを変換（再配置）することができる。マークアップでTransformオブジェクトを使用する場合、それらをTransformDecoratorの子として指定する必要がある。
【００６２】
ScaleTransform変形は、使用可能な変形の中で最も簡単であり、要素をサイズ変更するべき係数を指定するだけで使用される。以下の例は、親Canvasの座標系のｙ軸に沿ってPolygon要素のサイズを１５０パーセント変更するものである。
【００６３】
【表１０】
【００６４】
同じTransformDecoratorオブジェクトをさらに変形するように指定する場合、TransformCollectionで囲む必要があることに留意されたい。また、各変形が解析および適用される順番によって、最終的な効果が異なる。たとえば、要素を異なるスクリーン座標に変換する前に回転させると、異なる効果を生じさせることができる。
【００６５】
以下の例では、２つの線分群要素に回転および変換が適用される。
【００６６】
【表１１】
【００６７】
これら２つの変形では、それぞれの形状の最終スクリーン位置が同じにならないことに留意されたい。回転変形を使用する場合、変形は特定要素の座標系全体を回転させる。起点を基準にした要素の位置によって、回転の効果が要素を「所定の位置で」回転させない場合がある。たとえば、ｘ軸に沿って０から２００単位に配置された要素の場合、３０度回転させると、起点を中心に描かれた半径２００の円に沿って要素を３０度回す効果がある。そのため、Transformを処理する場合、要素を起点に変換し、回転、傾斜、または縮尺の変形を加え、その後要素を最終位置に再変換する方が簡単である。
【００６８】
特定の構文を使用して、変形設定の他の変換とは無関係に、特定ポイントを中心とした回転を指定することができる。実際には、この構文は新しい起点への変換、回転、および以前の起点への再変換を指定する。ポイント（ｃｘ，ｃｙ）を中心とするｒ度の回転を指定する場合、以下の構文を使用する。
transform="rotate(rx [cx,cy])"
【００６９】
開発者は傾斜変形を使用して、一方または両方の軸に沿って形状を歪ませることができる。SkewTransformクラスは、どちらかの軸に沿って比例オフセットを指定する、AngleXおよびAngleYプロパティを提供する。
【００７０】
【表１２−１】
【００７１】
【表１２−２】
【００７２】
他の変形の場合と同様に、傾斜変形の適用効果は単に形状だけでなく座標系を傾斜させることである。したがって起点が設定されると必ず、座標系は起点から傾斜する。起点からある程度距離を有する形状で傾斜変形が行われると、「空空間」もその傾斜を反映し、要素の配置に影響を与える。同じ理由から、開発者が配置変形を適用する順番も、レンダリングされる傾斜または回転に影響を与える。
【００７３】
形状またはコントロールに色が加えられる場合は、いつでもブラシが使用される。本発明は、開発者のアプリケーションが、単純なソリッドカラーから複雑なパターンおよび画像のセットまで何でも使用してユーザインターフェース（ＵＩ）要素をペイントできるようにする、マークアップを提供する。
【００７４】
ブラシは、キャンバスに描かれた形状の内部および枠に色付けすることができる。ブラシを使用して、ＵＩを形成する任意の要素の外観を変更することもできる。以下に記載するのはBrush型の属性の一部であり、いずれのブラシも使用することができる。
Control.Background
Control.BorderBrush
Column.Background
Text.Foreground
Shape.Fill
Shape.Stroke
【００７５】
２つの主な型のブラシ、すなわちベクトルブラシおよびビットマップブラシがある。ベクトルベースのブラシには、SolidColorBrush、LinearGradientBrush、RadialGradientBrush、およびDrawingBrushが含まれる（ただしDrawingBrushはビットマップで塗りつぶされた形状を含むことができる）。ビットマップベースのブラシには、ImageBrushおよびNineGridBrushが含まれる。一般にビットマップは、領域を塗りつぶすために引伸ばしまたは縮尺された場合に品質が低下するが、ベクトルは低下しない。したがって、可能であれば必ずベクトルベースのブラシを使用すべきである。
【００７６】
基本型の塗りつぶしは、領域をソリッドカラーで塗りつぶすSolidColorBrushである。ソリッドカラーを指定するには、いくつかの方法がある。よく知られた色は、名前で選択することができる。たとえば、形状のFill属性を「Red」に設定することができる。赤、緑、および青の量を指定することにより３２ビットの色パレットから色を選択して、単一のソリッドカラーに混合することができる。３２ビットのパレットから色を指定するための形式は「#RRGGBB」であり、ここでRRは赤の相対的な量を指定する２桁の１６進数であり、GGは緑の量を指定し、BBは青の量を指定する。さらに、色は「#AARRGGBB」として指定することも可能であり、ここでAAは、色のアルファチャネル、すなわち透過性を指定する。他の配色も実行可能である。
【００７７】
以下の例で、Ellipse要素のFillは、予め定義された色名のうちの１つを使用して設定される。
【００７８】
【表１３】
【００７９】
アルファチャネルは、任意のソリッドカラーブラシに直接指定することが可能である一方で、ブラシのOpacityプロパティで指定することもできる。要素全体およびその子要素の不透明度は、UIElement.Opacityプロパティを使用して指定することができる。これらの値は、それぞれ０と１の間のDoubleとして指定される。１の値は完全に不透明であり、０の値は完全に透明である。不透明度を記述する様々な方法は累積的である。すなわち、アルファチャネルが０×７Ｆ（５０パーセント不透明）でありUIElement.Opacityプロパティが０．５（５０パーセント不透明）である場合、要素は２５パーセント不透明でペイントされる。
【００８０】
勾配ブラシとは、軸に沿って１つの色から他の色に変化する塗りつぶしのことである。ベクトルグラフィックス（Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）でサポートされている勾配には、線形勾配および放射勾配の２種類がある。
【００８１】
勾配ブラシの基本的な構築ブロックは勾配停止である。勾配停止は、勾配軸に沿って相対的なオフセットで色を指定する。勾配停止間の点の色は、２つの境界となる勾配停止によって指定された色の組合せとして、線形補間される（ｌｉｎｅａｒｌｙ ｉｎｔｅｒｐｏｌａｔｅｄ）。オフセットは、０から１までの範囲のDoubleである。以下に、勾配の例を示す。
【００８２】
勾配ブラシを持つ方法の１つは、勾配停止を明示的に指定することである。以下にその一例を示す。
【００８３】
【表１４】
【００８４】
以下の例では、LinearGradientBrushを使用して、４つの勾配停止を有するボタンの背景を線形勾配で塗りつぶす。
【００８５】
【表１５】
【００８６】
RadialGradientBrushを使用して、放射勾配で領域を塗りつぶす。放射勾配は線形勾配と同様であるが、勾配の軸は楕円の内側から外側へと存在する。放射勾配で塗りつぶされた円は、黄色の中心と緑の輪郭を有し、それらの間で色を補間することができる。以下の画像は、白から灰色への放射勾配で塗りつぶされた矩形を示すものである。外側の円は勾配円を表し、赤いドットは焦点を示す。この勾配では、SpreadMethodをPadに設定している。
【００８７】
以下の例では、Rectangle要素のFillプロパティはRadialGradientBrushを使用して設定される。放射勾配は（０．５，０．５）の焦点を有する。
【００８８】
【表１６】
【００８９】
２色のみで勾配を作成する場合、Stroke、Fill、およびBackgroundのプロパティにキーワードを使用して、表記法を簡略化することができる。以下のサンプルは、青から赤へ変化する線形勾配型の水平勾配で塗りつぶされた矩形を作成する方法を示す。
【００９０】
【表１７】
【００９１】
水平、垂直、および放射の勾配を作成するための省略された構文は、GradientType StartColor EndColorであり、ここでGradientTypeはVerticalGradient、HorizontalGradient、またはRadialGradientである。StartColorおよびEndColorは、予め定義された色名（青など）または１６進値とすることができる。
【００９２】
垂直勾配とは、始点と終点が垂直な線を形成する線形勾配のことである。同様に、水平勾配とは、始点と終点が水平な線を形成する線形勾配のことである。開発者は、構文
LinearGradient StartPoint EndPoint StartColor EndColor
を使用して彼ら自身の２色の線形勾配を明示的に記述することが可能であり、ここでStartPointおよびEndPointは開始および終了座標であって、それぞれの座標が０．１，０．１および０．５，０．５などの０から１までのｘ値とｙ値のペアとして表される。これらの値は始点または終点の相対位置を示し、０．５，０．５の終点は、塗りつぶし領域の右まで５０パーセント、領域の上部からの距離の５０パーセントで配置され、この点が形状の中央になるように位置付けられる。
【００９３】
以下の例で、Rectangle要素のFillプロパティは線形勾配を使用して明示的に設定される。
【００９４】
【表１８】
【００９５】
以下の例に、省略された構文を使用して２色の放射勾配で領域を塗りつぶす方法を示す。
【００９６】
【表１９】
【００９７】
Fill属性に加え、勾配を使用してShape要素のStrokeなどのオブジェクトの輪郭を塗りつぶすこともできる。
【００９８】
描画ブラシとは、形状またはコントロールを、他の形状およびブラシの組合せで塗りつぶすことができるようにするものである。通常のShape要素とは異なり、DrawingBrush内部のShapeは要素ツリーの中の要素ではない。その代わりに、媒体レイヤによって直接解析およびレンダリングされる。その結果、ユーザインターフェースの一部が多くの形状からなる場合、性能を大幅に向上されることができる。
【００９９】
描画ブラシはタイルブラシの一種である。ここでは、開発者が描画ブラシをどのようにコントロールして出力領域を塗りつぶすことができるかについて、追加の機能に関する情報を提供する。
【０１００】
ImageBrushは、領域をビットマップ画像で塗りつぶすものである。以下のサンプルでは、ImageBrushを使用して画像をCanvasの背景としてレンダリングする方法を示す。
【０１０１】
【表２０】
【０１０２】
画像ブラシはタイルブラシの一種である。このセクションでは、画像がどのように出力領域を塗りつぶすかをコントロールするのに開発者が使用できる追加の機能に関する情報を提供する。
【０１０３】
DrawingBrushおよびImageBrushはどちらもタイルブラシの一種である（TileBrushクラスから導出する）。したがって、開発者が領域の塗りつぶし方法をかなり詳細にコントロールすることのできる、共通の機能集合を有する。たとえば、開発者は、単に引伸ばされた画像で領域を塗りつぶすのではなく、パターンを作成する一連の画像タイルで領域を塗りつぶすことができる。
【０１０４】
タイルブラシは、コンテンツで塗りつぶされた１つまたは複数のタイルを記述するものである。ImageBrushは、そのタイルをビットマップ画像で塗りつぶすタイルブラシである。DrawingBrushは、そのタイルを描画で塗りつぶすタイルブラシである。
【０１０５】
タイルブラシは、開発者に２つのレベルのコントロールを提供するため、開発者はブラシのコンテンツがそのタイルをどのように塗りつぶすかをコントロールすることが可能であり、その開発者はブラシのタイルが領域をどのように塗りつぶすかをコントロールすることができる。デフォルト時には、タイルブラシは出力領域を単一のタイルで塗りつぶし、ブラシのコンテンツはそのタイルを塗りつぶすように引伸ばされる。開発者がこのデフォルトの挙動を上書きできるようにするプロパティの中には、Stretch、ViewPort、およびViewBoxのプロパティがある。（図１８を参照しながら以下でも説明する）Stretchプロパティは、ブラシのコンテンツがそのタイルをどのように塗りつぶすかを定義する。ViewPortはブラシのタイルのサイズおよび位置を定義し、ViewBoxプロパティはブラシのコンテンツのサイズおよび位置を決定する。
【０１０６】
Stretchプロパティは、タイルブラシのコンテンツがそのタイルを塗りつぶすためにどのように引伸ばされるかをコントロールする。Stretchプロパティは、Stretch列挙法で定義された以下の値を受け入れる。
None: ブラシのコンテンツはタイルを塗りつぶすために引伸ばされない。
Fill: ブラシのコンテンツはタイルに合うように縮尺される。コンテンツの高さおよび幅は別個に縮尺されるため、コンテンツのオリジナルのアスペクト比が保持されない可能性がある。すなわち、出力タイルを完全に塗りつぶすために、ブラシのコンテンツが歪められる場合がある。
Uniform: ブラシのコンテンツは、タイル内に完全にはまるように縮尺される。コンテンツのアスペクト比は保持される。
UniformToFill: ブラシのコンテンツは出力領域を完全に塗りつぶすように縮尺される一方で、コンテンツのオリジナルのアスペクト比は保持される。
【０１０７】
HorizontalAlignmentおよびVerticalAlignmentプロパティは、タイルブラシのコンテンツがそのタイル内でどのように位置合わせされるかを決定する。HorizontalAlignmentプロパティは、HorizontalAlignment列挙法で定義された、Left、Center、およびRightの値を受け入れる。VerticalAlignmentプロパティは、VerticalAlignment列挙法で定義された、Top、Center、およびBottomの値を受け入れる。
【０１０８】
ViewPortプロパティは、ブラシのタイルのサイズおよび位置を決定する。ViewPortUnitsプロパティは、ViewPortが絶対座標または相対座標のどちらを使用して指定されるかを決定する。相対座標の場合、出力領域のサイズに比例する。ポイント（０，０）は出力領域の左上コーナを表し、（１，１）は出力領域の右下コーナを表す。ViewPortプロパティが絶対座標を使用するように指定するためには、ViewPortUnitsプロパティをAbsoluteに設定する。
【０１０９】
以下の例では、幅および高さが１００であり、その左上コーナが（０，０）にあるタイルが、画像を使用して作成される。
【０１１０】
【表２１】
【０１１１】
ブラシのコンテンツのサイズおよび位置は、ViewBoxプロパティを使用して指定することができる。タイルブラシのタイルが出力領域を完全に塗りつぶしていない場合、そのTileModeプロパティが残りの出力領域をどのように塗りつぶすかを指定する。TileModeプロパティは、TileMode列挙法で定義された以下の値を受け入れる。
None: 基本タイルのみが描画される。
Tile: 基本タイルが描画され、残りの領域は、１つのタイルの右縁が次のタイルの左縁に隣接し、下と上も同様に隣接するように、基本タイルを反復することによって塗りつぶされる。
FlipX: Tileと同様であるが、タイルの交互の列が水平に反転される。
FlipY: Tileと同様であるが、タイルの交互の行が垂直に反転される。
FlipXY: FlipXおよびFlipYの組合せ。
【０１１２】
様々なタイリングモードについて、図１９を参照しながら以下で説明する。
【０１１３】
図１７を参照しながら以下で説明するNineGridBrushは、領域をビットマップ画像で塗りつぶすという点が画像ブラシと非常によく似ている。しかし、NineGridBrushでは、画像は４本の境界によって９つの領域またはグリッドに分けられる。詳細な情報については、NineGridBrushのページを参照されたい。
【０１１４】
図３および４はそれぞれ、Visualと呼ばれる基本オブジェクトを含むシーングラフ３００および４００の例を示す図である。映像オブジェクトまたは単に映像は、線分、テキスト、および画像などのグラフィカルコンテンツ用のコンテナである。図５のVisualクラスのオブジェクト継承で示されるように、グラフィカルコンテンツを直接含まないが子Drawing Visualオブジェクトを含むContainerVisualを含む、いくつかの異なる映像オブジェクトがある。子Drawing Visualオブジェクトは、他のDrawingVisualオブジェクトではなく、ContainerVisualに追加される。これによって開発者は、全体の描画コンテキストを再作成およびその後の再レンダリングすることなく、個々の映像オブジェクトのプロパティを変更および設定することが可能であり、同時に、コンテナオブジェクトのクリッピングおよび変形プロパティにアクセスすることもできる。ContainerVisualオブジェクトは入れ子にすることができる。
【０１１５】
DrawingVisualとは、グラフィカルコンテンツを格納することのできるVisualのことである。このVisualはいくつかの描画方法を公開する。DrawingVisualの子オブジェクトは、ゼロベースまたはｚオーダの空間で編成される。RetainedVisualとは、描画に使用できる「保持された命令ストリーム」を導入するVisualのことである。簡単に言うと、RetainedVisualは、開発者が映像のコンテンツを保持し、必要なときだけこれを再描画できるようにするものである。RetainedVisualはDrawingVisualと同様に、RenderOpenを呼び出すことおよび戻されたDrawingContextを描画に使用することによって、命令的に使用することができる。RetainedVisualは、妥当性検査コールバック機能およびInvalidateVisualメソッドを提供する。妥当性検査機能を使用するために、ユーザは、RetainedVisualまたはそれから導出されたクラスでIRetainedRenderインターフェースを実施する。
【０１１６】
図５に戻ると、さらに他の映像HwndVisual 505があり、これは従来のＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎ３２（登録商標）のコントロールまたはウィンドウを、シーングラフの映像シーン内で子映像としてホストするために使用される映像である。より具体的に言えば、依然として古いプログラムが、以前のグラフィックス技術に基づいて子HWnd（または同様のもの）を描画するWM_PAINTメソッド（または同様のもの）を介して動作することになる。こうしたプログラムを新しいグラフィックス処理モデルでサポートするために、HwndVisualはHwndがシーングラフ内に格納され、親映像の再配置に従って移動されるようにすることができる。２次元世界と３次元世界を接続することのできる３次元（３Ｄ）映像などの、他の型の映像も実現可能であり、たとえばカメラのようなビューが２次元映像を介して３次元世界にビューを入れることが可能である。
【０１１７】
図３に示されるように、映像マネージャ３０４は、映像ツリーを媒体に接続するオブジェクトを備える。映像マネージャは、映像データ構造（ルート映像３０２）とそのデータのレンダリング先である対象との間に保持された接続を確立し、その２つの相違点を追跡する機能を提供する。映像マネージャ３０４はウィンドウメッセージを受け取り、描画座標内の１つのポイントを装置座標に変形するための方法、およびその逆を提供する。
【０１１８】
典型的なアプリケーションは、前述のように（たとえば、特許文献４参照）「ＸＡＭＬ」でレイアウトを定義することによって、さらにまた何らかの描画オペレーションをＣ＃で指定することによって、グラフィックスを描画することができる。開発者は、Shape要素を作成するか、またはプリミティブを備えたGeometryクラスを使用して幾何学形状を描画することができる。以下のシナリオでは、コードはCanvasの下にあるVisualでの楕円の描画を実演する。
【０１１９】
【表２２】
【０１２０】
代わりに開発者は、映像ＡＰＩを使用してVisualに直接描画することができる（そうでなければLayout要素を介してアクセスされることになる）。
【０１２１】
DrawingVisualオブジェクトのコンテンツをレンダリングするために、通常、アプリケーションはDrawingVisualでRenderOpenメソッドを呼び出す。RenderOpenはDrawingContextを戻し、アプリケーションはこれを使用して描画オペレーションを実行することができる。Visualのコンテンツを消去する場合、アプリケーションはDrawingContextでCloseを呼び出す。アプリケーションがCloseを呼び出すと、その後DrawingContextは使用できなくなる。
【０１２２】
以下のコードは、楕円形状ではなくGeometryオブジェクトを使用して、DrawingVisualに楕円（前の例と同じ楕円）を描画するものである。この例では、DrawingVisualを作成し、DrawingVisualのDrawingContextを取得し、DrawingContextのDrawGeometryメソッドを呼び出して楕円を描画する。開発者は、この場合はウィンドウであるトップレベルオブジェクトの映像ツリーに、Visualを追加する必要があることに留意されたい。
【０１２３】
【表２３】
【０１２４】
以下の例は、同様の楕円をContainerVisualに追加することによって、前の例にさらに構築するものであり、この例はわかりやすくするために冗長であることに留意されたい。ContainerVisualを使用すると、シーンオブジェクトを編成する際に役立ち、開発者がヒットテストまたは妥当性検査（RetainedVisualオブジェクト）を実行するために、Visualオブジェクトを通常の描画コンテンツから分離し、コンテンツの不必要な再描画を最小限に抑えることができる。
【０１２５】
【表２４−１】
【０１２６】
【表２４−２】
【０１２７】
【表２４−３】
【０１２８】
RetainedVisualはDrawingVisualと似ているが、映像コンテンツの選択的な再描画が可能である。その名前が示唆するように、RetainedVisualはコンテンツを媒体上で複数出現させるために保持することができる。また、コールバックおよび妥当性検査機能も提供する。この機能は、コンテンツの再レンダリングを介して開発者により多くのコントロールを提供することで、レンダリングの実行を助けることができる。
【０１２９】
基本レベルでは、ユーザはRetainedVisualをDrawingVisualとほとんど同様に作成および使用することが可能であり、すなわちユーザはRenderOpenを呼び出してDrawingContextを取得することができる。別法として、ユーザはRetainedVisualでIRetainedRenderインターフェースを実施することができる。そのように実行することにより、ユーザは、グラフィックスシステムがRenderBoundsプロパティに設定された値をIRetainedVisual.Render呼出しでレンダリングされるコンテンツの境界として確実に使用できるようにする。
【０１３０】
シーンをレンダリングする場合、グラフィックスシステムは任意の子Visualを検査することになる。RenderBoundsプロパティの値が、シーンをレンダリングする際に特定のVisualのコンテンツが必要となることを示す場合、システムはIRetainedVisual.Renderを呼び出してVisualのコンテンツを塗りつぶし、すでにメモリ内にある任意のコンテンツを置き換えることになる。アプリケーションは、InvalidateVisualを呼び出して、Visualからコンテンツを直接フラッシュする（ｆｌｕｓｈ）こともできる。アプリケーションがRetainedVisualでIRetainedRenderを実施しなかった場合、InvalidateVisualへのいずれの呼出しも例外処理を実行することになる。
【０１３１】
以下のコードは、RetainedVisualでIRetainedRenderを実施し、それに描画するクラスをインスタンス化するものである。
【０１３２】
【表２５】
【０１３３】
映像ＡＰＩは、本発明のグラフィックスシステムの残りの部分と同様に管理されたＡＰＩであり、強力なタイピングおよびガーベッジ集合を含む管理されたコードの典型的な機能を使用する。また、レンダリングのためのハードウェア加速機能も利用する。既存の管理されていないアプリケーションを使用して作業を行う開発者に対処するために、映像ＡＰＩは、本グラフィックスシステムとＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）のＧｒａｐｈｉｃｓ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ（ＧＤＩ）ベースのレンダリングサービスとの間に限られた相互運用性を提供する。
【０１３４】
この相互運用性により、開発者は、本発明の描画およびレンダリングに基づいたHwnd Visualオブジェクト、書込み制御、およびテーマ化を使用して、映像認識アプリケーションでＧＤＩベースのウィンドウをホストするが、依然として古いＧＤＩアプリケーションで動作し、ハードウェア加速およびカラーモデルを含む新しいレンダリング機能を利用するようにＧＤＩ ＨＷＮＤベースのアプリケーションを修正することができる。
【０１３５】
HwndVisualは、Ｗｉｎ３２コンテンツを映像認識アプリケーションでホストできるようにするものである。図５に示されるように、HwndVisualはContainerVisualを継承する。ＧＤＩと新しい描画モデルとを同じHwndVisualで混合できないことに留意されたい。代わりに、この映像は、制限された範囲の古いコントロールにはより役立つ可能性がある。以下の例では、HwndVisualでコントロールを作成することおよびそれを映像ツリーに追加することを実演する。
【０１３６】
【表２６】
【０１３７】
他のオブジェクトの場合と同様に、開発者は、Visualでいったんホストされると変形および他のプロパティの変更をコントロールに適用することが可能である。
【０１３８】
【表２７】
【０１３９】
図３に示されるように、トップレベル（またはルート）のVisual３０２は映像マネージャオブジェクト３０４に接続され、これは（たとえばハンドルを介して）、ウィンドウ（Hwnd）３０６またはプログラムコード用にグラフィックデータが出力される同様の単位との関係も有する。映像マネージャ３０４は、トップレベルのVisual（およびそのVisualの任意の子）のそのウィンドウ３０６への描画を管理する。図６は、本明細書に記載されたグラフィックスシステムのオブジェクトモデルにおけるオブジェクトの集合６００のうちの１つとしての映像マネージャを示す図である。
【０１４０】
描画する際、映像マネージャ３０４は、前述の米国特許出願に全体として記載されたように、ディスパッチャ３０８がスケジュールしたようにシーングラフを処理（たとえば、トラバースまたは伝送）し、低いレベルのコンポーネント２１８（図２）へのグラフィックス命令および他のデータをその対応するウィンドウ３０６に提供する。シーングラフの処理は、通常、低いレベルのコンポーネント２１８および／またはグラフィックスサブシステム２２２のリフレッシュ速度よりも比較的遅い速度で、ディスパッチャ３０８によってスケジュールされることになる。
【０１４１】
図３は、トップレベル（ルート）Visual３０２の下に階層状に配置構成された、いくつかの子Visual３１０〜３１４を示す図であり、その一部は、たとえば命令リストおよび他のVisualを含む関連するそれぞれの命令リスト３１８および３１９と共に、（その一時的な性質を表すために破線の四角で示された）描画コンテキスト３１６、３１７を介して読み込まれたように表されている。Visualは他のプロパティ情報を含むこともできる。一般に、基本映像クラスでのほとんどのアクセスは、IVisualインターフェースを介して行われ、Visualは図５に示されるようにDependencyObjectから導出される。他の描画プリミティブの中で、命令リストはImageDataへの参照を含むことができる。その後、そのImageDataは、描画コンテキストをそれから取得することによって、またはSurfaceVisualRender（あるいはImageDataVisualRendererと名付けられた）を有することによって、直接変更／更新することができる。
【０１４２】
Visualは、クリップ、不透明度、ならびに、ゲットメソッドを介して設定および／または読み取ることのできる可能な他のプロパティを提供することによって、サービスを提供する。さらにVisualは、どのようにヒットテストに参加するかをコントロールするフラグを有する。Showプロパティを使用してVisualが表示／非表示となり、たとえばｆａｌｓｅの場合Visualは不可視であり、そうでない場合Visualは可視である。さらに、これらのオブジェクト（映像ＡＰＩレイヤのVisualかまたは要素レイヤの要素）は、階層状に存在する。座標系はこの階層を下に向かって継承される。この場合、親は、レンダリングする軌跡を修正してその親の子に適用させる座標変形を強要することができる。
【０１４３】
Visual用の変形は、そのVisualへの接続上にある。つまり、親のIVisualインターフェース上で[Get|Set]ChildTransformを介して設定される。
【０１４４】
座標変形は、あたかもビットマップに対して行なわれるかのように、一様な方法であらゆるものに適用可能であることに留意されたい。これは、変形は常にビットマップに適用されるが、レンダリングされるものが等しく変形の影響を受けることを意味するものでないことに留意されたい。例を挙げると、ユーザが１インチ（約２．５４ｃｍ）幅の丸いペンを使用して円を描画し、Ｘ方向にその円の２倍のスケールを適用した場合、ペンは左右は２インチ（約５．０８ｃｍ）幅、上下は１インチ（約２．５４ｃｍ）幅のみとなる。これは、時に（ジオメトリのみに影響を与えるスケルトンまたはジオメトリスケールとは対照的に）合成またはビットマップ変形と呼ばれることがある。図８に、非変形画像８００を左側に示し、非均一スケールの変形済み画像８０２を右側に表すスケーリング変形を示す。図９には、非変形画像８００を左側に示し、ジオメトリスケーリングの変形済み画像９０４を右側に示すスケーリング変形を示す。
【０１４５】
映像の座標変形に関して、TransformToDescendantはポイントを基準映像から下位映像へと変形する。ポイントは、基準映像の変形後座標空間から下位映像の変形後座標空間へと変形される。TransformFromDescendantは、ポイントを下位映像から親チェーンを上方に基準映像まで変形する。ポイントは、下位映像の変形後座標空間から基準映像の変形後座標空間へと変形される。ユーザは、下位へおよび下位から、ならびにいずれかの任意映像からおよび任意映像への、行列を取得することができる。Visualのコンテンツの境界ボックスを決定するために使用できる２つのプロパティ、すなわち下位の境界ボックスであるDescendantBounds、およびコンテンツの境界であるContentBoundsが使用可能である。これらにUnionを適用すると、全体の境界が与えられる。
【０１４６】
クリッププロパティは、Visualのクリッピング領域を設定（および取得）する。任意のGeometry（Geometryクラスは図１０に示されている）をクリッピング領域として使用することが可能であり、クリッピング領域は変形後座標空間で適用される。一実施態様では、クリッピング領域に関するデフォルト設定はｎｕｌｌ、すなわちクリッピングなしであり、これは無限大のクリッピング矩形（−∞，−∞）から（＋∞，＋∞）とみなすことができる。
【０１４７】
不透明度プロパティは、Visualのコンテンツが不透明度値および選択された混合モードに基づいて描画表面で混ぜ合わされるように、Visualの不透明度値を取得／設定する。BlendModeプロパティを使用して、使用される混合モードを設定（または取得）することができる。たとえば、不透明度（アルファ）値は０．０から０．１の間に設定し、線形アルファ混合を、たとえば、Color = alpha * foreground color + (1.0-alpha)*background color)のモードとして設定することができる。たとえば、ぼかし、モノクロなどの特殊効果プロパティなどの他のサービスを、Visualに含めることができる。
【０１４８】
（変形、不透明度、およびクリップを含む）様々なサービスを描画コンテンツ上でプッシュ（ｐｕｓｈ）およびポップ（ｐｏｐ）させることが可能であり、プッシュ／ポップオペレーションは、各プッシュ呼出しに対して適切なポップ呼出しがある限り、入れ子にすることができる。
【０１４９】
PushTransformメソッドは、変形をプッシュする。後続の描画オペレーションは、プッシュされた変形を基準にして実行される。ポップ呼出しは、以下のように、合致するPushTransform呼出しによってプッシュされた変形をポップする。
【０１５０】
【表２８】
【０１５１】
同様に、PushOpacityメソッドは、不透明度値をプッシュする。後続の描画オペレーションは、指定された不透明度値を使用して一時表面上でレンダリングされ、シーンに合成される。Pop( )は、以下のように、合致するPushOpacity呼出しによってプッシュされた不透明度をポップする。
【０１５２】
【表２９】
【０１５３】
PushClipメソッドは、クリッピングジオメトリをプッシュする。後続の描画オペレーションはジオメトリにクリップされる。クリッピングは、変形後空間に適用される。Pop( )は、以下のように、合致するPushClip呼出しによってプッシュされたクリッピング領域をポップする。
【０１５４】
【表３０】
【０１５５】
プッシュオペレーションは、ポップオペレーションがプッシュと合致する限り、任意に入れ子にできることに留意されたい。たとえば、以下は有効である。
【０１５６】
【表３１】
【０１５７】
ProxyVisualは、シーングラフ、たとえばContainer Visualの下に、複数回追加することのできるVisualである。ProxyVisualによって参照される任意のVisualには、ルートからの複数のパスを通すことが可能であるため、読取りサービス（TransformToDescendent、TransformFromDescendent、およびHitTest）はProxyVisualを介して動作しない。実際のところ、任意のVisualから映像ツリーのルートへの標準パスが１つあり、そのパスはいずれのProxyVisualも含まない。
【０１５８】
図４に、ContainerVisualおよびDrawingVisual（およびその他）がシーングラフ内で関連しており、（たとえば対応する描画コンテキスト内に）命令リストの形の関連するデータを有するシーングラフ４００の一例を示す。ContainerVisualはVisual用のコンテナであり、ContainerVisualは互いに入れ子にすることができる。ContainerVisualの子は、ContainerVisualを実施するIVisualインターフェース上のメソッドを介して操作することができる。VisualCollection内のVisualの順序が、Visualがレンダリングされる順番を決定するものであり、すなわち、Visualは最下位のインデックスから最高位のインデックスへと、後ろから前へレンダリングされる（ペインティング順序）。
【０１５９】
前述のように、Visualは、Geometry、ImageSource、およびMediaDataを含む様々な描画プリミティブと共に、その描画コンテキストを読み込むことによって描画することができる。さらに、このスタック全体を通じて共用されるリソースおよびクラスの集合がある。これには、Pen、Brush、Geometry、Transform、およびEffectが含まれる。DrawingContext抽象クラスは、DrawingVisual、ValidationVisual、ImageDataなどを読み込むために使用できる描画オペレーションの集合を公開する。言い換えれば、DrawingContext抽象クラスは描画オペレーションの集合を公開し、各描画オペレーションについて、定数を引数として取る方法とアニメータを引数として取る方法の２つがある。
【０１６０】
Geometryは、ストロークまたは塗りつぶしなしでベクトルグラフィックススケルトンを定義するクラスの一種である（図１０）。各Geometryオブジェクトは単純な形状（LineGeometry、EllipseGeometry、RectangleGeometry）、複雑な単一形状（PathGeometry）、または組合せオペレーション（たとえば合併、交差など）が指定されたこうした形状のリストGeometryCollectionである。これらのオブジェクトは、図１０に示されるようなクラス階層を形成する。
【０１６１】
図１１に示すように、PathGeometryは、Figureオブジェクトの集合である。ここでは、それぞれのFigureオブジェクトが、実際に図の形状を定義する１つまたは複数のSegmentオブジェクトからなる。Figureとは、セグメント集合を定義するGeometryのサブセクションである。このセグメント集合は、単一の関連した一連の２次元Segmentオブジェクトシリーズである。Figureは、領域が定義されたクローズ形状、または曲線は定義するが領域はクローズでない接続された一連のSegmentのみの、いずれかが可能である。
【０１６２】
図１２に示されるように、ジオメトリ（たとえば矩形）を描画する場合、以下で説明するようにブラシまたはペンを指定することができる。さらに、PenオブジェクトはBrushオブジェクトも有する。Brushオブジェクトはグラフィックで平面を塗りつぶす方法を定義するものであり、クラス階層のBrushオブジェクトがある。これを図１２に、矩形およびブラシの命令およびパラメータを含む映像が処理されると、結果として生じる塗りつぶされた矩形１２０２として示す。Penオブジェクトは、以下で説明するように、BrushならびにWidth、LineJoin、LineCap、MiterLimit、DashArray、およびDashOffsetに関するプロパティ上で保持される。さらに以下で説明するように、（勾配および９グリッドなどの）Brush型の中には、それ自体でサイズを決めるものもある。これらのBrushが使用される場合、そのサイズは境界ボックスから取得される。たとえば、Brush用のGradientUnits／DestinationUnitsがRelativeToBoundingBoxに設定されている場合、描画されているプリミティブの境界ボックスが使用される。これらのプロパティがAbsoluteに設定された場合、座標空間が使用される。
【０１６３】
本発明のグラフィックスオブジェクトモデルには、Brushオブジェクトモデルが含まれ、これは一般に平面をピクセルでカバーするという概念を対象としている。Brush型の例は、図１３でBrush基本クラスの下に階層状に示されており、GradientBrush、NineGridBrush、SolidColorBrush、およびTileBrushが含まれる。GradientBrushには、LinearGradientおよびRadialGradientのオブジェクトが含まれる。DrawingBrushおよびImageBrushはTileBrushから導出される。クラスの代替の配置構成が実現可能であり、たとえばTileBrushからImageBrush、VisualBrush、VideoBrush、NineGridBrush、およびDrawingBrushを導出することができる。Brushオブジェクトは、それらが使用される場合に座標系にどのように関係するか、および／またはそれらが使用される形状の境界ボックスにそれらがどのように関係するかを認識できることに留意されたい。一般に、サイズなどの情報は、ブラシが描画されるオブジェクトから推測することができる。より詳細には、Brush型の多くがそれらのパラメータの一部を指定する際に座標系を使用する。この座標系は、Brushが適用される形状の単純な境界ボックスを基準に定義するか、またはブラシが使用される時点でアクティブな座標空間を基準に定義することが可能である。これらはそれぞれ、RelativeToBoundingBoxモードおよびAbsoluteモードとして知られている。
【０１６４】
SolidColorBrushオブジェクトは、識別された平面をソリッドカラーで塗りつぶす。色のアルファコンポーネントがある場合、これは、倍加する方法でBrush基本クラスの対応する不透明度属性と組み合わされる。以下に、SolidColorBrushオブジェクトの例を示す。
【０１６５】
【表３２】
【０１６６】
GradientBrushオブジェクトまたは単にGradientは勾配塗りつぶしを行い、何らかの進行に沿って色を指定する勾配停止の集合を指定することによって描画されるものである。Gradientは、ガンマ２．２ＲＧＢ色空間で勾配停止間の線形補間を実行することによって描画されるが、代わりに他のガンマまたは他の色空間（ＨＳＢ、ＣＭＹＫなど）を介した補間を実行することもできる。この２つの型のGradientオブジェクトには、線形勾配および放射勾配が含まれる。
【０１６７】
一般に、Gradientは勾配停止のリストからなる。これらの勾配停止は、それぞれ色（アルファ値が含まれる）およびオフセットを含む。指定された勾配停止がない場合、ブラシは、あたかもブラシがまったく指定されていないかのように濃淡のない透明な黒として描画される。勾配停止が１つだけ指定された場合、ブラシは１色だけ指定されたソリッドカラーとして描画される。「Ｃｈａｎｇｅａｂｌｅ Ｃｌａｓｓ ａｎｄ Ｐａｔｔｅｒｎ ｔｏ Ｐｒｏｖｉｄｅ Ｓｅｌｅｃｔｉｖｅ Ｍｕｔａｂｉｌｉｔｙ ｉｎ Ｃｏｍｐｕｔｅｒ Ｐｒｏｇｒａｍｍｉｎｇ Ｅｎｖｉｒｏｎｍｅｎｔｓ」という名称の米国特許出願に記載されているように、勾配停止クラス（下記の表の例）は他のリソースクラスと同様に変更可能クラスから導出されるため、選択的に可変である。
【０１６８】
Gradientは勾配停止の集合を指定することによって描画される。これらの勾配停止は、何らかの連続した色を指定する。現在サポートされている勾配には２つの型、すなわち線形勾配および放射勾配がある。Gradientは、指定された色空間内の勾配停止間で補間を実行することによって描画される。
【０１６９】
Gradientは、勾配停止のリストからなる。これらの勾配停止はそれぞれ、色（アルファ値が含まれる）およびオフセットを含む。指定された勾配停止がない場合、ブラシは（あたかもブラシがまったく指定されていないかのように）透明として描画される。勾配停止が１つだけ指定された場合、ブラシは１色だけ指定されたソリッドカラーとして描画される。０から１の範囲内（０．０．．．１．０）のオフセットを備えた任意の勾配停止が考慮の対象とされ、最大の停止は（−∞．．．０．０］、最小の停止は［１．０．．．＋∞）である。考慮の対象とされる停止の集合に０から１の範囲外にある停止が含まれる場合、暗黙の停止として０（および／または１）が導出され、これがこの停止で発生することになる補間された色を表す。さらに、２つまたはそれ以上の停止が同じオフセットで設定される場合、そのオフセットで（補間済みでない）ハード遷移が発生する。停止が追加される順序によって、このオフセットでの挙動が決められ、追加される最初の停止はそのオフセットの前の有効な色であり、設定される最後の停止はこの停止の後の有効な色であり、このオフセットでのいずれの追加の停止も無視される。
【０１７０】
このクラスは、他のリソースクラスと同様にChangeableである。
【０１７１】
【表３３】
【０１７２】
SolidColorBrushと同様に、これはChangeablesをアニメーション集合内に入れ子にする。
【０１７３】
GradientSpreadMethod 列挙法は、指定されたベクトルまたは空間の外で勾配がどのように描画されるべきかを指定する。可能な値には、末端（最初および最後）の色を使用して残りの空間が塗りつぶされるPadと、停止を逆の順序で繰り返し再生して空間が塗りつぶされるReflectと、停止を順番に繰り返して空間が塗りつぶされるRepeatの、３つの値が含まれる。この型のプロパティのデフォルト値はPadである。
【０１７４】
【表３４】
【０１７５】
図１４および１５は、いくつかのGradientSpreadMethodの例（たとえ色でなくグレースケールの場合であっても）を提供する。各形状が、白からグレーに移行する線形勾配を有する。実線が勾配ベクトルを表す。
【０１７６】
一般に、LinearGradientBrushを使用して領域を線形勾配で塗りつぶす。線形勾配とは、線分に沿って勾配を定義するものである。線形勾配のStartPointおよびEndPointプロパティによって、線分の末端が定義される。デフォルト時には、線形勾配のStartPointは（０，０）であって領域の左上コーナが塗りつぶされ、そのEndPointは（１，１）であって領域の右下コーナが塗りつぶされる。図１５に示されるように、デフォルトの値を使用すると、結果として生じる勾配の色は斜めの軌跡に沿って補間される。本明細書では、勾配の補間軌跡をハイライト表示するために、勾配の始点および終点から形成された黒い線分が追加されている。
【０１７７】
ColorInterpolationMode列挙法は、勾配内の色に対して補間モードを定義する。PhysicallyLinearGamma10およびPerceptuallyLinearGamma22の２つのオプションがある。
【０１７８】
【表３５】
【０１７９】
これは抽象基本クラスである。
【０１８０】
【表３６】
【０１８１】
Changeablesの項で説明したように、GradientBrushはそのGradientStopsプロパティそれ自体がChangeablesを保持するので、Changeablesに関して複合型である。これは、GradientBrushが、保護されたメソッドMakeUnchangeableCore( )とPropagateEventHandler( )、ならびにChangeableサブクラスが実施するCloneCore( )とを実施する必要があることを意味する。たとえば集合を構成するGradientStopsの無効な組合せがある場合、ValidateObjectState( )を実施するように選択することもできる。
【０１８２】
LinearGradientは、ベクトルに沿って線形勾配ブラシを指定する。個々の停止は、そのベクトルに沿ってカラーストップを指定する。
【０１８３】
【表３７−１】
【０１８４】
【表３７−２】
【０１８５】
LinearGradient用のマークアップは、０および１のオフセットで２つのカラーストップを使用してLinearGradientを指定することが可能である。「LinearGradient」バージョンが使用される場合、それぞれ始点および終点が指定される。「HorizontalGradient」が使用される場合、始点は０，０に設定され、終点は１，０に設定される。「VerticalGradient」が使用される場合、始点は０，０に設定され、終点は０，１に設定される。これらの場合、RelativeToBoundingBoxというデフォルトのMappingModeが使用される。
【０１８６】
RadialGradientは、プログラミングモデルでは線形勾配と同様である。しかし、線形勾配は勾配ベクトルを定義するための始点および終点を有するのに対して、放射勾配は勾配の挙動を定義するための円ならびに焦点を有する。円は勾配の終点を定義しており、言い換えれば、１．０の勾配停止は円の周囲の色を定義する。焦点は勾配の中心を定義する。０．０の勾配停止は焦点の色を定義する。図１６は、白からグレーへと（グレースケールで）進むRadialGradientを表す。外側の円は勾配円を表し、中実のドットは焦点を示す。この勾配は、SpreadMethodがPadに設定されている。
【０１８７】
【表３８−１】
【０１８８】
【表３８−２】
【０１８９】
RadialGradient用のマークアップは、それぞれ０および１のオフセットで２つのカラーストップを使用してRadialGradientを指定することが可能である。デフォルトの半径が０．５である場合、RelativeToBoundingBoxというデフォルトのMappingModeが使用される。
【０１９０】
【表３９】
【０１９１】
TileBrushは、タイルを記述する論理とタイルが領域を塗りつぶす際に使用する手段とを含む抽象基本クラスである。TileBrushのサブクラスはコンテンツを含み、無限の平面を塗りつぶす方法を論理的に定義する。
【０１９２】
Stretch列挙法を使用して、ViewBox（ソース座標空間）をViewPort（宛先座標空間）にマッピングする方法を記述する。これはTileBrushで使用される。
【０１９３】
【表４０】
【０１９４】
図１８に、引伸ばし（ｓｔｒｅｔｃｈ）の例を示す。これらの例では、コンテンツは左／上に位置合わせをされる。
【０１９５】
TileMode列挙法を使用して、Tileで空間を塗りつぶすのか、およびどの様に塗りつぶすのかを記述する。TileBrushは、基本Tileが（ViewPortによって指定される）場所を定義する。残りの空間はTileMode値に基づいて塗りつぶされる。
【０１９６】
【表４１】
【０１９７】
図１９は、TileModeの例を提供する。各例の一番左上のタイルが基本タイルである。これらの例は、None、Tile、FlipX、FlipY、およびFlipXYを表す。
【０１９８】
VerticalAlignment列挙法を使用して、コンテナ内でコンテンツを垂直に配置する方法を記述する。
【０１９９】
【表４２】
【０２００】
HorizontalAlignment列挙法を使用して、コンテナ内でコンテンツを水平に配置する方法を記述する。
【０２０１】
【表４３】
【０２０２】
TileBrushプロパティは、タイル（ViewBox）となる無限の平面の矩形部分を選択し、塗りつぶされる領域内の基本タイルとなる宛先矩形（ViewPort）を記述する。残っている宛先領域は、TileModeプロパティに基づいて塗りつぶされることになり、これが残っている空間を塗りつぶすためにオリジナルタイルが複製されるのか、およびどの様に複製されるのかを制御する。
【０２０３】
【表４４−１】
【０２０４】
【表４４−２】
【０２０５】
TileBrushのコンテンツには固有の境界がなく、無限の平面を効果的に記述する。これらのコンテンツは、それ自身の座標空間内に存在し、TileBrushによって塗りつぶされている空間は適用時のローカル座標空間である。コンテンツ空間は、ViewBox、ViewPort、Alignment、およびStretchのプロパティに基づいてローカル空間にマッピングされる。ViewBoxはコンテンツ空間内に指定され、この矩形はViewPort矩形にマッピングされる。
【０２０６】
ViewPortは、コンテンツが最終的に描画される場所を定義し、このBrush用の基本タイルを作成する。ViewPortUnitsの値がAbsoluteである場合、ViewPortの値は適用時にローカル空間内にあるものとみなされる。代わりに、ViewPortUnitsの値がRelativeToBoundingBoxである場合、ViewPortの値は座標空間内にあるものとみなされ、０，０はペイントされているオブジェクトの境界ボックスの左／上コーナであり、１，１は同じボックスの右／下コーナである。たとえば、１００，１００から２００，２００まで描画されたRectangleGeometryが塗りつぶされていると考えてみる。次に、ViewPortUnitsがAbsoluteである場合、ViewPort（１００，１００，１００，１００）がコンテンツ領域全体を記述することになる。ViewPortUnitsがRelativeToBoundingBoxである場合、ViewPort（０，０，１，１）がコンテンツ領域全体を記述することになる。ViewPortのSizeが空であり、StretchがNoneでない場合、このBrushは何もレンダリングしない。
【０２０７】
ViewBoxは、コンテンツ空間内に指定される。この矩形は、AlignmentプロパティおよびStretchプロパティによって決定されたViewPort内に収まるように変形される。Stretchがnoneの場合、コンテンツには何の縮尺も適用されない。StretchがFillの場合、ViewBoxはViewPortと同じサイズになるようにXおよびYの両方で別個に縮尺される。StretchがUniformまたはUniformToFillの場合、論理は同じであるが、XおよびYの寸法は均一に縮尺され、コンテンツのアスペクト比を保持する。StretchがUniformの場合、ViewBoxは、ViewPortのサイズに等しい、より多くの制約付き寸法を有するように縮尺される。StretchがUniformToFillの場合、ViewBoxはViewPortのサイズに等しい、より少ない制約付き寸法を有するように縮尺される。別の見方をすると、UniformとUniformToFillはどちらもアスペクト比を保持するが、UniformはViewBox全体がViewPort内にあることを保証し（場合によっては、ViewPortの一部がViewBoxによって覆われない状態で残る）、UniformToFillはViewPort全体がViewBoxによって塗りつぶされることを保証する（場合によっては、ViewBoxの一部がViewPortの外にはみ出る）。ViewBoxの領域が空の場合、Stretchは適用されない。それでも位置合わせは発生することになり、「ポイント」ViewBoxを位置付けることになる。
【０２０８】
いったんViewPortが（ViewPortUnitsに基づいて）決定され、ViewBoxの宛先サイズが（Stretchに基づいて）決定されると、ViewBoxをViewPort内に位置付ける必要がある。ViewBoxがViewPortと同じサイズの場合（StretchがFillの場合、または他の３つのStretch値のうちの１つに偶然に生じただけの場合）、ViewBoxはViewPortと同じになるようにOriginに位置付けられる。そうでない場合、HorizontalAlignmentおよびVerticalAlignmentが考慮の対象となる。これらのプロパティに基づいて、ViewBoxにＸおよびＹの両方の寸法で位置合わせを行う。HorizontalAlignmentがLeftの場合、ViewBoxの枠の左側がViewPortの枠の左側に位置付けられることになる。これがCenterの場合、ViewBoxの中心がViewPortの中心に位置付けられることになり、Rightの場合、枠の右側が合致することになる。Ｙ寸法についてもこのプロセスが繰り返される。
【０２０９】
ViewBoxがEmptyの場合は、未設定とみなされる。未設定の場合、ContentUnitsが考慮の対象となる。ContentUnitsがAbsoluteの場合、縮尺またはオフセットは発生せず、コンテンツは変形なしでViewPortに描画される。ContentUnitsがRelativeToBoundingBoxの場合、コンテンツの起点とViewPort Originとの位置合わせを行い、コンテンツはオブジェクトの境界ボックスの幅および高さによって縮尺される。
【０２１０】
空間がTileBrushで塗りつぶされる場合、コンテンツは上記のようにViewPortにマッピングされ、ViewPortにクリッピングされる。これによって塗りつぶし用の基本タイルが形成され、残りの空間のはBrushのTileModeに基づいて塗りつぶされる。設定が行われている場合、Brushの変形が適用されるが、これは他のマッピング、縮尺、オフセットなどの後に行われる。
【０２１１】
VisualBrushとは、Visualによってコンテンツが指定されるTileBrushである。このBrushを使用して複雑なパターンを作成でき、またはこれを使用してシーンの他の部分のコンテンツの追加のコピーを描画することができる。
【０２１２】
【表４５】
【０２１３】
ImageBrushは、ImageDataによって指定されたコンテンツを有するTileBrushである。このBrushを使用して空間をImageで塗りつぶすことができる。
【０２１４】
【表４６】
【０２１５】
VideoBrushは、VideoDataによって指定されたコンテンツを有するTileBrushである。このBrushを使用して空間をVideoで塗りつぶすことができる。
【０２１６】
【表４７】
【０２１７】
NineGridBrushは、オブジェクトの境界ボックスを常にそのコンテンツ画像で塗りつぶすブラシであり、画像の引伸ばしは映像スケールを介してのみ実施されるものではない。Imageソースは４本の境界によって９つの矩形に分けられる（したがってNineGridと名付けられる）。これら９つの領域のそれぞれに存在する画像のコンテンツは、オブジェクト境界ボックスを塗りつぶすまで０、１、または２の寸法で縮尺される。各セクションが縮尺される寸法を図で見ることが可能であって、図１７はNineGridの概念を表すものであり、第１のインスタンス１７０２から第２のインスタンス１７０４に拡大され、Top、Left、Bottom、およびRightの境界によって定義される９つのグリッドを示す４つの型がある。各グリッドスクエア内の矢印は、それらのコンテンツがViewPortサイズに合致するように引伸ばされる寸法を示している。
【０２１８】
上記の９つのグリッド領域に加えて、オプションの「１０番目」のグリッドがある。これは、ViewPortの中心に位置する縮尺されない追加の画像の形を取る。これを使用して、ボタンなどの中心に形状を配置することができる。この「１０番目のグリッド」はグリフと呼ばれ、GlyphImageDataプロパティによって公開される。
【０２１９】
【表４８−１】
【０２２０】
【表４８−２】
【０２２１】
境界のメンバは、画像の枠から画像ピクセル単位でカウントに入れることに留意されたい。
【０２２２】
Penは、空間／Geometryをストロークで描く方法を記述したBrushおよび他のパラメータを取るオブジェクトである。概念上、PenはGeometryからストローク領域を作成する方法を記述する。Geometryの枠、PenのThickness、PenLineJoin、PenLineCap、などに基づいて新しい領域が作成される。いったんこの領域が作成されると、Brushで塗りつぶされる。
【０２２３】
【表４９−１】
【０２２４】
【表４９−２】
【０２２５】
PenLineCapは、ストローク線分の端部を描画する方法を決定する。
【０２２６】
【表５０】
【０２２７】
PenDashCapは、破線状のストローク線分における各ダッシュの端部を描画する方法を決定する。
【０２２８】
【表５１】
【０２２９】
PenLineJoinは、線分をストロークで描く際にジョイントを描画する方法を決定する。
【０２３０】
【表５２】
【０２３１】
DashArraysクラスは、一般的なよく知られた破線スタイルにアクセスする静的プロパティを備える。
【０２３２】
【表５３】
【０２３３】
図１３に示された他のBrushオブジェクトがVisualBrushオブジェクトである。VisualBrushとは、Visualによってコンテンツが指定されるTileBrushである。このBrushを使用して複雑なパターンを作成するか、またはこれを使用してシーンの他の部分のコンテンツの追加コピーを描画することができる。
【０２３４】
【表５４】
【０２３５】
概念上、VisualBrushは、塗りつぶしとして繰り返されるタイル様式でVisualを描画する方法を提供する。これは、図１２では、単一の円形状１２２０を指定するVisual（および任意の子Visual）を参照する映像ブラシによって表され、その円形状が矩形１２２２を塗りつぶしている。したがってVisualBrushオブジェクトは、そのブラシが描画されることになる方法を定義するためにVisualを参照することが可能であり、これは一種のVisualの複数使用を導入することになる。この方法では、プログラムは任意のグラフィックス「メタファイル」を使用して、ブラシまたはペンを介して領域を塗りつぶすことができる。これは任意のグラフィックスを格納および使用するための圧縮された形式であるため、グラフィックスリソースを提供する。
【０２３６】
一実施態様では、VisualBrushのコンテンツには固有の境界がなく、無限の平面を効果的に記述する。これらのコンテンツはそれら自体の座標空間内に存在し、VisualBrushが塗りつぶしている空間が適用時のローカル座標空間である。コンテンツ空間は、ViewBox、ViewPort、Alignments、およびStretchのプロパティに基づいてローカル空間にマッピングされる。ViewBoxはコンテンツ空間内に指定され、この矩形がViewPort（OriginおよびSizeプロパティを介して指定されたように）矩形にマッピングされる。
【０２３７】
ViewPortは、コンテンツが最終的に描画されることになる場所を定義し、このブラシ用の基本タイルを作成する。DestinationUnitsの値がUserSpaceOnUseである場合、OriginおよびSizeプロパティは適用時にローカル空間にあるものとみなされる。その代わりにDestinationUnitsの値がObjectBoundingBoxである場合、OriginおよびSizeは座標空間にあるものとみなされ、０，０はブラシ処理されているオブジェクトの境界ボックスの左／上コーナであり、１，１は同じボックスの右／下コーナである。たとえば、１００，１００から２００，２００まで描画されたRectangleGeometryを塗りつぶしていると考えてみる。こうした例では、DestinationUnitsがUserSpaceOnUseである場合、１００，１００のOriginおよび１００，１００のSizeがコンテンツ領域全体を記述することになる。DestinationUnitsがObjectBoundingBoxである場合、０，０のOriginおよび１，１のSizeがコンテンツ領域全体を記述することになる。Sizeが空の場合、このブラシは何もレンダリングしない。
【０２３８】
ViewBoxはコンテンツ空間内に指定される。この矩形が、AlignmentプロパティおよびStretchプロパティによって決められたViewPort内に収まるように変形される。Stretchがnoneの場合、コンテンツには縮尺が適用されない。StretchがFillの場合、ViewBoxはViewPortと同じサイズになるようにＸおよびＹで別々に縮尺される。StretchがUniformまたはUniformToFillの場合、論理は同様であるが、ＸおよびＹの寸法が均一に縮尺されてコンテンツのアスペクト比が保持される。StretchがUniformの場合、ViewBoxは、ViewPortのサイズに等しい、より多くの制約付き寸法を有するように縮尺される。StretchがUniformToFillの場合、ViewBoxは、ViewPortのサイズに等しい、より少ない制約付き寸法を有するように縮尺される。言い換えれば、UniformおよびUniformToFillはどちらもアスペクト比を保持するが、UniformはViewBox全体がViewPort内にあることを保証し（場合によっては、ViewPortの一部がViewBoxによって覆われていない状態で残り）、UniformToFillはViewPort全体がViewBoxによって塗りつぶされることを保証する（場合によっては、ViewBoxの一部がViewPortの外にはみ出る）。ViewBoxが空の場合、Stretchは適用されない。それでも位置合わせは発生することになり、「ポイント」ViewBoxを位置付けることになることに留意されたい。
【０２３９】
図１８は、様々な引伸ばし設定でレンダリングされたグラフィックスの単一タイル１８００を示す図であり、引伸ばしが「none」に設定されたときのタイル１８００が含まれている。タイル１８０２は引伸ばしが「Uniform」に設定された場合、タイル１８０４は引伸ばしが「UniformToFill」に設定された場合、およびタイル１８０６は引伸ばしが「Fill」に設定された場合を表す。
【０２４０】
いったんViewPortが（DestinationUnitsに基づいて）決定され、ViewBoxのサイズが（Stretchに基づいて）決定されると、ViewBoxをViewPort内に位置付ける必要がある。ViewBoxがViewPortと同じサイズの場合（StretchがFillであるか、または他の３つのStretch値のうちの１つに偶然に生じただけの場合）、ViewBoxはViewPortと同じになるようにOriginに位置付けられる。そうでない場合、HorizontalAlignmentおよびVerticalAlignmentが考慮の対象となる。これらのプロパティに基づいて、ViewBoxにＸおよびＹの両方の寸法で位置合わせを行う。HorizontalAlignmentがLeftの場合、ViewBoxの枠の左側がViewPortの枠の左側に位置付けられることになる。これがCenterの場合、ViewBoxの中心がViewPortの中心に位置付けられることになり、Rightの場合、枠の右側が合致することになる。Ｙ寸法についてもこのプロセスが繰り返される。
【０２４１】
ViewBoxが（０，０，０，０）の場合は未設定とみなされ、これによってContentUnitsが考慮の対象となる。ContentUnitsがUserSpaceOnUseの場合、縮尺またはオフセットは発生せず、コンテンツは変形なしにViewPortに描画される。ContentUnitsがObjectBoundingBoxの場合、コンテンツの起点がViewPort Originと位置合わせされ、コンテンツはオブジェクトの境界ボックスの幅および高さによって縮尺される。
【０２４２】
空間をVisualBrushで塗りつぶす場合、コンテンツは上記のようにViewPortにマッピングされ、ViewPortにクリッピングされる。これによって塗りつぶし用の基本タイルが形成され、BrushのTileModeに基づいて残りの空間が塗りつぶされる。最後に、Brushの変形が設定されていればこれが適用されるが、これは他のすべてのマッピング、縮尺、オフセットなどの後に実行される。
【０２４３】
TileMode列挙法を使用して、空間がそのBrushによって塗りつぶされるかどうか、およびその方法を記述する。タイル処理が可能なBrushにはタイル矩形が定義されており、このタイルは塗りつぶされる空間内に基本位置を有する。残りの空間はTileMode値に基づいて塗りつぶされる。図１９は、様々なTileMode設定のグラフィックス例を示した図であり、「None」１９００、「Tile」１０９２、「FlipX」１９０４、「FlipY」１９０６、および「FlipXY」１９０８が含まれる。様々なグラフィックス例の中の一番左上のタイルが基本タイルを備えるものである。
【０２４４】
図２０は、VisualBrush内のタイル用に定義されたVisualBrushグリッドを表す図である。第１の円は単純なグリッドであり、第２の円はＸ方向に４７のSkewで変形されたものである。図２１はこれを画像で塗りつぶした図である。
【０２４５】
図１３に戻ると、タイルブラシから画像ブラシが導出され、タイル処理することができる。NineGridBrushは、画像がサイズに基づいて歪められることを除いて、ImageBrushと非常によく似ている。本質的には、NineGridBrushはStretchのカスタム型と考えられ、画像の一定部分は引伸ばされるが、他の部分（たとえば境界）は引伸ばされない。したがって、ImageBrushでは画像のサイズは単純な縮尺を実行し、NineGridBrushは所望のサイズまで不均一な縮尺を実行することになる。ブラシが適用される場合、縮尺されない領域に対する単位はユーザ単位であり、これはContentUnits（NineGridBrush用に存在する場合）がUserUnitsOnUseに設定されることになることを意味する。BrushのTransformプロパティを有効に使用することができる。境界のメンバは、画像の枠からカウントに入れることに留意されたい。
【０２４６】
上記で概説したように、本発明のグラフィックスオブジェクトモデルにはTransformオブジェクトモデルが含まれ、これは図７の階層でTransform基本クラスの下に表された変形の型を含むものである。変形を構成するこれらの異なる型のコンポーネントは、TransformList、TranslateTransform、RotateTransform、ScaleTransform、SkewTransform、およびMatrixTransformを含むことができる。個々のプロパティをアニメーション処理することが可能であり、たとえばプログラム開発者はRotateTransformのAngleプロパティをアニメーション処理することができる。
【０２４７】
２Ｄ計算用の行列が３×３行列として表される。変形が必要な場合、３×３行列すべてではなく６つの値のみが必要とされる。これらは以下のように命名され、および定義される。
【０２４８】
【表５５】
【０２４９】
行列とポイントを掛け合わせると、そのポイントが新しい座標系から前の座標系に変形される。
【０２５０】
【表５６】
【０２５１】
変形は何重にも入れ子にすることができる。新しい変形が適用される場合は必ず、現在の変形行列に後から掛け合わせたものと同じになる。
【０２５２】
【表５７】
【０２５３】
ＡＰＩ内のほとんどの場所は直接行列を取らないが、代わりにアニメーションをサポートするTransformクラスを使用する。
【０２５４】
【表５８−１】
【０２５５】
【表５８−２】
【０２５６】
【表５８−３】
【０２５７】
（ベクトルグラフィックス用のマークアップ言語およびオブジェクトモデル）
本発明の一態様によれば、ＡＰＩレイヤ２１２（図２）の詳細に関する特定の知識を必要とすることなく、ユーザプログラムおよびツールがシーングラフデータ構造２１６と対話できるようにするために、マークアップ言語および要素オブジェクトモデルが提供される。一般に、交換フォーマット、ならびに要素オブジェクトモデルを介してベクトルグラフィックスを表現するための単純なマークアップベースのオーサリングフォーマットを備えた、ベクトルグラフィックスマークアップ言語が提供される。この言語を介して、マークアップ（たとえばＨＴＭＬまたはＸＭＬ型のコンテンツ）をプログラムすることができる。そこで、シーングラフを構築するため、前記で説明したように、マークアップは解析され、適切な映像ＡＰＩレイヤオブジェクトに変換される。この高位のオペレーティングレベルで、かなりの複雑さを処理するために要素ツリー、プロパティシステム、およびレイアウトシステムが提供され、シーン設計者が複雑なシーンを簡単に設計できるようになっている。
【０２５８】
一般に、ベクトルグラフィックスシステムは、形状および他の要素の集合、一般的なプロパティシステムとの統合、グループ化および複合化システム、ならびに、ユーザが柔軟性および性能のニーズに合致する方法でプログラミング可能なような２層（要素レベルおよびリソースレベル）方式を提供する。ベクトルグラフィックスを処理するための要素オブジェクトモデルは、本発明の一態様を維持しながら、シーングラフオブジェクトモデルと相関関係にある。つまり、ベクトルグラフィックスシステムおよび映像ＡＰＩレイヤは、要素オブジェクトモデルレベルでリソースの集合を共用するものであり、たとえば、映像ＡＰＩで描画する際にはBrushオブジェクトが使用され、これはShapeでのFillプロパティ型でもある。したがってマークアップ言語は、シーングラフオブジェクトと相関する要素を有することに加えて、いくつかのプリミティブリソース（たとえばブラシ、変形など）を映像ＡＰＩレイヤと共用する。さらにベクトルグラフィックスシステムは、レベル間で幅広く共用される映像ＡＰＩレイヤのアニメーション機能も公開し、および拡張する。
【０２５９】
さらに以下で説明するように、ベクトルグラフィックスシステムは、要素レベルおよびリソースレベルを含む異なるプロファイルまたはレベルでプログラミングすることができる。要素レベルでは、それぞれの描画形状が、ページ／スクリーン内の残りのプログラム可能な要素と同じレベルの要素として表される。これは、形状が、レイアウトシステム、イベント、およびプロパティとフル方式で対話することを意味する。リソースレベルでは、ベクトルグラフィックスシステムは従来のグラフィックスメタファイルと同様に純粋なリソースフォーマットで動作する。リソースレベルは効率的であるが、カスケードプロパティ、イベンティング、および微細なプログラミングについてのサポートは限定的である。したがってシーン設計者は、必要に応じて効率性とプログラム可能性との釣り合いを取ることができる。
【０２６０】
リソースレベルのベクトルグラフィックスシステムは、本発明の一態様を維持しながら、一実施態様においてリソースレベルマークアップがVisualBrushとして表されるという点で、映像ＡＰＩレイヤとも相関関係にある。リソースマークアップが解析される際に、映像オブジェクトが作成される。映像オブジェクトは、形状、コントロール、および他の要素が要素レベルで使用可能なVisualBrushに設定される。
【０２６１】
図２２は、要素クラスの階層２２００を示す図である。本発明のマークアップ言語オブジェクトモデルのクラスは影付きボックスで表され、形状クラス２５０２、画像クラス２５０４、ビデオクラス２２０６、およびキャンバスクラス２２０８が含まれる。形状クラスの要素には、矩形２２１０、線分群２２１２、多角形２２１４、軌跡２２１６、線分２２１８、および楕円２２２０が含まれる。一部の実施では、図２２の破線ボックス２２２２で示されるような円要素が存在しない場合があるが、本明細書では様々な例を示す目的で円要素２２２２について説明する。各要素は、塗りつぶし（プロパティ）データ、ストロークデータ、クリッピングデータ、変形データ、フィルタ効果データ、およびマスクデータを含むか、またはこれらに関連付けられることができる。
【０２６２】
以下で説明するように、形状は、継承およびカスケードされた提示プロパティで描画されるジオメトリに対応する。提示プロパティは、形状を描画するために必要なペンおよびブラシを構築する際に使用される。一実施態様では、形状は他のコントロール要素と同様にフルプレゼンタ（ｆｕｌｌ ｐｒｅｓｅｎｔｅｒ）である。ただし他の実施では、キャンバスクラス２５０８を形状用のコンテナとして提供することが可能であり、形状はキャンバス要素内にある場合にのみ描画することができる。たとえば、形状を軽量に保つために、形状にプレゼンタを付加することができない場合がある。代わりに、キャンバスが付加プレゼンタを有し、形状を描画する。キャンバス要素については、以下でより詳細に説明する。
【０２６３】
後述するように、画像クラスは形状よりも特異であり、たとえば複雑な場合のある境界データを含むことができる。たとえば、境界は上側は１色、両側は異なる色を指定し、様々な厚さを指定することおよび他のプロパティを設定することができる。画像、あるいはテキストまたはビデオなどの同様のボックスで囲まれた要素に対して、位置、サイズ、回転、および縮尺を設定することができる。画像およびビデオ要素は、キャンバス要素の外側に存在し、および表示することが可能であり、たとえばその要素から背景、境界、およびパッドサポートを取得するために、BoxedElementから継承することもできることに留意されたい。
【０２６４】
ビデオ要素は、表示された要素の中でビデオ（または同様のマルチメディア）を再生させることができるものである。この方法では、ベクトルグラフィックスシステムは、テキスト、２Ｄグラフィックス、３Ｄグラフィックス、アニメーション、ビデオ、静止画像、および音声を含むマルチメディアを横切ってシームレスに一貫した、ＡＰＩレイヤへのマークアップインターフェースを提供する。これによって設計者は、１つの媒体で作業を行い、他の媒体をアプリケーションおよび文書に容易に一体化させることを習得することができる。ベクトルグラフィックスシステムは、他の要素と同じ方法でマルチメディアをアニメーション化させることも可能であり、設計者はここでも、個々の媒体型の中核を成す固有性を失わせることなく他の要素と同様にマルチメディアを使用することが可能である。たとえば設計者は、回転、縮尺、アニメーション化、描画、合成、および他の効果に対して、異なる媒体型にまたがって同じ命名方式を使用することが可能であり、これによって設計者は、非常に豊富なアプリケーションを容易に作成すること、ならびに非常に効率的なレンダリングおよび合成の実施をその下に構築することができる。
【０２６５】
図２３に、マークアップコード２３０２がパーサ／トランスレータ２３０４によって解釈される一実施態様を示す。一般に、パーサ／トランスレータ２３０４は、要素ツリー／プロパティシステム２０８（図２にも示される）に要素を追加し、それらの要素にプレゼンタを付加する。その後、レイアウトシステム２１０は付加されたプレゼンタと共に要素ツリー２１０を取得し、そのデータをオブジェクトおよび映像ＡＰＩレイヤ２１２への呼出しに変換する。変換する必要があるのはすべての要素ではなく、プレゼンタが付加されたもののみであることに留意されたい。
【０２６６】
一般にマークアップはオブジェクトに分解され、通常、ＸＡＭＬマークアップに関するＸＭＬ方式がマークアップファイルの上位で以下のように宣言される。
【０２６７】
【表５９】
【０２６８】
たとえば<Path>タグが使用される場合、パーサはこの方式を使用して関連する名前空間（たとえば、System.Windows.Shapes）を検索し、オブジェクトを分解および構築する。
【０２６９】
一般に、要素とは、プロパティシステム、イベンティング、およびレイアウト／提示システムに加わっている要素レイヤ内のオブジェクトのことである。パーサはタグを見つけ、それらのタグが要素またはリソースオブジェクトの定義に役立つかどうかを判別する。特別なVisualBrushの場合、それらのタグが現れる場所の状況に応じて、たとえば複雑なプロパティ構文内に現れるか否かに応じて、同じタグを要素として解釈するか、またはリソースオブジェクトとして解釈することもできる。
【０２７０】
本発明の一態様によれば、マークアップ言語は、単純な文字列フォーマットまたは複雑なオブジェクト表記法を含むリソースを記述する独特の方法を提供する。単純な文字列フォーマットの場合、パーサ／トランスレータ２３０４は、型変換器２３０８を使用して文字列を適切な映像ＡＰＩオブジェクトに変換する。例を挙げると、型変換器２３０８を介して、以下のマークアップ行でFillプロパティ値をBrushオブジェクトに変換することができる。
【０２７１】
【表６０】
【０２７２】
容易に理解できるように、こうした単純なパラメータの文字列を備えたタグベースのマークアップの線分の内側行をBrushオブジェクトに変換するのは簡単であり、形状およびその属性をシーンに追加する単純な方法をシーン設計者に提供する。
【０２７３】
しかしながら、Fill属性が複雑すぎて単一の文字列に入らない場合がある。こうした状況では、マークアップで線分の内側である可能性のある複雑なプロパティ構文を使用して、このプロパティを設定する。たとえば以下の複雑なプロパティ構文は、ソリッドカラーではなく勾配で円を塗りつぶすものであり、様々な勾配停止（０から１までの範囲が可能）で色を指定する。
【０２７４】
【表６１】
【０２７５】
マークアップで線分の内側であることに加えて、リソースインスタンスはどこにでも（たとえば、ローカルであるか、またはリモートネットワーク上にあり適切にダウンロード可能な、マークアップまたはファイル内に）配置することが可能であり、名前（たとえば、テキスト名、参照または他の好適な識別子）で参照することができる。この方法の場合、シーン設計者は、複雑なプロパティ構文で記述された要素を含む要素ツリー内の要素を、シーン全体にわたって再使用することができる。
【０２７６】
パーサは、必要に応じて型変換器２３０８にアクセスすること、さらに指定されたパラメータをオブジェクトプロパティと付き合わせることによって、複雑なプロパティ構文内のマークアップを処理し、これによってシーンの設計が容易になる。したがってパーサは、オブジェクトをセットアップするだけではなく、オブジェクト上の属性も設定する。オブジェクトは不変であるため、パーサはオブジェクトを作成するために実際にビルダをインスタンス化することに留意されたい。
【０２７７】
同じレンダリングモデルが要素レベルとＡＰＩレベルの間で共用されるため、多くのオブジェクトが本質的に同じである。これによって解析／変換がかなり効率的になり、様々な種類のプログラミング言語（たとえば、Ｃ＃のような言語）が、マークアップからそれ自体の構文への変換およびその逆への変換を容易に実行できるようになる。図２３に表されているように、こうした他のプログラミング言語２３１０は、要素ツリー２０８に要素を追加するか、または映像ＡＰＩレイヤ２１２と直接インターフェースできることに留意されたい。
【０２７８】
図２３にも示されているように、また本発明の一態様によれば、同じマークアップ２３０２を使用して、要素レベルおよびリソースレベルでプログラミングすることができる。前述のように要素レベルは、完全なプログラミングが可能であり、継承（たとえばスタイルシートのような機能）を提供するプロパティシステムの使用と、（たとえばそれによって要素が、ユーザの入力イベントに応答して外観、位置などを変更するためにコードを付加することができる）イベンティングとを、シーン設計者に与える。しかし本発明は、リソースレベルの機構も提供しており、シーン設計者はこれを使用して、本質的に要素ツリーをショートカットし、システムおよびプログラムを映像ＡＰＩレイヤに直接レイアウトすることができる。要素レベルの機能を必要としない多くの型の静的形状、画像、および同様のものの場合、これによって、適切なオブジェクトを出力するためのより効率の良い軽量な方法が提供される。このためパーサは、「映像ブラシ」型の塗りつぶしが存在する場合を認識し、リソースレベルデータ２３１２を備えたＡＰＩレイヤ２１２を直接呼び出して、オブジェクトを作成する。つまり、図２２に示されるように、要素レベルのベクトルグラフィックスは作成済みの要素に解析され、これを後にオブジェクトに変換する必要がある一方で、リソースレベルのベクトルグラフィックスは解析された後、効率的な方法で直接格納される。
【０２７９】
例を挙げると、以下のマークアップはLinearGradientオブジェクト用のオブジェクトモデルから直接導出され、VisualBrushで外側の円を塗りつぶす。そのVisualBrushのコンテンツは内側のマークアップによって定義される。この構文は、一般に、様々なブラシ、変形、およびアニメーションを表すために使用されることに留意されたい。
【０２８０】
【表６２】
【０２８１】
これらの映像ブラシ塗りつぶしオブジェクトが効率的に格納される一方で、図２３に全体として示されるように、リソースレベルデータ（またはそれによって作成されたオブジェクト）は要素および要素ツリー２０８の一部によって参照できることに留意されたい。このため、これらの映像ブラシリソースは、複雑なプロパティ構文を介して記述された他のリソースと同様に、（たとえば名前、参照、または他の好適な識別子を使用して）命名および参照することができる。
【０２８２】
次にキャンバスについて説明すると、上記で代替の一実施態様で述べたように、形状は軽量に維持することが可能であるため、キャンバスに格納する必要がある場合がある。この代替実施では、コンテンツはレンダリングされる場合に、関連する座標系を有する装置に依存しない無限のキャンバス上にレンダリングされる。キャンバス要素は、絶対座標に従ってコンテンツを位置付けることができる。キャンバス要素は任意で、クリッピング、変形、好ましいアスペクト比、およびViewPortを親空間にマッピングする方法を指定するViewPortを定義することができる。確立されたViewPortがない場合、キャンバス要素は描画プリミティブのグループ化のみを指定し、変形、不透明度、および他の合成属性をセットアップすることができる。
【０２８３】
以下にキャンバスについてのマークアップ例を示す。
【０２８４】
【表６３】
【０２８５】
一実施態様では、座標が単位なしで指定された場合、９６分の１インチ（約０．０２６ｃｍ）の「論理ピクセル」とみなされ、上記の例では、線分の長さは２００ピクセルとなることに留意されたい。他のプロパティには座標に加えて、幅、高さ、水平および垂直の位置合わせ、ならびにViewBox（Rect型、デフォルト値は未設定または（０，０，０，０）、すなわち調整されない、ならびに引伸ばしおよび位置合わせプロパティは無視される）が含まれる。図１８〜２０を参照しながら上記で概説したように、他のプロパティには引伸ばしが含まれ、これが指定されない場合、オリジナルサイズを保持するか、１）アスペクト比が保持されず、上／左／幅／高さによって確立された境界を塗りつぶすようにコンテンツが縮尺されるFillを指定する、２）上／左／幅／高さによって確立された境界に画像が収まるまでサイズを均一に縮尺するUniformを指定する、あるいは３）上／左／幅／高さによって確立された境界を塗りつぶすようにサイズを均一に縮尺し、必要に応じてクリッピングするUniformToFillを指定することができる。
【０２８６】
より低いレベルのオブジェクトモデルとさらに相関させるために、変形プロパティは要素の子に対して新しい座標フレームを確立するが、クリッププロパティは、キャンバス上にコンテンツを描画できる範囲を境界ボックスとして定義されたデフォルトのクリッピングする軌跡によって制約する。ZIndexプロパティを使用して、パネル内の入れ子にされたキャンバス要素のレンダリング順序を指定することができる。
【０２８７】
ViewBoxは、たとえばViewPortの範囲および起点を再定義することによって、コンテンツ用の新しい座標系を指定する。引伸ばしは、これらのコンテンツをViewPortにマッピングする方法を指定する際に役立つ。ViewBox属性の値は、たとえば空白および／またはカンマによって分けられた４つの「単位なし」数<min-x>、<min-y>、<width>、および<height>のリストであり、Rect型である。ViewBox rectは、ユーザ空間内に境界ボックスにマッピングする矩形を指定する。これは、scaleXおよびscaleYを挿入するのと同じ働きをする。引伸ばしプロパティ（オプションがNone以外の場合）は、グラフィックスのアスペクト比を保持するための追加の制御を提供する。指定された効果を達成するために、所与の要素の下位に対して追加の変形が適用される。
【０２８８】
上記の例では、各引伸ばし規則の下での上のマークアップサンプルでの矩形の効果的な結果は以下のようになる。
【０２８９】
【表６４】
【０２９０】
キャンバス上で変形がある場合、本質的には上の（たとえばツリー内の）ViewBoxへのマッピングが適用される。このマッピングにより、形状だけでなくキャンバス内のいずれかの要素、たとえばボックス、テキストなどが引伸ばされることに留意されたい。さらに、ViewBoxが指定された場合、キャンバスはもはやそのコンテンツをサイズ変更せず、指定のサイズを有することにも留意されたい。y-widthおよびy-heightも指定された場合、ViewBoxは引伸ばし／位置合わせプロパティを使用して指定された幅および高さに合わせられる。
【０２９１】
オブジェクトモデル内の要素は、それぞれ「Clip」属性を適用することができる。一部の要素、特に形状では、これは一般的な言語ランタイムプロパティとして直接公開されるが、他の要素（たとえばほとんどのコントロール）では、このプロパティはDynamicPropertyを介して設定される。
【０２９２】
概略的に図２４に示されるように、一般にクリッピングする軌跡は、コンテンツが描画できる領域を制限するものであり、この図では、クリッピングされていない形２４０２と、クリッピングする軌跡が指定された形２４０４（破線がクリッピングする軌跡を表す）でボタンが示されている。概念上は、現在アクティブなクリッピングする軌跡で境界付けられた領域の外部にある描画の部分は、いずれも描画されない。クリッピングする軌跡はマスクとみなすことが可能であり、クリッピングする軌跡の外にあるピクセルは黒であってアルファ値０を備え、クリッピングする軌跡の中にあるピクセルは白であってアルファ値１を備える（シルエットの枠に沿ったアンチエイリアス（ａｎｔｉ−ａｌｉａｓｉｎｇ）は例外とする）。
【０２９３】
クリッピングする軌跡は、線分の内側またはより一般的にはリソースセクション内のいずれかで、Geometryオブジェクトによって定義される。クリッピングする軌跡は、以下の例に示されるように、要素上の「Clip」プロパティを用いて使用し、および／または参照される。
【０２９４】
【表６５】
【０２９５】
クリップのアニメーション化は変形のアニメーション化と同様であることに留意されたい。
【０２９６】
【表６６】
【０２９７】
軌跡は、「Geometry」データならびにFill、Stroke、およびStrokeWidthなどのレンダリングプロパティをPath要素上に指定することによって描画される。軌跡のマークアップの例は以下のように指定される。
【０２９８】
【表６７】
【０２９９】
軌跡「Data」文字列はGeometry型である。描画される軌跡を指定するためのより冗長かつ完全な方法は、前述のように複雑なプロパティ構文を介することである。マークアップ（以下の例のような）は、前述のGeometryビルダクラスへ直接送られる。
【０３００】
【表６８】
【０３０１】
軌跡データ文字列用の文法を記述するための以下の表記法を使用して、軌跡データ文字列も記述される。
【０３０２】
【表６９】
【０３０３】
この表記法で記述された軌跡データ文字列情報の例を、以下に示す（一実施態様では、要素レベルのプロパティの代わりにFillModeを指定できることに留意されたい）。
【０３０４】
【表７０−１】
【０３０５】
【表７０−２】
【０３０６】
【表７０−３】
【０３０７】
【表７０−４】
【０３０８】
【表７０−５】
【０３０９】
【表７０−６】
【０３１０】
画像要素（図２５）は、完全なファイルのコンテンツが現在のユーザ座標系内の所与の矩形にレンダリングされることを示す。画像（画像タグで示される）は、以下の例で示すようにＰＮＧまたはＪＰＥＧなどのラスタ画像ファイル、またはＭＩＭＥ型の「image/wvg」を備えたファイルを表示することができる。
【０３１１】
【表７１】
【０３１２】
以下の表は、画像用のプロパティ例の一部に関する情報を提供するものである。
【０３１３】
【表７２−１】
【０３１４】
【表７２−２】
【０３１５】
前述のように、形状は、継承およびカスケードされた提示プロパティで描画された幾何学形状に対応する。以下の表は、前述の基本形状要素（Rectangle、Ellipse、Line、Polyline、Polygon）用の形状プロパティの例を示すものである。これらの基本形状は、ストロークプロパティ、塗りつぶしプロパティを有し、クリッピングする軌跡として使用され、継承特徴を有し、要素とリソースの両方のレベルに適用可能であることに留意されたい
。
【０３１６】
【表７３−１】
【０３１７】
【表７３−２】
【０３１８】
矩形用のマークアップ構文の例を以下に示す。
【０３１９】
【表７４】
矩形とは、オブジェクトモデル内に以下のプロパティを有するものである（矩形は読取り／書込みされ、ゼロに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３２０】
【表７５】
【０３２１】
円用のマークアップ構文の例を以下に示す。
【０３２２】
【表７６】
【０３２３】
円とは、オブジェクトモデル内に以下のプロパティを有するものである（円は読取り／書込みされ、ゼロに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３２４】
【表７７】
【０３２５】
楕円用のマークアップ構文の例を以下に示す。
【０３２６】
【表７８】
【０３２７】
楕円とは、オブジェクトモデル内に以下のプロパティを有するものである（楕円は読取り／書込みされ、ゼロに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３２８】
【表７９】
【０３２９】
線分用のマークアップ構文の例を以下に示す。
【０３３０】
【表８０】
【０３３１】
線分とは、オブジェクトモデル内に以下のプロパティを有するものである（線分は読取り／書込みされ、ゼロに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３３２】
【表８１】
【０３３３】
「Polyline」は接続された直線セグメントの集合を定義する。通常、「Polyline」は開いた形状を定義する。
【０３３４】
線分群用のマークアップ構文の例を以下に示す。
【０３３５】
【表８２】
【０３３６】
線分群とは、オブジェクトモデル内に以下のプロパティを有するものである（線分は読取り／書込みされ、ｎｕｌｌに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３３７】
【表８３】
【０３３８】
Polygon要素は、接続された直線セグメントの集合を備えた閉じた形状を定義する。多角形用のマークアップ構文の例を以下に示す。
【０３３９】
【表８４】
【０３４０】
多角形とは、オブジェクトモデル内に以下のプロパティを有するものである（線分は読取り／書込みされ、ｎｕｌｌに等しいデフォルトの値を有し、継承をサポートし、要素とリソースの両方のレベルに適用されることに留意されたい）。
【０３４１】
【表８５】
【０３４２】
「Polyline」および「Polygon」要素でポイントを指定するための文法は、以下の表記法で記述される。
【０３４３】
【表８６】
【０３４４】
上記の表記法を使用した「Polyline」および「Polygon」要素でのポイントの指定について、以下に記載する。
【０３４５】
【表８７−１】
【０３４６】
【表８７−２】
【０３４７】
（結論）
前述の詳細な説明からわかるように、シーングラフとインターフェースするための様々な機構をプログラムコードに提供するシステム、方法、および要素／オブジェクトモデルが提供される。当該システム、方法、およびオブジェクトモデルは使用が簡単であり、さらに強力、柔軟、かつ拡張可能である。
【０３４８】
本発明には様々な修正および代替構造が可能であるが、図面にはその例示的実施形態が示されており、上記で詳細に説明してきた。しかし、開示された特定の形式に本発明を限定する意図はなく、逆に、本発明の精神および範囲内にあるすべての修正、代替構造、および等価物をカバーすることを意図するものであることを理解されたい。
【図面の簡単な説明】
【０３４９】
【図１】本発明を組み込むことが可能な例示的なコンピュータシステムを表すブロック図である。
【図２】本発明を組み込むことが可能なグラフィックレイヤアーキテクチャを全体として表すブロック図である。
【図３】本発明の一態様に従って、グラフィックスコマンドおよび他のデータを提供するために、シーングラフをトラバースすることなどによりシーングラフを処理するためのＶｉｓｕａｌおよび関連するコンポーネントのシーングラフを示す図である。
【図４】本発明の一態様に従って構築された、妥当性検査映像、描画映像、および関連する命令リストのシーングラフを示す図である。
【図５】本発明の一態様に従った、オブジェクトモデルの映像クラスを示す図である。
【図６】本発明の一態様に従った、オブジェクトモデルの様々な他のオブジェクトを示す図である。
【図７】本発明の一態様に従った、変形クラス階層を示す図である。
【図８】本発明の一態様に従った、ジオメトリスケールでの映像データの変形を示す図である。
【図９】本発明の一態様に従った、不均一スケールでの映像データの変形を示す図である。
【図１０】本発明の一態様に従った、ジオメトリクラスのオブジェクトモデルを示す図である。
【図１１】本発明の一態様に従った、PathGeometry構造を示す図である。
【図１２】本発明の一態様に従った、プリミティブによって作成されたグラフィックスの例を示す映像および命令リストのシーングラフを示す図である。
【図１３】本発明の一態様に従った、オブジェクトモデルのブラシクラスを示す図である。
【図１４】本発明の一態様に従った、線形勾配ブラシオブジェクト内のデータから生じたレンダリングされたグラフィックスを示す図である。
【図１５】本発明の一態様に従った、線形勾配ブラシオブジェクト内のデータから生じたレンダリングされたグラフィックスを示す図である。
【図１６】本発明の一態様に従った、放射勾配ブラシオブジェクト内のデータから生じたレンダリングされたグラフィックスを示す図である。
【図１７】本発明の一態様に従った、レンダリングされた９グリッドブラシオブジェクトを示す図である。
【図１８】本発明の一態様に従った、様々な引伸ばし値を有することから生じたレンダリングされたグラフィックスを示す図である。
【図１９】本発明の一態様に従った、様々なタイル値を有することから生じたレンダリングされたグラフィックスを示す図である。
【図２０】本発明の一態様に従った、映像ブラシオブジェクト内のデータから生じたグリッドおよび変形グリッドを示す図である。
【図２１】本発明の一態様に従った、映像から描画されたレンダリングされたグラフィックスを有するグリッドおよび変形グリッドを示す図である。
【図２２】本発明の一態様に従った、要素オブジェクトモデルの要素クラスを示す図である。
【図２３】本発明の一態様に従った、映像ＡＰＩレイヤとインターフェースするためにマークアップ言語コードを解釈するためのコンポーネントを示す図である。
【図２４】本発明の一態様に従った、ジオメトリ軌跡を介したクリッピングを示す図である。
【特許請求の範囲】
【請求項１】
コンピューティング環境において、
インターフェースを介してマークアップ言語データを備えた機能呼出しを受け取るステップと、
前記マークアップ言語データを解釈してシーングラフ内のデータを修正するステップと
を備えたことを特徴とする方法。
【請求項２】
前記シーングラフ内のデータを修正するステップは、映像クラスの新しいインスタンスを初期化するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記シーングラフ内のデータを修正するステップは、前記シーングラフ内の映像オブジェクトと変形とを関連付けるコードを呼び出すステップを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記シーングラフデータ構造内のデータを修正するステップは、描画する映像を前記シーングラフ内に配置するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
、前記描画する映像をレンダリングする機構を提供する描画コンテキストを返すステップをさらに備えたことを特徴とする請求項４に記載の方法。
【請求項６】
前記シーングラフ内のデータを修正するステップは、前記シーングラフ内の映像オブジェクトとブラシデータとを関連付けるコードを呼び出すステップを含むことを特徴とする請求項２に記載の方法。
【請求項７】
前記ブラシデータを関連付けるステップは、ソリッドカラーに対応するデータとして受け取るステップをさらに備えたことを特徴とする請求項６に記載の方法。
【請求項８】
前記ブラシデータを関連付けるステップは、線形勾配ブラシと少なくとも１つの停止を含む停止集合とに対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項９】
前記ブラシデータを関連付けるステップは、放射勾配ブラシに対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項１０】
前記ブラシデータを関連付けるステップは、画像に対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項１１】
前記画像に適用する画像効果に対応するマークアップ言語データを受け取るステップをさらに備えたことを特徴とする請求項１０に記載の方法。
【請求項１２】
形状の輪郭を定義するペンデータに対応するマークアップ言語データを受け取るステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１３】
前記マークアップ言語データは、矩形、線分群、多角形、軌跡、線分、および楕円の形状を含む集合のうちの少なくとも１つを含む形状クラスに対応することを特徴とする請求項１に記載の方法。
【請求項１４】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に矩形を表す幾何学形状関連機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１５】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に軌跡を表す幾何学形状関連機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１６】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に線分を表す幾何学形状関連機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１７】
前記マークアップ言語データは、前記シーングラフデータ構造内の映像のヒットテストに関連することを特徴とする請求項１に記載の方法。
【請求項１８】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内の映像の座標変形に関する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１９】
前記マークアップ言語データは、前記シーングラフデータ構造内の映像の境界ボックスの計算に関連することを特徴とする請求項１に記載の方法。
【請求項２０】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内の映像オブジェクトへの共通インターフェースを介して機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２１】
映像マネージャを呼び出し、レンダリング対象に少なくとも１つの映像オブジェクトのツリーをレンダリングするステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項２２】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に少なくとも１つの映像オブジェクトを含むように構成されるコンテナオブジェクトを配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２３】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に画像データを配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２４】
前記シーングラフ内のデータを修正するステップは、前記画像データに関連付けられた前記シーングラフデータ構造内に画像効果オブジェクトを配置する機能を呼び出すステップを含むことを特徴とする請求項２３に記載の方法。
【請求項２５】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内にテキストに対応するデータを配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２６】
前記シーングラフ内のデータを修正するステップは、前記機能呼出しに応答して描画コンテキストを提供する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２７】
前記機能呼出しは、保持された映像に対応し、コールバックを行って前記保持された映像の描画コンテキストを前記シーングラフデータ構造に戻すステップをさらに備えたことを特徴とする請求項２６に記載の方法。
【請求項２８】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に３次元映像を配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２９】
前記シーングラフ内のデータを修正するステップは、前記３次元映像に２次元表面をマッピングするステップを含むことを特徴とする請求項２８に記載の方法。
【請求項３０】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内にアニメーションデータを配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項３１】
前記アニメーションデータに対応するタイムライン情報を合成エンジンに送るステップをさらに備えたことを特徴とする請求項３０に記載の方法。
【請求項３２】
前記合成エンジンは、前記タイムライン情報に基づくグラフィックスデータを補間し、前記シーングラフデータ構造内のオブジェクトに対応する出力をアニメーション化することを特徴とする請求項３１に記載の方法。
【請求項３３】
前記合成エンジンは、前記シーングラフについて低いレベルであることを特徴とする請求項３２に記載の方法。
【請求項３４】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に音声および／またはビデオデータに対応するオブジェクトを配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項３５】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内のオブジェクトの可変値を変更するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３６】
コンピューティング環境において、
マークアップパーサと、
前記マークアップパーサをマークアップ言語データのソースに結合するインターフェースと、
オブジェクトモデルの映像情報用のコンテナと、
を備えたシステムであって、前記マークアップパーサは、前記インターフェースで受け取ったマークアップ言語データを前記オブジェクトモード内のオブジェクトのメソッド呼出しに変換し、前記映像情報用のコンテナ内のデータを修正することを特徴とするシステム。
【請求項３７】
前記マークアップ言語データは、メソッド呼出しに変換され、映像オブジェクトのツリーをシーングラフデータ構造内に配置することを特徴とする請求項２６に記載のシステム。
【請求項３８】
前記マークアップ言語データは、少なくとも１つのメソッド呼出しに変換され、前記映像オブジェクトのツリーを前記シーングラフデータ構造内に配置構成することを特徴とする請求項３７に記載のシステム。
【請求項３９】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトを前記シーングラフデータ構造内に配置することを特徴とする請求項３７に記載のシステム。
【請求項４０】
前記マークアップ言語データは、メソッド呼出しに変換され、映像オブジェクトを前記シーングラフデータ構造内に配置することを特徴とする請求項３６に記載のシステム。
【請求項４１】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトにブラシを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項４２】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに幾何学形状を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項４３】
前記幾何学形状は、楕円形状、矩形形状、線分形状、および軌跡形状を含む集合のうちの少なくとも１つを含むことを特徴とする請求項４２に記載のシステム。
【請求項４４】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトと変形とを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項４５】
前記変形は、前記映像オブジェクトの知覚された角度を変更する回転変形を含むことを特徴とする請求項４４に記載のシステム。
【請求項４６】
前記変形は、前記映像オブジェクトの知覚されたサイズを変更する尺度変形を含むことを特徴とする請求項４４に記載のシステム。
【請求項４７】
前記変形は、前記映像オブジェクトの知覚された位置を変更する変換変形を含むことを特徴とする請求項４４に記載のシステム。
【請求項４８】
前記変形は、前記映像オブジェクトの知覚された歪みを変更する歪み変形を含むことを特徴とする請求項４４に記載のシステム。
【請求項４９】
前記マークアップ言語データは、前記変形に関連付けられたアニメーション情報を提供するものであって、前記アニメーション情報は、前記変形に関連付けられた変形データを経時的に変更し、それによって前記映像オブジェクトの前記変形を経時的にアニメーション化するものであることを特徴とする請求項４４に記載のシステム。
【請求項５０】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに色を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５１】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに勾配データを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５２】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトにタイルブラシを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５３】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに画像を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５４】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに描画プリミティブを備える描画を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５５】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに音声および／またはビデオ媒体を関連付けるためにことを特徴とする請求項４０に記載のシステム。
【請求項５６】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに画像効果を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５７】
前記マークアップ言語データは、形状の輪郭がどのようであるかを記述するために、メソッド呼出しに変換され、前記映像オブジェクトにペンを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５８】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに関連付けられた描画コンテキストを取得することを特徴とする請求項４０に記載のシステム。
【請求項５９】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトにヒットテストデータを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項６０】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに矩形を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項６１】
前記マークアップ言語データは、ソースの矩形をどのように引伸ばし、目的の矩形に合わせるべきかを記述するデータを含むことを特徴とする請求項６０に記載のシステム。
【請求項６２】
コンピューティング環境において、
マークアップ言語データを備えた機能呼出しを受け取るためのインターフェース手段と、
前記マークアップ言語データをグラフィックスデータのレンダリングに関連付けられたオブジェクトモデルに対応するデータに変換する解析手段と、
前記グラフィックスデータを出力するレンダリング手段と
を備えたことを特徴とするシステム。
【請求項１】
コンピューティング環境において、
インターフェースを介してマークアップ言語データを備えた機能呼出しを受け取るステップと、
前記マークアップ言語データを解釈してシーングラフ内のデータを修正するステップと
を備えたことを特徴とする方法。
【請求項２】
前記シーングラフ内のデータを修正するステップは、映像クラスの新しいインスタンスを初期化するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記シーングラフ内のデータを修正するステップは、前記シーングラフ内の映像オブジェクトと変形とを関連付けるコードを呼び出すステップを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記シーングラフデータ構造内のデータを修正するステップは、描画する映像を前記シーングラフ内に配置するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
、前記描画する映像をレンダリングする機構を提供する描画コンテキストを返すステップをさらに備えたことを特徴とする請求項４に記載の方法。
【請求項６】
前記シーングラフ内のデータを修正するステップは、前記シーングラフ内の映像オブジェクトとブラシデータとを関連付けるコードを呼び出すステップを含むことを特徴とする請求項２に記載の方法。
【請求項７】
前記ブラシデータを関連付けるステップは、ソリッドカラーに対応するデータとして受け取るステップをさらに備えたことを特徴とする請求項６に記載の方法。
【請求項８】
前記ブラシデータを関連付けるステップは、線形勾配ブラシと少なくとも１つの停止を含む停止集合とに対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項９】
前記ブラシデータを関連付けるステップは、放射勾配ブラシに対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項１０】
前記ブラシデータを関連付けるステップは、画像に対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項１１】
前記画像に適用する画像効果に対応するマークアップ言語データを受け取るステップをさらに備えたことを特徴とする請求項１０に記載の方法。
【請求項１２】
形状の輪郭を定義するペンデータに対応するマークアップ言語データを受け取るステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１３】
前記マークアップ言語データは、矩形、線分群、多角形、軌跡、線分、および楕円の形状を含む集合のうちの少なくとも１つを含む形状クラスに対応することを特徴とする請求項１に記載の方法。
【請求項１４】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に矩形を表す幾何学形状関連機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１５】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に軌跡を表す幾何学形状関連機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１６】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に線分を表す幾何学形状関連機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１７】
前記マークアップ言語データは、前記シーングラフデータ構造内の映像のヒットテストに関連することを特徴とする請求項１に記載の方法。
【請求項１８】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内の映像の座標変形に関する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１９】
前記マークアップ言語データは、前記シーングラフデータ構造内の映像の境界ボックスの計算に関連することを特徴とする請求項１に記載の方法。
【請求項２０】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内の映像オブジェクトへの共通インターフェースを介して機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２１】
映像マネージャを呼び出し、レンダリング対象に少なくとも１つの映像オブジェクトのツリーをレンダリングするステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項２２】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に少なくとも１つの映像オブジェクトを含むように構成されるコンテナオブジェクトを配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２３】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に画像データを配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２４】
前記シーングラフ内のデータを修正するステップは、前記画像データに関連付けられた前記シーングラフデータ構造内に画像効果オブジェクトを配置する機能を呼び出すステップを含むことを特徴とする請求項２３に記載の方法。
【請求項２５】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内にテキストに対応するデータを配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２６】
前記シーングラフ内のデータを修正するステップは、前記機能呼出しに応答して描画コンテキストを提供する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２７】
前記機能呼出しは、保持された映像に対応し、コールバックを行って前記保持された映像の描画コンテキストを前記シーングラフデータ構造に戻すステップをさらに備えたことを特徴とする請求項２６に記載の方法。
【請求項２８】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に３次元映像を配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２９】
前記シーングラフ内のデータを修正するステップは、前記３次元映像に２次元表面をマッピングするステップを含むことを特徴とする請求項２８に記載の方法。
【請求項３０】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内にアニメーションデータを配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項３１】
前記アニメーションデータに対応するタイムライン情報を合成エンジンに送るステップをさらに備えたことを特徴とする請求項３０に記載の方法。
【請求項３２】
前記合成エンジンは、前記タイムライン情報に基づくグラフィックスデータを補間し、前記シーングラフデータ構造内のオブジェクトに対応する出力をアニメーション化することを特徴とする請求項３１に記載の方法。
【請求項３３】
前記合成エンジンは、前記シーングラフについて低いレベルであることを特徴とする請求項３２に記載の方法。
【請求項３４】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内に音声および／またはビデオデータに対応するオブジェクトを配置する機能を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項３５】
前記シーングラフ内のデータを修正するステップは、前記シーングラフデータ構造内のオブジェクトの可変値を変更するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３６】
コンピューティング環境において、
マークアップパーサと、
前記マークアップパーサをマークアップ言語データのソースに結合するインターフェースと、
オブジェクトモデルの映像情報用のコンテナと、
を備えたシステムであって、前記マークアップパーサは、前記インターフェースで受け取ったマークアップ言語データを前記オブジェクトモード内のオブジェクトのメソッド呼出しに変換し、前記映像情報用のコンテナ内のデータを修正することを特徴とするシステム。
【請求項３７】
前記マークアップ言語データは、メソッド呼出しに変換され、映像オブジェクトのツリーをシーングラフデータ構造内に配置することを特徴とする請求項２６に記載のシステム。
【請求項３８】
前記マークアップ言語データは、少なくとも１つのメソッド呼出しに変換され、前記映像オブジェクトのツリーを前記シーングラフデータ構造内に配置構成することを特徴とする請求項３７に記載のシステム。
【請求項３９】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトを前記シーングラフデータ構造内に配置することを特徴とする請求項３７に記載のシステム。
【請求項４０】
前記マークアップ言語データは、メソッド呼出しに変換され、映像オブジェクトを前記シーングラフデータ構造内に配置することを特徴とする請求項３６に記載のシステム。
【請求項４１】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトにブラシを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項４２】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに幾何学形状を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項４３】
前記幾何学形状は、楕円形状、矩形形状、線分形状、および軌跡形状を含む集合のうちの少なくとも１つを含むことを特徴とする請求項４２に記載のシステム。
【請求項４４】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトと変形とを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項４５】
前記変形は、前記映像オブジェクトの知覚された角度を変更する回転変形を含むことを特徴とする請求項４４に記載のシステム。
【請求項４６】
前記変形は、前記映像オブジェクトの知覚されたサイズを変更する尺度変形を含むことを特徴とする請求項４４に記載のシステム。
【請求項４７】
前記変形は、前記映像オブジェクトの知覚された位置を変更する変換変形を含むことを特徴とする請求項４４に記載のシステム。
【請求項４８】
前記変形は、前記映像オブジェクトの知覚された歪みを変更する歪み変形を含むことを特徴とする請求項４４に記載のシステム。
【請求項４９】
前記マークアップ言語データは、前記変形に関連付けられたアニメーション情報を提供するものであって、前記アニメーション情報は、前記変形に関連付けられた変形データを経時的に変更し、それによって前記映像オブジェクトの前記変形を経時的にアニメーション化するものであることを特徴とする請求項４４に記載のシステム。
【請求項５０】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに色を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５１】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに勾配データを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５２】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトにタイルブラシを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５３】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに画像を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５４】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに描画プリミティブを備える描画を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５５】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに音声および／またはビデオ媒体を関連付けるためにことを特徴とする請求項４０に記載のシステム。
【請求項５６】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに画像効果を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５７】
前記マークアップ言語データは、形状の輪郭がどのようであるかを記述するために、メソッド呼出しに変換され、前記映像オブジェクトにペンを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５８】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに関連付けられた描画コンテキストを取得することを特徴とする請求項４０に記載のシステム。
【請求項５９】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトにヒットテストデータを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項６０】
前記マークアップ言語データは、メソッド呼出しに変換され、前記映像オブジェクトに矩形を関連付けることを特徴とする請求項４０に記載のシステム。
【請求項６１】
前記マークアップ言語データは、ソースの矩形をどのように引伸ばし、目的の矩形に合わせるべきかを記述するデータを含むことを特徴とする請求項６０に記載のシステム。
【請求項６２】
コンピューティング環境において、
マークアップ言語データを備えた機能呼出しを受け取るためのインターフェース手段と、
前記マークアップ言語データをグラフィックスデータのレンダリングに関連付けられたオブジェクトモデルに対応するデータに変換する解析手段と、
前記グラフィックスデータを出力するレンダリング手段と
を備えたことを特徴とするシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【公表番号】特表２００７−５０９４３６（Ｐ２００７−５０９４３６Ａ）
【公表日】平成１９年４月１２日（２００７．４．１２）
【国際特許分類】
【出願番号】特願２００６−５３６６０８（Ｐ２００６−５３６６０８）
【出願日】平成１６年７月２８日（２００４．７．２８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２５７２３
【国際公開番号】ＷＯ２００５／０４５８００
【国際公開日】平成１７年５月１９日（２００５．５．１９）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成１９年４月１２日（２００７．４．１２）
【国際特許分類】
【出願日】平成１６年７月２８日（２００４．７．２８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２５７２３
【国際公開番号】ＷＯ２００５／０４５８００
【国際公開日】平成１７年５月１９日（２００５．５．１９）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]