(57)【要約】  プログラムコード開発者は、アプリケーションプログラミングインターフェイス（ＡＰＩ）およびオブジェクトモデルで実装されるインターフェースムを使用することにより、シーングラフデータ構造と矛盾しない形で出力グラフィックスとのインターフェースを実現できる。プログラムコードでは、インターフェースを介して、幾何学形状データ、画像データ、アニメーションデータ、およびその他のデータなどの描画プリミティブを、バリデーション映像オブジェクト、描画映像オブジェクト、および表面映像オブジェクトを含む、描画表面を表す映像に書き込む。このコードでは、さらに、映像に関する変換、クリッピング、および不透明を指定し、子映像を他の映像に追加して、階層型シーングラフを構築することもできる。映像マネージャは、シーングラフをトラバースして、リッチグラフィックスデータを低いレベルのグラフィックスコンポーネントに供給する。
2007509420.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング環境において、
シーングラフに関連付けられているオブジェクトモデルのオブジェクトのインターフェースを介して関数呼び出しを受け取るステップと、
前記シーングラフ内のデータを修正するステップにより、前記関数呼び出しに応答するステップと
を備えたことを特徴とする方法。
【請求項２】
前記シーングラフ内のデータを修正するステップは、映像クラスの新規インスタンスを初期化させるステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記シーングラフ内のデータを修正するステップは、前記シーングラフ内の映像オブジェクトと変換とを関連付けるコードを呼び出すステップを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフ内に描画映像を配置するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記描画映像内にレンダリング機構を有する描画コンテキストを戻すステップをさらに備えたことを特徴とする請求項４に記載の方法。
【請求項６】
前記シーングラフ内のデータを修正するステップは、前記シーングラフ内の映像オブジェクトとブラシデータとを関連付けるコードを呼び出すステップを含むことを特徴とする請求項２に記載の方法。
【請求項７】
ソリッドカラーに対応するデータとして前記ブラシデータを受け取るステップをさらに備えたことを特徴とする請求項６に記載の方法。
【請求項８】
前記ブラシデータを受け取るステップは、線形勾配ブラシおよび少なくとも１つの停止を含む停止集合に対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項９】
前記ブラシデータを受け取るステップは、放射状勾配ブラシに対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項１０】
前記ブラシデータを受け取るステップは、画像に対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項１１】
画像効果に対応するインターフェースを介して関数呼び出しを受け取り、前記画像に用いるステップをさらに備えたことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記関数呼び出しと関連してペンデータを受け取るステップをさらに備え、前記シーングラフデータ構造内のデータを修正するステップは、形状の輪郭を定義するペン関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内で楕円を表すコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内で矩形を表すコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１５】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内で軌跡を表すコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１６】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内で線分を表すコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１７】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内で映像のヒットテストの実行に関係するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１８】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内で映像の座標変換を実行するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１９】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内で映像の境界ボックスを計算するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２０】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造に映像オブジェクトを配置するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２１】
映像マネージャを呼び出し、少なくとも１つの映像オブジェクトのツリーをレンダリング対象にレンダリングするステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項２２】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造にコンテナオブジェクトを配置するコードを呼び出すステップを含み、前記コンテナオブジェクトが、少なくとも１つの映像オブジェクトを含むように構成されることを特徴とする請求項１に記載の方法。
【請求項２３】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内に画像データを配置するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２４】
前記シーングラフデータ構造内のデータを修正するステップは、前記画像データに関連付けられている前記シーングラフデータ構造内に画像効果オブジェクトを配置するコードを呼び出すステップを含むことを特徴とする請求項２３に記載の方法。
【請求項２５】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内にテキストに対応するデータを配置するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２６】
前記シーングラフデータ構造内のデータを修正するステップは、前記関数呼び出しへの応答として描画コンテキストを提供するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２７】
前記関数呼び出しは、保持された映像に対応し、およびコールバックし、前記保持された映像の前記描画コンテキストを前記シーングラフデータ構造に返すステップをさらに備えたことを特徴とする請求項２６に記載の方法。
【請求項２８】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造に３次元映像を配置するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２９】
シーングラフデータ構造内のデータを修正するステップは、前記３次元映像に２次元表面をマッピングするコードを呼び出すステップを含むことを特徴とする請求項２８に記載の方法。
【請求項３０】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内にアニメーションデータを配置するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項３１】
前記アニメーションデータに対応するタイムライン情報を合成エンジンに伝達するステップをさらに備えたことを特徴とする請求項３０に記載の方法。
【請求項３２】
前記合成エンジンは、前記タイムラインに基づくグラフィックスデータを補間し、前記シーングラフデータ構造内でオブジェクトに対応する出力をアニメーション化するステップを特徴とする請求項３１に記載の方法。
【請求項３３】
前記インターフェースを介して関数呼び出しを受け取るステップは、マークアップ言語データを受け取るステップを含み、前記シーングラフデータ構造内のデータを修正させるステップは、オブジェクトのインターフェースへの呼び出しに前記マークアップ言語データを構文解析するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３４】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内に音声および／またはビデオデータに対応するオブジェクトを配置するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項３５】
前記シーングラフデータ構造内のデータを修正するステップは、前記シーングラフデータ構造内のオブジェクトの変異可能な値を変更するコードを呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項３６】
コンピューティング環境において、
可視化が可能な統合された出力とすることができるデータを含むシーングラフデータ構造と、
前記シーングラフデータ構造に含めることができる映像オブジェクトおよびその他のデータを含むオブジェクトモデルと
を備えたことを特徴とするシステム。
【請求項３７】
前記映像オブジェクトのツリーを前記シーングラフデータ構造内に配置するために、前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出されることを特徴とする請求項３６に記載のシステム。
【請求項３８】
呼び出されると、前記映像オブジェクトのツリーをレンダリング対象にレンダリングする映像マネージャをさらに備えたことを特徴とする請求項３７に記載のシステム。
【請求項３９】
前記映像オブジェクトのツリーは、映像集合オブジェクトに含まれることを特徴とする請求項３７に記載のシステム。
【請求項４０】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、前記映像オブジェクトを前記シーングラフデータ構造内に配置することを特徴とする請求項２６に記載のシステム。
【請求項４１】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、ブラシを前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項４２】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、幾何学形状を前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項４３】
前記幾何学形状は、楕円形状、矩形形状、線分形状、および軌跡形状を含む集合の中の少なくとも１つを含むことを特徴とする請求項４２に記載のシステム。
【請求項４４】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、前記映像オブジェクトと変換とを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項４５】
前記変換は、前記映像オブジェクトの認識されている角度を変更する回転変換を含むことを特徴とする請求項４４に記載のシステム。
【請求項４６】
前記変換は、前記映像オブジェクトの認識されているサイズを変更する拡大縮小変換を含むことを特徴とする請求項４４に記載のシステム。
【請求項４７】
前記変換は、前記映像オブジェクトの認識されている位置を変更する平行移動変換を含むことを特徴とする請求項４４に記載のシステム。
【請求項４８】
前記変換は、前記映像オブジェクトの認識されている傾斜を変更する傾斜変換を含むことを特徴とする請求項４４に記載のシステム。
【請求項４９】
前記変換に関連付けられたアニメーション情報をさらに備え、前記アニメーション情報により、前記変換に関連付けられている変換データが時間の経過に伴って変化し、前記映像オブジェクトの変換のアニメーションが時間の経過に伴って実行されることを特徴とする請求項４４に記載のシステム。
【請求項５０】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、前記映像オブジェクトと色とを関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５１】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、勾配データを前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５２】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、タイルブラシを前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５３】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、画像を前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５４】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、３次元データを前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５５】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、描画プリミティブを含む描画を前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５６】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、音声および／またはビデオ媒体を前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５７】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、画像効果を前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項５８】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、ペンを前記映像オブジェクトに関連付け、形状の輪郭の作り方を記述することを特徴とする請求項４０に記載のシステム。
【請求項５９】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、前記映像オブジェクトに関連付けられている描画コンテキストを取得することを特徴とする請求項４０に記載のシステム。
【請求項６０】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、ヒットテストデータを前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項６１】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、矩形を前記映像オブジェクトに関連付けることを特徴とする請求項４０に記載のシステム。
【請求項６２】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、前記映像オブジェクトに対応する元の矩形をどのように引き延ばし、目的の矩形に適合させるかを記述することを特徴とする請求項６１に記載のシステム。
【請求項６３】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、前記映像オブジェクトに対応するコンテナ内で垂直にどのようにコンテンツを配置するかを記述することを特徴とする請求項６１に記載のシステム。
【請求項６４】
前記オブジェクトモデルのオブジェクトの少なくとも１つの関数が呼び出され、前記映像オブジェクトに対応するコンテナ内で水平にどのようにコンテンツを配置するかを記述することを特徴とする請求項６１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にはコンピュータシステムに関し、より詳細には、コンピュータシステムに表示するグラフィックおよびその他のビデオ情報を処理することに関する。
【背景技術】
【０００２】
コンピュータシステム上のグラフィックスにアクセスする従来の即時モードモデルは限界に達してきている。その原因の一部は、メモリおよびバスのスピードが主プロセッサおよび／またはグラフィックスプロセッサの進歩に遅れをとっていることである。一般に、フレームを作成するための現在の（例えばＷＭ＿ＰＡＩＮＴ）モデルでは、複雑なグラフィックス効果が望まれる場合に、ハードウェアのリフレッシュ速度に遅れないために大量のデータを処理する必要がある。結果として、従来のグラフィックスモデルで複雑なグラフィックス効果が試される場合、結果的に次のフレームで遅れずに視覚効果が知覚されるように変更を完了する代わりに、異なるフレームにわたって変更が追加される場合があり、視覚的にかつ顕著に望ましくない結果となる。
【０００３】
グラフィックス出力を制御するための新しいモデルが記載されており（例えば、特許文献１、２、３、４、５、および６を参照）、本発明の譲受人に譲渡され、参照により本明細書に組み込まれている。この新しいモデルは、グラフィックス処理技術においていくつかの重要な改良点を提供するものである。例えば、複数レベルのグラフィックス処理のシステムおよび方法を対象としているものもあり（例えば、特許文献１参照）、（例えば、オペレーティングシステムの）より高いレベルのコンポーネントが、簡略化されたデータ構造および／またはグラフィックスコマンドを低いレベルのコンポーネントに渡すために、シーングラフの構築、アニメーションパラメータの更新、およびシーングラフのデータ構造のトラバースという、相対的に遅い動作速度で集中的に計算が行われる態様を実行する。高いレベルの処理がデータを大幅に簡略化することから、低いレベルのコンポーネントは、グラフィックスサブシステムのフレームのリフレッシュ速度に対応する速度など、（高いレベルのコンポーネントに比べて）より高速に動作し、データをグラフィックスサブシステム用の定常出力データに処理することが可能である。アニメーションが使用される場合、低いレベルの処理は、変更に伴ってシーン全体を書き直すことなく、必要に応じてレンダリング時にわずかに変更されたシーンをフレームごとに提供する瞬間値を取得するためにパラメータ間隔を補間し、平滑なアニメーションを提供することができる。
【０００４】
可変（アニメーション化された）値を提供するパラメータ化されたシーングラフと、グラフィックスを描画しようとするプログラムコード（例えば、アプリケーションプログラムまたはオペレーティングシステムコンポーネント）が、他のアスペクトはそのままでシーングラフ記述の一定のアスペクトを選択的に変更できるようにパラメータ化されたグラフコンテナとが記載されている（例えば、特許文献２を参照）。プログラムコードは、異なるパラメータを使用する可能性のある、シーングラフのうちのすでに構築された部分を再使用することもできる。パラメータ化を介して表示されたアイテムの外観を容易に変更する機能、および／またはシーングラフの既存の部分の再使用は、グラフィックス処理効率全体を大きく改善することが理解されよう。
【０００５】
シーングラフ内のオブジェクトおよびデータを介して映像情報を格納するための、キャッシュデータ構造および関連機構が、全体として記載されている（例えば、特許文献３を参照）。データ構造は一般に、その中の映像情報がどのように読み込み（ｐｏｐｕｌａｔｅ）および使用されるかを知的に制御する機構に関連付けられる。例えば、アプリケーションプログラムが特に要求しない限り、データ構造内に格納されたほとんどの情報はそれに対する外部参照を持たないため、この情報を最適化するかまたはその他の方法で処理することができる。これによって効率性とリソースの保存性が与えられ、例えばキャッシュデータ構造内のデータを、よりコンパクトであり、かつ／または、ビットマップまたは他の後処理結果などの後続の反復的な処理が少ない異なるフォーマットに処理可能であることが理解されよう。
【０００６】
上記の改良点はグラフィックス処理技術に大きな恩恵を与えるものであるが、依然として、この改良されたグラフィックスモデルおよびその他の関連する改良点を簡単な方法で効果的に使用するためのプログラムが求められている。改良されたグラフィックスモデルによって提供される多くの特徴およびグラフィックス処理機能を利用し、それによって複雑なグラフィックスおよび視聴覚データを効率的な方法で出力するための、包括的かつ簡単なプログラム用のモデルが必要とされている。
【０００７】
【特許文献１】米国特許出願第１０／１８４７９５号明細書
【特許文献２】米国特許出願第１０／１８４７９６号明細書
【特許文献３】米国特許出願第１０／１８５７７５号明細書
【特許文献４】米国特許出願第１０／４０１７１７号明細書
【特許文献５】米国特許出願第１０／４０２３２２号明細書
【特許文献６】米国特許出願第１０／４０２２６８号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
簡潔に述べると、本発明は、オブジェクトモデルを提供し、さらにプログラムコード開発者がシーングラフデータ構造との矛盾のないインターフェースを介してグラフィックスを出力できるように、そのオブジェクトモデルにアクセスするアプリケーションプログラミングインターフェイス（ＡＰＩ）を提供する。このモデルおよびＡＰＩ群における基本オブジェクトは、ユーザに対し仮想表面を表示する映像（Ｖｉｓｕａｌｓ）であり、シーングラフは、映像オブジェクトで構成される。このような映像には、コンテナの映像オブジェクト（ｃｏｎｔａｉｎｅｒ  ｖｉｓｕａｌ  ｏｂｊｅｃｔｓ）、保持される映像オブジェクト（ｒｅｔａｉｎｅｄ  ｖｉｓｕａｌ  ｏｂｊｅｃｔｓ）、描画する映像オブジェクト（ｄｒａｗｉｎｇ  ｖｉｓｕａｌ  ｏｂｊｅｃｔｓ）、およびその他の映像オブジェクトがある。映像自体は、クリップオブジェクト、変換オブジェクトなどのリソースオブジェクト上に保持することができ、ある種の映像（例えば、ＤｒａｗｉｎｇＶｉｓｕａｌ、  ＲｅｔａｉｎｅｄＶｉｓｕａｌ）は、画像、ブラシ、および／または勾配（ｇｒａｄｉｅｎｔ）などのリソースオブジェクトを参照できる描画命令リスト（ｄｒａｗｉｎｇ  ｉｎｓｔｒｕｃｔｉｏｎ  ｌｉｓｔ）上に保持することができる。
【課題を解決するための手段】
【０００９】
シーングラフ内のほとんどのリソースオブジェクトは、いったん作成されると不変性（ｉｍｍｕｔａｂｌｅ）がある、つまり作成されると変更がきかないということである。開発者が簡単に変更できることを望むオブジェクトについては、本発明の譲受人に譲渡され、参照により本明細書に組み込まれている、本明細書と同時に出願された「Changeable Class and Pattern to  Provide Selective Mutability in Computer Programming Environments」という表題の米国同時係属特許出願において説明されているように、変更可能パターンおよび実装により変異性（ｍｕｔａｂｉｌｉｔｙ）が与えられる。
【００１０】
アプリケーションプログラミングインターフェイスを介して、プログラムコードは、幾何学形状データ、画像データ、アニメーションデータ、およびその他のデータなどの描画プリミティブを映像に書き込む。例えば、プログラムコードは、線分描画命令、幾何学形状描画命令、ビットマップ描画命令などの描画プリミティブを映像に書き込む。これらの描画命令は、軌跡の描画の仕方を記述する幾何学形状データなどの複合データと組み合わせられることが多く、また、ビットマップ、ビデオなどのリソースを参照することもできる。
【００１１】
コードで映像のクリッピング、不透明、およびその他のプロパティを指定することができ、また変換、不透明、およびヒットテスト識別のプッシュおよびポップ変換を行うメソッドが提供される。さらに、映像は、ヒットテストに加わることができる。プログラムコードは、さらに、映像とのインターフェースを介して、子映像を追加し、それにより、階層型シーングラフを構成する。映像マネージャは、シーングラフを処理（例えば、トラバースまたは伝送）して、リッチグラフィックスデータを低いレベルのグラフィックスコンポーネントに供給する。
【００１２】
コンテナ映像は、子映像の集合を規定し、一実装では、階層を定義できる唯一の映像である。コンテナ映像上の子の集合では、子映像の任意の挿入、削除、および並べ替えを行うことができる。
【００１３】
描画映像は、呼び出し側に描画コンテキスト（例えば、描画コンテキストオブジェクトへの参照）を返すオープン呼び出しで開かれる。一般に、描画コンテキストは、映像を配置するために使用される一時的補助オブジェクトである。その後、プログラムコードは、描画コンテキストを使用して、描画プリミティブを映像に追加する。オープン呼び出しにより、映像のコンテンツ（子）を削除するか、または追加呼び出しを使用して、その現在の映像に付加するため映像を開くことができる。描画パラメータとして静的な値を受け取ることのほかに、描画コンテキストをアニメーションオブジェクトで塗りつぶすことができる。
【００１４】
保持映像は、プログラムコード側で塗りつぶすことを望んでいるときではなく、システムが塗りつぶすことを要求したときに描画コンテキストが塗りつぶされることを除き、描画映像と似た方法で動作する。例えば、シーンのレンダリングで特定の映像のコンテンツが必要になる場合、システムはＩＲｅｔａｉｎｅｄＶｉｓｕａｌ．Ｒｅｎｄｅｒを呼び出して映像のコンテンツを塗りつぶし、メモリ内にすでにあるコンテンツを置き換える。
【００１５】
こうして、描画コンテキストを使用して、幾何学形状、画像データ、およびビデオデータを含む、異なる種類のプリミティブを映像内に描画することができる。幾何学形状は、ストロークまたは塗りつぶしなしのベクトルグラフィックススケルトン、例えば矩形を定義するある種のクラスである。それぞれの幾何学形状オブジェクトは、単純な形状（ＬｉｎｅＧｅｏｍｅｔｒｙ、ＥｌｌｉｐｓｅＧｅｏｍｅｔｒｙ、ＲｅｃｔａｎｇｌｅＧｅｏｍｅｔｒｙ）、複合単一形状（ＰａｔｈＧｅｏｍｅｔｒｙ）、または結合オペレーション（例えば、合併、交差など）が指定されているそのような形状のリスト（ＧｅｏｍｅｔｒｙＬｉｓｔ）に対応する。これらのオブジェクトはクラス階層を形成する。さらに、ＤｒａｗＲｅｃｔａｎｇｌｅメソッドなどの使用されるいくつかの種類の幾何学形状を頻繁に描画するためのショートカットもある。
【００１６】
幾何学形状が描画される場合、ブラシまたはペンを指定することができる。ブラシオブジェクトは平面にグラフィックスで埋める方法を定義し、ブラシオブジェクトのクラス階層がある。ペンも、ストローク領域を塗りつぶす方法を記述した、指定されたブラシを有する。特別な種類のブラシオブジェクト（ＶｉｓｕａｌＢｒｕｓｈ）は、そのブラシを描画する方法を定義するために映像を参照できる。描画ブラシにより、他の形状とブラシの組み合わせで形状を塗りつぶしたり制御したりすることが可能である。
【００１７】
他の利点および特徴は、図面とともに説明したときに以下の詳細な説明から明らかになる。
【発明を実施するための最良の形態】
【００１８】
（例示的なオペレーティング環境）
図１は、本発明が実施可能である、適したコンピューティングシステム環境１００の一例を示す図である。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲に関していかなる制限をも示唆することを意図するものではない。さらにコンピューティング環境１００は、例示的オペレーティング環境１００内に示されたいずれのコンポーネントまたはコンポーネントの組合せに関しても、いかなる依存性または要件を有するものとも解釈されるべきではない。
【００１９】
本発明は、多数の他の汎用または特定用途向けのコンピューティングシステム環境または構成を使用して動作可能である。本発明で使用するのに適する可能性のある、よく知られたコンピューティングシステム、環境、および／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、タブレット装置、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能な市販の電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたは装置のいずれかを含む分散コンピューティング環境、およびその他が含まれるが、これらに限定されるものではない。
【００２０】
本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令との全体的な関連において説明することができる。一般に、プログラムモジュールにはルーチン、プログラム、オブジェクト、コンポーネント、データ構造、などが含まれ、特定のタスクを実行するかまたは特定の抽象データ型を実施する。本発明は、タスクが通信ネットワークを介してリンクされたリモート処理装置によって実行される、分散コンピューティング環境でも実施可能である。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよびリモート双方のコンピュータ記憶媒体に配置することができる。
【００２１】
図１を参照すると、本発明を実施するための例示的システムには、コンピュータ１１０の形の汎用コンピューティング装置が含まれる。コンピュータ１１０のコンポーネントは、処理装置１２０と、システムメモリ１３０と、システムメモリを含む様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１とを含むことができるが、これらに限定されるものではない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含む、いくつかの種類のバス構造のうちのいずれであってもよい。例を挙げると、こうしたアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ）バス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれるが、これらに限定されるものではない。
【００２２】
コンピュータ１１０は、通常、様々なコンピュータ読取り可能な媒体を含む。コンピュータ読取り可能な媒体は、コンピュータ１１０によってアクセス可能な揮発性および不揮発性媒体、ならびに取外し可能および固定の両方の媒体を含む、任意の使用可能な媒体とすることが可能である。例を挙げると、コンピュータ読取り可能な媒体はコンピュータ記憶媒体および通信媒体を含むことができるが、これらに限定されるものではない。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、または他のデータなどの、情報を記憶するための任意の方法または技術で実施された揮発性および不揮発性、取外し可能および固定の、両方の媒体を含む。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、あるいは所望の情報を記憶するために使用可能でありコンピュータ１１０がアクセス可能な任意の他の媒体が含まれるが、これらに限定されるものではない。通信媒体は、通常、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、または搬送波または他の移送機構などの被変調データ信号中の他のデータを具体化し、任意の情報送達媒体を含むものである。「被変調データ信号」という用語は、信号内の情報を符号化するような方法で、その特性のうちの１つまたは複数が設定または変更された信号を意味する。例を挙げると、通信媒体には、有線ネットワークまたはダイレクトワイヤード接続などの有線媒体と、音波、ＲＦ、赤外線、および他の無線媒体などの無線媒体とが含まれるが、これらに限定されるものではない。上記のうちの任意の組合せも、コンピュータ読取り可能な媒体の範囲に含まれるものとする。
【００２３】
システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。コンピュータ１１０内の要素間での起動時などの情報転送に役立つ基本ルーチンを含む基本入力／出力システム１３３（ＢＩＯＳ）は、通常、ＲＯＭ１３１に格納される。ＲＡＭ１３２は、通常、処理装置１２０が即時にアクセス可能であり、かつ／または現在動作中である、データおよび／またはプログラムを含む。例を挙げると、図１にはオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７が示されているが、これらに限定されるものではない。
【００２４】
コンピュータ１１０は、他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体を含むこともできる。単なる例として、図１には、固定の不揮発性磁気媒体からの読取りまたはこれへの書込みを行うハードディスクドライブ１４１と、取外し可能な不揮発性磁気ディスク１５２からの読取りまたはこれへの書込みを行う磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭまたは他の光媒体などの取外し可能な不揮発性光ディスク１５６からの読取りまたはこれへの書込みを行う光ディスクドライブ１５５が示されている。例示的なオペレーティング環境で使用可能な他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、などが含まれるが、これらに限定されるものではない。ハードディスクドライブ１４１は、通常、インターフェース１４０などの固定のメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取外し可能メモリインターフェースによってシステムバス１２１に接続される。
【００２５】
上記で考察し、図１に示すドライブおよびそれらの関連するコンピュータ記憶媒体は、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、およびコンピュータ１１０に関する他のデータのストレージを提供するものである。例えば図１では、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納しているものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであるかまたは異なるかの、いずれであってもよいことに留意されたい。本明細書では、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともこれらが異なるコピーであることを示すために異なる番号が与えられている。ユーザは、タブレット（電子ディジタイザ）１６４、マイクロフォン１６３、キーボード１６２、および、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などの入力装置を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、スキャナ、またはその他を含むことができる。これらおよび他の入力装置は、システムバスに結合されたユーザ入力インターフェース１６０を介して処理装置１２０に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することも可能である。モニタ１９１または他の種類のディスプレイ装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１は、タッチスクリーンインターフェースなどのインターフェースを介してコンピュータシステム１１０に手書き入力するなどの、デジタル化された入力を行うことのできる、タッチスクリーンパネルまたはその他と一体型にすることも可能である。モニタおよび／またはタッチスクリーンパネルは、タブレット型のパーソナルコンピュータの場合などのように、コンピューティングデバイス１１０が組み込まれたハウジングに物理的に結合可能であり、ここでタッチスクリーンパネルは本質的にタブレット１６４として働くことに留意されたい。さらに、コンピューティングデバイス１１０などのコンピュータは、出力周辺インターフェース１９４またはその他を介して接続可能なスピーカ１９５およびプリンタ１９６などの他の周辺出力装置も含むことができる。
【００２６】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般的なネットワークノードとすることが可能であり、通常は、コンピュータ１１０に関して上記で述べた要素の多くまたはすべてを含むが、図１にはメモリ記憶装置１８１のみが記載されている。図１に示された論理接続には、ローカル絵リアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークを含むこともできる。こうしたネットワーキング環境は、オフィス、企業規模コンピュータネットワーク、イントラネット、およびインターネットで普及している。
【００２７】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０はネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介した通信を確立するためのモデム１７２または他の手段を含む。モデム１７２は内蔵型または外付けが可能であり、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化環境では、コンピュータ１１０に関して示されたプログラムモジュールまたはその一部を、リモートのメモリ記憶デバイスに格納することができる。例を挙げると、図１にはリモートアプリケーションプログラム１８５がメモリ装置１８１に常駐しているように示されているが、これらに限定されるものではない。図示されたネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段が使用可能であることを理解されよう。
【００２８】
（シーングラフデータ構造へのインターフェース）
本発明の一態様は、一般に、アプリケーションまたはオペレーティングシステムコンポーネントなどのプログラムコードが、システムディスプレイ上にグラフィック出力をレンダリングするために、描画命令および他の情報（例えば画像ビットマップ）をグラフィックスコンポーネントに送ることができるようにすることを対象としている。このため本発明は、プログラムがデータ構造、描画プリミティブ（コマンド）、および他のグラフィックス関連データと共にシーングラフを読み込めるようにする例えば、オブジェクトモデルへのアプリケーションプログラムインターフェースの形において、いくつかの予め定義された関数および方法を提供するものである。処理が実行されると、シーングラフはスクリーン上にグラフィックスを表示することになる。
【００２９】
図２は、本発明が実施可能な、全体的なレイヤードアーキテクチャ２００を示す図である。図２に示されるように、（例えば、アプリケーションプログラムまたはオペレーティングシステムコンポーネントなど）プログラムコード２０２を開発して、画像化機構２０４を介すること、ベクトルグラフィック要素２０６を介すること、および／または映像アプリケーションプログラミングインターフェース（ＡＰＩ）レイヤ２１２に直接配置された機能／メソッド呼出しを介することを含む、本発明の一態様に基づいて１つまたは複数の様々な方法でグラフィックスデータを出力することができる。一般に、画像２０４は、読み込み、編集および例えばビットマップなどの画像の保存のための機構を有するプログラムコード２０２を提供する。上述のように、これらの画像をシステムの他の一部によって使用することができる。プリミティブ描画コードを使用して、画像を直接描く方法もある。ベクトルグラフィック要素２０６は、（下記の）他のオブジェクトモデルに適合するグラフィックを描く他の方法を提供する。要素／プロパティシステム２０８およびレイアウトシステム２１０が解釈し、適する呼び出しを作成するマークアップ言語によって、ベクトルグラフィック要素２０６を生成することができる。ベクトルグラフィック要素２０６は、要素／プロパティシステム２０８およびレイアウトシステム２１０と共に、特許文献４において説明される。
【００３０】
一実施態様では、グラフィックスレイヤアーキテクチャ２００には高いレベルの合成およびアニメーションエンジン２１４が含まれ、これがキャッシュデータ構造２１６を含むかまたは他の方法でこれに関連付けられる。キャッシュデータ構造２１６は、以下で説明するように、定義済みオブジェクトモデルに従って管理される階層上に配置構成されたオブジェクトを備えたシーングラフを含む。一般に、映像ＡＰＩレイヤ２１２は、オブジェクトの作成、オブジェクトにデータを提供するためのオブジェクトのオープンおよびクローズなどの機能を含む、キャッシュデータ構造２１６へのインターフェースをプログラムコード２０２（およびレイアウトシステム２１０）に提供する。つまり、高いレベルの合成およびアニメーションエンジン２１４は、開発者が、グラフィックス情報を表示するためにグラフィックスおよび媒体に関する意図を表現し、基礎となるプラットフォームがプログラムコードに対するハードウェアの使用を最適化できるようにプラットフォームに十分な情報を提供する際に使用できる統一媒体ＡＰＩレイヤ２１２を公開する。例えば基礎となるプラットフォームは、キャッシュ、リソースの折衝（ｎｅｇｏｔｉａｔｉｏｎ）、および媒体の統合に関する責務を負うことになる。
【００３１】
一実施態様では、高いレベルの合成およびアニメーションエンジン２１４は、命令ストリームおよび可能な他のデータ（例えばビットマップを指すポインタ）を高速の低いレベルの合成およびアニメーションエンジン２１８に渡す。「高いレベル」および「低いレベル」という用語が本明細書で使用される場合、他のコンピューティングシナリオで使用される場合と同様に、一般に、高いレベルのコンポーネントに比べてソフトウェアコンポーネントが低いレベルであるほど、そのコンポーネントはハードウェアに近くなる。したがって、例えば高いレベルの合成およびアニメーションエンジン２１４から送られたグラフィックス情報を、低いレベルの合成およびアニメーションエンジン２１８で受け取ることが可能であり、ハードウェア２２２を含むグラフィックスサブシステムにグラフィックスデータを送信する際にその情報が使用される。
【００３２】
高いレベルの合成およびアニメーションエンジン２１４はプログラムコード２０２と共に、プログラムコード２０２によって提供されたグラフィックスシーンを表すためのシーングラフを構築する。例えば、描画されるそれぞれのアイテムを描画命令と共にロードすることが可能であり、システムはこれをシーングラフデータ構造２１６にキャッシュすることができる。以下で説明するように、このデータ構造２１６および何を描画するかを指定するにはいくつかの様々な方法がある。さらに、高いレベルの合成およびアニメーションエンジン２１４は、タイミングおよびアニメーションシステム２２０と統合し、宣言（または他の）アニメーション制御（例えばアニメーション間隔）およびタイミング制御を提供する。アニメーションシステムは、本質的にアニメーション値を、例えば要素プロパティレベル２０８、映像ＡＰＩレイヤ２１２の内部、および任意の他のリソース内を含む、システム内のどこにでも渡せるようにするものであることに留意されたい。タイミングシステムは、要素レベルおよび映像レベルで公開される。
【００３３】
低いレベルの合成およびアニメーションエンジン２１８はシーンの合成、アニメーション、およびレンダリングを管理し、その後これがグラフィックスサブシステム２２２に提供される。低いレベルのエンジン２１８は、複数のアプリケーションのシーンについてレンダリングを合成し、レンダリングコンポーネントを使用して、スクリーンへのグラフィックスの実際のレンダリングを実施する。しかし、時には、一部のレンダリングはより高いレベルで発生することが必要かつ／または有利な場合があることに留意されたい。例えば、複数アプリケーションからのサービス要求が低レイヤになるほど、アプリケーションごとのインスタンス生成がより高レイヤになり、これによって、画像化機構２０４を介して、時間のかかるまたはアプリケーション特有のレンダリングが高いレベルで実行され、ビットマップへの参照が低レイヤに渡される可能性がある。
【００３４】
本発明の一態様に基づいて、Visualアプリケーションプログラミングインターフェース（ＡＰＩ）は、本発明の一態様に基づく映像ツリーを定義するオブジェクトの集合を提供する。映像ツリーは、グラフィックスシステムによって媒体（画面、プリンターまたは表面）にレンダリングされることが可能なデータ構造を表す。レンダリングされた場合、映像ツリー内のデータは、視覚化された「シーン」である。映像オブジェクト（または単にVisual）は、幾何学形状、プリミティブ、ブラシ、色勾配、およびアニメーションのような描画シーンを作り上げる他のグラフィカルオブジェクトを含み、および管理する。
【００３５】
本発明は、よりよく知られたオブジェクトおよびプロパティシステムを使用する高いレベルの抽出において、描画およびレンダリングサービスへのアクセスも提供するが、マークアップ言語（「ＸＡＭＬ」）によってマークアップレベルにおけるベクトルグラフィックオブジェクトを提供する。VisualＡＰＩは、プロパティシステムまたはマークアップを使用して容易に実現することができる描画機能性をより巧みに制御したい開発者にとって最も興味深いものになる。
【００３６】
図３および４はそれぞれ、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での楕円の描画を実演する。
【００４１】
【表１】
2007509420.tif 000003
【００４２】
代わりに開発者は、映像ＡＰＩを使用してVisualに直接描画することができる（そうでなければLayout要素を介してアクセスされることになる）。
【００４３】
DrawingVisualオブジェクトのコンテンツをレンダリングするために、通常、アプリケーションはDrawingVisualでRenderOpenメソッドを呼び出す。RenderOpenはDrawingContextを戻し、アプリケーションはこれを使用して描画オペレーションを実行することができる。Visualのコンテンツを消去する場合、アプリケーションはDrawingContextでCloseを呼び出す。アプリケーションがCloseを呼び出すと、その後DrawingContextは使用できなくなる。
【００４４】
以下のコードは、楕円形状ではなくGeometryオブジェクトを使用して、DrawingVisualに楕円（前の例と同じ楕円）を描画するものである。この例では、DrawingVisualを作成し、DrawingVisualのDrawingContextを取得し、DrawingContextのDrawGeometryメソッドを呼び出して楕円を描画する。開発者は、この場合はウィンドウであるトップレベルオブジェクトの映像ツリーに、Visualを追加する必要があることに留意されたい。
【００４５】
【表２】
2007509420.tif 000004
【００４６】
以下の例は、同様の楕円をContainerVisualに追加することによって、前の例にさらに構築するものであり、この例はわかりやすくするために冗長であることに留意されたい。ContainerVisualを使用すると、シーンオブジェクトを編成する際に役立ち、開発者がヒットテストまたは妥当性検査（RetainedVisualオブジェクト）を実行するために、Visualオブジェクトを通常の描画コンテンツから分離し、コンテンツの不必要な再描画を最小限に抑えることができる。
【００４７】
【表３−１】
2007509420.tif 000005
【００４８】
【表３−２】
2007509420.tif 000006
【００４９】
【表３−３】
2007509420.tif 000007
【００５０】
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を実施し、それに描画するクラスをインスタンス化するものである。
【００５４】
【表４】
2007509420.tif 000008
【００５５】
映像ＡＰＩは、本発明のグラフィックスシステムの残りの部分と同様に管理されたＡＰＩであり、強力なタイピングおよびガーベッジ集合を含む管理されたコードの典型的な機能を使用する。また、レンダリングのためのハードウェア加速機能も利用する。既存の管理されていないアプリケーションを使用して作業を行う開発者に対処するために、映像ＡＰＩは、本グラフィックスシステムとＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）のＧｒａｐｈｉｃｓ  Ｄｅｖｉｃｅ  Ｉｎｔｅｒｆａｃｅ（ＧＤＩ）ベースのレンダリングサービスとの間に限られた相互運用性を提供する。
【００５６】
この相互運用性により、開発者は、本発明の描画およびレンダリングに基づいたHwnd Visualオブジェクト、書込み制御、およびテーマ化を使用して、映像認識アプリケーションでＧＤＩベースのウィンドウをホストするが、依然として古いＧＤＩアプリケーションで動作し、ハードウェア加速およびカラーモデルを含む新しいレンダリング機能を利用するようにＧＤＩ  ＨＷＮＤベースのアプリケーションを修正することができる。
【００５７】
HwndVisualは、Ｗｉｎ３２コンテンツを映像認識アプリケーションでホストできるようにするものである。図５に示されるように、HwndVisualはContainerVisualを継承する。ＧＤＩと新しい描画モデルとを同じHwndVisualで混合できないことに留意されたい。代わりに、この映像は、制限された範囲の古いコントロールにはより役立つ可能性がある。以下の例では、HwndVisualでコントロールを作成することおよびそれを映像ツリーに追加することを実演する。
【００５８】
【表５】
2007509420.tif 000009
【００５９】
他のオブジェクトの場合と同様に、開発者は、Visualでいったんホストされると変形および他のプロパティの変更をコントロールに適用することが可能である。
【００６０】
【表６】
2007509420.tif 000010
【００６１】
図３に示されるように、トップレベル（またはルート）の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呼出しによってプッシュされた変形をポップする。
【００７２】
【表７】
2007509420.tif 000011
【００７３】
同様に、PushOpacityメソッドは、不透明度値をプッシュする。後続の描画オペレーションは、指定された不透明度値を使用して一時表面上でレンダリングされ、シーンに合成される。Pop( )は、以下のように、合致するPushOpacity呼出しによってプッシュされた不透明度をポップする。
【００７４】
【表８】
2007509420.tif 000012
【００７５】
PushClipメソッドは、クリッピングジオメトリをプッシュする。後続の描画オペレーションはジオメトリにクリップされる。クリッピングは、変形後空間に適用される。Pop( )は、以下のように、合致するPushClip呼出しによってプッシュされたクリッピング領域をポップする。
【００７６】
【表９】
2007509420.tif 000013
【００７７】
プッシュオペレーションは、ポップオペレーションがプッシュと合致する限り、任意に入れ子にできることに留意されたい。例えば、以下は有効である。
【００７８】
【表１０】
2007509420.tif 000014
【００７９】
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オブジェクトの例を示す。
【００８７】
【表１１】
2007509420.tif 000015
【００８８】
GradientBrushオブジェクトまたは単にGradientは勾配塗りつぶしを行い、何らかの進行に沿って色を指定する勾配停止の集合を指定することによって描画されるものである。Gradientは、ガンマ２．２ＲＧＢ色空間で勾配停止間の線形補間を実行することによって描画されるが、代わりに他のガンマまたは他の色空間（ＨＳＢ、ＣＭＹＫなど）を介した補間を実行することもできる。この２つの型のGradientオブジェクトには、線形勾配および放射勾配が含まれる。
【００８９】
一般に、Gradientは勾配停止のリストからなる。これらの勾配停止は、それぞれ色（アルファ値が含まれる）およびオフセットを含む。指定された勾配停止がない場合、ブラシは、あたかもブラシがまったく指定されていないかのように濃淡のない透明な黒として描画される。勾配停止が１つだけ指定された場合、ブラシは１色だけ指定されたソリッドカラーとして描画される。「Ｃｈａｎｇｅａｂｌｅ  Ｃｌａｓｓ  ａｎｄ  Ｐａｔｔｅｒｎ  ｔｏ  Ｐｒｏｖｉｄｅ  Ｓｅｌｅｃｔｉｖｅ  Ｍｕｔａｂｉｌｉｔｙ  ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｅｎｖｉｒｏｎｍｅｎｔｓ」という名称の米国特許出願に記載されているように、勾配停止クラス（下記の表の例）は他のリソースクラスと同様に変更可能クラスから導出されるため、選択的に可変である。
【００９０】
Gradientは勾配停止の集合を指定することによって描画される。これらの勾配停止は、何らかの連続した色を指定する。現在サポートされている勾配には２つの型、すなわち線形勾配および放射勾配がある。Gradientは、指定された色空間内の勾配停止間で補間を実行することによって描画される。
【００９１】
Gradientは、勾配停止のリストからなる。これらの勾配停止はそれぞれ、色（アルファ値が含まれる）およびオフセットを含む。指定された勾配停止がない場合、ブラシは（あたかもブラシがまったく指定されていないかのように）透明として描画される。勾配停止が１つだけ指定された場合、ブラシは１色だけ指定されたソリッドカラーとして描画される。０から１の範囲内（０．０．．．１．０）のオフセットを備えた任意の勾配停止が考慮の対象とされ、最大の停止は（−∞．．．０．０］、最小の停止は［１．０．．．＋∞）である。考慮の対象とされる停止の集合に０から１の範囲外にある停止が含まれる場合、暗黙の停止として０（および／または１）が導出され、これがこの停止で発生することになる補間された色を表す。さらに、２つまたはそれ以上の停止が同じオフセットで設定される場合、そのオフセットで（補間済みでない）ハード遷移が発生する。停止が追加される順序によって、このオフセットでの挙動が決められ、追加される最初の停止はそのオフセットの前の有効な色であり、設定される最後の停止はこの停止の後の有効な色であり、このオフセットでのいずれの追加の停止も無視される。
【００９２】
このクラスは、他のリソースクラスと同様にChangeableである。
【００９３】
【表１２】
2007509420.tif 000016
【００９４】
SolidColorBrushと同様に、これはChangeablesをアニメーション集合内に入れ子にする。
【００９５】
GradientSpreadMethod 列挙法は、指定されたベクトルまたは空間の外で勾配がどのように描画されるべきかを指定する。可能な値には、末端（最初および最後）の色を使用して残りの空間が塗りつぶされるPadと、停止を逆の順序で繰り返し再生して空間が塗りつぶされるReflectと、停止を順番に繰り返して空間が塗りつぶされるRepeatの、３つの値が含まれる。この型のプロパティのデフォルト値はPadである。
【００９６】
【表１３】
2007509420.tif 000017
【００９７】
図１４および１５は、いくつかのGradientSpreadMethodの例（たとえ色でなくグレースケールの場合であっても）を提供する。各形状が、白からグレーに移行する線形勾配を有する。実線が勾配ベクトルを表す。
【００９８】
一般に、LinearGradientBrushを使用して領域を線形勾配で塗りつぶす。線形勾配とは、線分に沿って勾配を定義するものである。線形勾配のStartPointおよびEndPointプロパティによって、線分の末端が定義される。デフォルト時には、線形勾配のStartPointは（０，０）であって領域の左上コーナが塗りつぶされ、そのEndPointは（１，１）であって領域の右下コーナが塗りつぶされる。図１５に示されるように、デフォルトの値を使用すると、結果として生じる勾配の色は斜めの軌跡に沿って補間される。本明細書では、勾配の補間軌跡をハイライト表示するために、勾配の始点および終点から形成された黒い線分が追加されている。
【００９９】
ColorInterpolationMode列挙法は、勾配内の色に対して補間モードを定義する。PhysicallyLinearGamma10およびPerceptuallyLinearGamma22の２つのオプションがある。
【０１００】
【表１４】
2007509420.tif 000018
【０１０１】
これは抽象基本クラスである。
【０１０２】
【表１５】
2007509420.tif 000019
【０１０３】
Changeablesの項で説明したように、GradientBrushはそのGradientStopsプロパティそれ自体がChangeablesを保持するので、Changeablesに関して複合型である。これは、GradientBrushが、保護されたメソッドMakeUnchangeableCore( )とPropagateEventHandler( )、ならびにChangeableサブクラスが実施するCloneCore( )とを実施する必要があることを意味する。例えば集合を構成するGradientStopsの無効な組合せがある場合、ValidateObjectState( )を実施するように選択することもできる。
【０１０４】
LinearGradientは、ベクトルに沿って線形勾配ブラシを指定する。個々の停止は、そのベクトルに沿ってカラーストップを指定する。
【０１０５】
【表１６−１】
2007509420.tif 000020
【０１０６】
【表１６−２】
2007509420.tif 000021
【０１０７】
LinearGradient用のマークアップは、０および１のオフセットで２つのカラーストップを使用してLinearGradientを指定することが可能である。「LinearGradient」バージョンが使用される場合、それぞれ始点および終点が指定される。「HorizontalGradient」が使用される場合、始点は０，０に設定され、終点は１，０に設定される。「VerticalGradient」が使用される場合、始点は０，０に設定され、終点は０，１に設定される。これらの場合、RelativeToBoundingBoxというデフォルトのMappingModeが使用される。
【０１０８】
RadialGradientは、プログラミングモデルでは線形勾配と同様である。しかし、線形勾配は勾配ベクトルを定義するための始点および終点を有するのに対して、放射勾配は勾配の挙動を定義するための円ならびに焦点を有する。円は勾配の終点を定義しており、言い換えれば、１．０の勾配停止は円の周囲の色を定義する。焦点は勾配の中心を定義する。０．０の勾配停止は焦点の色を定義する。図１６は、白からグレーへと（グレースケールで）進むRadialGradientを表す。外側の円は勾配円を表し、中実のドットは焦点を示す。この勾配は、SpreadMethodがPadに設定されている。
【０１０９】
【表１７−１】
2007509420.tif 000022
【０１１０】
【表１７−２】
2007509420.tif 000023
【０１１１】
RadialGradient用のマークアップは、それぞれ０および１のオフセットで２つのカラーストップを使用してRadialGradientを指定することが可能である。デフォルトの半径が０．５である場合、RelativeToBoundingBoxというデフォルトのMappingModeが使用される。
【０１１２】
【表１８】
2007509420.tif 000024
【０１１３】
TileBrushは、タイルを記述する論理とタイルが領域を塗りつぶす際に使用する手段とを含む抽象基本クラスである。TileBrushのサブクラスはコンテンツを含み、無限の平面を塗りつぶす方法を論理的に定義する。
【０１１４】
Stretch列挙法を使用して、ViewBox（ソース座標空間）をViewPort（宛先座標空間）にマッピングする方法を記述する。これはTileBrushで使用される。
【０１１５】
【表１９】
2007509420.tif 000025
【０１１６】
図１８に、引伸ばし（ｓｔｒｅｔｃｈ）の例を示す。これらの例では、コンテンツは左／上に位置合わせをされる。
【０１１７】
TileMode列挙法を使用して、Tileで空間を塗りつぶすのか、およびどの様に塗りつぶすのかを記述する。TileBrushは、基本Tileが（ViewPortによって指定される）場所を定義する。残りの空間はTileMode値に基づいて塗りつぶされる。
【０１１８】
【表２０】
2007509420.tif 000026
【０１１９】
図１９は、TileModeの例を提供する。各例の一番左上のタイルが基本タイルである。これらの例は、None、Tile、FlipX、FlipY、およびFlipXYを表す。
【０１２０】
VerticalAlignment列挙法を使用して、コンテナ内でコンテンツを垂直に配置する方法を記述する。
【０１２１】
【表２１】
2007509420.tif 000027
【０１２２】
HorizontalAlignment列挙法を使用して、コンテナ内でコンテンツを水平に配置する方法を記述する。
【０１２３】
【表２２】
2007509420.tif 000028
【０１２４】
TileBrushプロパティは、タイル（ViewBox）となる無限の平面の矩形部分を選択し、塗りつぶされる領域内の基本タイルとなる宛先矩形（ViewPort）を記述する。残っている宛先領域は、TileModeプロパティに基づいて塗りつぶされることになり、これが残っている空間を塗りつぶすためにオリジナルタイルが複製されるのか、およびどの様に複製されるのかを制御する。
【０１２５】
【表２３−１】
2007509420.tif 000029
【０１２６】
【表２３−２】
2007509420.tif 000030
【０１２７】
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を使用して複雑なパターンを作成でき、またはこれを使用してシーンの他の部分のコンテンツの追加のコピーを描画することができる。
【０１３４】
【表２４】
2007509420.tif 000031
【０１３５】
ImageBrushは、ImageDataによって指定されたコンテンツを有するTileBrushである。このBrushを使用して空間をImageで塗りつぶすことができる。
【０１３６】
【表２５】
2007509420.tif 000032
【０１３７】
VideoBrushは、VideoDataによって指定されたコンテンツを有するTileBrushである。このBrushを使用して空間をVideoで塗りつぶすことができる。
【０１３８】
【表２６】
2007509420.tif 000033
【０１３９】
NineGridBrushは、オブジェクトの境界ボックスを常にそのコンテンツ画像で塗りつぶすブラシであり、画像の引伸ばしは映像スケールを介してのみ実施されるものではない。Imageソースは４本の境界によって９つの矩形に分けられる（したがってNineGridと名付けられる）。これら９つの領域のそれぞれに存在する画像のコンテンツは、オブジェクト境界ボックスを塗りつぶすまで０、１、または２の寸法で縮尺される。各セクションが縮尺される寸法を図で見ることが可能であって、図１７はNineGridの概念を表すものであり、第１のインスタンス１７０２から第２のインスタンス１７０４に拡大され、Top、Left、Bottom、およびRightの境界によって定義される９つのグリッドを示す４つの型がある。各グリッドスクエア内の矢印は、それらのコンテンツがViewPortサイズに合致するように引伸ばされる寸法を示している。
【０１４０】
上記の９つのグリッド領域に加えて、オプションの「１０番目」のグリッドがある。これは、ViewPortの中心に位置する縮尺されない追加の画像の形を取る。これを使用して、ボタンなどの中心に形状を配置することができる。この「１０番目のグリッド」はグリフと呼ばれ、GlyphImageDataプロパティによって公開される。
【０１４１】
【表２７−１】
2007509420.tif 000034
【０１４２】
【表２７−２】
2007509420.tif 000035
【０１４３】
境界のメンバは、画像の枠から画像ピクセル単位でカウントに入れることに留意されたい。
【０１４４】
Penは、空間／Geometryをストロークで描く方法を記述したBrushおよび他のパラメータを取るオブジェクトである。概念上、PenはGeometryからストローク領域を作成する方法を記述する。Geometryの枠、PenのThickness、PenLineJoin、PenLineCap、などに基づいて新しい領域が作成される。いったんこの領域が作成されると、Brushで塗りつぶされる。
【０１４５】
【表２８−１】
2007509420.tif 000036
【０１４６】
【表２８−２】
2007509420.tif 000037
【０１４７】
PenLineCapは、ストローク線分の端部を描画する方法を決定する。
【０１４８】
【表２９】
2007509420.tif 000038
【０１４９】
PenDashCapは、破線状のストローク線分における各ダッシュの端部を描画する方法を決定する。
【０１５０】
【表３０】
2007509420.tif 000039
【０１５１】
PenLineJoinは、線分をストロークで描く際にジョイントを描画する方法を決定する。
【０１５２】
【表３１】
2007509420.tif 000040
【０１５３】
DashArraysクラスは、一般的なよく知られた破線スタイルにアクセスする静的プロパティを備える。
【０１５４】
【表３２】
2007509420.tif 000041
【０１５５】
図１３に示された他のBrushオブジェクトがVisualBrushオブジェクトである。VisualBrushとは、Visualによってコンテンツが指定されるTileBrushである。このBrushを使用して複雑なパターンを作成するか、またはこれを使用してシーンの他の部分のコンテンツの追加コピーを描画することができる。
【０１５６】
【表３３】
2007509420.tif 000042
【０１５７】
概念上、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プロパティをアニメーション処理することができる。
【０１６９】
２Ｄ計算用の行列が３×３行列として表される。変形が必要な場合、３×３行列すべてではなく６つの値のみが必要とされる。これらは以下のように命名され、および定義される。
【０１７０】
【表３４】
2007509420.tif 000043
【０１７１】
行列とポイントを掛け合わせると、そのポイントが新しい座標系から前の座標系に変形される。
【０１７２】
【表３５】
2007509420.tif 000044
【０１７３】
変形は何重にも入れ子にすることができる。新しい変形が適用される場合は必ず、現在の変形行列に後から掛け合わせたものと同じになる。
【０１７４】
【表３６】
2007509420.tif 000045
【０１７５】
ＡＰＩ内のほとんどの場所は直接行列を取らないが、代わりにアニメーションをサポートするTransformクラスを使用する。
【０１７６】
【表３７−１】
2007509420.tif 000046
【０１７７】
【表３７−２】
2007509420.tif 000047
【０１７８】
【表３７−３】
2007509420.tif 000048
【０１７９】
（結論）
前記の詳細な説明からわかるように、シーングラフとのインターフェース機能を持つプログラムコードを実装するシステム、方法、およびオブジェクトモデルが実現される。このシステム、方法、およびオブジェクトモデルは使いやすいうえに、強力で柔軟性および拡張性に優れる。
【０１８０】
本発明はさまざまな修正を加えることができ、また他の構成も可能であるが、いくつかの例示されている実施形態は、図面に示されており、上で詳細に説明済みである。しかし、本発明を開示されている特定の形態に制限する意図はなく、むしろその反対に、本発明が本発明の趣旨と範囲にあるすべての修正形態、代替の構成、および等価物を対象とすることは、理解されるであろう。
【図面の簡単な説明】
【０１８１】
【図１】本発明を組み込むことができるコンピュータシステムの実施例を表すブロック図である。
【図２】本発明を組み込むことができるグラフィックスレイヤアーキテクチャを一般的に表すブロック図である。
【図３】本発明の一態様により映像のシーングラフと、シーングラフをトラバースしてグラフィックスコマンドおよびその他のデータを供給することによりシーングラフを処理するための関連するコンポーネントとの表現である。
【図４】本発明の一態様により構成されるバリデーション映像、描画映像、および関連する命令リストのシーングラフの表現である。
【図５】本発明の一態様による、オブジェクトモデルの、映像クラスの表現である。
【図６】本発明の一態様による、オブジェクトモデルの他のさまざまなオブジェクトの表現である。
【図７】本発明の一態様による、変換クラス階層の表現である。
【図８】本発明の一態様による、幾何学的縮尺比および不均等縮尺比による映像のデータの変換の表現である。
【図９】本発明の一態様による、幾何学的縮尺比および不均等縮尺比による映像のデータの変換の表現である。
【図１０】本発明の一態様による、オブジェクトモデルの幾何学形状クラスの表現である。
【図１１】本発明の一態様による、ＰａｔｈＧｅｏｍｅｔｒｙ構造の表現である。
【図１２】本発明の一態様による、プリミティブにより出力されるグラフィック例を示す映像のシーングラフおよび命令リストの表現である。
【図１３】本発明の一態様による、オブジェクトモデルのブラシクラスの表現である。
【図１４】本発明の一態様による、線形勾配ブラシオブジェクト内のデータから得られるレンダリングされたグラフィックスの表現である。
【図１５】本発明の一態様による、線形勾配ブラシオブジェクト内のデータから得られるレンダリングされたグラフィックスの表現である。
【図１６】本発明の一態様による、放射状勾配ブラシオブジェクト内のデータから得られるレンダリングされたグラフィックスの表現である。
【図１７】本発明の一態様によるレンダリングされた９グリッドブラシオブジェクトの表現である。
【図１８】本発明の一態様による、さまざまな伸長度値（ｓｔｒｅｔｃｈ  ｖａｌｕｅｓ）を設定することで得られるレンダリングされたグラフィックスの表現である。
【図１９】本発明の一態様による、さまざまなタイル値（ｔｉｌｅ  ｖａｌｕｅｓ）を設定することで得られるレンダリングされたグラフィックスの表現である。
【図２０】本発明の一態様による、映像ブラシオブジェクト内のデータから得られる、グリッドおよび変換されたグリッドの表現である。
【図２１】本発明の一態様による、グリッドおよび変換されたグリッドの表現であって、そのグリッド内のレンダリングされたグラフィックスが映像から描画されることを示す図である。
【図１】
2007509420.tif 000049
【図２】
2007509420.tif 000050
【図３】
2007509420.tif 000051
【図４】
2007509420.tif 000052
【図５】
2007509420.tif 000053
【図６】
2007509420.tif 000054
【図７】
2007509420.tif 000055
【図８】
2007509420.tif 000056
【図９】
2007509420.tif 000057
【図１０】
2007509420.tif 000058
【図１１】
2007509420.tif 000059
【図１２】
2007509420.tif 000060
【図１３】
2007509420.tif 000061
【図１４】
2007509420.tif 000062
【図１５】
2007509420.tif 000063
【図１６】
2007509420.tif 000064
【図１７】
2007509420.tif 000065
【図１８】
2007509420.tif 000066
【図１９】
2007509420.tif 000067
【図２０】
2007509420.tif 000068
【図２１】
2007509420.tif 000069
【国際調査報告】
2007509420.tif 000070