(57)【要約】  アプリケーションプログラミングインターフェース（ＡＰＩ）およびオブジェクトモデルを含む媒体統合レイヤを用いると、プログラムコード開発者が、グラフィックスを出力するために、一貫性のある形でシーングラフデータ構造とインターフェースできるようになる。このインターフェースを介して、プログラムコードは、子ビジュアルを他のビジュアルに追加して、階層的シーングラフを構築し、形状データ、画像データ、アニメーションデータ、および他の出力用のデータなどの命令リストを書き込み、ビジュアルに対する変換プロパティ、クリッピングプロパティ、および不透明度プロパティを指定することができる。媒体統合レイヤおよびＡＰＩは、プログラマが、簡単な形式においてアプリケーション内で合成効果を達成すると同時に、普通のアプリケーション実行に悪影響を及ぼさない形式においてグラフィックス処理装置を活用することを可能にする。複数レベルシステムに、異なる媒体型（２Ｄ、３Ｄ、ビデオ、音声、テキスト、および画像ングなど）を組み合わせ、それらを滑らかに継ぎ目なくアニメーションにする能力が含まれる。
2007509426.tif 000002
【特許請求の範囲】
【請求項１】
媒体統合レイヤのインターフェースを介して、グラフィックス関連データに対応する関数呼出しを受け取るステップと、
前記関数呼出しに基づいて、シーングラフデータ構造内のデータを変更させるステップと
を備えたことを特徴とする出力への処理のためにコンピュータグラフィックスデータを配置する方法。
【請求項２】
前記シーングラフデータ構造内のデータを変更させるステップは、ビジュアルクラスの新しいインスタンスを初期化する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ビジュアルに関連する変換に対応するインターフェースを介して、関数呼び出しを受け取るステップをさらに備えたことを特徴とする請求項２に記載の方法。
【請求項４】
前記シーングラフデータ構造内のデータを変更させるステップは、描画ビジュアルクラスの新しいインスタンスを初期化する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
インターフェースを介して関数呼び出しを受け取り、レンダリングのために描画ビジュアルインスタンスをオープンするステップと、それに応答して、前記描画ビジュアルへのレンダリングの機構を提供する描画コンテキストを返させるステップとをさらに備えたことを特徴とする請求項４に記載の方法。
【請求項６】
前記関数呼出しに関連するブラシデータを受け取るステップをさらに備え、前記シーングラフデータ構造内のデータを変更させるステップは、フレームが前記シーングラフからレンダリングされる時、領域が前記ブラシデータに対応する可視データを用いて塗り潰されるように、ブラシ関数を呼び出して、前記シーングラフデータ構造内のデータ構造を変更するステップを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記ブラシデータを受け取るステップは、単色に対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記ブラシデータを受け取るステップは、リニア勾配ブラシおよび少なくとも１つのストップを含むストップ集合に対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項９】
前記ブラシデータを受け取るステップは、ラジアル勾配ブラシに対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項１０】
前記ブラシデータを受け取るステップは、画像に対応するデータを受け取るステップを含むことを特徴とする請求項６に記載の方法。
【請求項１１】
画像効果に対応するインターフェースを介する関数呼び出しを受け取り、前記画像を適用するステップをさらに備えたことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記関数呼出しに関連するペンデータを受け取るステップをさらに備え、前記シーングラフデータ構造内のデータを変更させるステップは、形状の輪郭を定義するペン関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造内の楕円を表す形状関連関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造内の長方形を表す形状関連関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１５】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造内のパスを表す形状関連関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１６】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造内の線を表す形状関連関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１７】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造内のビジュアルのヒットテストに関連する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１８】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造内のビジュアルの座標変換に関連する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１９】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造内のビジュアルの境界ボックスの計算に関連する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２０】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造内のビジュアルオブジェクトへの共通インターフェースを介して関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２１】
ビジュアルマネージャを呼び出し、レンダリング対象に少なくとも１つのビジュアルオブジェクトのツリーをレンダリングするステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項２２】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造に、少なくとも１つのビジュアルオブジェクトを含むように構成されたコンテナオブジェクトを配置する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２３】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造に画像データを配置する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２４】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造に前記画像データに関連する画像効果ブジェクトを配置する関数を呼び出すステップを含むことを特徴とする請求項２３に記載の方法。
【請求項２５】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造に、テキストに対応するデータを配置する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２６】
前記シーングラフデータ構造内のデータを変更させるステップは、前記関数呼出しに応答して描画コンテキストを提供する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２７】
前記関数呼び出しは、保持されたされたビジュアルに対応し、およびコールバックして、前記保持されたビジュアルの描画コンテキストを前記シーングラフデータ構造に返させるステップをさらに備えたことを特徴とする請求項２６に記載の方法。
【請求項２８】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造に３次元ビジュアルを配置する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項２９】
前記シーングラフデータ構造内のデータを変更させるステップは、２次元サーフェスを３次元ビジュアルにマッピングするステップを含むことを特徴とする請求項２８に記載の方法。
【請求項３０】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造内にアニメーションデータを配置する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項３１】
前記アニメーションデータに対応するタイムライン情報を、前記媒体統合レイヤの別のレイヤにある合成エンジンに通信するステップをさらに備えたことを特徴とする請求項３０に記載の方法。
【請求項３２】
前記合成エンジンは、前記タイムラインに基づいてグラフィックスデータを補間し、前記シーングラフデータ構造内のオブジェクトに対応する出力をアニメーションにするステップを特徴とする請求項３１に記載の方法。
【請求項３３】
前記媒体統合レイヤのインターフェースを介して関数呼び出しを受け取るステップは、マークアップ要素を受け取るステップを含み、前記シーングラフデータ構造内のデータを変更させるステップは、オブジェクトのインターフェースへの呼出し内の前記マークアップ要素を解析するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３４】
前記シーングラフデータ構造内のデータを変更させるステップは、音声および／またはビデオデータに対応するオブジェクトを前記シーングラフデータ構造内に配置する関数を呼び出すステップを含むことを特徴とする請求項１に記載の方法。
【請求項３５】
前記シーングラフデータ構造内のデータを変更させるステップは、前記シーングラフデータ構造内のオブジェクトのミュータブル値を変更するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３６】
コンピューティング環境において、
可視の次の統合された出力用の出力にレンダリングできるデータを含むレイヤードシステムのシーングラフデータ構造と、
前記シーングラフデータ構造に含まれることができるオブジェクトおよび他のデータを含むオブジェクトモデルであって、前記オブジェクトモデルのオブジェクトの少なくとも一部が、前記シーングラフデータ構造の内容を変更する関数を呼び出すインターフェースを有するオブジェクトモデルと
を備えたことを特徴とするシステム。
【請求項３７】
少なくとも１つの前記関数は、ビジュアルオブジェクトのツリーを前記シーングラフデータ構造に置くために呼び出されることを特徴とする請求項２６に記載のシステム。
【請求項３８】
呼び出されたとき、レンダリング対象に前記ビジュアルオブジェクトのツリーをレンダリングするビジュアルマネージャをさらに備えたことを特徴とする請求項３７に記載のシステム。
【請求項３９】
前記ビジュアルオブジェクトのツリーは、ビジュアル集合オブジェクトに含まれることを特徴とする請求項３７に記載のシステム。
【請求項４０】
少なくとも１つの前記関数は、前記シーングラフデータ構造にビジュアルオブジェクトを置くために呼び出されることを特徴とする請求項２６に記載のシステム。
【請求項４１】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトにブラシを関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項４２】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに形状を関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項４３】
前記形状は、楕円形状、長方形形状、線形状、およびパス形状を含む集合の少なくとも１つを含むことを特徴とする請求項４２に記載のシステム。
【請求項４４】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに変換を関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項４５】
前記変換は、前記ビジュアルオブジェクトの知覚される角度を変更する回転変換を含むことを特徴とする請求項４４に記載のシステム。
【請求項４６】
前記変換は、前記ビジュアルオブジェクトの知覚されるサイズを変更するスケール変換を含むことを特徴とする請求項４４に記載のシステム。
【請求項４７】
前記変換は、前記ビジュアルオブジェクトの知覚される位置を変更する並進変換を含むことを特徴とする請求項４４に記載のシステム。
【請求項４８】
前記変換は、前記ビジュアルオブジェクトの知覚される傾斜を変更する傾斜変換を含むことを特徴とする請求項４４に記載のシステム。
【請求項４９】
前記変換に関連するアニメーション情報をさらに備え、前記アニメーション情報は、前記変換に関連する変換データを経時的に変化させ、これによって、前記ビジュアルオブジェクトの前記変換を経時的にアニメーションにすることを特徴とする請求項４４に記載のシステム。
【請求項５０】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトにカラーを関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項５１】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに勾配データを関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項５２】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトにタイルブラシを関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項５３】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに画像を関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項５４】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに３次元データを関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項５５】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに描画プリミティブを含む描画を関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項５６】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに音声媒体および／またはビデオ媒体を関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項５７】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに画像効果を関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項５８】
少なくとも１つの前記関数は、形状の輪郭を描く方法を記述するために、前記ビジュアルオブジェクトにペンを関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項５９】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに関連する描画コンテキストを得るために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項６０】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトにヒットテストデータを関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項６１】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに長方形を関連付けるために呼び出されることを特徴とする請求項４０に記載のシステム。
【請求項６２】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに対応する宛先長方形に収まるようにソース長方形を引き延ばす方法を記述するために呼び出されることを特徴とする請求項６１に記載のシステム。
【請求項６３】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに対応するコンテナ内で内容を垂直に位置決めする方法を記述するために呼び出されることを特徴とする請求項６１に記載のシステム。
【請求項６４】
少なくとも１つの前記関数は、前記ビジュアルオブジェクトに対応するコンテナ内で内容を水平に位置決めする方法を記述するために呼び出されることを特徴とする請求項６１に記載のシステム。
【請求項６５】
コンピューティング環境において、
関数呼び出しを受け取るインターフェース手段と、
前記インターフェース手段を介して受け取られるグラフィックス関連データおよび／または媒体関連データをシーングラフに統合する高レベル合成手段と、
前記シーングラフを送出または表示されることができる出力に変換するレンダリング手段と
を備えたことを特徴とするシステム。
【請求項６６】
前記レンダリング手段は、前記高レベル合成エンジンから受け取られるデータに基づく表示のためにフレームを構成する低レベル合成手段を含むことを特徴とする請求項６５に記載のシステム。
【請求項６７】
アニメーション手段をさらに備え、前記高レベル合成エンジンは、少なくとも２つのフレームにまたがる前記可視データの外見を補間するために前記低レベル合成手段にタイムラインデータを供給して、可視データを経時的にアニメーションにすることを特徴とする請求項６５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的にはコンピュータシステムに関し、より詳細には、コンピュータシステム上で表示されるグラフィカル情報および他のビデオ情報の処理に関する。
【背景技術】
【０００２】
１つには、メモリおよびバスの速度がメインプロセッサおよび／またはグラフィックスプロセッサの進歩に追いついていけていないことから、コンピュータシステムでグラフィックスにアクセスする従来の即時モードモデルが限界に達しようとしている。一般に、フレームを用意する現在の（例えばＷＭ＿ＰＡＩＮＴ）モデルは、複雑なグラフィックス効果が望まれるときに、ハードウェアリフレッシュに対応していくために非常に多くのデータ処理を必要とする。その結果、複雑なグラフィックス効果が従来のグラフィックスモデルを用いて試みられるとき、知覚される視覚的効果をもたらす変化を次のフレームに対して適時完了するのではなく、変化が、異なるフレームに亘って追加され、視覚的に顕著に望ましくない結果が引き起こされる場合がある。
【０００３】
グラフィックス出力を制御する新しいモデルが、本発明の譲受人に譲渡された、参照によって本明細書に組み込まれる、特許文献１、２、３、４、５、および６に記載されている。この新しいモデルは、グラフィックス処理テクノロジの複数の重要な改善を提供する。例えば、特許文献１は、全般的に、単純化されたデータ構造および／またはグラフィックスコマンドを下位レベルコンポーネントに渡すために、上位レベルコンポーネント（例えばオペレーティングシステムの）が、場面グラフ構築の計算集中的態様、アニメーションパラメータの更新、および場面グラフのデータ構造のトラバースを、比較的低い動作速度で実行する、複数レベルグラフィックス処理のシステムおよび方法を対象とする。上位レベル処理によって、データが大幅に単純化されるので、下位レベルコンポーネントは、グラフィックスサブシステムのフレームリフレッシュレートに対応するレートなどのより速いレート（上位レベルコンポーネントに対して）で演算して、データを、グラフィックスサブシステム用の一定の出力データに処理することができる。アニメーションが使用されるときに、変更を伴う場面全体を再描画する必要があるのではなく、下位レベル処理は、必要に応じてパラメータ間隔を補間して、レンダリングされるときに各フレームのわずかに変化した場面を提供する瞬間値を得ることができ、スムーズなアニメーションが提供される。
【０００４】
特許文献２には、グラフィックスの描画を求めるプログラムコード（アプリケーションプログラムまたはオペレーティングシステムコンポーネント）が他の態様を無変更のままにしながら場面グラフ記述のある態様を選択的に変更できるようにする、ミュータブル（ｍｕｔａｂｌｅ）（アニメーションにされた）値を提供するパラメータ化された場面グラフおよびパラメータ化されたグラフコンテナが記載されている。プログラムコードは、おそらくは異なるパラメータと共に、場面グラフの既に構築された部分を再利用することもできる。よく知られているように、パラメータ化を介して表示されたアイテムの外見を簡単に変更する能力および／または場面グラフの既存部分の再利用は、全体的なグラフィックス処理効率のかなりの向上をもたらす。
【０００５】
特許文献３には、全般的に、場面グラフ内のオブジェクトおよびデータを介してビジュアル情報を保管する、キャッシングデータ構造および関連する機構が記載されている。このデータ構造は、全般的に、それに含まれるビジュアル情報を取り込み、使用する形を知的に制御する機構に関連する。例えば、アプリケーションプログラムによって特に要求されない限り、このデータ構造に保管される情報のほとんどは、その情報への外部参照がなく、これによって、この情報を最適化するか、他の形で処理することが可能になる。よく知られているように、これによって、効率性およびリソースの節約がもたらされ、例えば、キャッシュデータ構造内のデータを異なるフォーマットに処理して、最もコンパクトな形にし、かつ／またはビットマップまたは他の後処理結果などの後続の繰り返される処理の必要性を減らすことができる。
【０００６】
【特許文献１】米国特許仮出願第１０／１８４７９５号
【特許文献２】米国特許仮出願第１０／１８４７９６号
【特許文献３】米国特許仮出願第１０／１８５７７５号
【特許文献４】米国特許仮出願第１０／４０１７１７号
【特許文献５】米国特許仮出願第１０／４０２３２２号
【特許文献６】米国特許仮出願第１０／４０２２６８号
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記の改良は、グラフィックス処理テクノロジでの多大な利益をもたらすが、プログラムが、この改善されたグラフィックスモデルおよび他の関連する改善を直接の形で効率的に使用する形であることが必要である。必要なものは、プログラムが、改善されたグラフィックスモデルによって提供される多数の特徴およびグラフィックス処理機能を利用し、これによって、複雑なグラフィックスデータおよび音声ビジュアルデータを効率的な形で出力するための、包括的だが単純なモデルである。
【課題を解決するための手段】
【０００８】
簡単に言えば、本発明は、プログラマが、普通のアプリケーション性能に悪影響を及ぼさない形でグラフィックス処理ユニットを活用しながら、単純な形でアプリケーション内で可能な複雑な合成効果を達成するＡＰＩを提供する媒体統合レイヤ（ｍｅｄｉａ  ｉｎｔｅｇｒａｔｉｏｎ  ｌａｙｅｒ、ＭＩＬ）を提供することである。１つの態様が、異なる媒体種（例えば、２Ｄ、３Ｄ、ビデオ、音声、テキスト、画像ングなど）を組み合わせ、これらを一緒に滑らか、かつ継ぎ目なくアニメーションにする能力を提供する。
【０００９】
ＭＩＬは、マルチステージ合成のグラフィックスアーキテクチャと、プログラマチックなおよびスクリプト化されたインターフェースでの機能的パリティを可能にするプログラミングモデルを提供する。ＡＰＩおよびスクリプトによって、レンダリングされるときに合成されるが、より即時モードの性質を有する領域を含む、保持される構造または場面の記述を作成できるようになる。
【００１０】
インターフェースを介して、ＭＩＬは、ビジュアル情報を保管するデータ構造へのアクセスを提供し、その結果、アプリケーションが、コンピュータハードウェアによって提供されるグラフィックス機能を利用できるようになる。インターフェースは、要素オブジェクトモデルと、プログラムコード開発者がグラフィックスを作るために場面グラフデータ構造と一貫してインターフェースすることを可能にする形で、その要素オブジェクトモデルを使用するベクトルグラフィックスマークアップ言語とをサポートする。データ構造は、ビジュアル情報を直接にレンダリングするか「コンパイル」するのにも使用することができ、その結果、このデータ構造を、高速の合成およびアニメーションのために下位レベルグラフィックスシステムに供給できるようになる。
【００１１】
ベクトルグラフィックス要素オブジェクトモデルは、一般に、場面グラフの場面グラフオブジェクトモデルに相関する画像要素およびビデオ要素を含む、形状要素および他の要素に対応する。マークアップ要素を、場面グラフデータ構造のオブジェクトに変換される要素ツリー内の要素を含むデータに解析することができる。他のマークアップ要素を、場面グラフオブジェクトを作成するデータおよび呼出しに直接に変換することができる。マークアップ言語は、単純なストリングフォーマットまたは複合プロパティ構文を含む要素を記述する別個の形を提供し、この要素に名前を付けることができ、マークアップ要素内の他の位置での再利用が可能になる。
【００１２】
ＭＩＬの一態様が、ＡＰＩセットにまたがるアニメーションとタイミングの統合であり、これによって、固有のベースレベルの概念としてのアニメーションが提供される。スムーズなアニメーションを容易にするために、ＭＩＬは、マルチレベルグラフィックス処理のシステムおよび方法（例えばオペレーティングシステムの）を提供する。そのようなマルチレベルグラフィックス処理システムの１つに、２つのコンポーネントすなわち、ティックオンデマンド（ｔｉｃｋ−ｏｎ−ｄｅｍａｎｄ）または低速ティック高レベルコンポーネントと、高速ティック（例えば、グラフィックスハードウェアのフレームリフレッシュレートでの）低レベルコンポーネントが含まれる。一般に、高レベルでより低周波数のコンポーネントは、低レベルコンポーネントに単純化されたデータ構造を渡すために、アニメーションパラメータ更新および場面データ構造トラバースという計算集中型の態様を実行する。低レベルコンポーネントは、グラフィックスサブシステムのフレームリフレッシュレートなどのより高い周波数で動作して、データ構造をグラフィックスサブシステムの一定の出力データに処理する。低レベル処理には、アニメーションのフレームごとの場面をレンダリングする瞬間値を得るのに必要な、すべてのパラメータ間隔の補間が含まれる。
【００１３】
最上位ＭＩＬオブジェクトに、ビジュアルツリーが含まれ、このビジュアルツリーは、描画される主要な内容を含むオブジェクトである。コントロールが、ツリーのビジュアルから直接に導出される。ビジュアルは、装置独立であり、親コンテキスト独立である。レンダ対象は、ビジュアルが描画される装置である。このオブジェクト（例えば画面）は、それ自体のダーティ機構または無効化機構を有することができる。様々なレンダ対象に、ウィンドウ内の画面、Ｐｒｉｎｔｅｒ、Ｍｅｔａｆｉｌｅ、Ｓｕｒｆａｃｅ、ストリーミング媒体ファイル（例えばＤＶＤ）、および、場面のうちで場面の残りと別々に描画される部分である「サブウィンドウ」が含まれる。他の描画関連オブジェクトに、レンダ対象でビジュアルツリーを描画するように構成されるオブジェクトを含むＶｉｓｕａｌＲｅｎｄｅｒｅｒと、レンダ対象でビジュアルツリーを描画すべきときを知っているＤｉｓｐｌａｙ  Ｓｃｈｅｄｕｌｅｒオブジェクトが含まれる。Ｔｉｍｅ  Ｍａｎａｇｅｒは、タイミングノード群のコンテキストオブジェクトであり、それに対してスケジューラがティックを呼び出すオブジェクトである。
【００１４】
Ｖｉｓｕａｌ  ＡＰＩが提供され、これは、本質的に、媒体統合レイヤを介する描画の開始点であり、Ｖｉｓｕａｌ  Ｔｒｅｅを媒体に接続するＶｉｓｕａｌＭａｎａｇｅｒオブジェクトを含む複数の型のオブジェクトを含む。異なる型のＶｉｓｕａｌＭａｎａｇｅｒ（例えば、Ｓｃｒｅｅｎ、Ｐｒｉｎｔｅｒ、およびＳｕｒｆａｃｅ）が、その特定の媒体にＶｉｓｕａｌ  Ｔｒｅｅをレンダリングする責任を負う。ビジュアルは、プログラマが描画する場所であり、ビジュアルツリー内のノードであり、プログラムが描画する場所を提供する。
【００１５】
ＤｒａｗｉｎｇＣｏｎｔｅｘｔ  ＡＰＩは、ＶｉｓｕａｌをＩｍａｇｅＤａｔａに取り込むかレンダリングするビジュアル内容を構成する方法のコンテキストベースプログラミングモデルを提供する。ＤｒａｗｉｎｇＣｏｎｔｅｘｔクラスならびに、ＤｒａｗｉｎｇＣｏｎｔｅｘｔを獲得し、ＲｅｔａｉｎｅｄＶｉｓｕａｌ／ＤｒａｗｉｎｇＶｉｓｕａｌでビジュアル内容を列挙するのに必要なクラスおよびエントリポイントが設けられる。
【００１６】
ミュータビリティ（ｍｕｔａｂｉｌｉｔｙ）を可能にするために、共通のＣｈａｎｇｅａｂｌｅ基底クラスから派生する型の単一の集合が設けられる。ミュータビリティが所望の変化であるすべての型を、Ｃｈａｎｇｅａｂｌｅクラスから派生することができる。例えば、グラフィックスプログラミングで、オブジェクトモデルに、Ｂｒｕｓｈ、Ｐｅｎ、Ｇｅｏｍｅｔｒｙ、ＦｌｏａｔＡｎｉｍａｔｉｏｎ、ＧｒａｄｉｅｎｔＳｔｏｐ、Ｓｅｇｍｅｎｔなどが含まれる。ＩｓＣｈａｎｇｅａｂｌｅプロパティは、変更可能なオブジェクトを、状態を定義するその現在値に応じて変更できるか否かを示す。
【００１７】
ブラシは、平面を塗り潰す方法を表すオブジェクトである。平面を絶対的な形で塗り潰すことができる他に、媒体統合レイヤのブラシは、塗り潰すオブジェクトのサイズに関して平面を塗り潰す方法を適合させることもできる。ブラシの型の例に、ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ、ＶｉｓｕａｌＢｒｕｓｈ（ベクトルグラフィックスリソース／Ｖｉｓｕａｌを参照することができる）、ＤｒａｗｉｎｇＢｒｕｓｈ、ＬｉｎｅａｒＧｒａｄｉｅｎｔ、ＲａｄｉａｌＧｒａｄｉｅｎｔ、ＩｍａｇｅＢｒｕｓｈ、およびＮｉｎｅＧｒｉｄＢｒｕｓｈが含まれる。ある種のブラシオブジェクトは、使用されるときに、座標系にどのように関係するかを知っており、形状の境界ボックスが使用されるときに、それに関係する方法を知っている。このサイズは、ブラシが塗り潰すオブジェクトに基づく。ある型のブラシ（例えばＶｉｓｕａｌＢｒｕｓｈ）は、プログラマ定義のパターンを作成するためにタイリングすることもできる。Ｂｒｕｓｈ基底クラスは、トランスフォーム、全般的な不透明度、およびブレンドのモードを有する。Ｂｒｕｓｈ（ならびにＶｅｃｔｏｒ  ＧｒａｐｈｉｃｓおよびＭＩＬ  ＡＰＩの他のオブジェクトリソース）オブジェクトは、変更可能であり、作成の後に書き込み可能であり、条件付きの使用（ｑｕａｌｉｆｉｅｄ  ｕｓｅ）に使用された後にどのように振る舞うかに関する全般的な変更可能なパターンに従う。
【００１８】
オブジェクトのＧｅｏｍｅｔｒｙクラスは、ＰｅｎおよびＢｒｕｓｈを用いる２Ｄベクトルベースデータのクリッピング、ヒットテスト（ｈｉｔ−ｔｅｓｔｉｎｇ）、およびレンダリングに使用することができる。派生されたＧｅｏｍｅｔｒｙクラスは、より具体的な構築および列挙のセマンティクスを提供する。複数の形状固有Ｇｅｏｍｅｔｒｙ型、ならびにより複雑な形状のＧｅｏｍｅｔｒｙの明示的定義を可能にする一般化されたＰａｔｈＧｅｏｍｅｔｒｙが、設けられる。Ｇｅｏｍｅｔｒｙは、抽象基底クラスである。ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎは、定義された領域で特定のＣｏｍｂｉｎｅＭｏｄｅ演算を使用して組み合わされた複数のＧｅｏｍｅｔｒｙオブジェクトの集合である。このオブジェクトを用いると、ＰａｔｈＧｅｏｍｅｔｒｙ内でのＰａｔｈＦｉｇｕｒｅオブジェクトを厳密に使用することが可能であるより簡単に、Ｇｅｏｍｅｔｒｙオブジェクトの視覚的組合せの構築が可能になる。
【００１９】
ＩｍａｇｅＳｏｕｒｃｅは、画像ングの基本構成要素を含む抽象クラスである。ＩｍａｇｅＳｏｕｒｃｅは、概念的に、特定のサイズおよび解像度におけるピクセルの単一で、一定の集合を表す。例えば、ＩｍａｇｅＳｏｕｒｃｅは、Ｄｅｃｏｄｅｒが提供できる画像ファイルの単一のフレームとすることができ、あるいは、それ自体のあるＩｍａｇｅＳｏｕｒｃｅに演算する変換の結果とすることができる。ＩｍａｇｅＳｏｕｒｃｅは、変更可能であるが、これは、それ自体のプロパティを変更できるからではなく、潜在的にそのサブクラスのプロパティを変更できるからである。
【００２０】
オブジェクトのＴｒａｎｓｆｏｒｍクラスは、ベクトルグラフィックスおよびラスタグラフィックスのスケーリング、回転、並進、および傾斜のために設けられる。派生されたＴｒａｎｓｆｏｒｍクラスは、扱い易い使用法および列挙のセマンティクスを提供する。
【００２１】
Ｅｆｆｅｃｔｓは、レンダリング中心の形で場面のビジュアル内容を変更する手段を提供する。例えば、ＩｍａｇｅＥｆｆｅｃｔｓ（ラスタベースのビットマップ効果）は、場面の一部の画像に基づく完全に合成された表現を演算する。Ｅｆｆｅｃｔｓは、ＩｍａｇｅＥｆｆｅｃｔｓ、ＢｌｅｎｄＭｏｄｅ、およびＶｅｃｔｏｒＥｆｆｅｃｔｓを含む様々な型に分解される。ＩｍａｇｅＥｆｆｅｃｔｓは、サブグラフまたはＥｌｅｍｅｎｔに適用することによってリテインモードの場面で使用することができ、独立型の画像パイプラインで使用することができる。ＢｌｅｎｄＭｏｄｅは、画像に基づく効果の特定の形であり、全般的にＩｍａｇｅＥｆｆｅｃｔｓと同一の形でリテインモードの場面に適用することができる。ブレンドモードは、ソースが合成されるときに、例えば乗算または加算など、ソースカラーと宛先カラーの組合せを実行する。
【００２２】
ヒットテストは、場面のビジュアルを選択するのに使用され、コントロールツリーの最上部から開始し、点または形状によってコントロールまたはコントロール群を返すことによって演算する。コントロールは、レンダリングされた形状、境界ボックス、アウトオブバンド形状（ヒット領域）、画像不透明度またはマスク、およびそれ自体の論理を含むサポートサービスを用いて、それがヒットするか否かを定義することができる。コントロールは、ヒットに関する特定のヒット関連データを返すことができる。ヒットテスト機構は、効率的な形でヒットテスト結果をフィルタリングすることができる。ヒットテストウォークは、ビジュアルツリーの深い右から左への探索であり、ヒットは、コールバックを介して、ｚ順で上から下への形でレポートされる。下降するときに、ヒットテスタは、要素レベルの関係、例えば形状を有するキャンバスまたは内側キャンバスを有するドックパネルに関して、フィルタリングを見る。ヒットが発生するときに、ヒットテスタは、（存在する場合）さらなるヒットの処理を継続するか、または停止することができる。
【００２３】
タイミング制御エンジンとアニメーションオブジェクトとの集合からなるアニメーションシステムが設けられる。タイミングエンジンは、例えばアニメーションと音声またはビデオの媒体オブジェクトなど、時間依存性（ｔｉｍｅ−ｖａｒｙｉｎｇ）挙動を示すすべてのオブジェクトが使用できるサービスである。アニメーションオブジェクトは、タイムスパンを他のデータ型にマッピングする関数群を実装し、このデータ型は、その後、他の上位レベルオブジェクトへの入力として使用される。グラフィカルアニメーションが、アニメーション集合をレンダリング演算に関連付けることによって達成される。レンダリング動作で使用される各アニメーションは、「タイムライン」と称する別々のクロックに実行することができる。複数のタイムラインを、タイミングツリー内で編成して、階層的タイミングをサポートすることができる。アニメートされるプリミティブが描画され、アニメーションパラメータが指定されたならば、低レベルレンダリングシステムが、規則的な間隔で場面再描画を処理する。フレームがレンダリングされるたびに、その場面にかかわるアニメーションの現在値が、（ほとんどの場合にシステムクロックによって測定される）経過時間に基づいて計算され、その後、アニメーションにされるプリミティブが再描画される。
【００２４】
様々なプリミティブ型、カラー特徴、および媒体サポートも、ＭＩＬを介して提供される。ＭｅｄｉａＤａｔａを使用して、あらゆる音声／ビデオ内容を再生することができる。
【００２５】
他の利益および長所は、図面と共に解釈される次の詳細な説明から明白になる。
【発明を実施するための最良の形態】
【００２６】
（例示的オペレーティング環境）
図１に、本発明を実施できる適切なコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例にすぎず、本発明の使用または機能性の範囲に関する制限を提案することを意図されたものではない。コンピューティング環境１００を、例示的オペレーティング環境１００に示された構成要素のいずれかまたはその組合せに関する依存性または要件を有するものと解釈してもならない。
【００２７】
本発明は、多数の他の汎用または特殊目的のコンピューティングシステム環境またはコンピューティングシステム構成と共に動作する。本発明と共に使用するのに適する可能性がある周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例に、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド装置、ラップトップ装置、タブレット装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境、および類似物が含まれるが、これに制限はされない。
【００２８】
本発明を、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。本発明は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリ記憶装置を含むローカルおよびリモートの両方のコンピュータ記憶媒体に配置することができる。
【００２９】
図１を参照すると、本発明を実施する例示的なシステムに、コンピュータ１１０の形の汎用コンピューティング装置が含まれる。コンピュータ１１０のコンポーネントに、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１が含まれるが、これには制限はされない。システムバス１２１は、メモリバス、メモリコントローラ、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含む複数の種類のバス構造のいずれかとすることができる。制限ではなく例として、そのようなアーキテクチャに、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（マイクロチャネルアーキテクチャ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ）バス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。
【００３０】
コンピュータ１１０に、通常は、様々なコンピュータ読取り可能な媒体が含まれる。コンピュータ読取り可能な媒体は、コンピュータ１１０によってアクセスでき、揮発性および不揮発性、取外し可能および固定の両方を含む使用可能な媒体のいずれかとすることができる。限定ではなく例として、コンピュータ読取り可能な媒体に、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体に、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、または他のデータなどの情報を保管する任意の方法またはテクノロジで実施された、揮発性および不揮発性、取外し可能および固定の両方の媒体が含まれる。コンピュータ記憶媒体に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、および他のメモリテクノロジ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶、または他の磁気記憶装置、あるいは所望の情報の保管に使用でき、コンピュータ１１０によってアクセスできる他のすべての媒体が含まれるが、これに限定されない。通信媒体によって、通常は、搬送波または他の移送機構などの変調されたデータ信号内のコンピュータ読取り可能な命令、データ構造、プログラムモジュール、または他のデータが実施され、通信媒体には、すべての情報配布媒体が含まれる。用語「変調されたデータ信号」は、信号内で情報をエンコードする形でその特性の１つまたは複数を設定または変更された信号を意味する。限定ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組合せも、コンピュータ読取り可能な媒体の範囲に含まれるべきである。
【００３１】
システムメモリ１３０に、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性メモリおよび／または不揮発性メモリの形のコンピュータ記憶媒体が含まれる。起動中などにコンピュータ１１０内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）が、通常はＲＯＭ  １３１に保管される。ＲＡＭ  １３２には、通常は、処理ユニット１２０から即座にアクセス可能、かつ／または処理ユニット１２０によって現在操作中のデータおよび／またはプログラムモジュールが含まれる。制限ではなく例として、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。
【００３２】
コンピュータ１１０に、他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体も含めることができる。例のみとして、図１に、固定の不揮発性磁気媒体から読み取るかこれに書き込むハードディスクドライブ１４１、取外し可能な不揮発性磁気ディスク１５２から読み取るかこれに書き込む磁気ディスクドライブ１５１、ＣＤ−ＲＯＭまたは他の光媒体などの取外し可能な不揮発性光ディスク１５６から読み取るかこれに書き込む光ディスクドライブ１５５を示す。例示的なオペレーティング環境で使用できる他の取外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体に、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、および類似物が含まれるが、これに限定されない。ハードディスクドライブ１４１は、通常は、インターフェース１４０などの固定のメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取外し可能なメモリインターフェースによってシステムバス１２１に接続される。
【００３３】
上述の図１に示したドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ１１０のコンピュータ読取り可能な命令、データ構造、プログラムモジュール、および他のデータの記憶を提供する。図１では、例えば、ハードドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を保管するものとして図示されている。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一のまたは異なるもののいずれともすることができることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、少なくとも異なるコピーであることを示すために、異なる符号を与えられている。ユーザは、タブレット（電子ディジタイザ）１６４、マイクロホン１６３、キーボード１６２および、一般にマウス、トラックボール、またはタッチパッドと称するポインティングデバイス１６１などの入力装置を介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）に、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、または類似物を含めることができる。上記および他の入力装置は、しばしば、システムバスに結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、またはＵＳＢ（ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ）などの他のインターフェースおよびバス構造によって接続することができる。モニタ１９１または他のタイプのディスプレイ装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ１９１に、タッチスクリーンインターフェース１９２などのインターフェースを介してコンピュータシステム１１０に手書きなどのデジタル化された入力を入力できるタッチスクリーンパネル１９３または類似物と一体化することもできる。モニタおよび／またはタッチスクリーンパネルを、タブレット型パーソナルコンピュータのように、コンピューティング装置１１０が組み込まれるハウジングに物理的に結合することができ、この場合に、タッチスクリーンパネル１９３が、本質的にタブレット１６４として働くことに留意されたい。さらに、コンピューティング装置１１０などのコンピュータに、スピーカ１９５およびプリンタ１９６など、出力周辺インターフェース１９４または類似物を介して接続できる他の周辺出力装置も含めることができる。
【００３４】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般的なネットワークノードとすることができ、通常は、上でコンピュータ１１０に関して説明した要素の多くまたはすべてが含まれるが、図１には、メモリ記憶装置１８１だけを示した。図１に示された論理接続に、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークも含めることができる。そのようなネットワーキング環境は、オフィス、会社規模のコンピュータネットワーク、イントラネット、およびインターネットとして一般的である。
【００３５】
ＬＡＮネットワーキング環境で使用されるときに、コンピュータ１１０は、ネットワークインターフェースまたはネットワークアダプタ１７０を介してＬＡＮ  １７１に接続される。ＷＡＮネットワーキング環境で使用されるときに、コンピュータ１１０に、通常は、インターネットなどのＷＡＮ  １７３を介する通信を確立する、モデム１７２または他の手段が含まれる。モデム１７２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１６０または他の適当な手段を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して図示されたプログラムモジュールまたはその一部を、リモートメモリ記憶装置に保管することができる。限定ではなく例として、図１に、メモリ装置１８１に常駐するものとしてリモートアプリケーションプログラム１８５を示す。図示のネットワーク接続が例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用できることを理解されたい。
【００３６】
（媒体統合レイヤ（ＭＩＬ））
本発明の一態様は、全般的に、媒体統合レイヤ（ＭＩＬ）と称するアーキテクチャを対象とし、このＭＩＬには、即時モードグラフィックスアプリケーションプログラミングインターフェース（ＡＰＩ）、描画命令のキャッシングでも役割を演ずる画面分割データ構造およびＡＰＩ、コントロールレベルオブジェクト群、ならびにマークアップ言語が含まれる。一般に、アーキテクチャは、アプリケーションまたはオペレーティングシステムコンポーネントなどのプログラムコードが、システムディスプレイにグラフィカル出力をレンダリングするために、描画命令および他の情報（例えば画像ビットマップ）をグラフィックスコンポーネントに通信できるようにする。本発明の態様は、例えばオブジェクトモデルに対するＡＰＩの形の、データ構造、命令リスト（描画プリミティブ／コマンド）、および他のグラフィックス関連データをプログラムがシーングラフに取り込むことを可能にする、複数の定義された関数およびメソッドを提供する。処理されるときに、シーングラフは、画面に表示されるグラフィックスをもたらす。
【００３７】
本発明の態様によれば、ＭＩＬは、レイヤで働く合成されたシステムである。合成される各アイテムは、概念上、完全なアルファチャネルを有するビットマップに描画される。そのアルファチャネルが、ビットマップをバックバッファに合成するときに使用される。個々のオブジェクトは、後ろから前の順で合成される。これが、概念モデルであるが、実際には、システムは、完全な中間ビットマップサーフェスが必要でないときを理解し、バックバッファまたは他のバッキングサーフェスに直接合成することに留意されたい。システムは、増分変更も理解し、最小限の再ペイントを行うことができる。
【００３８】
図２は、本発明を実施することができる全般的なレイヤアーキテクチャ（ＭＩＬ）２００を表す。図２に示すように、プログラムコード２０２（例えば、アプリケーションプログラム、オペレーティングシステムコンポーネント、または類似物）を開発して、イメージング２０４、ベクトルグラフィックス要素２０６、および／またはビジュアルアプリケーションプログラミングインターフェース（ＡＰＩ）レイヤ２１２に対して直接に行われる関数呼出し／メソッド呼出しを介することを含む１つまたは複数の様々な形でグラフィックスデータを出力することができる。一般に、イメージング２０４は、例えばビットマップなどの画像を読み込み、編集し、保存する機構を有するプログラムコード２０２を提供する。下で説明するように、これらの画像を、システムの他の部分によって使用することができ、画像を直接に描画するためにプリミティブ描画コードを使用する形もある。ベクトルグラフィックス要素２０６は、オブジェクトモデルの残りとの一貫性のある、グラフィックスを描画するもう１つの形を提供する（下で説明する）。ベクトルグラフィックス要素２０６は、マークアップ言語によって作成することができ、このマークアップ言語を、要素／プロパティシステム２０８およびレイアウトシステム２１０が解釈して、ビジュアルＡＰＩレイヤ２１２への適当な呼出しが行われる。ベクトルグラフィックス要素２０６は、要素／プロパティシステム２０８およびレイアウトシステム２１０と共に、前述の同時係属の特許文献４に記載されている。
【００３９】
したがって、ＭＩＬ２００には、イメージング２０４を含む、画像の読み込み、編集、および保存のためのパイプラインである、プログラマがプログラムできる異なる階層が含まれる。これらの画像は、望み通りにシステムの残りで使用することができる。さらに、プリミティブ描画コードを使用して画像を直接に描画する形もある。
【００４０】
もう１つの階層に、Ｖｉｓｕａｌ  ＡＰＩ２１２が含まれ、ビジュアルＡＰＩ２１２は、主に、描画される項目を編成するためにデータ構造２１６へのアクセスを提供するＡＰＩである。これらのアイテムの各々を、システムによってキャッシングできる描画命令を用いて読み込むことができる。このデータ構造および描画されるものを指定する様々な形があり、通常のＭＩＬ対応アプリケーションの内部では、このＡＰＩを、レイアウトシステム２１０の中から使用することができる。
【００４１】
プログラミングの第３レベルに、ベクトルグラフィックス要素レベル２０６が含まれ、これは、コントロール／要素オブジェクトモデルの残りとの一貫性がある形でグラフィックスを記述し描画するマークアップ言語である。ベクトルグラフィックス要素によって、要素システムを介してグラフィックスシステムが公開される。これには、レンダリング用の要素群と、任意の要素に作用するプロパテ群が含まれる。一実施形態に、２つのサブセットがあり、これには、要素に解析され、要素を作成する要素レベルベクトルグラフィックスと、効率的な形で解析され、保管されるリソースレベルベクトルグラフィックスが含まれる。要素レベルオブジェクトモデルは、要素ツリーにプロパティシステムおよびレイアウトシステム２１０を持ち込む、上位レベルでのコントロールワールドで動作することを指す。解析に関して、要素レベルの多くの動的プロパティが、ＭＩＬ型である。一般に、マークアップ要素は、オブジェクトに解決され、ＸＡＭＬマークアップのＸＭＬスキームが、通常は次のようにマークアップファイルの最上部で宣言される。
【００４２】
<Canvas xmlns="http://schemas.microsoft.com/2003/xaml"
xmlns:def="Definition"
def:Class="Surfin.ChannelBrowser"
def:CodeBehind="ChannelBrowser.xaml.cs"
ID="mainCanvas" Background="Black" Width="100%"
Height="100%"
Loaded="PageLoaded">
【００４３】
例えば＜Ｐａｔｈ＞タグが使用されるときに、パーサは、スキーマを使用して関連する名前空間（例えばＳｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｓｈａｐｅｓ）を検索して、オブジェクトを解決し、構築する。前述の同時係属の特許文献４に全般的に記載されているように、パーサは、型コンバータに頼って、文字列からＭＩＬオブジェクトのインスタンスに変換する。複合構文を必要とする型のそれぞれが、任意選択のＸＭＬ属性として公開される書込可能なＣＬＲ（ｃｏｍｍｏｎ  ｌａｎｇｕａｇｅ  ｒｕｎｔｉｍｅ）プロパティを有し、このプロパティが、動的プロパティと同一の形で解析される。一部の型（特にＢｒｕｓｈ）は、単純な形と複雑な形のどちらでも解析することができる。
【００４４】
これらのレイヤのいずれかまたはこれらのクラスのいずれかに対する関数呼出しを、直接にまたは間接に処理できることに留意されたい。例えば、要求ハンドラに、あるオペレーティングシステムで受け取られる要求を別のオペレーティングシステムによって処理されるＡＰＩ呼出しに変換するミドルウェアコードを含めることができる。したがって、本明細書で使用される関数は、実際の処理がどこで行われるかにかかわらず、データ構造およびクラスがどこで提供されるかにかかわらず、要求された挙動を「行わせる」プログラムによって呼び出される。
【００４５】
理解されるように、また、図２に示すように、アニメーションシステム２２０は、ＡＰＩ全体に広がる。本明細書で説明するように、アニメション値（ａｎｉｍａｔｅ  ｖａｌｕｅｓ）を、要素プロパティレベル２０８、Ｖｉｓｕａｌ  ＡＰＩ２１２の内部、および他のリソースのすべてを含む、実質的にどこにでも渡すことができる。タイミングシステムも、要素レベルとビジュアルレベルの両方で公開される。
【００４６】
一実施形態において、グラフィックスレイヤアーキテクチャ２００に、高レベル合成アニメーションエンジン２１４が含まれ、高レベル合成アニメーションエンジン２１４は、キャッシングデータ構造２１６を含むか、他の形でこれに関連する。キャッシングデータ構造２１６には、後述するように、定義されたオブジェクトモデルに従って管理される階層的に配置されたオブジェクトを含むシーングラフが含まれる。一般に、ビジュアルＡＰＩレイヤ２１２は、プログラムコード２０２（およびレイアウトシステム２１０）に、オブジェクトの作成、オブジェクトにデータを供給するためのオブジェクトのオープンおよびクローズなどの能力を含む、キャッシングデータ構造２１６へのインターフェースを提供する。言い換えると、高レベル合成アニメーションエンジン２１４は、統一された媒体ＡＰＩレイヤ２１２を公開し、この媒体ＡＰＩレイヤ２１２によって、開発者が、グラフィックス情報を表示するためにグラフィックスおよび媒体に関する意図を表現し、基礎になるプラットフォームがプログラムコードに関するハードウェアの使用を最適化できるように、そのプラットフォームに十分な情報を供給することができる。例えば、基礎になるプラットフォームは、キャッシング、リソースネゴシエーション、および媒体統合の責任を負う。
【００４７】
一実施形態において、高レベル合成アニメーションエンジン２１４は、命令ストリームおよび場合により他のデータ（例えば、ビットマップへのポインタ）を、高速な低レベル合成アニメーションエンジン２１８に渡す。一般に、低レベル合成アニメーションエンジン／レンダラ２１８は、実際の描画および画面への合成を管理するシステム群を提供する。本明細書で使用される用語「高レベル」および「低レベル」が、他のコンピューティングシナリオで使用されるものに類似し、一般に、上のコンポーネントに対してソフトウェアコンポーネントが低レベルであるほど、そのコンポーネントはハードウェアに近い。したがって、例えば、高レベル合成アニメーションエンジン２１４から送られるグラフィックス情報を、低レベル合成アニメーションエンジン２１８で受け取ることができ、その情報が、ハードウェア２２２を含むグラフィックスサブシステムにグラフィックスデータを送るのに使用される。本発明を、２層以上の多層合成に拡張できることに留意されたい。
【００４８】
さらに、解像度および装置から独立なユーザインターフェースを容易にするために、ピクセルの概念が、主ＡＰＩの基本単位として公開されないことに留意されたい。そうではなく、最初の座標系は、その座標系の１単位が１／９６インチ（約０．２６５ｍｍ）と等しくなるように設定される。一部のシステム（高解像度のモニタまたはプリンタなど）では、これがピクセルにマッピングされないが、これをｄｉｐまたはｐｘと呼ぶことができる。Ｌｅｎｇｔｈでは、ｄｉｐ単位が、１ユーザ単位に直接に変換される。他の物理単位（インチ、ｃｍ、ポイントなど）の間の乗数は、１／９６インチ（約０．２６５ｍｍ）でロックされる。これは、スケール変換が使用される場合に、物理的問題に指定される場合であっても、その変換が描画されるすべてのものに影響することを意味する。１／９６インチ（約０．２６５ｍｍ）という値は、デフォルトユーザ単位が、デフォルト設定を有する現在のディスプレイでの１ピクセルと等しくなるように選択されたものである。レイアウトシステムおよび他のユーザコードにヒントを供給し、その結果、これらを、レンダリング先の装置の出力解像度に合わせて最適化できるようにする機構を提供できることに留意されたい。
【００４９】
高レベル合成アニメーションエンジン２１４は、プログラムコード２０２とあいまって、プログラムコード２０２によって供給されるグラフィックス場面を表す場面グラフを構築する。例えば、描画される各アイテムを、描画命令を用いて読み込むことができ、この描画命令を、システムが場面グラフデータ構造２１６にキャッシングすることができる。後述するように、このデータ構造２１６および描画されるものを指定する複数の様々な形がある。さらに、高レベル合成アニメーションエンジン２１４は、タイミングアニメーションシステム２２０と一体化して、宣言的（または他の）アニメーションコントロール（例えばアニメーションインターバル）およびタイミングコントロールを提供する。アニメーションシステムを用いると、例えば要素プロパティレベル２０８、ビジュアルＡＰＩレイヤ２１２の内部、および他のリソースのすべてを含む、システム内の本質的にすべての場所にアニメーション値を渡せるようになることに留意されたい。タイミングシステムは、要素レベルとビジュアルレベルで公開される。
【００５０】
低レベル合成アニメーションエンジン２１８は、グラフィックスサブシステム２２２によって提供される、場面の合成、アニメーション、およびレンダリングを管理する。低レベルエンジン２１８は、複数のスレッド（例えば１つまたは複数のアプリケーションからの）の場面のレンダリングを合成し、レンダリングコンポーネントと共に、画面へのグラフィックスの実際のレンダリングを実施する。しかし、時々、レンダリングの一部を上位レベルで行うことが必要かつ／または有利になる場合があることに留意されたい。例えば、下位レイヤは、複数のスレッドからの要求をサービスするが、上位レイヤは、スレッドごとの基礎でインスタンス化され、これによって、イメージング機構２０４を介して、時間がかかるがスレッド固有のレンダリングを上位レベルで実行し、ビットマップへの参照を下位レイヤに渡すことが可能になる。
【００５１】
ＭＩＬ２００は、Ｐｅｎ、Ｂｒｕｓｈ、Ｇｅｏｍｅｔｒｙ、Ｔｒａｎｓｆｏｒｍ、およびＥｆｆｅｃｔｓを含む、この階層化スタック全体を介して共有されるリソースおよびクラスの集合など、グラフィックスプログラミングおよび音声ビジュアルプログラミングの改良を提供するために統合される複数の概念を提供する。また、Ｐｏｉｎｔｓ、Ｒｅｃｔａｎｇｌｅなどを含む単純なプリミティブ型が設けられる。ＰｅｎおよびＢｒｕｓｈは、これらの様々な階層でレンダリングにどのように影響するかを記述する複合型である。ＶｉｓｕａｌＢｒｕｓｈと称するＢｒｕｓｈの特殊な型も設けられ、これによって、プログラマが、領域の塗潰しに任意のグラフィックス「メタファイル」を使用できるようになる（明示的にＶｉｓｕａｌＢｒｕｓｈを介してまたはＶｉｓｕａｌＢｒｕｓｈを参照するＰｅｎを介して）。これは、任意のグラフィックスを保管し、使用する圧縮形式なので、グラフィックスリソースの役割を演ずる。これらのオブジェクトを直接に作成するのに使用されるベクトルグラフィックスマークアップ構文の特定のプロファイルがある。全般的にＶｉｓｕａｌＢｒｕｓｈに似ているが、ＤｒａｗｉｎｇＢｒｕｓｈは、より圧縮され、要約されており、本質的にメタファイルブラシであるが、ＶｉｓｕａｌＢｒｕｓｈは場面グラフブラシである。
【００５２】
他のクラスに、Ｇｅｏｍｅｔｒｙが含まれ、これは、塗潰し、ストローキング、またはクリッピングに関して領域を定義するのに使用される複合型である。Ｔｒａｎｓｆｏｒｍは、座標空間をどのように変換するかを定義するもう１つの複合型階層である。Ｅｆｆｅｃｔｓは、内容のセクションに対する任意のフィルタ効果、例えばブラーをかけるためのシステムを記述する。これに、アドイン拡張性モデルも含まれることに留意されたい。
【００５３】
上記の型を使用して画面または他の対象へのビットを得るＶｉｓｕａｌ  ＡＰＩが設けられる。これには、システムの残りへのベースレベルフックアップ（ｈＷｎｄまたは他の機構を介する）が、上で導入した画面分割データ構造と共に含まれる。Ｉｍａｇｉｎｇを用いると、プログラマが、画像をＭＩＬベースシステムに与えるかそれから得ることができるようになる。Ｍｅｄｉａは、音声およびビデオを含む媒体の他の形を使用する能力を提供する。一般に、Ｖｉｓｕａｌ  ＡＰＩは、要素システムおよびレイアウトシステムの下位で動作するＡＰＩ群をさし、上位レベルではなくＶｉｓｕａｌを用いてプログラムし、Ｖｉｓｕａｌに対して直接にプログラムすることを指す。ビジュアルが、キャッシングデータ構造２１６の基本オブジェクトであり、画面上のビジュアルなものに関する保存されるデータ構造を含み、性能のためにＩｎｓｔｒｕｃｔｉｏｎ  Ｌｉｓｔおよび装置固有リソースをキャッシングすることに留意されたい。
【００５４】
図３および４に、それぞれＶｉｓｕａｌと称するベースオブジェクトを含む、例のシーングラフ３００および４００を示す。一般に、Ｖｉｓｕａｌには、ユーザへの仮想サーフェスを表し、ディスプレイのＶｉｓｕａｌ表現を有するオブジェクトが含まれる。図５からわかるように、基底クラスＶｉｓｕａｌは、他のＶｉｓｕａｌ型の基礎の機能性を提供する、すなわち、Ｖｉｓｕａｌクラスは、そこからＶｉｓｕａｌ型が派生される抽象基底クラスである。
【００５５】
図３に示すように、トップレベル（またはルート）Ｖｉｓｕａｌ３０２は、Ｖｉｓｕａｌマネージャオブジェクト３０４に接続され、Ｖｉｓｕａｌマネージャオブジェクト３０４は、グラフィックデータがプログラムコードのために出力されるウィンドウ（ＨＷｎｄ）３０６または類似するユニットとの関係（例えばハンドルを介する）も有する。ＶｉｓｕａｌＭａｎａｇｅｒ３０４は、そのウィンドウ３０６へのトップレベルＶｉｓｕａｌ（およびそのＶｉｓｕａｌのすべての子）の描画を管理する。図６に、本明細書に記載のグラフィックスシステムのオブジェクトモデル内の他のオブジェクト６２０の集合の１つとしてＶｉｓｕａｌＭａｎａｇｅｒを示す。
【００５６】
描画するために、ＶｉｓｕａｌＭａｎａｇｅｒ３０４は、前述の米国特許仮出願に全般的に記載されているように、ディスパッチャ３０８によってスケジューリングされるものとしてシーングラフを処理し（例えばトラバースするか送り）、グラフィックス命令および他のデータを、その対応するウィンドウ３０６の低レベルコンポーネント２１８（図２）に供給する。シーングラフ処理は、通常、低レベルコンポーネント２１８および／またはグラフィックスサブシステム２２２のリフレッシュレートより相対的に低いレートでディスパッチャ３０８によってスケジューリングされる。図３に、トップレベル（ルート）Ｖｉｓｕａｌ３０２の下に階層的に配置された複数の子Ｖｉｓｕａｌ  ３１０から３１４を示すが、子Ｖｉｓｕａｌの一部は、例えばＩｎｓｔｒｕｃｔｉｏｎ  Ｌｉｓｔｓおよび他のＶｉｓｕａｌを含む関連する命令リスト３１８および３１９に関連する描画コンテキスト３１６および３１７（その一時的な性質を表すために破線で図示）を介して取り込まれたものとして表されている。Ｖｉｓｕａｌに、他のプロパティ情報も含めることができる。一般に、図５に示されているように、基底ビジュアルクラスに対するアクセスのほとんどは、ＩＶｉｓｕａｌインターフェースを介し、ビジュアルは、ＤｅｐｅｎｄｅｎｃｙＯｂｊｅｃｔから派生する。Ｖｉｓｕａｌ（付録でさらに説明する）に、次の例のＶｉｓｕａｌクラスに示されているように、他のプロパティ情報も含めることができる。
【００５７】
【表１−１】
2007509426.tif 000003
【００５８】
【表１−２】
2007509426.tif 000004
【００５９】
Ｖｉｓｕａｌは、グラフィカル内容および子の集合のコンテナである。Ｖｉｓｕａｌの様々なプロパティを使用して、Ｖｉｓｕａｌのレンダリング挙動を制御することができる。例えば、Ｖｉｓｕａｌでクリップを設定することによって、Ｖｉｓｕａｌの内容が、指定された形状にクリッピングされる。他のプロパティは、ｔｒａｎｓｆｏｒｍ、ｂｌｅｎｄ  ｍｏｄｅ、ｏｐａｃｉｔｙ、ｓｈｏｗなどである。これらのプロパティのすべてを、ｇｅｔプロパティおよびｓｅｔプロパティを介して制御することができる。
【００６０】
Ｓｈｏｗプロパティは、ビジュアルの表示／非表示に使用され、例えば、偽のときにビジュアルが不可視であり、そうでないときにビジュアルが可視になる。さらに、ＭＩＬオブジェクト（Ｖｉｓｕａｌ  ＡＰＩレイヤのＶｉｓｕａｌまたは要素レイヤの要素のいずれか）が、階層内に存在する。座標系は、この階層を介して下に継承される。この形で、親が、レンダリングパスを変更する座標変換をプッシュし、その親の子に適用させることができる。
【００６１】
ビジュアルの変換は、そのビジュアルへの接続に対するものである。言い換えると、変換は、親のＶｉｓｕａｌＣｏｌｌｅｃｔｉｏｎ  Ｃｈｉｌｄｒｅｎプロパティに対する［Ｇｅｔ｜Ｓｅｔ］ＣｈｉｌｄＴｒａｎｓｆｏｒｍを介して設定される。後で説明するＶｉｓｕａｌＣｏｌｌｅｃｔｉｏｎも参照されたい。
【００６２】
座標変換を、すべてのものに、それがビットマップ内にあるかのように均一な形で適用できることに留意されたい。これが、変換が必ずビットマップに適用され、レンダリングされるものが変換によって同等に影響を受けることを意味しないことに留意されたい。例えば、ユーザが、１インチ（２５．４ｍｍ）幅のラウンドペンを用いて円を描画し、その円に、Ｘ方向で２のスケールを適用する場合に、ペンは、左右で２インチ（５０．８ｍｍ）幅、上下で１インチ（２５．４ｍｍ）幅になる。これを、時々、合成またはビットマップ変換と称する（形状だけに影響するスケルトンスケールまたは形状スケールではなく）。図８は、変換されていない画像８００が左、不均一スケールを有する変換された画像８０２が右に示された、スケーリング変換を表す図である。図９は、変換されていない画像８００が左、形状スケーリングを有する変換された画像９０４が右に示された、スケーリング変換を表す図である。
【００６３】
ビジュアルの座標変換に関して、ＴｒａｎｓｆｏｒｍＴｏＤｅｓｃｅｎｄａｎｔは、基準ビジュアルから子孫ビジュアルに向かう座標空間変化を反映する変換を返す。この変換は、例えば、基準ビジュアルの座標空間から子孫ビジュアルの座標空間に点を変換するのに使用することができる。ＴｒａｎｓｆｏｒｍＦｒｏｍＤｅｓｃｅｎｄａｎｔは、同様に、子孫Ｖｉｓｕａｌから基準Ｖｉｓｕａｌに向かう座標空間変化を記述する変換を返す。この変換は、子孫ビジュアルの座標空間から基準ビジュアルの座標空間に点を変換するのに使用することができる。便宜上、Ｖｉｓｕａｌ  ＡＰＩは、やはり各々の座標空間変化の変換を返すＴｒａｎｓｆｏｒｍＴｏＡｎｃｅｓｔｏｒ、ＴｒａｎｓｆｏｒｍＦｒｏｍＡｎｃｅｓｔｏｒ、ＴｒａｎｓｆｏｒｍＦｒｏｍＶｉｓｕａｌ、およびＴｒａｎｓｆｏｒｍＴｏＶｉｓｕａｌを提供する。最後の２つのＡＰＩで、Ｖｉｓｕａｌの間の関係が指定されないことに留意されたい。これらは、共通の祖先を共有する限り、Ｖｉｓｕａｌツリー内で対等とすることもできる。実施形態は、共通の祖先を見つけ、基準Ｖｉｓｕａｌから共通の祖先への座標変換を計算し、その後、共通の祖先から対象Ｖｉｓｕａｌへの座標変換を計算する。結果の変換は、例えば、指定されたＶｉｓｕａｌの間で点を変換するのに使用することができる。
【００６４】
Ｖｉｓｕａｌの内容の境界ボックスを判定するのに使用できる２ｇｅｔプロパティすなわち、子孫のすべてのグラフィカル内容の境界ボックスであるＶｉｓｕａｌＤｅｓｃｅｎｄａｎｔＢｏｕｎｄｓと、内容の境界であるＶｉｓｕａｌＣｏｎｔｅｎｔＢｏｕｎｄｓがある。これらにＵｎｉｏｎを適用することによって、Ｖｉｓｕａｌの全体的な境界が提供される。
【００６５】
ｃｌｉｐプロパティは、ビジュアルのクリッピング領域を設定（および取得）する。すべてのＧｅｏｍｅｔｒｙ（ｇｅｏｍｅｔｒｙクラスを、図１０に示し、下のＧｅｏｍｅｔｒｙセクションで説明する）を、クリッピング領域として使用することができる。一実施形態で、クリッピング領域のデフォルト設定が、ｎｕｌｌである、すなわち、クリッピングなしであり、これは、（−∞，−∞）から（＋∞，＋∞）までの無限に大きいクリッピング長方形と考えることができる。
【００６６】
Ｏｐａｃｉｔｙプロパティは、ビジュアルの不透明度値を取得／設定し、ビジュアルの内容が、不透明度値および選択された混合モードに基づいて描画サーフェスで混合されるようにする。ＢｌｅｎｄＭｏｄｅプロパティは、使用される混合モードの設定（または取得）に使用することができる。例えば、不透明度（アルファ）値を、０．０と１．０の間で設定し、モードとして線形アルファ混合を設定することができ、例えば、色＝アルファ×前景色＋（１．０−アルファ）×背景色になる。特殊効果プロパティなどの他のサービス、例えばブラー、モノクロームなどを、ビジュアルに含めることができる。
【００６７】
Ｖｉｓｕａｌは、子のセットを管理するためのＣｈｉｌｄｒｅｎプロパティも有する。Ｖｉｓｕａｌは、Ｖｉｓｕａｌが子を有するか否かを検査するＨａｓＣｈｉｌｄｒｅｎプロパティも備える。Ｃｈｉｌｄｒｅｎプロパティは、子の集合に対して追加、除去、挿入などの動作をユーザが実行できるようにするＶｉｓｕａｌＣｏｌｌｅｃｔｉｏｎを返す。次に、ＶｉｓｕａｌＣｏｌｌｅｃｔｉｏｎの例を示す。
【００６８】
【表２】
2007509426.tif 000005
【００６９】
ＶｉｓｕａｌＣｏｌｌｅｃｔｉｏｎでのＶｉｓｕａｌの順序によって、Ｖｉｓｕａｌがレンダリングされる順序が決定される、すなわち、Ｖｉｓｕａｌは、後ろから前へ、最小のインデクスから最大のインデックスへ（ペイント順序）レンダリングされる。
【００７０】
Ｐｒｏｘｙ  Ｖｉｓｕａｌは、例えばコンテナビジュアルの下で、シーングラフに複数回追加できるビジュアルである。Ｐｒｏｘｙ  Ｖｉｓｕａｌによって参照されるすべてのビジュアルに、ルートから複数のパスによって達することができるので、読取サービス（ＴｒａｎｓｆｏｒｍＴｏＤｅｓｃｅｎｄｅｎｔ、ＴｒａｎｓｆｏｒｍＦｒｏｍＤｅｓｃｅｎｄｅｎｔ、およびＨｉｔＴｅｓｔ）は、  Ｐｒｏｘｙ  Ｖｉｓｕａｌを介しては動作しない。本質的に、すべてのビジュアルからビジュアルツリーのルートへの１つの正規パスがあり、そのパスには、Ｐｒｏｘｙ  Ｖｉｓｕａｌは含まれない。
【００７１】
図４に、ＣｏｎｔａｉｎｅｒＶｉｓｕａｌおよびＤｒａｗｉｎｇＶｉｓｕａｌがシーングラフ内で関係し、Ｉｎｓｔｒｕｃｔｉｏｎ  Ｌｉｓｔの形の関連データを有する（例えば、対応する描画コンテキスト内）例のシーングラフ４００を示す。ＣｏｎｔａｉｎｅｒＶｉｓｕａｌは、Ｖｉｓｕａｌ基底クラスから派生した構造的内容だけを有するＶｉｓｕａｌである。Ｖｉｓｕａｌは、任意の形で互いにネストすることができる。具体的には、ＣｏｎｔａｉｎｅｒＶｉｓｕａｌをネストすることは、違反でない。ＣｏｎｔａｉｎｅｒＶｉｓｕａｌの主な目的は、ＩＶｓｉｕａｌインターフェースを経由せずに便利にアクセスできる、Ｖｉｓｕａｌのコンテナを提供することである。したがって、ＣｏｎｔａｉｎｅｒＶｉｓｕａｌは、ＩＶｉｓｕａｌメソッドのすべてをｐｕｂｌｉｃメソッドとして再実装する。ＣｏｎｔａｉｎｅｒＶｉｓｕａｌの子は、ＣｏｎｔａｉｎｅｒＶｉｓｕａｌのＶｉｓｕａｌＣｏｌｌｅｃｔｉｏｎ  Ｃｈｉｌｄｒｅｎプロパティのメソッドを用いて操作することができる。
【００７２】
図５に戻ると、もう１つのビジュアルが、Ｗｉｎ３２子ＨＷｎｄを場面グラフ内で位置決めするＨｗｎｄＶｉｓｕａｌ  ５０５である。具体的に言うと、レガシープログラムは、以前のグラフィックス技術に基づいて子ＨＷｎｄ（または類似物）に描画するＷＭ＿ＰＡＩＮＴメソッド（または類似物）を介して演算する。そのようなプログラムを新しいグラフィックス処理モデルでサポートするために、ＨｗｎｄＶｉｓｕａｌは、Ｈｗｎｄをシーングラフに含め、親ビジュアルが再位置決めされるときに移動することを可能にする。２次元の世界と３次元の世界の間の接続を可能にする３次元（３Ｄ）ビジュアルなど、他の型のビジュアル５０６も可能であり、例えば、３次元の世界へのビューを有する２次元ビジュアルを介して、カメラのようなビューが可能になる。そのような３Ｄビジュアルを、後述する。
【００７３】
前述したように、ビジュアルに、Ｇｅｏｍｅｔｒｙ、ＩｍａｇｅＳｏｕｒｃｅ、およびＭｅｄｉａＤａｔａを含む様々な描画プリミティブを描画コンテキストに取り込むことによって描画することができる。さらに、このスタック全体に関して共有されるリソースおよびクラス群がある。これには、Ｐｅｎ、Ｂｒｕｓｈ、Ｇｅｏｍｅｔｒｙ、Ｔｒａｎｓｆｏｒｍ、およびＥｆｆｅｃｔが含まれる。ＤｒａｗｉｎｇＣｏｎｔｅｘｔ抽象クラスは、ＤｒａｗｉｎｇＶｉｓｕａｌ、ＲｅｔａｉｎｅｄＶｉｓｕａｌ、ＩｍａｇｅＤａｔａなどを取り込むのに使用できる描画演算およびコンテキスト状態演算群を公開する。言い換えると、描画コンテキスト抽象クラスは、描画演算およびプッシュ／ポップ演算の組を公開し、描画演算およびプッシュ演算ごとに、２つのメソッドすなわち、引数として定数を取るメソッドと引数としてアニメータを取るメソッドがある。プッシュ／ポップ演算の例が、ＰｕｓｈＴｒａｎｓｆｏｒｍ、ＰｏｐＴａｒｎｓｆｏｒｍ、ＰｕｓｈＣｌｉｐ、ＰｏｐＣｌｉｐ、ＰｕｓｈＯｐａｃｉｔｙ、ＰｏｐＯｐａｃｉｔｙなどである。
【００７４】
（変換、不透明度、およびクリップを含む）様々なサービスを、描画コンテキストにプッシュし、ポップすることができ、プッシュ呼出しごとに適切なポップ呼出しがある限り、プッシュ／ポップ演算をネストすることができる。
【００７５】
ＰｕｓｈＴｒａｎｓｆｏｒｍメソッドは、変換をプッシュする。後続の描画演算は、プッシュされた変換に関して実行される。ポップ呼出しは、一致するＰｕｓｈＴｒａｎｓｆｏｒｍ呼出しによってプッシュされた変換をポップする。
【００７６】
void PushTransform(Transform transform);
void PushTransform(Matrix matrix);
void Pop();
同様に、ＰｕｓｈＯｐａｃｉｔｙメソッドは、不透明度値をプッシュする。後続の描画演算は、指定された不透明度値を用いて一時サーフェスにレンダリングされ、その後、場面に合成される。Ｐｏｐ（）は、一致するＰｕｓｈＯｐａｃｉｔｙ呼出しによってプッシュされた不透明度値をポップする。
【００７７】
void PushOpacity(float opacity);
void PushOpacity(FloatAnimation opacity);
void Pop();
ＰｕｓｈＣｌｉｐメソッドは、クリッピング形状をプッシュする。後続の描画演算は、その形状にクリッピングされる。クリッピングは、変換後の空間で適用される。Ｐｏｐ（）は、一致するＰｕｓｈＣｌｉｐ呼出しによってプッシュされたクリッピング領域をポップする。
【００７８】
void PushClip(Geometry clip);
void Pop();
ポップ動作がプッシュと一致する限り、プッシュ演算を任意にネストできることに留意されたい。例えば、次のコードが有効である。
【００７９】
【表３】
2007509426.tif 000006
【００８０】
Ｇｅｏｍｅｔｒｙは、ストロークおよび塗潰しがない、ベクトルグラフィックススケルトンを定義するクラスの型（図１０）である。各ｇｅｏｍｅｔｒｙオブジェクトは、単純な形状（ＬｉｎｅＧｅｏｍｅｔｒｙ、ＥｌｌｉｐｓｅＧｅｏｍｅｔｒｙ、ＲｅｃｔａｎｇｌｅＧｅｏｍｅｔｒｙ）、複雑な単一の形状（ＰａｔｈＧｅｏｍｅｔｒｙ）、またはコンバイン演算（例えば、和集合、交差など）を指定されたそのような形状のリストＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎである。これらのオブジェクトが、図１０に示されたクラス階層を形成する。
【００８１】
図１１からわかるように、ＰａｔｈＧｅｏｍｅｔｒｙは、Ｆｉｇｕｒｅオブジェクトの集合である。Ｆｉｇｕｒｅオブジェクトのそれぞれは、ｆｉｇｕｒｅの形状を実際に定義する１つまたは複数のＳｅｇｍｅｎｔオブジェクトからなる。Ｆｉｇｕｒｅは、セグメント集合を定義する、Ｇｅｏｍｅｔｒｙのサブセクションである。このセグメント集合は、２次元Ｓｅｇｍｅｎｔオブジェクトの単一の連結されたシリーズである。Ｆｉｇｕｒｅは、定義された領域を有する閉じた形状、または曲線を定義するが閉じた区域がないＳｅｇｍｅｎｔの接続されたシリーズのいずれかとすることができる。
【００８２】
図１２からわかるように、形状（例えば長方形）が描かれるときに、ブラシまたはペンを、下で説明するように選択することができる。さらに、ペンオブジェクトは、ブラシオブジェクトを有することもできる。ブラシオブジェクトは、平面をグラフィカルに塗り潰す方法を定義し、ブラシオブジェクトのクラス階層がある。これは、図１２では、塗り潰された長方形１２０２によって表され、この長方形は、長方形、ブラシ命令、およびパラメータを含むビジュアルが処理されるときにもたらされる。Ｐｅｎオブジェクトは、下で説明するように、Ｔｈｉｃｋｎｅｓｓ、ＬｉｎｅＪｏｉｎ、ＬｉｎｅＣａｐ、ＥｎｄＣａｐ、ＭｉｔｅｒＬｉｍｉｔ、ＤａｓｈＡｒｒａｙ、およびＤａｓｈＯｆｆｓｅｔのプロパティと共にＢｒｕｓｈを保持する。下で説明するように、いくつかの型のＢｒｕｓｈ（勾配およびナイングリッド（ｎｉｎｅ  ｇｒｉｄ）など）は、それ自体のサイズを決定する。使用されるときに、これらのブラシのサイズは、境界ボックスから入手され、例えば、ＢｒｕｓｈのＧｒａｄｉｅｎｔＵｎｉｔｓ／ＤｅｓｔｉｎａｔｉｏｎＵｎｉｔｓにＲｅｌａｔｉｖｅＴｏＢｏｕｎｄｉｎｇＢｏｘが設定されているときには、描画されるプリミティブの境界ボックスが使用される。これらのプロパティにＡｂｓｏｌｕｔｅが設定されている場合には、座標空間が使用される。
【００８３】
上で延べ、下でさらに説明するように、本発明のグラフィックスオブジェクトモデルには、Ｂｒｕｓｈオブジェクトモデルが含まれ、このＢｒｕｓｈオブジェクトモデルは、全般的に、ピクセルで平面を覆うという概念を対象とする。ブラシの型の例が、図１３の階層に表されており、Ｂｒｕｓｈ基底クラスの下に、ＧｒａｄｉｅｎｔＢｒｕｓｈ、ＮｉｎｅＧｒｉｄＢｒｕｓｈ、ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ、およびＴｉｌｅＢｒｕｓｈが含まれる。ＧｒａｄｉｅｎｔＢｒｕｓｈには、ＬｉｎｅａｒＧｒａｄｉｅｎｔオブジェクトおよびＲａｄｉａｌＧｒａｄｉｅｎｔオブジェクトが含まれる。ＤｒａｗｉｎｇＢｒｕｓｈおよびＩｍａｇｅＢｒｕｓｈは、ＴｉｌｅＢｒｕｓｈから派生する。クラスの代替配置が可能であり、例えば、ＴｉｌｅＢｒｕｓｈから、ＩｍａｇｅＢｒｕｓｈ、ＶｉｓｕａｌＢｒｕｓｈ、ＶｉｄｅｏＢｒｕｓｈ、ＮｉｎｅＧｒｉｄＢｒｕｓｈ、およびＤｒａｗｉｎｇＢｒｕｓｈを派生することができる。Ｂｒｕｓｈオブジェクトが、使用されるときに座標系と関係する方法を認識でき、かつ／またはそれに対して使用される形状の境界ボックスと関係する方法を認識できることに留意されたい。一般に、サイズなどの情報は、ブラシが描かれるオブジェクトから推論することができる。具体的に言うと、ブラシ型の多くが、パラメータの一部を指定するために座標系を使用する。この座標系は、ブラシが適用される形状の単純な境界ボックスに関して定義することができ、あるいは、ブラシが使用されるときにアクティブである座標空間に対するものとすることができる。これらを、それぞれ、ＲｅｌａｔｉｖｅＴｏＢｏｕｎｄｉｎｇＢｏｘモードおよびＡｂｓｏｌｕｔｅモードと称することが知られている。
【００８４】
（Ｖｉｓｕａｌ  ＡＰＩ）
Ｖｉｓｕａｌ  ＡＰＩは、媒体統合レイヤを介する描画の出発点であり、Ｖｉｓｕａｌ  Ｔｒｅｅを媒体に接続するＶｉｓｕａｌＭａｎａｇｅｒオブジェクトを含む複数の型のオブジェクトを含む。ＶｉｓｕａｌＭａｎａｇｅｒの異なる型（例えば、Ｓｃｒｅｅｎ、Ｐｒｉｎｔｅｒ、Ｓｕｒｆａｃｅ）は、特定の媒体へのＶｉｓｕａｌ  Ｔｒｅｅのレンダリングプロセスを管理する。ＶｉｓｕａｌＭａｎａｇｅｒは、「トップレベルＭＩＬオブジェクト」という題名のセクションでさらに説明する。
【００８５】
ビジュアルは、ユーザが描画を行う場所である。ビジュアルは、ビジュアルツリー内のノード（下で説明するように、場面の構造であるコンテナオブジェクト）であり、プログラムが描画する場所を提供する。それぞれが異なる用途に合わせて調整された、様々な型のビジュアルがある。ビジュアルは、Ｗｉｎ３２  ｈＷｎｄのビジュアル／出力側に似ている。
【００８６】
ビジュアルは、複数の機能を提供し、これには、親ビジュアルアクセス、子ビジュアル集合、任意の形状に基づくクリッピング、不透明度、ブレンドモード、ビジュアルおよびその子に影響する変換、ヒットテスト、座標変換サービス、境界ボックスサービス、および効果（ラスタおよびベクトル）が含まれる。
【００８７】
ビジュアル場面をレンダリングするために、ビジュアルツリーを、例えば上から下、左から右にトラバースし、まず内容をレンダリングし、次にＶｉｓｕａｌの子を左から右にトラバースする。ビジュアルの子のすべてが、そのビジュアル自体の内容の前に描画される。内容が、ユーザへのコールバックを必要とする場合には、そのコールバックは、レンダリング時中に同期式に行われる。Ｖｉｓｕａｌツリーを装置にレンダリングするためにシステムが行う（ＶｉｓｕａｌＲｅｎｄｅｒｅｒを介して）ことの擬似コードを示す。
【００８８】
【表４】
2007509426.tif 000007
【００８９】
導出されたビジュアルは、ＲｅｎｄｅｒＣｏｎｔｅｎｔｓ呼出し中にユーザにコールバックすることができる。
【００９０】
図１３は、一実施形態のＶｉｓｕａｌ  Ｃｌａｓｓ  Ｈｉｅｒａｒｃｈｙを表す。レンダパスの一部として行われるコールバック中に（ＩＲｅｔａｉｎｅｄＶｉｓｕａｌ．ＲｅｎｄｅｒへのコールバックまたはＰａｉｎｔｉｎｇＶｉｓｕａｌ．ＲｅｎｄｅｒＣｏｒｅへのコールバックを含む）、ビジュアルツリーが、実行理由のために「ロック」される。このロックは、コンテキスト全体に亘って行われ、ビジュアルがどのビジュアルツリーに属するかにかかわらずに、ロックされたときにコンテキストがツリーを変更できないことを意味する。ツリーがロックされているときに、Ｖｉｓｕａｌの子を変更することはできず、いかなる形でも（例えば、Ｏｐｅｎ、ルート３Ｄモデルの設定など）別のビジュアルの内容を変更することはできず、Ｖｉｓｕａｌに対してＴｒａｎｓｆｏｒｍ、Ｏｐａｃｉｔｙ、Ｃｌｉｐ、ＢｌｅｎｄＭｏｄｅ、またはＥｆｆｅｃｔを設定することはできず、ヒットテストは動作せず、境界情報のＧｅｔ演算は働かない。
【００９１】
Ｖｉｓｕａｌの機能は、ＩＶｉｓｕａｌインターフェースを介して公開され、これによって、その機能がｐｕｂｌｉｃになると同時に、オブジェクトモデルが保護される。次のリストは、１つの例示的な実施形態のＩＶｉｓｕａｌインターフェースである。
【００９２】
【表５】
2007509426.tif 000008
【００９３】
Ｖｉｓｕａｌには、レンダ内容および子の集合が含まれる。ｔｒａｎｓｆｏｒｍ、ｃｌｉｐ、ｏｐａｃｉｔｙ、ｂｌｅｎｄ  ｍｏｄｅなどを含む複数のプロパティを使用して、Ｖｉｓｕａｌツリーの実際のレンダリングを制御することができる。Ｖｉｓｕａｌが、内容および子を同時に有する必要がないことに留意されたい。一実施形態で、レンダリング内容および子集合を、オンデマンドで作成して、メモリ使用を最適化することができる。Ｖｉｓｕａｌ  ＡＰＩを用いると、そのユーザが、Ｖｉｓｕａｌから派生し、特殊化できるようになる。
【００９４】
子に対する変換は、型ＶｉｓｕａｌＣｏｌｌｅｃｔｉｏｎのプロパティＣｈｉｌｄｒｅｎに対する変換を介して実行される。
【００９５】
【表６】
2007509426.tif 000009
【００９６】
Ｔｒａｎｓｆｏｒｍａｔｉｏｎ  Ｒｅａｄ  Ｓｅｒｖｉｃｅは、ユーザが、ある座標フレームから別の座標フレームへの集約変換を表すＭａｔｒｉｘを得られるようにするメソッドを提供する。
【００９７】
【表７】
2007509426.tif 000010
【００９８】
ＴｒａｎｓｆｏｒｍＴｏＡｎｃｅｓｔｏｒメソッドおよびＴｒａｎｓｆｏｒｍＴｏＤｅｓｃｅｎｄａｎｔメソッドは、より効率的であるが、呼出し側が２つのＶｉｓｕａｌの間の関係を知ることを必要とする。より一般的なＴｒａｎｓｆｏｒｍＴｏ／ＦｒｏｍＶｉｓｕａｌメソッドは、共通の祖先を見つけ、そのビジュアルまでの変換を計算する。これらが、キャッシュの更新と、任意のビジュアルに対するＯｎＲｅｎｄｅｒの呼出しを引き起こす場合があることに留意されたい。ビジュアルが接続されてないか、縮重変換（ｄｅｇｅｎｅｒａｔｅ  ｔｒａｎｓｆｏｒｍ）に出会う場合には、例外が送出される。
【００９９】
境界計算も提供される。
【０１００】
【表８】
2007509426.tif 000011
【０１０１】
ＶｉｓｕａｌＤｅｓｃｅｎｄａｎｔＢｏｕｎｄｓは、現在のビジュアルの子孫の、現在のビジュアルの内容を含まない内容境界ボックスの和集合を返す。ＶｉｓｕａｌＣｏｎｔｅｎｔＢｏｕｎｄｓは、現在のビジュアルの内容の境界ボックスを返す。
【０１０２】
Ｏｐａｃｉｔｙプロパティ（例えばｄｏｕｂｌｅ）は、親と合成されるときにＶｉｓｕａｌに適用される任意選択のＯｐａｃｉｔｙ値を指定する。デフォルトで、この値は１．０であり、これによって、内容が完全に不透明に見えるようになる。この値は、サブグラフ内の他のＯｐａｃｉｔｙデータと掛け合わされるので、１．０のＯｐａｃｉｔｙによって何も変更されないことに留意されたい。０．０のＯｐａｃｉｔｙによって、内容全体が透明になり、０．２５の値によって、Ｏｐａｃｉｔｙが公称値の２５％になる。Ｏｐａｃｉｔｙは、ＢｌｅｎｄＭｏｄｅの前に適用される。
【０１０３】
ＢｌｅｎｄＭｏｄｅは、このＶｉｓｕａｌが合成されるときに、サブグラフの内容および宛先に任意選択のＢｌｅｎｄＭｏｄｅを適用することを指定するプロパティである。デフォルトで、この値はＢｌｅｎｄＭｏｄｅ．Ｎｏｒｍａｌであり、これによって、宛先へのアルファチャネル対応合成が実行される。このプロパティに別の値を設定することによって、ソースとしてのＶｉｓｕａｌの内容と宛先としてのレンダ対象の内容の合成が実行される。これは、Ｏｐａｃｉｔｙプロパティが適用された後に適用される。
【０１０４】
基底ビジュアルクラスは、Ｖｉｓｕａｌが共通して有する特徴のインターフェースを提示する。
【０１０５】
【表９−１】
2007509426.tif 000012
【０１０６】
【表９−２】
2007509426.tif 000013
【０１０７】
ＣｏｎｔａｉｎｅｒＶｉｓｕａｌは、ｖｉｓｕａｌクラスから直接に派生し、ｐｒｏｔｅｃｔｅｄプロパティをｐｕｂｌｉｃに昇格させる。これは、ユーザが、新しいクラスを派生する必要なしにビジュアルコンテナシップを作成できるようにするためである。
【０１０８】
【表１０】
2007509426.tif 000014
【０１０９】
ＲｅｔａｉｎｅｄＶｉｓｕａｌは、描画に使用できる「保持された命令ストリーム」を導入するビジュアルである。
【０１１０】
【表１１−１】
2007509426.tif 000015
【０１１１】
【表１１−２】
2007509426.tif 000016
【０１１２】
命令ストリームを、ＯｎＤｅｍａｎｄモードで使用することができ、このモードでは、必要に応じて、レンダリングのためにユーザがコールバックされる。ユーザは、ＩＲｅｔａｉｎｅｄＲｅｎｄｅｒを実装する必要がある。命令ストリームを、Ｉｍｐｅｒａｔｉｖｅモードで使用することができ、このモードでは、ユーザが、ＲｅｎｄｅｒＯｐｅｎを直接に呼び出し、描画コンテキストを得ることができる。一般に、ユーザは、一時にこのモードの１つを使用するが、これらを混合した形で使用することが可能である。
【０１１３】
ＲｅｎｄｅｒＯｐｅｎおよびＲｅｎｄｅｒＡｐｐｅｎｄは、現在のストリームに影響し、様々なシナリオで使用可能である。これらは、このＶｉｓｕａｌが現在Ｒｅｎｄｅｒコールバック内である場合に送出される。ＲｅｎｄｅｒＯｐｅｎは、ＲｅｔａｉｎｅｄＶｉｓｕａｌ内にあった以前の内容のすべてをクリアし、ＲｅｎｄｅｒＡｐｐｅｎｄは、ストリームの終りに新しい内容をつなぎ合わせる。ユーザが、ビジュアルに対するＩＲｅｔａｉｎｅｄＲｅｎｄｅｒを実装している場合に、ユーザは、ＯｎＤｅｍａｎｄモードも使用されなければならないことをシステムに知らせる。システムは、Ｒｅｎｄｅｒ呼出しによって供給される内容の境界として、ＲｅｎｄｅｒＢｏｕｎｄｓプロパティに設定された値を使用する。ＩＲｅｔａｉｎｅｄＲｅｎｄｅｒが実施されているときに、システムは、場面を最適化すると決定し、いつでも内容を捨てることができる。ＲｅｎｄｅｒＢｏｕｎｄｓは、空の長方形がデフォルトであるが、Ｒｅｃｔ．Ｉｎｆｉｎｉｔｅまたは未設定の値が可能な代替物である。コールバックによって暗示される仮想化性能の向上を得るために、ユーザは、適当な値を設定しなければならない。
【０１１４】
場面をレンダリングするときに、システムは、概念では各ビジュアルを検査する（実際には、システムがほとんどのときにほとんどのビジュアルを無視できることに留意されたい）。そのビジュアルが、ＩｓＶｉｓｕａｌＩｎｖａｌｉｄに真を設定されており、ＲｅｎｄｅｒＢｏｕｎｄｓに基づいて、そのビジュアルの内容が必要である場合に、システムは、ＩＲｅｔａｉｎｅｄＶｉｓｕａｌ．Ｒｅｎｄｅｒを呼び出して、そのビジュアルの内容を書き込む。これによって、既にあるすべての内容が置換される。ユーザは、Ｉｎｖａｌｉｄａｔｅを呼び出すことによって、内容ストリームを捨てるようにシステムに手動で指示することができる。
【０１１５】
ＩＲｅｔａｉｎｅｄＲｅｎｄｅｒが実装されていない場合には、ＩｓＶｉｓｕａｌＩｎｖａｌｉｄは、必ず偽を返す。Ｉｎｖａｌｉｄａｔｅは何もしない。ＩＲｅｔａｉｎｅｄＲｅｎｄｅｒがそのように命名されている（例えばＩＲｅｎｄｅｒではなく）のは、これが、すべてのレンダリングコールバックの場合に使用するのに一般に十分でないからであることに留意されたい。例えば、ＰａｉｎｔｉｎｇＶｉｓｕａｌは、無効な長方形を用いてコールバックする。
【０１１６】
ＤｒａｗｉｎｇＶｉｓｕａｌは、ＲｅｔａｉｎｅｄＶｉｓｕａｌに非常に似ているが、派生なしで使用されるように設計されている。ｐｒｏｔｅｃｔｅｄメソッドが、ｐｕｂｌｉｃに「昇格」される。さらに、Ｒｅｎｄｅｒコールバックはなく、ＩＲｅｔａｉｎｅｄＲｅｎｄｅｒインターフェースを実装する必要はない。この故に、ＲｅｔａｉｎｅｄＶｉｓｕａｌでＩＲｅｔａｉｎｅｄＲｅｎｄｅｒが実装されないときに似て、内容が、必ず保持（リテイン）される。
【０１１７】
【表１２−１】
2007509426.tif 000017
【０１１８】
【表１２−２】
2007509426.tif 000018
【０１１９】
ＰａｉｎｔｉｎｇＶｉｓｕａｌも提供される。
【０１２０】
【表１３−１】
2007509426.tif 000019
【０１２１】
【表１３−２】
2007509426.tif 000020
【０１２２】
ＲｅｔａｉｎｅｄＶｉｓｕａｌは、保持された命令ストリームを追加するが、ＰａｉｎｔｉｎｇＶｉｓｕａｌは、本質的に、サーフェスによってバッキングされる。システムは、性能要件が満たされる限り、サーフェスを仮想化し、レンダリング命令を保つことができる。この故に、サーフェスは、ユーザによってアクセス可能でない。
【０１２３】
ＲｅｔａｉｎｅｄＶｉｓｕａｌに対するＰａｉｎｔｉｎｇＶｉｓｕａｌの相違の１つが、このメソッドが、アニメーションを許可しないＳｔａｔｉｃＤｒａｗｉｎｇＣｏｎｔｅｘｔを提供することである。アニメートされる引数がどこかで使用される場合に、例外が送出される。もう１つの相違は、「Ａｐｐｅｎｄ」が、メモリコストに関してはるかに安価に命令ストリームを増大させることである。さらに、本質的にユーザに対してハードクリップを設定するＰａｉｎｔｉｎｇＢｏｕｎｄｓが、要求され、必要である。これによって、このビジュアルの内容の境界が定められるが、Ｃｌｉｐは、このビジュアルおよびその子のすべての内容をクリッピングするので、これがｃｌｉｐプロパティと異なることに留意されたい。ＲｅｎｄｅｒＣｏｒｅ（ＩＲｅｔａｉｎｅｄＶｉｓｕａｌ．Ｒｅｎｄｅｒに類似する）も、実装され、解像度が変化する場合またはシステムがなんらかの理由で内容の再レンダリングを必要とする場合に、ユーザが、この機構を提供する。
【０１２４】
ＰａｉｎｔｉｎｇＶｉｓｕａｌは、サーフェスによるこのビジュアルの明示的バッキングがないので、潜在的にＳｕｒｆａｃｅＶｉｓｕａｌよりはるかに軽量である。その代わりに、これは、サーフェスによってバッキングされる、どこかより低い点にあるディスプレイツリー内のノードである。
【０１２５】
ＳｕｒｆａｃｅＶｉｓｕａｌを達成するために、ユーザは、ＲｅｔａｉｎｅｄＶｉｓｕａｌを作成し、ＤｒａｗＩｍａｇｅを呼び出し、その後、場面の背後で画像を変更しなければならない。その場合に、ユーザは、システムにコールバックさせるのではなく、ラスタ化を明示的に制御している。画像を直接に操作するための即時モードＡＰＩがある。このＡＰＩを用いると、ユーザが、画像を操作するＳｔａｔｉｃＤｒａｗｉｎｇＣｏｎｔｅｘｔを得られるようになる。ＳｕｒｆａｃｅＶｉｓｕａｌのＡＰＩが、ｈＷｎｄ、ＤＵｓｅｒ  Ｇａｄｇｅｔ、またはＴｒｉｄｅｎｔディスプレイツリーノードに似ていることに留意されたい。内容の「付加」（実際には、既にあるものに対して合成される小さいデルタの作成）は、安価な動作である。概して、ＲｅｔａｉｎｅｄＶｉｓｕａｌと異なって、内容の付加に関するメモリペナルティはなく、ＲｅｎｄｅｒＡｐｐｅｎｄによって命令ストリームがどんどん長くなり、潜在的に指数関数的増大につながる。このビジュアルをバッキングできるサーフェスが、現れ、消える可能性があるので、ビジュアルは、「オンデマンド」ＲｅｎｄｅｒＣｏｒｅ仮想を実装する必要がある。
【０１２６】
ＰａｉｎｔｉｎｇＶｉｓｕａｌの主な使用シナリオは、主にＷＭ＿ＰＡＩＮＴペインティングモデルを中心にして構成されたアプリケーションコードの移植である。これは、ほとんど変化せず、密である静的内容にも有用である。ＰａｉｎｔｉｎｇＶｉｓｕａｌを、メタファイルまたは真のサーフェスによってバッキングできることに留意されたい。システムは、例えばメモリおよび性能の懸念に基づいて、どれが適当であるかをランタイムに判断することができる。しかし、ある点を過ぎると、新しい内容の付加が、メモリの追加コストを引き起こさないことが保証される。システムは、必要に応じてメタファイルとサーフェス記憶の間で切り替えることができる。
【０１２７】
（トップレベルＭＩＬオブジェクト）
すぐに理解されるように、通常のウィンドウありのシナリオでの演算のために、様々なオブジェクトが設けられる。これらが、必ずしも正式のクラスでない（例えば、明示的なスケジューラインターフェースまたはスケジューラオブジェクトがない）ことに留意されたい。
【０１２８】
そのようなオブジェクトの１つに、ビジュアルツリーが含まれ、これは、描画される主要な内容を含むオブジェクトである。コントロールは、このツリーのビジュアルから直接に派生する。ビジュアルは、装置独立であり、コンテキスト独立である。
【０１２９】
レンダ対象は、ビジュアルが描画される装置である。このオブジェクト（例えば画面）は、それ自体のダーティ機構または無効化機構を有することができ、この機構は、レガシｈＷｎｄによるビジュアルシステムをバッキングするのに必要である。様々なレンダ対象に、ウィンドウ内の画面、Ｐｒｉｎｔｅｒ、Ｍｅｔａｆｉｌｅ、Ｓｕｒｆａｃｅ、および、場面のうちで場面の残りと別に描画される部分である「サブウィンドウ」が含まれる。これは、クロススレッド描画を可能にする機構であり、下位レベルエンジンの合成可能オブジェクトと同等である。
【０１３０】
他の描画関連オブジェクトに、レンダ対象にビジュアルツリーを描画するように構成されたオブジェクトを含むＶｉｓｕａｌＲｅｎｄｅｒｅｒと、レンダ対象にビジュアルツリーをいつ描画すべきかを知っているＤｉｓｐｌａｙ  Ｓｃｈｅｄｕｌｅｒオブジェクトが含まれる。Ｔｉｍｅ  Ｍａｎａｇｅｒは、タイミングノードの組のコンテキストオブジェクトであり、スケジューラがそれに対してティックを呼び出すオブジェクトである。
【０１３１】
次は、画面に描画するコントロールの例のフローである。
【０１３２】
１．ユーザが、ある形でＵｉＣｏｎｔｅｘｔを獲得し、Ｖｉｓｕａｌ  Ｔｒｅｅの変更を開始する。これは、アプリケーションスタートアップ中か、多分ＵＩ入力イベントに応答するものとすることができる。
【０１３３】
２．ダーティ通知が、Ｖｉｓｕａｌツリーを上に伝搬する。ルートビジュアルは、それに関連するビジュアルレンダラがどれであるかを知っており、このダーティ通知を転送する。この通知は、ｐｒｉｖａｔｅである。
【０１３４】
３．ビジュアルレンダラが、ｐｕｂｌｉｃイベントを介して、それが変更され、レンダ対象と同期していないことを報告する。
【０１３５】
４．スケジューラが、この状況をいつどこで修正するかを判断し、描画を行わせる。通常、これは、ワークアイテムをディスパッチャにポストすることによって行われる。しかし、ユーザが、他のことを行うことができる。
【０１３６】
５．ユーザが、ＵｉＣｏｎｔｅｘｔを作り、Ｄｉｓｐａｔｃｈｅｒに実行させる。
【０１３７】
６．Ｄｉｓｐａｔｃｈｅｒが、実行し、スケジューラが延期したワークアイテムを呼び出す（多分、単一コンテキストのすべての延期されたワークアイテムが、合体されている。また、スラッシングを減らすために、レイアウトシステムとのロックステップを実行する可能性が高い）
７．スケジューラが、その主更新ループを実行する
ａ．ＴｉｍｅＭａｎａｇｅｒをティックする
ｂ．とりわけ、レイアウトを実行する
ｃ．ビジュアルレンダラに、レンダ対象に新しい変更をレンダリングするように命令する。レンダラは、
ｉ．ダーティパーツＶｉｓｕａｌ  Ｔｒｅｅをウォークし、内部でキャッシングされた境界ボックスを更新する。
【０１３８】
ｉｉ．レンダリングされるすべての必要な「オンデマンド」ビジュアルを呼び出す（デフォルトで、「オンデマンド」ビジュアルは、その境界として空の長方形を有し、したがって、これらは、レイアウトが実行され、これらをセットアップするまでは呼び出されない）。
【０１３９】
ｉｉｉ．ダーティパーツをもう一度探索し、必要なレンダリング更新を下位レベルグラフィックスシステムに送る。
【０１４０】
ビジュアルシステムが、ディスパッチャについて何も知らないことに留意されたい。この詳細の処理をするのは、スケジューラオブジェクトの責任である。スケジューラは、適当な制御フローを行うことができる。
【０１４１】
さらに、増分ビジュアルレンダラおよびスナップショットビジュアルレンダラという考えがある。ビジュアルが、一時に１つの増分ビジュアルレンダラだけに属することが望ましい場合がある。この制限は、ビジュアル自体に対するデータの効率的なキャッシングに必要である。しかし、レンダ対象へのビジュアルツリー全体の「スナップショットをとる」形を有することも道理に合っている。この場合に、ビジュアルツリーとレンダラの間の持続的な接続はない。これは、高解像度画面グラブを得るか、ビジュアルツリー（画面上の）を直接にプリンタに送るのに使用することができる。
【０１４２】
Ｗｉｎｄｏｗは、上のレンダ対象の役割を演ずる。Ｗｉｎｄｏｗは、ｈＷｎｄの管理される置換物でもある。
【０１４３】
【表１４−１】
2007509426.tif 000021
【０１４４】
【表１４−２】
2007509426.tif 000022
【０１４５】
ウィンドウマネージャコントロールは、このオブジェクトの外部にあるが、プロパティ（例えばＳｉｚｅなど）読取／書込値を作り、位置、ウィンドウタイトルなどの追加プロパティを設けることによって、ＷｉｎｄｏｗＣｏｎｔｅｘｔと一体化することができる。Ｓｉｚｅが、物理的（１／９６インチ（約０．２６５ｍｍ））単位でＷｉｎｄｏｗのサイズを表すことに留意されたい。これは、ピクセルサイズではない。ウィンドウにレンダリングされるデータが、ビデオモード切り替えまたはローカルコンソールからリモートターミナルサーバセッションへの切り替えなど、なんらかの理由で失われる状況があることに留意されたい。
【０１４６】
ＶｉｓｕａｌＲｅｎｄｅｒｅｒおよびＶｉｓｕａｌＭａｎａｇｅｒは、他のオブジェクトであり、レンダ対象にＶｉｓｕａｌのツリーをレンダリングする責任を負う。ＶｉｓｕａｌＲｅｎｄｅｒｅｒは、媒体にレンダリングする単純な「ワンショット」モデルを提供し、ＶｉｓｕａｌＭａｎａｇｅｒは、ビジュアルのツリーと、それがレンダリングされる対象との間の保持された接続を確立する。ＶｉｓｕａｌＭａｎａｇｅｒは、媒体への「増分」レンダリングをサポートする。
【０１４７】
次のコードは、一実施形態で基底ＶｉｓｕａｌＲｅｎｄｅｒｅｒがどのように見えるかの例である。
【０１４８】
【表１５−１】
2007509426.tif 000023
【０１４９】
【表１５−２】
2007509426.tif 000024
【０１５０】
このクラスは、「デフォルト」媒体がないので、パブリックにインスタンス化することができない。ＶｉｓｕａｌＲｅｎｄｅｒｅｒは、ＣｏｎｔｅｘｔＡｆｆｉｎｉｔｙオブジェクトでもある。
【０１５１】
ＢａｃｋｇｒｏｕｎｄＣｏｌｏｒプロパティが設けられる。
【０１５２】
【表１６】
2007509426.tif 000025
【０１５３】
これは、ビジュアルマネージャのデフォルト背景色であり、ＶｉｓｕａｌＭａｎａｇｅｒｓのために透明をデフォルトにすることができる。しかし、一部の媒体（レガシＨＷｎｄへのレンダリングなど）はピクセルごとの透明度をサポートできず、したがって、各ＶｉｓｕａｌＭａｎａｇｅｒが、このプロパティのそれ自体のデフォルトを定義することができる。ほとんどのアプリケーションは、このプロパティを無視し、例えば、システムウィンドウ背景色または透明を設定することができる。
【０１５４】
ＲｏｏｔＶｉｓｕａｌプロパティは、レンダリングに関するルートビジュアルを識別する。
【０１５５】
【表１７】
2007509426.tif 000026
【０１５６】
これは、ｎｕｌｌがデフォルトである。ＲｏｏｔＶｉｓｕａｌプロパティがｎｕｌｌであるときに、ＶｉｓｕａｌＭａｎａｇｅｒは、媒体に背景色を描画する。
【０１５７】
ＲｏｏｔＳｉｚｅプロパティは、仮想単位で、レンダ対象のサイズを返す。例えば、ウィンドウによってバッキングされるＶｉｓｕａｌＭａｎａｇｅｒでは、これがウィンドウのクライアントサイズになる。
【０１５８】
【表１８】
2007509426.tif 000027
【０１５９】
Ｒｅｓｏｌｕｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎも設けられる。
【０１６０】
【表１９】
2007509426.tif 000028
【０１６１】
すべての媒体が、ピクセルによってバッキングされない場合であっても、装置解像度を有することを要求される。例えば、印刷するときに、メタファイルにキャプチャする場合であっても、ＶｉｓｕａｌＭａｎａｇｅｒを介して解像度情報を使用可能にし、その結果、その解像度について内容を最適化できるようにすることが必要である。メタファイルキャプチャの場合に、比較的高いデフォルト解像度を使用することができるが、ユーザに解像度を直接に構成させることに留意されたい。
【０１６２】
ＲｏｏｔＶｉｓｕａｌの最初の「ワールドから装置へ」の変換セットアップは、そのビジュアルの１単位が装置上の１／９６インチ（約０．２６５ｍｍ）と等しくなるようになされる。例えば、１９２ｄｐｉの装置によってバッキングされるＳｃｒｅｅｎＶｉｓｕａｌＭａｎａｇｅｒがある場合に、最初の変換は、ＲｏｏｔＶｉｓｕａｌの座標フレームの１単位が、装置の２単位と等しくなるようにセットアップされなければならない。この場合に、ＲｅｓｏｕｌｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ．ＰｉｘｅｌＳｉｚｅは、（０．５，０．５）を返して、各ピクセルが１側面で１／４８インチ（約０．９２１ｍｍ）であることを示す。
【０１６３】
ＶｉｓｕａｌＭａｎａｇｅｒは、ルートビジュアルおよびレンダ対象への長期接続を確立し、差を追跡する。
【０１６４】
【表２０−１】
2007509426.tif 000029
【０１６５】
【表２０−２】
2007509426.tif 000030
【０１６６】
ＷｉｎｄｏｗＶｉｓｕａｌＭａｎａｇｅｒは、画面に描画する主たる方法である。ＷｉｎｄｏｗＶｉｓｕａｌＭａｎａｇｅｒは、ＷｉｎｄｏｗＣｏｎｔｅｘｔへのＶｉｓｕａｌ  Ｔｒｅｅのレンダリングを管理する。
【０１６７】
【表２１】
2007509426.tif 000031
【０１６８】
（描画コンテキスト）
ＤｒａｗｉｎｇＣｏｎｔｅｘｔ  ＡＰＩは、Ｖｉｓｕａｌを取り込むかＩｍａｇｅＤａｔａにレンダリングされるビジュアル内容を構築する方法に関する、当業者の慣れた「コンテキストベース」プログラミングモデルを提示する。このセクションでは、ＤｒａｗｉｎｇＣｏｎｔｅｘｔクラスならびに、ＤｒａｗｉｎｇＣｏｎｔｅｘｔの獲得およびＲｅｔａｉｎｅｄＶｉｓｕａｌ／ＤｒａｗｉｎｇＶｉｓｕａｌでのビジュアルコンテキストの列挙に必要なクラスおよびエントリポイントを説明する。
【０１６９】
アプリケーションは、ＤｒａｗｉｎｇＣｏｎｔｅｘｔを直接には構築せず、ＤｒａｗｉｎｇＣｏｎｔｅｘｔの公開されるバージョンは、抽象クラスである。ビジュアル内容を置くためにＤｒａｗｉｎｇＣｏｎｔｅｘｔを獲得する方法は、複数ある。これには、ＲｅｔａｉｎｅｄＶｉｓｕａｌ．ＲｅｎｄｅｒＯｐｅｎ（）またはＲｅｔａｉｎｅｄＶｉｓｕａｌ．ＲｅｎｄｅｒＡｐｐｅｎｄ（）が含まれ、これらは、それぞれ、命令が発行される先のＤｒａｗｉｎｇＣｏｎｔｅｘｔを返す。他の方法に、ＩＲｅｔａｉｎｅｄＲｅｎｄｅｒ．Ｒｅｎｄｅｒ（）、ＤｒａｗｉｎｇＶｉｓｕａｌ．ＲｅｎｄｅｒＯｐｅｎ（）、ＤｒａｗｉｎｇＶｉｓｕａｌ．ＲｅｎｄｅｒＡｐｐｅｎｄ（）、およびＰａｉｎｔｉｎｇＶｉｓｕａｌ．ＰａｉｎｔｉｎｇＯｐｅｎ（）またはＰａｉｎｔｉｎｇＶｉｓｕａｌ．ＰａｉｎｔｉｎｇＡｐｐｅｎｄ（）が含まれる（ただし、ＰａｉｎｔｉｎｇＶｉｓｕａｌはアニメーションを処理しない）。ＩｍａｇｅＤａｔａ（またはＩｍａｇｅＤａｔａのサブクラス）は、固定解像度のビットマップサーフェスにレンダリングするためのＤｒａｗｉｎｇＣｏｎｔｅｘｔを返す機構を有する。ＩｍａｇｅＤａｔａも、アニメーションを処理しない。
【０１７０】
次に、ＤｒａｗｉｎｇＣｏｎｔｅｘｔ  ＡＰＩを示す。
【０１７１】
【表２２−１】
2007509426.tif 000032
【０１７２】
【表２２−２】
2007509426.tif 000033
【０１７３】
【表２２−３】
2007509426.tif 000034
【０１７４】
ＤｒａｗｉｎｇＣｏｎｔｅｘｔオブジェクトのメソッドのほとんどは、当業者には自明であるが、ＤｒａｗｉｎｇＣｏｎｔｅｘｔが、ＣｏｎｔｅｘｔＡｆｆｉｎｉｔｙＯｂｊｅｃｔであり、単一のＵＩＣｏｎｔｅｘｔからのみ使用されなければならないことに留意されたい。ＤｒａｗｉｎｇＣｏｎｔｅｘｔオブジェクトは、ＩＤｉｓｐｏｓａｂｌｅでもあり、Ｃ＃での推奨されるパターンが、例えばＲｅｎｄｅｒＯｐｅｎ／Ａｐｐｅｎｄから受け取られる場合に、「ｕｓｉｎｇ」文節でこれらを使用することである。さらに、ＤｒａｗＡｒｃ、ＤｒａｗＰｉｅ、ＤｒａｗＢｅｚｉｅｒ、およびＤｒａｗＰｏｌｙｌｉｎｅなどのメソッドがないことに留意されたい。これらは、関連するＧｅｏｍｅｔｒｙの構築およびＤｒａｗＧｅｏｍｅｔｒｙの使用を必要とする（下で説明する）。
【０１７５】
さらに、Ｐｕｓｈ＊メソッドは複数あるが、Ｐｏｐメソッドは１つだけである。これは、オーバーラップする属性を設けられないことを暗示する。Ｐｕｓｈ＊（）によって確立される属性は、それ相応に構成される。例えば、ＣｌｉｐはＩｎｔｅｒｓｅｃｔｉｏｎ演算子を介して構成され、Ｏｐａｃｉｔｙは乗算演算、ＴｒａｎｓｆｏｒｍはＣｏｍｐｏｓｅＴｒａｎｓｆｏｒｍ演算を介して構成される。
【０１７６】
ユーザは、例えば、ｎｕｌｌのＢｒｕｓｈまたはｎｕｌｌのＰｅｎを用いてＤｒａｗＧｅｏｍｅｔｒｙを呼び出すことができるので、ＢｒｕｓｈおよびＰｅｎの両方についてｎｕｌｌを用いてＤｒａｗＧｅｏｍｅｔｒｙを呼び出すことが有効であるが、何もレンダリングされず、ヒットテストも行われない。
【０１７７】
非アニメート対象で使用されるとき（例えば、ラスタに直接にレンダリングするとき）に描画コンテキストに供給されるアニメーション特性は、時刻０になる（非アニメーション対象が、その代わりに時刻「現在」になることができるが）。これによって、動的ＤｒａｗｉｎｇＣｏｎｔｅｘｔ用に記述されたコードを、アニメーションを処理しないＤｒａｗｉｎｇＣｏｎｔｅｘｔの使用に、より簡単に移行できるようになる。
【０１７８】
「保持された」Ｖｉｓｕａｌの内部の内容の列挙は、その内容を挿入したＤｒａｗｉｎｇＣｏｎｔｅｘｔに密に関連する。Ｖｉｓｕａｌの内容の列挙および／または挿入ストリームの変更は、望まれる場合に、後述するようにＣｈａｎｇｅａｂｌｅ機構を介して実行することができる。全般的な考えは、「プッシュモデル」列挙機構を提供することである。
【０１７９】
ＤｒａｗｉｎｇＣｏｎｔｅｘｔクラス自体は、内容のプッシュモードウォークを登録するインターフェースすなわち、ＤｒａｗｉｎｇＣｏｎｔｅｘｔＷａｌｋｅｒと称するＤｒａｗｉｎｇＣｏｎｔｅｘｔのサブクラス（メソッドのほとんどが抽象メソッドのまま）を提供する。ユーザは、ＤｒａｗｉｎｇＣｏｎｔｅｘｔＷａｌｋｅｒのサブクラスを作成し、インスタンスをＶｉｓｕａｌに渡して列挙を開始する。Ｖｉｓｕａｌは、適当なＤｒａｗｉｎｇＣｏｎｔｅｘｔメソッドをコールバックして、それが有する内容を伝える。ＤｒａｗｉｎｇＣｏｎｔｅｘｔＷａｌｋｅｒは、列挙の進行方法（すなわち、例えば即座に停止しなければならないか否か）を制御するために操作できる状態も提供する。
【０１８０】
次のコードは、ＤｒａｗｉｎｇＣｏｎｔｅｘｔＷａｌｋｅｒオブジェクトの例のコードである。
【０１８１】
【表２３】
2007509426.tif 000035
【０１８２】
ＷａｌｋＣｏｎｔｅｎｔメソッドは、ＤｒａｗｉｎｇＣｏｎｔｅｘｔＷａｌｋｅｒ基底クラスで提供される。
【０１８３】
【表２４−１】
2007509426.tif 000036
【０１８４】
【表２４−２】
2007509426.tif 000037
【０１８５】
ユーザは、これのサブクラスを作り、すべての抽象メソッドを望み通りに実装する。ユーザは、オブジェクトのインスタンスを作成し、そのインスタンスのＷａｌｋＣｏｎｔｅｎｔを呼び出す。ＷａｌｋＣｏｎｔｅｎｔは、Ｖｉｓｕａｌをウォークする際に、適当なメソッドをコールバックする。これらのメソッドの実装のどれであっても、望まれる場合に、ｐｒｏｔｅｃｔｅｄメソッドＳｔｏｐＷａｌｋｉｎｇ（）を呼び出すことによって、探索を停止させることができる。ＶｉｓｕａｌのＤｒａｗｉｎｇＣｏｎｔｅｘｔが、それにレンダリングするためにオープンされているときには、探索を開始することが不正であることに留意されたい。
【０１８６】
オプションによって、探索を進める方法が決定される。
【０１８７】
【表２５】
2007509426.tif 000038
【０１８８】
ＩｎｃｌｕｄｅＡｎｉｍａｔｉｏｎｓが設定されている場合には、ウォーカは、アニメーションコンテンツを用いて適当なメソッドを呼び出す。そうでない場合には、内容の瞬間的な値が、ＤｒａｗｉｎｇＣｏｎｔｅｘｔＷａｌｋｅｒメソッドに供給される。
【０１８９】
ＤｒａｗｉｎｇＣｏｎｔｅｘｔは、ＤｒａｗｉｎｇＣｏｎｔｅｘｔＷａｌｋｅｒクラスを介して返される順序および構造で、Ｖｉｓｕａｌに内容の順序または構造を供給できるＰｒｅｓｅｒｖｅＲｅａｄｂａｃｋＯｒｄｅｒ  Ｂｏｏｌｅａｎを有する。これは、偽をデフォルトとするが、順序を保存することが重要であるときには、内容を挿入する前に真を設定することができる。例えば、前述したように、ＤｒａｗＧｅｏｍｅｔｒｙに、ｎｕｌｌのＢｒｕｓｈおよびｎｕｌｌのＰｅｎを与えることができる。ＰｒｅｓｅｒｖｅＲｅａｄｂａｃｋＯｒｄｅｒが真である場合に、この命令が、Ｖｉｓｕａｌの状態で維持される必要がある。ＰｒｅｓｅｒｖｅＲｅａｄｂａｃｋＯｒｄｅｒが偽である場合に、実装は、この命令を破棄することができる。
【０１９０】
このプッシュ手法に、他の型安全（ｔｙｐｅ−ｓａｆｅ）手法に対する多数の長所があり、この長所には、列挙の出力を反映する型の並列群の必要がないことと、コールバックインターフェースでのヒープ割り当ての必要が必ずしも存在しないことが含まれる。さらに、渡されるオブジェクトを作成せずにメソッドを直接に呼び出すことができ、ＤｒａｗｉｎｇＣｏｎｔｅｘｔインターフェースが既に存在し、ウォークを可能にするためにＶｉｓｕａｌ自体の側の追加のＡＰＩが不要である。
【０１９１】
ビジュアル内容の変更が、もう１つの考慮事項である。ＶｉｓｕａｌＣｏｎｔｅｎｔへの変更を表す形の１つが、リソース（Ｐｅｎ、Ｂｒｕｓｈなど）を使用することであり、このリソースは、本明細書の説明では、Ｃｈａｎｇｅａｂｌｅのサブクラスであり、ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅ＝＝ＵｓｅＳｔａｔｕｓ．ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅである。これによって、ＤｒａｗｉｎｇＣｏｎｔｅｘｔに送られる管理される構造体に含まれるデータへの参照を、アプリケーションによって維持できるようになる。これは、変更を行えるようにする均一な形を表し、これらのオブジェクトが、明示的に設定された既知の状態であるので、実装は、どのオブジェクトが変更される可能性が高いかを知っている。例えば、命令の順序の変更、あるいは命令の追加または削除が可能でない（ＲｅｎｄｅｒＡｐｐｅｎｄ（）が追加のために存在するが）ことに留意されたい。
【０１９２】
（Ｄｒａｗｉｎｇ）
Ｄｒａｗｉｎｇクラスには、描画コマンドの集合が含まれる。これは、ＤｒａｗｉｎｇＶｉｓｕａｌに保管される内容と正確に同等であり、ＤｒａｗｉｎｇＣｏｎｔｅｘｔによって構築される。Ｄｒａｗｉｎｇは、ミュータブルでないときにコンテキストアフィニティがなく、したがって、これおよび関連するクラスＤｒａｗｉｎｇＢｒｕｓｈは、それ自体がミュータブルでないときに、コンテキストにまたがって、デフォルトプロパティシートで使用することができる。
【０１９３】
Ｄｒａｗｉｎｇは、子を反復するか親を見つける手段を備えないという点で階層を直接にはサポートしないが、ＤｒａｗｉｎｇＣｏｎｔｅｘｔを介して、Ｄｒａｗｉｎｇを別のＤｒａｗｉｎｇに描画することができる。Ｄｒａｗｉｎｇを、ＤｒａｗＤｒａｗｉｎｇ（Ｄｒａｗｉｎｇ）を介してＤｒａｗｉｎｇＣｏｎｔｅｘｔに描画することができ、ＤｒａｗｉｎｇＢｒｕｓｈの内容記述として使用することができる。
【０１９４】
Ｄｒａｗｉｎｇは、完全にアニメーション可能であり、ＲｅｔａｉｎｅｄＶｉｓｕａｌと同一の形でリードバック／反復をサポートする。
【０１９５】
【表２６】
2007509426.tif 000039
【０１９６】
（変更可能なパターン）
説明のために、本発明を、主に、グラフィックス場面内の例のオブジェクトが構築され、使用され、変更されるプログラミング環境に関して説明する。しかし、理解されるように、本発明は、グラフィックス関連プログラミング環境でかなりの利益を提供するが、本発明は、グラフィックス関連プログラミング環境に制限されるのではなく、より一般的に、多数の他の種類のプログラミング環境に適用される。
【０１９７】
一実施形態で、本発明は、例えばＳｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｃｈａｎｇｅａｂｌｅなど、共通の基底クラスから派生する型の単一の集合を提供する。Ｃｈａｎｇｅａｂｌｅクラスから派生し、これによって、Ｃｈａｎｇｅａｂｌｅが提供する値−型セマンティクスを得ることによって、すべてのクラスをミュータブルにすることができる。例えば、グラフィックスプログラミングでは、前述の特許文献６に全般的に記載されているように、オブジェクトモデルに、Ｂｒｕｓｈ、Ｐｅｎ、Ｇｅｏｍｅｔｒｙ、ＦｌｏａｔＡｎｉｍａｔｉｏｎ、ＧｒａｄｉｅｎｔＳｔｏｐ、Ｓｅｇｍｅｎｔなどが含まれる。例えば、描画ブラシの階層を、次のようなものにすることができる。
【０１９８】
Object:Changeable:Animatable:Brush:TileBrush:DrawingBrush.
基本的な使用において、ｃｈａｎｇｅａｂｌｅオブジェクトに、次のプロパティおよびメソッドが含まれる。
【０１９９】
【表２７】
2007509426.tif 000040
【０２００】
ＩｓＣｈａｎｇｅａｂｌｅプロパティは、その現在値に応じて、ｃｈａｎｇｅａｂｌｅオブジェクトが変更可能であるか否かを指定する。例えば、ｂｒｕｓｈの不透明度プロパティを設定する試みは、そのｂｒｕｓｈオブジェクトのＩｓＣｈａｎｇｅａｂｌｅプロパティが真と等しい場合に限って成功する。そうでない場合には、例外が送出される。構築されるときに、ｃｈａｎｇｅａｂｌｅオブジェクトは、デフォルトでＩｓＣｈａｎｇｅａｂｌｅプロパティに真を設定され、したがって、即座に変更可能である。
【０２０１】
図１４に示すように、アプリケーションプログラムから発する関数呼出しを介するなど、ｃｈａｎｇｅａｂｌｅクラス１４０４に向けられた要求１４０２が、受け取られる。一般に、状態機械１４０８を含む要求ハンドラ１４０６は、後述するように、要求を処理し、現在のプロパティ状態に基づいて、適当なプロパティ状態と共にデータ構造をクローン化されたコピー１４１２にクローンを作成することによって、サポートするデータ構造１４１０を介して状態およびオブジェクトデータを維持する。現在のプロパティ状態からは許可されない推移を要求が求めるときなどに、例外１４１４を送出することができる。プロパティ状態は、下で図１５から１７を参照して説明する。
【０２０２】
ｃｈａｎｇｅａｂｌｅクラスに向けられた関数呼出しを、直接にまたは間接に処理できることに留意されたい。例えば、図１４の要求ハンドラ１４０６に、状態機械へのインターフェースを提供するＡＰＩ群を含めることができる。その代わりに、要求ハンドラ１４０６に、あるオペレーティングシステムで受け取られた要求を別のオペレーティングシステムによって処理されるＡＰＩ呼出しに変換するミドルウェアコードを含めることができる。したがって、本明細書で使用される要求は、要求ハンドラを介して、実際の状態機械処理がどこで行われ、データ構造およびクラスがどこで提供されるかにかかわらずに、要求された挙動が行われることを「引き起こす」。
【０２０３】
この形で、（他の機構の中でも）、アプリケーションが、「ｎｅｗ」要求を介してｃｈａｎｇｅａｂｌｅオブジェクトを構築し、それに値を設定し、それを使用し、値を設定することを継続し、使用を継続することができる。
【０２０４】
次のコードは、アプリケーションがどのように単色のブラシ（ｓｃｂ）を作成し、単色（赤）を有するようにブラシを変更し、ブラシを使用してボタンの背景に赤の色を付けるかの例を示す。
【０２０５】
【表２８】
2007509426.tif 000041
【０２０６】
値を「使用する」と言う概念は、特定の意味を有する、すなわち、値は、ある条件の下でのみ使用について検討される。この条件に、値がＰｒｏｐｅｒｔｙ  Ｓｙｓｔｅｍプロパティに設定されるとき、値がより複雑なｃｈａｎｇｅａｂｌｅ内のサブオブジェクトとして使用されるとき、および値がＤｒａｗｉｎｇＣｏｎｔｅｘｔコマンドで使用されるときなどが含まれる。システムエクステンダが、「使用」として見なすオブジェクトの変更可能な状態を変更するｃｈａｎｇｅａｂｌｅオブジェクトの使用の他の例を簡単に定義できることに留意されたい。
【０２０７】
値が、これらの種類の条件付きの使用の１つとして用いられるときに、ユーザ−モデルの展望から、値のクローンが作られ、そのクローンは、ＩｓＣｈａｎｇｅａｂｌｅプロパティに偽を設定される。実際には、クローンが必ずしも作成されず、作成されるときには、必ずしも（後述するように、オブジェクト階層内で）深いコピーでないことに留意されたい。それにもかかわらず、モデルの展望からは、クローンが作られると考えることが適当であり、したがって、本明細書で使用される「クローン」の概念は、実際に作成されるクローン、部分的に作成されるクローン、および／または必ずしも作成されないがモデルの観点から論理的に作成されるクローンが含まれる。クローンは、実際に使用されるものであり、デフォルトで、クローンを変更することはできない。
【０２０８】
上記で示したように、ｃｈａｎｇｅａｂｌｅオブジェクトには、Ｃｏｐｙ（）およびＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）を含むメソッドも含まれる。Ｃｏｐｙ（）メソッドへの明示的な呼出しによって、そのｃｈａｎｇｅａｂｌｅのコピーが作成され、コピーのＩｓＣｈａｎｇｅａｂｌｅプロパティに真が設定される。この呼出しは、メソッドが呼び出されたオブジェクトを変更しない。ＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）メソッドは、どのｃｈａｎｇｅａｂｌｅに対しても呼び出すことができ、ＩｓＣｈａｎｇｅａｂｌｅプロパティを変更して、偽にする（既に偽でない場合。偽の場合にはこの呼出しは何もしない）。
【０２０９】
上の機構は、プロパティを置換するパターンを容易にする。ｃｈａｎｇｅａｂｌｅオブジェクトを変更するためには、ＩｓＣｈａｎｇｅａｂｌｅプロパティ値を真にする必要がある。オブジェクトの条件付きの使用によって、ｃｈａｎｇｅａｂｌｅでないクローンが作成されるので、そのオブジェクトは、Ｃｏｐｙ（）メソッドを介してコピーされ、変更され、使用される必要がある。これによって、効果的に、存在した最初のオブジェクトが、オリジナルの変更されたコピーである新しいオブジェクトに置換される。これの例を、下記で示す。使用中のｃｈａｎｇｅａｂｌｅが、使用されたｃｈａｎｇｅａｂｌｅであり、したがって、上の定義によれば、ＩｓＣｈａｎｇｅａｂｌｅプロパティに使用時に偽が設定されるので、変更可能でないことに留意されたい。したがって、そのｃｈａｎｇｅａｂｌｅが変更されるのではなく、ｃｈａｎｇｅａｂｌｅが、コピーされ、置換される。ｃｈａｎｇｅａｂｌｅに関して、型の単一の集合だけがあり、これが、プログラミングの展望からははるかに望ましいことに留意されたい。さらに、真のミュータビリティは、後述するように追加のプロパティによって提供される。
【０２１０】
前述したように、ブラシを作成し、変更し、使用することは、簡単である。描画動作での単純な使用の例を、下に示す。
【０２１１】
【表２９】
2007509426.tif 000042
【０２１２】
上の命令を実行すると、１つの赤い長方形と１つの緑の長方形が描画される。「ｓｃｂ」が、実際には使用のたびにクローンを作成されることに留意されたい。
【０２１３】
色が、あるステップから別のステップに（例えば線形に）変化する、リニア勾配（ｌｉｎｅａｒ  ｇｒａｄｉｅｎｔ）ブラシ（ｌｇｂ）を使用するより複雑な構成を、下に示す。
【０２１４】
【表３０】
2007509426.tif 000043
【０２１５】
この場合に、この処理は、値（ＧｒａｄｉｅｎｔＳｔｏｐ）を作り、より複雑な値の定義にそれらの値を使用している。
【０２１６】
ボタン（Ｂｔｎ）背景の不透明度（０から１までの範囲とすることができる）を０．４に変更することを対象とするもう１つの例を検討されたい。この特定の使用では、Ｂａｃｋｇｒｏｕｎｄがオブジェクトにコピーされ、そのＩｓＣｈａｎｇｅａｂｌｅプロパティに真の値が設定され、背景が変更され、セットバックされる。
【０２１７】
【表３１】
2007509426.tif 000044
【０２１８】
最後の行の「Ｂｔｎ．Ｂａｃｋｇｒｏｕｎｄ」への割り当てが、あった可能性がある継承された値またはプロパティシート値を分離することに留意されたい。
【０２１９】
オブジェクト階層内のより深い変更は、ユーザには、浅い変更と異ならないように見える。
【０２２０】
【表３２】
2007509426.tif 000045
【０２２１】
Ｃｏｐｙ（）が、最上位レベルオブジェクトのみに対して呼び出される必要があり、個々のＧｒａｄｉｅｎｔＳｔｏｐに対して呼び出される必要がないことに留意されたい。これは、システムが、真のＩｓＣｈａｎｇｅａｂｌｅプロパティを有するオブジェクトのサブオブジェクト自体が、アクセスされるときにそのＩｓＣｈａｎｇｅａｂｌｅに真を設定されることの保証を処理するからである。
【０２２２】
図１５に、新規作成のときの、ＩｓＣｈａｎｇｅａｂｌｅプロパティに真が設定された状態で始まる、ｃｈａｎｇｅａｂｌｅオブジェクトの基本的な使用の状態を表す状態図を示す。一般に、実線の矢印は、現在の状態から対象状態に推移するオブジェクトの状態を示し、破線の矢印は、オブジェクトを同一の状態にするが、対象状態の新しいオブジェクトを作成する演算を示す。この状態図には、２つの状態があり、推移は、Ｃｏｐｙ（）またはＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）のいずれかが呼び出されるときと、前述したように、使用と見なされる形でオブジェクトが使用されるときに発生する。どちらの状態からでもＣｏｐｙ（）メソッドを呼び出すことによって、そのＩｓＣｈａｎｇｅａｂｌｅプロパティに真を設定された新しい値がもたらされ、ＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）を呼び出すことによって、ＩｓＣｈａｎｇｅａｂｌｅに偽を設定された対象値がもたらされることに留意されたい。
【０２２３】
上の説明は、２つの状態と、Ｃｏｐｙ（）およびＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）メソッドと、Ｃｈａｎｇｅａｂｌｅ値の「使用」と言う概念を有する基本的な使用を説明する、単純で自己矛盾のないモデルを提示する。しかし、変更に関して、上の変更の例は、置換すなわち、既存アイテムをコピーし、その場で変更し、コピーバックするという概念に基づく。これは、ヒープ割り当て（行われる変更の深さと、浅いクローンに関するオブジェクト自体の広さに依存して、潜在的に大きくなる可能性がある）ならびに変更される属性へのパスを見つける機構を維持するためのプログラマに対する追加の重荷を暗示する。
【０２２４】
本発明の態様によれば、値の真のミュータビリティという概念のサポートを追加するために、型ＵｓｅＳｔａｔｕｓのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅという名前のもう１つのプロパティを、モデルに追加する。単一プロパティモデルでミュータビリティを妨げる基本的な問題が、偽と等しいＩｓＣｈａｎｇｅａｂｌｅプロパティの結果の値を無条件にもたらす値の条件付きの使用であることに留意されたい。ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティによって、この問題が解決される。
【０２２５】
【表３３】
2007509426.tif 000046
【０２２６】
デフォルトで、ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティは、ＵｓｅＳｔａｔｕｓ．Ｕｎｃｈａｎｇｅａｂｌｅであるが、ＵｓｅＳｔａｔｕｓ．ＣｈａｎｇｅａｂｌｅＣｏｐｙをセットすることができ、これによって、これが設定される値の使用が、ＩｓＣｈａｎｇｅａｂｌｅプロパティに真を設定されたクローンオブジェクトの作成をもたらす。その結果、オブジェクト値を、追加のヒープ割り当てなしでその場で変更することができる。
【０２２７】
さらに、このモデルでは、使用中の値を変更できるので、そのような変更が行われるときに、単純なｃｈａｎｇｅｄイベントを介する通知が提供される。さらに、オブジェクトは、もはや非ミュータブルでないので、ＵＩＣｏｎｔｅｘｔメンバを介してコンテキストアフィニティが提供される。オブジェクトがミュータブルであるときに、これがｎｕｌｌ値を有することに留意されたい。そうでない場合には、オブジェクトは、それを作成したＵＩＣｏｎｔｅｘｔに属する。結果のＣｈａｎｇｅａｂｌｅクラス定義は、次のようになる。
【０２２８】
【表３４】
2007509426.tif 000047
【０２２９】
単純で浅いミュータビリティの上の例によって、Ｂｒｕｓｈの不透明度を変更する要件を説明したが、コードは、不透明度が変更されるたびに実行される必要があった。対照的に、ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティに基づくミュータビリティ機構では、まず、Ｂｔｎ．Ｂａｃｋｇｒｏｕｎｄ自体が、真のＩｓＣｈａｎｇｅａｂｌｅプロパティ値を有する。
【０２３０】
【表３５】
2007509426.tif 000048
【０２３１】
上記では、（条件付き使用において）ＵｓｅＳｔａｔｕｓ．ＣｈａｎｇｅａｂｌｅＣｏｐｙのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅを有する値が使用され、したがって、結果自体が変更可能になる。セットアップされたならば、プログラマは、次の例のように、望み通りに変更を行うことができる。
【０２３２】
【表３６】
2007509426.tif 000049
【０２３３】
プログラマは、望み通りに何度でもそのような変更を行うことができ、その変更は、後続設定でのオブジェクト割り当てなしに、直接に行われる。
【０２３４】
上の例で、最初にＢｔｎ．Ｂａｃｋｇｒｏｕｎｄを作る方法が説明されず、したがって、そのコピーを、Ｃｏｐｙ（）メソッドを介して作る必要があることに留意されたい。プログラマが、変更される背景を作成することを求める計画的なミュータビリティの状況では、次の例のように、これを直接に行うことがよりよい形である場合がある。
【０２３５】
【表３７】
2007509426.tif 000050
【０２３６】
ここで、ブラシが、当初にＳｔａｔｕｓＯｆＮｅｘｔＵｓｅがＵｓｅＳｔａｔｕｓ．ＣｈａｎｇｅａｂｌｅＣｏｐｙと等しいものとして作成されたので、プログラマは、望むときにいつでも不透明度を指定することができる（Ｂｔｎ．Ｂａｃｋｇｒｏｕｎｄ．Ｏｐａｃｉｔｙ＝．．．）。
【０２３７】
ミューテーションベースのモデルではなく置換ベースのモデルを使用することが、上の例を与えられれば特に困難でないことに留意されたい。これは、変更が、第１レベルで行われるからであり、ミューテーションではなく置換を必ず行うことが、禁止的に高価には見えない場合があるからである。実際に、限られたミュータビリティだけが望まれるとき、これは、有効な技法である。しかし、変更が、オブジェクトのより深い値に対して行われるときには、ミューテーションモデルが、明らかに優れている。
【０２３８】
そのような深いミュータビリティの例として、プログラマが、第７ストップ（ｌｇｂ．Ｓｔｏｐｓ［６］）の色を変更することを繰り返して求める、ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ（ｌｇｂ）を考慮されたい。プログラマは、上と同一の命令を使用して、ミュータブルバージョンをＢｔｎ．Ｂａｃｋｇｒｏｕｎｄにインストールすることができる。
【０２３９】
【表３８】
2007509426.tif 000051
【０２４０】
その後、プログラマは、所望の変更を繰り返して行うことができる。
【０２４１】
【表３９】
2007509426.tif 000052
【０２４２】
プログラマは、「ｌｇｂ」変数に１回アクセスし、それを保管し、その後、繰り返してそれに設定することができ、これは非常に効率的である。
【０２４３】
図１６は、ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティによって表される追加の状態が追加された、図１５の状態図の拡張である。モデルが、わずかに複雑になっていることに留意されたい。というのは、図１６の基本状態図が、２つの状態と７つの推移を有するが、ミュータビリティ状態図が、３つの状態と１１個の推移を有するからである。図１５からわかるように、重要な追加は、（ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅ＝＝ＣｈａｎｇｅａｂｌｅＣｏｐｙ）状態と、その状態から出る「使用」推移であり、これは、ＩｓＣｈａｎｇｅａｂｌｅプロパティ値に真を設定された新しいコピーをもたらす。
【０２４４】
図１５に示すように、Ｃｏｐｙ（）メソッドの呼出しは、ＩｓＣｈａｎｇｅａｂｌｅプロパティが真と等しい新しい値をもたらし、ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティにＵｎｃｈａｎｇｅａｂｌｅが設定される。同様に、ＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）メソッドの呼出しは、ＩｓＣｈａｎｇｅａｂｌｅプロパティに偽が設定された対象値をもたらす。ミュータビリティを介して柔軟性が追加されているが、これらの定数が変更されていないことに留意されたい。
【０２４５】
後続の変更が真に明確に定義されていないか、明示的に禁止されているので、ＣｈａｎｇｅａｂｌｅＣｏｐｙと等しいＳｔａｔｕｓＯｆＮｅｘｔＵｓｅとしての使用が許容されない状況がある。この例に、共有されるデフォルトスタイルシートの値の変更、またはローカルでないプロパティエンジンのプロパティの設定の試みが含まれる。そのような状況で、そのような使用を禁止するサブシステムは、例外を送出することを選択するか、値そのものを変更不能にする。何が起きたかをプログラマに対してより明瞭に示し、これによって後の混乱が避けられるので、例外を送出することが推奨される。
【０２４６】
さらに、ｃｈａｎｇｅａｂｌｅオブジェクトを変更不能にすることができない状況がある。その例には、基礎になるビジュアルを変更から制限できず、したがって、ＶｉｓｕａｌＢｒｕｓｈを「変更不能」と述べることは無意味であるＶｉｓｕａｌＢｒｕｓｈ（前述の特許文献６に記載のように）が含まれる。ＡｎｉｍａｔｉｏｎおよびＶｉｄｅｏＤａｔａ（これらは時間に伴って変化するので）も、その例である。そのようなオブジェクトに対してＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）を呼び出す試みは、例外を送出するか、さらに悪いことに、オブジェクトの一部が変更不能にされ、他の部分は変更不能にならないので、オブジェクトが不正な状態になる場合がある。この問題は、もう１つのプロパティＣａｎＭａｋｅＵｎｃｈａｎｇｅａｂｌｅを介して回避することができる。このプロパティが「真」の値を返す場合には、ＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）が成功することが保証される（この２つの呼出しの間にオブジェクトに対する変更が行われないならば）。
【０２４７】
ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅとＣａｎＭａｋｅＵｎｃｈａｎｇｅａｂｌｅの間に時々発生する、セマンティクスの衝突がある。ＣａｎＭａｋｅＵｎｃｈａｎｇｅａｂｌｅが偽と等しい場合に、次の使用を変更不能にすることができないので、ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅのＵｓｅＳｔａｔｕｓ．Ｕｎｃｈａｎｇｅａｂｌｅの値は、実際には意味をなさない。したがって、ＣａｎＭａｋｅＵｎｃｈａｎｇｅａｂｌｅが偽と等しいときにＳｔａｔｕｓＯｆＮｅｘｔＵｓｅが照会されるときには、ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅは絶対にＵｓｅＳｔａｔｕｓ．Ｕｎｃｈａｎｇｅａｂｌｅを返さない。その代わりに、他の形で以前にＵｓｅＳｔａｔｕｓ．Ｕｎｃｈａｎｇｅａｂｌｅを返したときに、ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅはＵｓｅＳｔａｔｕｓ．ＣｈａｎｇｅａｂｌｅＣｏｐｙを返す。
【０２４８】
上記は、ｃｈａｎｇｅａｂｌｅ（ＩｓＣｈａｎｇｅａｂｌｅが真と等しい）オブジェクトのすべての（条件付きの）使用が、作られるオブジェクトのコピーをもたらし、ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅの値に応じて、その「使用」自体が変更可能であるかそうでないモデルを表す。上のモデルが提供しないものは、複数の場所での値の使用と、その値への共有される参照の維持である。例えば、上のモデルでは、プログラマは、ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈを作成し、２つのＢｕｔｔｏｎコントロールで使用し、両方のコントロールに影響するために１度にＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈを変更することができない。そうではなく、プログラマは、これを２回使用し、コントロールからブラシを得、それぞれを独立に設定する必要がある。一般に、このモデルは、プログラマにとって、最も期待され、かつ／または最も驚かれないものになるが、追加の機能性が望ましいシナリオがある。
【０２４９】
そのようなシナリオが、Ａｎｉｍａｔｉｏｎにあり、この場合には、プログラマが、それぞれが同一のタイムラインに応答するｎ個の要素を有する場面を作成することを望む場合に、そのタイムラインのクローンをｎ回作成する必要があり、ＢｅｇｉｎＩｎ（）をｎ回実行することを要求される。性能および効率の観点の両方ならびにプログラミングモデルの利便性からのよりよい方法は、単一のタイムラインへの参照を共有し、それに対してＢｅｇｉｎＩｎ（）を呼び出し、必要に応じて伝搬させることである。
【０２５０】
このシナリオを可能にするために、第３の値ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅが、ＵｓｅＳｔａｔｕｓ列挙に設けられる。ＵｓｅＳｔａｔｕｓは、次のようになる。
【０２５１】
【表４０】
2007509426.tif 000053
【０２５２】
ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅにＵｓｅＳｔａｔｕｓ．ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅを設定されたｃｈａｎｇｅａｂｌｅオブジェクトが（条件付きの形で）使用されるとき、その値は、もはやコピーされない。そうではなく、既存の値への参照が渡され、その値（あるいはその前または後に渡される参照）に対する後続の変更が、使用の結果に影響する。言い換えると、ｃｈａｎｇｅａｂｌｅ値が、潜在的に任意の数の使用によって共有される。
【０２５３】
次のコードは、要素レベル使用の例である。
【０２５４】
【表４１】
2007509426.tif 000054
【０２５５】
上の例では、１つは赤、１つは青の２つの長方形を生成する単純な描画動作を説明した。
【０２５６】
【表４２】
2007509426.tif 000055
【０２５７】
これは、望まれた挙動である。しかし、プログラマが、その代わりにブラシの共有と、変更可能であることを望む場合には、次の命令を使用することができる。
【０２５８】
【表４３】
2007509426.tif 000056
【０２５９】
ここでは、両方の長方形が緑である。後に、色が変更され、例えばｓｃｂ．Ｃｏｌｏｒ＝Ｃｏｌｏｒｓ．Ｙｅｌｌｏｗの場合に、両方の長方形が、黄色になる。ｃｔｘ．ＤｒａｗＲｅｃｔａｎｇｌｅ（．．．）が、即時モード描画コマンドに見えるが、実際には、保存され、後に表示されるディスプレイリスト／メタファイルを作成していることに留意されたい。
【０２６０】
ユーザモデルの観点からは、ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅモードによって、ｃｈａｎｇｅａｂｌｅオブジェクトを使用する当事者が、その値のすべての変更について通知されることが保証される。これは、「Ｃｈａｎｇｅｄ」イベントを介して行われ、このイベントは、他のイベントとして、マルチキャスト委任（ｍｕｌｔｉｃａｓｔ  ｄｅｌｅｇａｔｅ）である。実装するためにシステムは、単一の通知シンクを有する複数の使用が、使用ごとにシンクに通知しないことを保証する必要がある。さらに、クリーンアップ機構は、シンクに接続された使用が除去されるときにそのシンクだけが除去されるように、アイテムを除去するときの要件を有する。これを行う手法の１つが、委任の参照カウントである。現在の実装は、ｐｒｉｖａｔｅデータ構造体、例えばＲｅｆＣｏｕｎｔｅｄＭｕｌｔｉｃａｓｔＥｖｅｎｔＨａｎｄｌｅｒを介してこの要件を達成することができる。
【０２６１】
図１７は、図１５および１６に基づくが、ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅ状態を（ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティのもう１つの設定を介して）追加された状態図である。本発明の態様に合わせて、ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅ状態およびそのノードから出る使用推移で、コピーがつくられないことに留意されたい。そうではなく、条件付きの使用は、次の使用プロパティの状況が、変更可能な参照状態に留まることをもたらし、これによって、真のミュータビリティがもたらされる。さらに、図１７は、図１５および１６より複雑であるが、Ｃｏｐｙ（）メソッドおよびＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）メソッドの挙動が、同一のままであり、Ｃｏｐｙ（）メソッドが、真のＩｓＣｈａｎｇｅａｂｌｅプロパティおよびＵｎｃｈａｎｇｅａｂｌｅのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティを有する新しい値オブジェクトをもたらし、ＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）メソッドが、偽のＩｓＣｈａｎｇｅａｂｌｅプロパティを有する対象値オブジェクトをもたらすことに留意されたい。
【０２６２】
型の単一集合の利益と共に、本発明が、プログラマにかなりの柔軟性を提供することに留意されたい。例えば、ミュータブルでない値のほうがリソースの消費が少ないので、アプリケーションによって普通に構築される値のほとんどが、ミュータブルではない。しかし、上で説明したように、ミュータビリティが使用可能であり、プログラマに、値、特に深い値を高性能に変更する強力で直観的な形が与えられる。図１７には示されていないが、新しい型が作成される状態（真のＩｓＣｈａｎｇｅａｂｌｅプロパティおよびＵｎｃｈａｎｇｅａｂｌｅのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティ）が、１つの可能なデフォルト状態にすぎないことにも留意されたい。したがって、代替の実施形態で、型を、ミュータブルな値をデフォルトにするなど、作成の後に別の状態、例えば真のＩｓＣｈａｎｇｅａｂｌｅプロパティとＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティ）にすることができる。
【０２６３】
本発明の動作の説明に移ると、本発明は、ドットダウン（ｄｏｔｔｉｎｇ−ｄｏｗｎ）と称する、オブジェクトの深いプロパティを扱うとき、多大な利益を提供する。例えば、次のコードを検討されたい。
【０２６４】
【表４４】
2007509426.tif 000057
【０２６５】
形状オブジェクト「ｇ」への深いアクセスが、ドットダウンと称するものの例である。プロパティへのアクセス（Ｇｅｏｍｅｔｒｉｅｓ、［１２］、Ｆｉｇｕｒｅｓ、［２］、Ｓｅｇｍｅｎｔｓ、［０］、およびＰｏｉｎｔｓ）が、呼出し側プロパティゲッタであってセッタでないことと、［１７］が、セッタの呼び出しをもたらす唯一のプロパティアクセスであることに留意されたい。プログラミング言語は、一般に、より深くプロパティ値を設定するためのプロパティへのアクセスと、より深く値を読み取るためのアクセスを区別することができない。
【０２６６】
変更不能オブジェクトからドットダウンが開始されるとき、ローカルメンバ変数がアクセスされる。その例に、「ＣｈａｎｇｅａｂｌｅＶａｌｕｅ」プロパティの使用を介して変更可能にされたことがない要素のアクセスが含まれる。
【０２６７】
プロパティが、ｃｈａｎｇｅａｂｌｅオブジェクトから発生するときには、結果の値も変更可能であり、その結果、ミュータブルになる。このために、親のプロパティゲッタは、既に変更可能である場合にサブオブジェクトを直接に返すか、サブオブジェクトの浅いクローンを作り、それをローカルメンバに設定し、そのクローンを返す。この属性が、上のコードによって、最初に実行され、浅いクローンを割り振り、割り当てた後に、ヒープ割り当てを必要としないことに関して自由に作られることに留意されたい。
【０２６８】
本発明の一態様は、オンデマンドの浅いクローン作成が、必要なときだけ実行されることである。これによって、共有が最大になり、ヒープ割り当てが最小になり、ヒープ割り当てなしの変更が可能になり、クローン作成の概念がユーザモデルに課されなくなる。これは、ツリーが深くなるにつれて、３次元で作業するときに重要になる。このために、Ｃｏｐｙ（）メソッドは、深いコピーの錯覚を与えるが、実際には、まず、浅いコピーだけを行い、その後、必要に応じてレイジリーに深いコピーを行う。そのようなドットダウンによって、かなりの性能改善がもたらされる。
【０２６９】
本発明の一態様によれば、ｃｈａｎｇｅａｂｌｅのもう１つのプロパティ（一般にアプリケーションには不可視）が、ｃｈａｎｇｅａｂｌｅが、ｃｈａｎｇｅｄイベント（型ＥｖｅｎｔＨａｎｄｌｅｒの）を有することである。Ｃｈａｎｇｅａｂｌｅのプロパティが変化するときに、そのｃｈａｎｇｅａｂｌｅのＣｈａｎｇｅｄ委任が、変化したｃｈａｎｇｅａｂｌｅをセンダとして呼び出される。ドットダウンを介して浅いクローンを作る動作は、ｃｈａｎｇｅｄイベントハンドラを浅いクローンにプッシュする。これによって、後続の変更が深い要素で発生し、正しいイベントハンドラをセットアップさせることが可能になる。Ｃｈａｎｇｅｄイベントは、プロパティシステム以外のクライアントがこのシステムを使用でき、通知に関して登録できるようにするためにも存在することに留意されたい。
【０２７０】
ｃｈａｎｇｅｄイベントハンドラに対する変更は、サブオブジェクトまで伝搬される。さらに、他のｃｈａｎｇｅａｂｌｅを伴うｃｈａｎｇｅａｂｌｅ自体の変更（例えば、ｃｈａｎｇｅａｂｌｅオブジェクトへのｃｈａｎｇｅａｂｌｅサブオブジェクトの追加、除去など）は、包含するｃｈａｎｇｅａｂｌｅのイベントハンドラが、古いｃｈａｎｇｅａｂｌｅから除去され、新しいｃｈａｎｇｅａｂｌｅにプッシュされること（再帰的に）をもたらす。
【０２７１】
図１８から２３に、この例の次のコードに基づいて、浅いクローニングとドットダウンがどのように働くかを示す。
【０２７２】
【表４５】
2007509426.tif 000058
【０２７３】
図１８からわかるように、Ｂｕｔｔｏｎ１およびＢｕｔｔｏｎ２の両方が、同一のリニア勾配ブラシ１８０２を指し、このリニア勾配ブラシ１８０２は、階層的に下に配置された、ｓｔｏｐｓノード１８０４と、指定されたｓｔｏｐｓのｃｏｌｏｒプロパティおよびｐｏｓｉｔｉｏｎプロパティを有する。次のコードを検討されたい。
【０２７４】
Btn1.Background = Btn1.Background.Copy();
このコードを実行すると、図１９に示されているように、リニア勾配ブラシ１８０２のコピー１９０２が作られ、Ｂｕｔｔｏｎ１によって指し示される。
【０２７５】
コード
LinearGradientBrush lgb = ((LinearGradientBrush)Btn1.Background);
lgb.Stops[1].Color = Colors.Orange;
を実行すると、ＣｈａｎｇｅａｂｌｅオブジェクトのＣｈａｎｇｅａｂｌｅ値のプロパティへのアクセスがもたらされ、このプロパティは、ＩｓＣｈａｎｇｅａｂｌｅ＝＝ｔｒｕｅを有し、これは、取り出されるものが書き込み可能であることを意味する。図２０から２２に全般的に示されているように、このコードを実行すると、（１）もう１つのｓｔｏｐｓノード２００４が、階層に挿入され、個々のｓｔｏｐのそれぞれをポイントし（図２０）、（２）第２のｓｔｏｐノード（ｓｔｏｐノード［１］、図２０および２１で符号２０１０を付す。下記のように「ｂｌｕｅ」プロパティを有する）のコピー２１１０（図２１）が作られ、このコピーの親である、前にコピーされたｓｔｏｐｓノード２００４が、その子としてこのコピー２１１０を有し（ｂｌｕｅプロパティに関する元のｓｔｏｐノード２０１０ではなく）、（３）図２０に示されているように、このノード２１１０のｂｌｕｅプロパティがｏｒａｎｇｅに変更される。Ｏｒａｎｇｅが、図面で菱形によって示される値型であり、図２３の色Ｒｅｄへの変更など、後続の変化が、割り当てをもたらさないことに留意されたい。
【０２７６】
変更不能状態では、ｃｈａｎｇｅａｂｌｅオブジェクトを、任意のコンテキストから読み取り、任意のコンテキストに書き込むことができる。構築時の判定で変更可能状態である場合に、ＵｉＣｏｎｔｅｘｔを、そのコンテキストからのアクセスだけを許可するようにｃｈａｎｇｅａｂｌｅオブジェクトに関連付けるのに使用することができる。その後、ＭａｋｅＵｎｃｈａｎｇｅａｂｌｅが呼び出される場合に、そのコンテキストがｎｕｌｌになる。また、ｃｈａｎｇｅａｂｌｅのＣｏｐｙ（）が行われるときに、いつでも、新しいコピーは、ソースのｃｈａｎｇｅａｂｌｅのコンテキストではなく、呼出し元からＵＩＣｏｎｔｅｘｔを得る。ＡＰＩは、ｃｈａｎｇｅａｂｌｅのＵＩＣｏｎｔｅｘｔ取得専用プロパティを提供し、これはミュータブルでないときにｎｕｌｌである。このプロパティは、ｐｕｂｌｉｃであり、その結果、アプリケーションは、所与のオブジェクトがアクセス可能であるか否かを知ることができる。
【０２７７】
コンストラクタにｎｕｌｌを渡して構築されるＣｈａｎｇｅａｂｌｅオブジェクトは、ｎｕｌｌのＵＩＣｏｎｔｅｘｔを用いて定義される。ｃｈａｎｇｅａｂｌｅオブジェクトが、ｎｕｌｌのＵＩＣｏｎｔｅｘｔを有し、ＩｓＣｈａｎｇｅａｂｌｅプロパティに真が設定されている場合に、アプリケーションは、生じる可能性がある可能なスレッド競合問題のすべてを管理する必要がある。この場合に、システムは、複数のコンテキストからの同時アクセスを妨げない。
【０２７８】
ｃｈａｎｇｅａｂｌｅオブジェクトが、別のｃｈａｎｇｅａｂｌｅオブジェクトを組み込もうとし（例えば、リニア勾配ブラシの勾配停止を設定するとき）、ＵＩＣｏｎｔｅｘｔが一致しない状況が発生する場合がある。例えば、ＧｒａｄｉｅｎｔＳｔｏｐ  ｇｓが、ＢのＵＩＣｏｎｔｅｘｔとＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅと等しいＳｔａｔｕｓＯｆＮｅｘｔＵｓｅの両方を有するときの、ＡのＵＩＣｏｎｔｅｘｔを有するＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈ  ｌｇｂを検討されたい。ｇｓにｌｇｂを設定しようとすると、例外が送出される。というのは、これが、ＵＩＣｏｎｔｅｘｔを混合する試みであり、それが許可されないからである。
【０２７９】
ｃｈａｎｇｅａｂｌｅオブジェクトに対して変更が行われるときに、Ｃｈａｎｇｅｄイベントが送出され、そのｃｈａｎｇｅａｂｌｅは、センダオブジェクトとしてイベントハンドラに供給される。しかし、実際に変更されたオブジェクトを送ることが望ましくなく、センダとして異なるオブジェクトを有することが役に立つ状況がある。これの例が、アニメーション（それ自体はｃｈａｎｇｅａｂｌｅ）が、そのアニメーション挙動を記述するタイムライン（時々クロックと称する）を保持する、アニメーションにされるオブジェクトに関する場合である。Ｐａｕｓｅ（）などのイベントは、タイムラインで発生し、アニメーションでは発生しないが、一般に、アプリケーションは、アニメーションが一時停止したか否かを知ることを求める。
【０２８０】
ｃｈａｎｇｅａｂｌｅｓのチェーンを上にたどってｃｈａｎｇｅｄイベントを実行する（ｆｉｒｅ）など、様々な解決策が可能である。これは、停止する場所を判断すること、イベントを受け取っているかつ／または使用しているものがないときでも実行されるさらなる多数のイベントで多数の通知を行うこと、ｃｈａｎｇｅａｂｌｅが設計により親を知らないが、一般に変更のイベントを通知する先だけを知っていることを含む、複数の問題を表す。ｃｈａｎｇｅａｂｌｅが親を追跡した方式を有することは、追加の記憶およびブックキーピングを必要とする。それにもかかわらず、そのような解決策を実装することができる。
【０２８１】
もう１つの解決策は、センダがｃｈａｎｇｅａｂｌｅオブジェクトであり、実際に変更される内側のｃｈａｎｇｅａｂｌｅではなくなるようにｃｈａｎｇｅａｂｌｅを実施することである。ＰｒｏｐａｇａｔｅＥｖｅｎｔＨａｎｄｌｅｒは、それが受け取るハンドラをプッシュするのではなく、そのハンドラを保管し、呼び出されたときに、保管されたハンドラを呼び出すがセンダ引数としてｃｈａｎｇｅａｂｌｅを用いる新しいローカルハンドラを作成するために実装される。新しいローカルハンドラは、ｃｈａｎｇｅａｂｌｅの子のＰｒｏｐａｇａｔｅＥｖｅｎｔＨａｎｄｌｅｒにプッシュされる。この技法が、すべてのイベントハンドラを傍受し、「偽」（ハンドラが除去されるとき）を用いて呼び出されるときにＰｒｏｐａｇａｔｅＥｖｅｎｔＨａｎｄｌｅｒが正しく処理されることを必要とし、したがってそのブックキーピングが実行されることを必要とすることに留意されたい。
【０２８２】
この解決策が、明示的なＢｅｇｉｎＣｈａｎｇｅ／ＥｎｄＣｈａｎｇｅスコーピング機構を持たず、（関係するモーダリティがなく、予想されない例外によって渡されるスキップされ得るＥｎｄＣｈａｎｇｅ（）がないので）より簡単になり、例外の場合に堅牢であることに留意されたい。しかし、Ｂｅｇｉｎ／ＥｎｄＣｈａｎｇｅは、クローンが凍結され、システムが書き込みモードでなかったときに、オブジェクトの「ゲッタ」が、得る値の浅いクローンを作る必要がなくなるようにするために存在した。そうでない場合、書込モードにおいて、これらの凍結された値は、それらでできている浅いクローンを得る。その結果、ツリーが、Ｂｅｇｉｎ／ＥｎｄＣｈａｎｇｅを用いる場合より頻繁に展開され、関係する設定が絶対になく、取得だけである場合にそれを行うことができる。それにもかかわらず、ゲッタが、まず変更不能な値について呼び出されている場合、ゲッタは、浅いクローンを作らない（これが、変更可能な値についてゲッタが呼び出され、「ｇｅｔ」を介して得られる値が変更不能である場合と別個であり、その場合には、クローン演算が行われることに留意されたい）。
【０２８３】
例えば、Ｂｔｎ．Ｂａｃｋｇｒｏｕｎｄ．Ｏｐａｃｉｔｙにアクセスし、Ｂｔｎ．Ｂａｃｋｇｒｏｕｎｄが（例えばデフォルトとして）変更可能でない場合、コピーは行われない。その代わりに、コピーは、「Ｂｔｎ．Ｂａｃｋｇｒｏｕｎｄ＝Ｂｔｎ．Ｂａｃｋｇｒｏｕｎｄ．ＣｈａｎｇｅａｂｌｅＶａｌｕｅ」または類似のものが発生するときに生じ、これは、コピーの出費が、使用される場合に限って発生することを意味する。言い換えると、値を変更する意図が表されない場合に、任意の「ｇｅｔ」は、コピーの費用を負担しない。値が、「最後に作成されたクローン」と言う概念を維持する場合に、そのクローンが作成された後にオブジェクトが変更されていない限り（そのような変更は、キャッシングされたクローンの解放をもたらす）、そのクローンを、オブジェクトの使用時に処理できることに留意されたい。これによって、さらなる共有が可能になる。さらに、コントロールインプリメンタは、ユーザに有用なパターンに関するのと同様に、このパターンに参加することによって、不当に負担をさせられないことに留意されたい。同様に、型拡張性が提供される場合に、ＭｅｄｉａＴｙｐｅの記述が、過度に複雑になってはならない。
【０２８４】
コントロールインプリメンタは、他のすべての値と同一の、Ｃｈａｎｇｅａｂｌｅを扱う同一のモデルを提示される。例えば、次のコードは、Ｇｒｉｄコントロールに、型ＢｒｕｓｈのＡｌｔｅｒｎａｔｅＢｒｕｓｈプロパティを与える。
【０２８５】
【表４６−１】
2007509426.tif 000059
【０２８６】
【表４６−２】
2007509426.tif 000060
【０２８７】
これが、このプロパティシステムに加わる一般的なプロパティと同一であることに留意されたい。というのは、ＷｒｉｔｅＬｏｃａｌが、Ｃｈａｎｇｅａｂｌｅクラスから派生する深いプロパティの特殊な処理を行うからである。
【０２８８】
ｃｈａｎｇｅａｂｌｅ型の実装側は、ｃｈａｎｇｅａｂｌｅ（例えばプロパティ）を変更するものに関する１行のプリアンブルと１行のポストスクリプトを必要とする。また、ｃｈａｎｇｅａｂｌｅの状態にアクセスするオブジェクト（例えば、プロパティゲッタ）に関する１行のプリアンブルが必要である。必要なのは、ＣｌｏｎｅＣｏｒｅ（）、ＭａｋｅＵｎｃｈａｎｇｅａｂｌｅＣｏｒｅ（）、ＰｒｏｐａｇａｔｅＥｖｅｎｔＨａｎｄｌｅｒＣｏｒｅ（）、ＰｒｏｐａｇａｔｅＥｖｅｎｔＨａｎｄｌｅｒｓ（）（最後の３つが、プロパティとして他のＣｈａｎｇｅａｂｌｅを有する型に限って必要であることに留意されたい）であり、Ｃｏｐｙ（）の型安全ラッパーも必要である。
【０２８９】
次の例は、（サブタイプのどれもがｃｈａｎｇｅａｂｌｅではないという点で単純化されている）単純なｃｈａｎｇｅａｂｌｅ型であるＧｒａｄｉｅｎｔＳｔｏｐの（人工的な）例を含む、参照されたプロトタイプからのものである。実際には、アニメーション集合（それ自体がｃｈａｎｇｅａｂｌｅ）を含むすべてのものが、これより複雑になるという点で、ごく少数のｃｈａｎｇｅａｂｌｅだけがここまで単純になることに留意されたい。
【０２９０】
【表４７−１】
2007509426.tif 000061
【０２９１】
【表４７−２】
2007509426.tif 000062
【０２９２】
【表４７−３】
2007509426.tif 000063
【０２９３】
次のコードは、（そのサブタイプの一部すなわちＧｒａｄｉｅｎｔＳｔｏｐ自体がｃｈａｎｇｅａｂｌｅなので）より複雑なｃｈａｎｇｅａｂｌｅ型であるＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈの例である。
【０２９４】
【表４８−１】
2007509426.tif 000064
【０２９５】
【表４８−２】
2007509426.tif 000065
【０２９６】
【表４８−３】
2007509426.tif 000066
【０２９７】
ｃｈａｎｇｅａｂｌｅオブジェクトモデルは、ｐｕｂｌｉｃ部分と、エクステンダおよびホスタが見る部分に分割される。やはり、この型を使用するコンポーネント製作者にとって、物事が簡単であることに留意されたい。
【０２９８】
【表４９−１】
2007509426.tif 000067
【０２９９】
【表４９−２】
2007509426.tif 000068
【０３００】
【表５０−１】
2007509426.tif 000069
【０３０１】
【表５０−２】
2007509426.tif 000070
【０３０２】
【表５０−３】
2007509426.tif 000071
【０３０３】
【表５０−４】
2007509426.tif 000072
【０３０４】
【表５０−５】
2007509426.tif 000073
【０３０５】
Ｃｈａｎｇｅａｂｌｅの、そのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅだけに頼る、条件付きの使用の動作が、すべての状況で正確に働くわけではないことに留意されたい。一般に、問題は、ｃｈａｎｇｅａｂｌｅオブジェクト（Ｂｒｕｓｈ、ＶｉｄｅｏＤａｔａなど）がＥｌｅｍｅｎｔプロパティ（ＶｉｄｅｏＳｏｕｒｃｅなど）に割り当てられるときに、ｃｈａｎｇｅａｂｌｅが、条件付きの使用で「使用」されることである。（ＶｉｄｅｏＤａｔａなどだが、すべてのアニメーションも）アニメーションＣｈａｎｇｅａｂｌｅの場合、「使用する」動作によってクローンが作成されるが、これは、正しい期待される挙動である。次に、要素のＯｎＲｅｎｄｅｒ（）メソッドが呼び出されるときに、ＯｎＲｅｎｄｅｒ（）実装は、通常、例えばＤｒａｗｉｎｇＣｏｎｔｅｘｔ．ＤｒａｗＶｉｄｅｏ（ｖｉｄｅｏＤａｔａ、．．．）を介して、値をＤｒａｗｉｎｇＣｏｎｔｅｘｔにプッシュする。このＤｒａｗｉｎｇＣｏｎｔｅｘｔへの呼び出しも、Ｃｈａｎｇｅａｂｌｅ（この例ではｖｉｄｅｏＤａｔａ）を「使用」し、もう１つのクローンが作られる結果となる。
【０３０６】
ｃｈａｎｇｅａｂｌｅがこの形で「使用」されるときの両方の挙動は、分離して検討されるとき、正しく意味をなす。しかし、これらを組み合わせたときに、コントロールのインプリメンタが、ＯｎＲｅｎｄｅｒ（）が呼び出されるたびの条件付きの使用を期待せず、（これがアプリケーションに公開されず、実際に、除去されなければならない純粋なオーバーヘッドなので）実際にそうすることに利益がないという点で問題が生じる。さらに、依存アニメーションおよび独立アニメーションが組み合わされるときに、ＯｎＲｅｎｄｅｒ（）が、頻繁に呼び出され、アニメーションが、繰り返してコピーされるが、これは正しい挙動ではない。ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅと称する機構によって、「使用」が、実際にコピーするのではなく、使用される値への参照だけを得ることが可能になる。
【０３０７】
解決策は、ＤｒａｗｉｎｇＣｏｎｔｅｘｔなどのエンティティとＤｅｐｅｎｄｅｎｃｙＯｂｊｅｃｔのＤｅｐｅｎｄｅｎｃｙＰｒｏｐｅｒｔｙとの間の協力を有することである。具体的に言うと、コントロールのＤｅｐｅｎｄｅｎｃｙＰｒｏｐｅｒｔｙは、値を設定されているとき、それが後に使用する特定のコンテキストがＣｈａｎｇｅａｂｌｅをＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅとして扱うことを望む場合に、そのように扱うことを「許容する」ことを示す必要がある。その場合、ＤｒａｗｉｎｇＣｏｎｔｅｘｔは、Ｃｈａｎｇｅａｂｌｅ自体がＣｈａｎｇｅａｂｌｅをＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅとして扱うことを許容するならば、それを「好む」ことを示す。
【０３０８】
これを行うために、ＣｈａｎｇｅａｂｌｅＨｅｌｐｅｒ．ＵｓｅＣｈａｎｇｅａｂｌｅで使用される、Ｃｈａｎｇｅａｂｌｅ．ＡｌｌｏｗＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅＯｖｅｒｒｉｄｅという名前のＢｏｏｌｅａｎプロパティおよび列挙ＣｈａｎｇｅａｂｌｅＵｓａｇｅＯｖｅｒｒｉｄｅが設けられる。この実装では、ＵｓｅＣｈａｎｇｅａｂｌｅは、ＦｏｒｃｅＵｎｃｈａｎｇｅａｂｌｅ／ＮｏＯｖｅｒｒｉｄｅへの真／偽マッピングを用いて、前と同様に働く。ＰｒｅｆｅｒＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅを用いてＵｓｅＣｈａｎｇｅａｂｌｅが呼び出され、ｃｈａｎｇｅａｂｌｅがＩｓＣｈａｎｇｅａｂｌｅ＝＝ｔｒｕｅを有し、ｃｈａｎｇｅａｂｌｅがＡｌｌｏｗＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅＯｖｅｒｒｉｄｅ＝＝ｔｒｕｅを有する場合に、そのＣｈａｎｇｅａｂｌｅの使用が、ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅとしての使用になる。
【０３０９】
これは、ＤｅｐｅｎｄｅｎｃｙＯｂｊｅｃｔ．ＳｅｔＶａｌｕｅ（）に、それが保持した（変更可能であるときに）ＣｈａｎｇｅａｂｌｅにＡｌｌｏｗＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅＯｖｅｒｒｉｄｅを設定させ、ＤｒａｗｉｎｇＣｏｎｔｅｘｔメソッドに、ＵｓａｇｅＯｖｅｒｒｉｄｅＰｒｅｆｅｒＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅを用いてＵｓｅＣｈａｎｇｅａｂｌｅを呼び出させることによって使用される。
【０３１０】
両方の条件が真ではないときに、Ｅｌｔ２．Ｐｒｏｐ＝Ｅｌｔ１．Ｐｒｏｐが、条件付きの使用において期待されるプロパティを使用し、変更可能である場合、ＵｓｅＣｈａｎｇｅａｂｌｅがＰｒｅｆｅｒＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅを用いて呼び出されないので、明示的にＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅが設定されていないならばそれをコピーするという点で、正しい挙動が発生することに留意されたい。ＤｒａｗｉｎｇＣｏｎｔｅｘｔを直接に使用することも、必要に応じて機能する。というのは、それに送られるＣｈａｎｇｅａｂｌｅが、ＡｌｌｏｗＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅＯｖｅｒｒｉｄｅを有しないからである。
【０３１１】
サブオブジェクトがＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅであるｃｈａｎｇｅａｂｌｅがあるとき、浅いクローンと深いクローンが作られることに留意されたい。ＣｌｏｎｅＣｏｒｅメソッドが、新しい浅い「シェル」を作成し、子の上で割り当て、この中にそれ以上深く入らないので、浅いクローンは機能しなければならない。深いクローンについては、Ｕｎｃｈａｎｇｅａｂｌｅまでクローンを作成し、（ＣａｎＭａｋｅＵｎｃｈａｎｇｅａｂｌｅが真であると仮定して）そこまでの各クローン自体をＵｎｃｈａｎｇｅａｂｌｅにすることによって、ＣｈａｎｇｅａｂｌｅＣｏｐｙおよびＵｎｃｈａｎｇｅａｂｌｅのツリーの場合、プロセスは簡単である。これは、最上位レベルがＣｈａｎｇｅａｂｌｅであり、その下のすべてのレベルがＵｎｃｈａｎｇｅａｂｌｅである、深いクローンをもたらす。ドットダウンによって、サブ要素がもう一度変更可能にされることに留意されたい。
【０３１２】
しかし、ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅがあるときに、クローン演算は、効果的に実行される必要があるが、参照が、「Ｃｈａｎｇｅａｂｌｅ」パスでＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅまで維持される。これは、ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅから通知があるときに、ホスティングされるすべてのものについて正しいハンドラが呼び出されるようにするために必要である。
【０３１３】
次の例を検討されたい。
【０３１４】
【表５１】
2007509426.tif 000074
【０３１５】
この例では、そのＳｔｏｐｓ集合および単一のＳｔｏｐと同様に、ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈが作成され、ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅにされる。ブラシは、複数の場所で使用でき、ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅ  ＧｒａｄｉｅｎｔＳｔｏｐへの変更は、両方のブラシに影響する必要がある。
【０３１６】
（Ｃｈａｎｇｅａｂｌｅオブジェクトの使用の（有効および無効な）例）
次のセクションでは、ブラシ、ペン、アニメーションなどのオブジェクトが、プログラマによる制御に従ってミュータブルである、Ｃｈａｎｇｅａｂｌｅクラスから派生するオブジェクトの使用および操作の要約を示す。Ｃｈａｎｇｅａｂｌｅから派生するクラスは、条件付きの使用で使用されるときにそれ自体の非ミュータブルバージョンを自動的に構築することによって、ミュータビリティをシミュレートする。前述したように、Ｃｈａｎｇｅａｂｌｅは、オブジェクトにＰｒｏｐｅｒｔｙ  Ｓｙｓｔｅｍプロパティが設定されるときに条件付きの使用で使用され、複合Ｃｈａｎｇｅａｂｌｅオブジェクト内のサブオブジェクトとして使用され、またはＤｒａｗｉｎｇＣｏｎｔｅｘｔコマンド内で使用されると考えられる。
【０３１７】
そのようなオブジェクトを用いるアプリケーションを開発するときに、グラフィックスシステムオブジェクトおよび媒体システムオブジェクトは、一般に、作成され、設定され、使用され、一度も変更されない。例えば、Ｂｕｔｔｏｎの背景を設定するために、プログラマは、Ｃｈａｎｇｅａｂｌｅから派生したＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈを使用することができるが、プログラマは、アプリケーションの進行中にボタンの背景を二度と変更しない場合がある。次がその例である。
【０３１８】
【表５２】
2007509426.tif 000075
【０３１９】
この形で使用されるとき、Ｃｈａｎｇｅａｂｌｅは、ＲｅｃｔまたはＣｏｌｏｒなどの値型のように振る舞う。Ｃｈａｎｇｅａｂｌｅは、その宛先にコピーされ、オリジナルに対する変更は、使用される値への変更に影響しない。しかし、プログラマが、使用の後にそのようなオブジェクトを変更する必要がある場合がある。例えば、プログラマが、ユーザが前のコードのボタンをクリックした後で、そのボタンの背景を変更したがると仮定する。
【０３２０】
上記などの様々な状況の必要を満たすＣｈａｎｇｅａｂｌｅパターンが存在する。一般に、Ｃｈａｎｇｅａｂｌｅは、ＩｓＣｈａｎｇｅａｂｌｅプロパティの値によって表されるように、変更可能とすることも、そうしないこともできる値である。ＩｓＣｈａｎｇｅａｂｌｅが偽のときに値の変更を試みると、例外が生じる。さらに、変更できるＩｓＣｈａｎｇｅａｂｌｅオブジェクトは、変化するときまたはそのメンバのいずれかが変更されるときに、Ｃｈａｎｇｅｄイベントを送出する。したがって、Ｃｈａｎｇｅａｂｌｅを扱うときに、Ｃｈａｎｇｅａｂｌｅが条件付きの使用で「使用される」場合を理解することが重要である。
【０３２１】
デフォルトで、Ｃｈａｎｇｅａｂｌｅオブジェクトが条件付きの使用に使用されるときに、非ミュータブルコピーが作成され、そのコピーが実際に使用される。コピーは、偽のＩｓＣｈａｎｇｅａｂｌｅ値を有する。次のコードは、ボタンの背景を設定するのに使用されたｍｙＢｒｕｓｈの変更不能コピーの変更を試みるので、例外の送出を引き起こす。
【０３２２】
【表５３】
2007509426.tif 000076
【０３２３】
オリジナルのＣｈａｎｇｅａｂｌｅオブジェクトを変更しても、コピーは更新されない。
【０３２４】
【表５４−１】
2007509426.tif 000077
【０３２５】
【表５４−２】
2007509426.tif 000078
【０３２６】
この例のボタンの背景を変更するために、プログラマは、変更されたブラシをボタンの背景プロパティに再割り当てする。
【０３２７】
【表５５−１】
2007509426.tif 000079
【０３２８】
【表５５−２】
2007509426.tif 000080
【０３２９】
プログラマは、Ｃｏｐｙメソッドを使用して、使用されたＣｈａｎｇｅａｂｌｅオブジェクトの変更可能なコピーを取り出すこともできる。取り出されたコピーは、効果を有するために、プロパティに再割り当てされる。
【０３３０】
【表５６】
2007509426.tif 000081
【０３３１】
例えば、Ｃｈａｎｇｅａｂｌｅの使用されたバージョン（ワーキングコピー）の変更を求めるプログラマを検討すると、これはすべての状況でのＣｈａｎｇｅａｂｌｅの理想的な挙動ではないので、Ｃｈａｎｇｅａｂｌｅクラスは、ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティを提供することによって使用される時のその挙動を、プログラマが指定できるようにする。
【０３３２】
ＳｔａｔｕｓＯｆＮｅｘｔＵｓｅは、使用時のＣｈａｎｇｅａｂｌｅの挙動の３つのオプションを提供する。
【０３３３】
Ｕｎｃｈａｎｇｅａｂｌｅ前のセクションの例に示された、デフォルト挙動である。Ｃｈａｎｇｅａｂｌｅオブジェクトが使用されるときに、そのオブジェクトは、それ自体の非ミュータブルコピーを作成し、このコピーが、オリジナルオブジェクトの代わりに使用される。プログラマは、オリジナルオブジェクトの変更を継続することができ、使用されるバージョン（作られたコピー）は、オリジナルオブジェクトへの変更によって影響されず、変更できない。使用されるバージョンを変更するためには、Ｃｏｐｙメソッドを使用して変更可能バージョンを入手し、そのバージョンを更新し、新しいバージョンによって使用されたバージョンを置換する。
【０３３４】
ＣｈａｎｇｅａｂｌｅＣｏｐｙ  Ｃｈａｎｇｅａｂｌｅオブジェクトが使用されるとき、そのオブジェクトは、それ自体の変更可能なコピーを作成し、そのコピーが、オリジナルオブジェクトの代わりに使用される。プログラマは、オリジナルオブジェクトの変更を継続することができ、使用されるバージョン（作られたコピー）は、オリジナルオブジェクトへの変更によって影響されないが、変更可能である。使用されるバージョンは、ＵｎｃｈａｎｇｅａｂｌｅのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅを有する。
【０３３５】
ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅ  Ｃｈａｎｇｅａｂｌｅオブジェクトが使用されるとき、そのオブジェクトは、それ自体への参照を提供する。プログラマは、オリジナルオブジェクトの変更を継続することができ、オリジナルオブジェクトへの変更は、使用されるバージョンに影響する（これらは同一のオブジェクトである）。
【０３３６】
ＣｈａｎｇｅａｂｌｅＣｏｐｙは、Ｃｈａｎｇｅａｂｌｅの挙動を変更し、その結果、使用時に、変更不能なコピー（デフォルト設定のＵｎｃｈａｎｇｅａｂｌｅの場合）ではなく、変更可能なコピーが作成されるようになる。次のコード（前に示した）は、ｍｙＢｒｕｓｈのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティがデフォルト設定のＵｎｃｈａｎｇｅａｂｌｅを有するので、例外を送出する。
【０３３７】
【表５７−１】
2007509426.tif 000082
【０３３８】
【表５７−２】
2007509426.tif 000083
【０３３９】
しかし、ブラシのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅにＣｈａｎｇｅａｂｌｅＣｏｐｙが設定されている場合には、コードは意図されたように動作する。
【０３４０】
【表５８−１】
2007509426.tif 000084
【０３４１】
【表５８−２】
2007509426.tif 000085
【０３４２】
ＣｈａｎｇｅａｂｌｅＣｏｐｙ設定は、主オブジェクトのサブオブジェクトも変更可能に保つ。次の例では、ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈに、ＣｈａｎｇｅａｂｌｅＣｏｐｙのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅが与えられる。その結果、ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈおよびそのサブオブジェクトは、使用された後に変更可能のままになり、プログラマは、この例のＧｒａｄｉｅｎｔＳｔｏｐなど、オブジェクトに含まれるＣｈａｎｇｅａｂｌｅオブジェクトのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティを設定する必要がなくなる。
【０３４３】
【表５９−１】
2007509426.tif 000086
【０３４４】
【表５９−２】
2007509426.tif 000087
【０３４５】
ＣｈａｎｇｅａｂｌｅＣｏｐｙのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅを有するＣｈａｎｇｅａｂｌｅオブジェクトを使用するとき、プログラマは、Ｃｈａｎｇｅａｂｌｅの使用されるバージョンへのハンドルを保持し、その参照を使用してオブジェクトを変更することもできる。次の例では、使用されるＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈへの参照が、取り出され、ボタンの背景の変更に使用される。
【０３４６】
【表６０−１】
2007509426.tif 000088
【０３４７】
【表６０−２】
2007509426.tif 000089
【０３４８】
ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅ設定は、Ｃｈａｎｇｅａｂｌｅの挙動を変更し、その結果、Ｃｈａｎｇｅａｂｌｅが、使用時にそれ自体への参照を提供するようになる。プログラマは、オリジナルのオブジェクトの変更を継続することができ、オリジナルオブジェクトへの変更は、これが使用されるバージョンと同一オブジェクトなので、使用されるバージョンに影響する。次がその例である。
【０３４９】
【表６１−１】
2007509426.tif 000090
【０３５０】
【表６１−２】
2007509426.tif 000091
【０３５１】
（ブラシおよびペン）
ブラシは、平面を塗り潰す方法を表すオブジェクトである。絶対的な形で平面を塗り潰せる他に、媒体統合レイヤのブラシは、塗り潰すオブジェクトのサイズに対して平面を塗り潰す方法を適合させることもできる。ブラシの種類の例に、ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ、（Ｖｉｓｕａｌを参照することができる）ＶｉｓｕａｌＢｒｕｓｈ、（ベクトルグラフィックスリソースを参照することができる）ＤｒａｗｉｎｇＢｒｕｓｈ、ＬｉｎｅａｒＧｒａｄｉｅｎｔ、ＲａｄｉａｌＧｒａｄｉｅｎｔ、ＩｍａｇｅＢｒｕｓｈ、およびＮｉｎｅＧｒｉｄＢｒｕｓｈが含まれる。ブラシプロパティのデフォルト値は、下記で指定するが、一般に、アクションをもたらさない値である。すなわち、色のデフォルトは、透明であり、他も同様である。また、アニメーション集合のデフォルトはｎｕｌｌである。
【０３５２】
前述のように、あるブラシオブジェクトは、使用時に座標系にどのように関係するかを知っており、使用される形状の境界ボックスにどのように関係するかを知っている。サイズは、ブラシが塗り潰すオブジェクトに基づく。
【０３５３】
Ｂｒｕｓｈ基底クラスは、Ｔｒａｎｓｆｏｒｍ、全般的な不透明度、およびブレンドモードを有する。
【０３５４】
【表６２】
2007509426.tif 000092
【０３５５】
ブラシ（ならびにＶｅｃｔｏｒ  ＧｒａｐｈｉｃｓおよびＭＩＬ  ＡＰＩの他のオブジェクトリソース）オブジェクトは、Ｃｈａｎｇｅａｂｌｅであり、作成の後に書き込み可能であり、条件付きの使用で使用された後の振る舞い方に関する全般的なＣｈａｎｇｅａｂｌｅパターンに従う。
【０３５６】
ブラシ（ＶｉｓｕａｌＢｒｕｓｈおよびＤｒａｗｉｎｇＢｒｕｓｈを除く）は、マークアップ要素での使用に関する単純構文を有するが、この単純構文は、すべてのプロパティおよび挙動へのアクセスを可能にするのではない。プログラマは、単純構文が提供するもの以上のアクセスを必要とする場合に、複合構文を使用する必要がある。複合構文が他のＣＬＲクラスと同一のパターンに従うので、冗長にならないように、本明細書では単純構文だけを文書化することに留意されたい。
【０３５７】
次は、現在の実装でのマークアップ要素に関する単純構文を有するブラシ型である。
【０３５８】
【表６３】
2007509426.tif 000093
【０３５９】
ブラシ型の多くは、パラメータのいくつかを指定するのに座標系を使用する。この座標系は、ブラシが使用される形状の単純な境界ボックスに対する相対値と定義することができ、または、絶対値とし、ブラシが使用される時にアクティブである座標空間内で解釈することができる。これらを、それぞれＲｅｌａｔｉｖｅＴｏＢｏｕｎｄｉｎｇＢｏｘモードおよびＡｂｓｏｌｕｔｅモードと称する。
【０３６０】
【表６４】
2007509426.tif 000094
【０３６１】
ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈは、平面を単色で塗り潰す。色のアルファ成分がある場合には、Ｂｒｕｓｈの対応する不透明度属性とかけ合わせる形で組み合わされる。
【０３６２】
【表６５】
2007509426.tif 000095
【０３６３】
これは単純な型なので（すなわち、そのプロパティのどれもがＣｈａｎｇｅａｂｌｅでない）、実装する必要がある唯一のｐｒｏｔｅｃｔｅｄメソッドは、ＣｌｏｎｅＣｏｒｅ（）である。また、このオブジェクトを無効にする値の組合せがないので、ＶａｌｉｄａｔｅＯｂｊｅｃｔＳｔａｔｅ（）メソッドを設ける必要はない。これらのメソッドおよび他の関連するメソッドは、添付の付録で説明する。
【０３６４】
ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈのマークアップ要素の単純構文を示す。
【０３６５】
【表６６】
2007509426.tif 000096
【０３６６】
Ｂｒｕｓｈクラスには、公開されるＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈインスタンスのｓｔａｔｉｃプロパティが含まれる。各々に、同一の名前の色の値が設定される。標準化されたブラシなので、これらは、偽を設定されたＩｓＣｈａｎｇｅａｂｌｅを有する（例えば、実装は、構築時にＭａｋｅＵｎｃｈａｎｇｅａｂｌｅ（）を呼び出す）ことに留意されたい。
【０３６７】
次に、標準的な色の一部を示す。
【０３６８】
【表６７−１】
2007509426.tif 000097
【０３６９】
【表６７−２】
2007509426.tif 000098
【０３７０】
【表６７−３】
2007509426.tif 000099
【０３７１】
【表６７−４】
2007509426.tif 000100
【０３７２】
【表６７−５】
2007509426.tif 000101
【０３７３】
【表６７−６】
2007509426.tif 000102
【０３７４】
勾配は、勾配停止の組を指定することによって描画される。これらの勾配停止は、ある種の進行に沿った色を指定する。現在サポートされている勾配には、線形および放射勾配の２種類がある。勾配は、指定された色空間で勾配停止の間の補間を行うことによって描かれる。
【０３７５】
勾配は、勾配停止のリストからなる。これらの勾配停止のそれぞれに、（含まれるアルファ値を伴う）色および相対位置が含まれる。勾配停止が指定されない場合、ブラシは、透明として（ブラシが指定されていないかのように）描かれる。１つの勾配停止だけが指定されている場合に、ブラシは、指定された１色の単色として描かれる。０から１の範囲（０．０．．．１．０）の相対位置を有する勾配停止は、範囲（−∞．．．０．０］内の最大の停止位置と範囲［１．０．．．＋∞）内の最小の停止位置を有すると考えられる。検討される停止位置の組に、０から１までの範囲の外の停止位置が含まれる場合に、暗黙の停止位置が、０（および／または１）で導出され、この停止位置は、この停止位置で発生する補間された色を表す。また、複数の停止位置が、同一の相対位置で設定される場合に、（補間ではなく）ハードトランジション（ｈａｒｄ  ｔｒａｎｓｉｔｉｏｎ）が、その相対位置で発生する。停止位置が追加される順序が、この相対位置での挙動を決定し、最初に追加される停止位置が、その相対位置の前で有効な色であり、最後に設定される停止位置が、その停止位置の後の有効な色であり、この相対位置の追加のストップは、無視される。
【０３７６】
このクラスは、他のリソースクラスと同様にＣｈａｎｇｅａｂｌｅである。
【０３７７】
【表６８】
2007509426.tif 000103
【０３７８】
ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈに似て、これは、アニメーション集合のネストしたＣｈａｎｇｅａｂｌｅを有する。
【０３７９】
ＧｒａｄｉｅｎｔＳｐｒｅａｄＭｅｔｈｏｄ列挙は、指定されたベクトルまたは空間の外で勾配を描く方法を指定する。３つの可能な値があり、これには、終りの色（最初と最後）が、残りの空間の塗り潰しに使用されるＰａｄと、空間を塗り潰すために停止位置が逆の順序で繰り返し再生されるＲｅｆｌｅｃｔと、空間が塗り潰されるまで順番に停止位置が繰り返されるＲｅｐｅａｔが含まれる。この型のプロパティのデフォルト値は、Ｐａｄである。
【０３８０】
【表６９−１】
2007509426.tif 000104
【０３８１】
【表６９−２】
2007509426.tif 000105
【０３８２】
図２４に、ＧｒａｄｉｅｎｔＳｐｒｅａｄＭｅｔｈｏｄの例（カラーではなくグレイスケールであるが）を示す。各形状は、白から灰色になる連続勾配を有する。実線は、勾配ベクトルを表す。
【０３８３】
ＣｏｌｏｒＩｎｔｅｒｐｏｌａｔｉｏｎＭｏｄｅ列挙は、勾配内の色の補間モードを定義する。２つのオプションが、ＰｈｙｓｉｃａｌｌｙＬｉｎｅａｒＧａｍｍａおよびＰｅｒｃｅｐｔｕａｌｌｙＬｉｎｅａｒＧａｍｍａである。
【０３８４】
【表７０】
2007509426.tif 000106
【０３８５】
これは、抽象基底クラスである。
【０３８６】
【表７１−１】
2007509426.tif 000107
【０３８７】
【表７１−２】
2007509426.tif 000108
【０３８８】
ＬｉｎｅａｒＧｒａｄｉｅｎｔは、ベクトルに沿った連続勾配ブラシを指定する。個々の停止位置は、ベクトルに沿った色停止位置を指定する。
【０３８９】
【表７２−１】
2007509426.tif 000109
【０３９０】
【表７２−２】
2007509426.tif 000110
【０３９１】
ＬｉｎｅａｒＧｒａｄｉｅｎｔＢｒｕｓｈのマークアップ要素の単純構文を示す。
【０３９２】
ｌｉｎｅａｒ−ｇｒａｄｉｅｎｔ−ｂｒｕｓｈ：
”ＨｏｒｉｚｏｎｔａｌＧｒａｄｉｅｎｔ”  ｃｏｍｍａ−ｗｓｐ  ｃｏｌｏｒ  ｃｏｍｍａ−ｗｓｐ  ｃｏｌｏｒ  ｜
”ＶｅｒｔｉｃａｌＧｒａｄｉｅｎｔ”  ｃｏｍｍａ−ｗｓｐ  ｃｏｌｏｒ  ｃｏｍｍａ−ｗｓｐ  ｃｏｌｏｒ  ｜
”ＬｉｎｅａｒＧｒａｄｉｅｎｔ”  ｃｏｍｍａ−ｗｓｐ  ｃｏｏｒｄｉｎａｔｅ−ｐａｉｒ  ｃｏｍｍａ−ｗｓｐ  ｃｏｌｏｒ  ｃｏｍｍａ−ｗｓｐ  ｃｏｌｏｒ
【０３９３】
ＬｉｎｅａｒＧｒａｄｉｅｎｔのマークアップ要素を用いると、相対位置０および相対位置１の２つの色停止位置を有するＬｉｎｅａｒＧｒａｄｉｅｎｔの指定が可能になる。「ＬｉｎｅａｒＧｒａｄｉｅｎｔ」バージョンが使用される場合に、始点および終点が指定される。「ＨｏｒｉｚｏｎｔａｌＧｒａｄｉｅｎｔ」が使用される場合には、始点に０，０が設定され、終点に１，０が設定される。「ＶｅｒｔｉｃａｌＧｒａｄｉｅｎｔ」が使用される場合には、始点に０，０が設定され、終点に０，１が設定される。これらの場合に、デフォルトのＭａｐｐｉｎｇＭｏｄｅが使用され、ＲｅｌａｔｉｖｅＴｏＢｏｕｎｄｉｎｇＢｏｘになる。
【０３９４】
ＲａｄｉａｌＧｒａｄｉｅｎｔは、連続勾配のプログラミングモデルに類似する。しかし、連続勾配が、勾配ベクトルを定義する始点および終点を有するのに対して、放射勾配は、勾配挙動を指定する、円および焦点を有する。円は、勾配の終点を定義し、言い換えれば、１．０で停止する勾配は、円の円周の色を定義する。焦点は、勾配の中心を定義する。０．０で停止する勾配は、焦点の色を定義する。図２５に、白から灰色に移る（グレイスケールの）ＲａｄｉａｌＧｒａｄｉｅｎｔを示す。外側の円は、勾配サークルを表し、黒い点は、焦点を表す。この勾配は、ＳｐｒｅａｄＭｅｔｈｏｄにＰａｄをセットされている。
【０３９５】
【表７３−１】
2007509426.tif 000111
【０３９６】
【表７３−２】
2007509426.tif 000112
【０３９７】
ＲａｄｉａｌＧｒａｄｉｅｎｔのマークアップ要素を用いると、０および１の相対位置の２つの色停止位置を有するＲａｄｉａｌＧｒａｄｉｅｎｔの指定が可能になる。デフォルトのＭａｐｐｉｎｇＭｏｄｅ（ＲｅｌａｔｉｖｅＴｏＢｏｕｎｄｉｎｇＢｏｘ）が使用され、デフォルトの半径０．５が使用される。
【０３９８】
【表７４】
2007509426.tif 000113
【０３９９】
ＴｉｌｅＢｒｕｓｈは、抽象基底クラスであり、タイルと、タイルが領域を塗り潰す手段とを記述した論理を含む。ＴｉｌｅＢｒｕｓｈのサブクラスは、内容を含み、無限平面を塗り潰す形を論理的に定義する。
【０４００】
Ｓｔｒｅｔｃｈ列挙が、ＶｉｅｗＢｏｘ（ソース座標空間）をＶｉｅｗＰｏｒｔ（宛先座標空間）にマッピングする方法を記述するのに使用される。これは、ＴｉｌｅＢｒｕｓｈで使用される。
【０４０１】
【表７５】
2007509426.tif 000114
【０４０２】
図２６に、ストレッチの例を示す。この例では、内容が左上に位置合せされている。
【０４０３】
ＴｉｌｅＭｏｄｅ列挙は、空間がＴｉｌｅによって塗り潰されるかどうかと、塗り潰し方を記述するのに使用される。ＴｉｌｅＢｒｕｓｈは、ベースＴｉｌｅの場所（ＶｉｅｗＰｏｒｔによって指定される）を定義する。残りの空間は、ＴｉｌｅＭｏｄｅ値に基づいて塗り潰される。
【０４０４】
【表７６−１】
2007509426.tif 000115
【０４０５】
【表７６−２】
2007509426.tif 000116
【０４０６】
図２７に、ＴｉｌｅＭｏｄｅの例を示す。各例の左上のタイルが、ベースタイルである。この例は、Ｎｏｎｅ、Ｔｉｌｅ、ＦｌｉｐＸ、ＦｌｉｐＹ、およびＦｌｉｐＸＹを表す。
【０４０７】
ＶｅｒｔｉｃａｌＡｌｉｇｎｍｅｎｔ列挙は、コンテナ内で内容を縦に位置決めする方法を記述するのに使用される。
【０４０８】
【表７７】
2007509426.tif 000117
【０４０９】
ＨｏｒｉｚｏｎｔａｌＡｌｉｇｎｍｅｎｔ列挙は、コンテナ内で内容を横に位置決めする方法を記述するのに使用される。
【０４１０】
【表７８】
2007509426.tif 000118
【０４１１】
ＴｉｌｅＢｒｕｓｈプロパティは、無限平面のタイリングされる長方形部分（ＶｉｅｗＢｏｘ）を選択し、塗り潰される領域内のベースＴｉｌｅになる宛先長方形（ＶｉｅｗＰｏｒｔ）を記述する。残りの宛先領域は、ＴｉｌｅＭｏｄｅプロパティに基づいて塗り潰され、このプロパティは、残りの空間を塗り潰すためにオリジナルタイルを複製するか否かとその方法を制御する。
【０４１２】
【表７９−１】
2007509426.tif 000119
【０４１３】
【表７９−２】
2007509426.tif 000120
【０４１４】
ＴｉｌｅＢｒｕｓｈの内容は、固有の境界がなく、事実上、無限平面が記述される。この内容は、それ自体の座標空間に存在し、ＴｉｌｅＢｒｕｓｈによって塗り潰される空間は、適用時のローカル座標空間である。内容空間は、ＶｉｅｗＢｏｘプロパティ、ＶｉｅｗＰｏｒｔプロパティ、Ａｌｉｇｎｍｅｎｔプロパティ、およびＳｔｒｅｔｃｈプロパティに基づいてローカル空間にマッピングされる。ＶｉｅｗＢｏｘは、内容空間で指定され、この長方形が、ＶｉｅｗＰｏｒｔ長方形にマッピングされる。
【０４１５】
ＶｉｅｗＰｏｒｔは、内容が最終的に描かれる位置を定義し、このＢｒｕｓｈのベースタイルを作成する。ＶｉｅｗＰｏｒｔＵｎｉｔｓの値がＡｂｓｏｌｕｔｅである場合には、ＶｉｅｗＰｏｒｔの値が、適用の時のローカル空間にあるとみなされる。そうではなく、ＶｉｅｗＰｏｒｔＵｎｉｔｓの値がＲｅｌａｔｉｖｅＴｏＢｏｕｎｄｉｎｇＢｏｘである場合には、ＶｉｅｗＰｏｒｔの値は、０，０がペイントされるオブジェクトの境界ボックスの左上角、１，１が同一のボックスの右下角である座標空間にあるとみなされる。例えば、１００，１００から２００，２００まで描かれる、塗り潰されるＲｅｃｔａｎｇｌｅＧｅｏｍｅｔｒｙを検討されたい。ＶｉｅｗＰｏｒｔＵｎｉｔｓがＡｂｓｏｌｕｔｅである場合に、（１００，１００，１００，１００）のＶｉｅｗＰｏｒｔは、内容領域全体を記述する。ＶｉｅｗＰｏｒｔＵｎｉｔｓがＲｅｌａｔｉｖｅＴｏＢｏｕｎｄｉｎｇＢｏｘである場合に、（０，０，１，１）のＶｉｅｗＰｏｒｔが、内容領域全体を記述する。ＶｉｅｗＰｏｒｔのＳｉｚｅが空であり、ＳｔｒｅｔｃｈがＮｏｎｅ以外である場合に、Ｂｒｕｓｈは何もレンダリングしない。
【０４１６】
ＶｉｅｗＢｏｘは、内容空間で指定される。この長方形は、ＡｌｉｇｎｍｅｎｔプロパティおよびＳｔｒｅｔｃｈプロパティによる決定に従って、ＶｉｅｗＰｏｒｔに収まるように変換される。ＳｔｒｅｔｃｈがＮｏｎｅの場合には、内容にスケーリングは適用されない。ＳｔｒｅｔｃｈがＦｉｌｌである場合には、ＶｉｅｗＢｏｘは、ＶｉｅｗＰｏｒｔと同一サイズになるように、ＸとＹの両方で独立にスケーリングされる。ＳｔｒｅｔｃｈがＵｎｉｆｏｒｍまたはＵｎｉｆｏｒｍＴｏＦｉｌｌである場合には、論理は類似するが、ＸおよびＹの寸法が、均一にスケーリングされ、内容のアスペクト比が保たれる。ＳｔｒｅｔｃｈがＵｎｉｆｏｒｍである場合に、ＶｉｅｗＢｏｘは、ＶｉｅｗＰｏｒｔのサイズと等しい、より小さい寸法を有するようにスケーリングされる。ＳｔｒｅｔｃｈがＵｎｉｆｏｒｍＴｏＦｉｌｌである場合に、ＶｉｅｗＢｏｘは、ＶｉｅｗＰｏｒｔのサイズと等しい、より大きいサイズを有するようにスケーリングされる。これを考えるもう１つの形は、ＵｎｉｆｏｒｍとＵｎｉｆｏｒｍＴｏＦｉｌｌの両方が、アスペクト比を保つが、Ｕｎｉｆｏｒｍは、ＶｉｅｗＢｏｘ全体がＶｉｅｗＰｏｒｔ内にある（潜在的に、ＶｉｅｗＰｏｒｔの一部がＶｉｅｗＢｏｘに覆われずに残される）ことを保証し、ＵｎｉｆｏｒｍＴｏＦｉｌｌは、ＶｉｅｗＰｏｒｔ全体がＶｉｅｗＢｏｘによって塗り潰される（潜在的に、ＶｉｅｗＢｏｘの一部がＶｉｅｗＰｏｒｔの外になる）ことを保証するということである。ＶｉｅｗＢｏｘの領域が空である場合に、Ｓｔｒｅｔｃｈは適用されない。それでも位置合わせは行われ、「点」ＶｉｅｗＢｏｘが位置決めされる。
【０４１７】
（ＶｉｅｗＰｏｒｔＵｎｉｔｓに基づいて）ＶｉｅｗＰｏｒｔが決定され、（Ｓｔｒｅｔｃｈに基づいて）ＶｉｅｗＢｏｘの宛先サイズが決定されたならば、ＶｉｅｗＢｏｘを、ＶｉｅｗＰｏｒｔ内で位置決めする必要がある。ＶｉｅｗＢｏｘが、ＶｉｅｗＰｏｒｔと同一のサイズである場合（ＳｔｒｅｔｃｈがＦｉｌｌの場合、または他の３つのＳｔｒｅｔｃｈ値の１つで偶然にそうなる場合）、ＶｉｅｗＢｏｘは、ＶｉｅｗＰｏｒｔと同一になるように、Ｏｒｉｇｉｎに位置決めされる。そうでない場合には、ＨｏｒｉｚｏｎｔａｌＡｌｉｇｎｍｅｎｔとＶｅｒｔｉｃａｌＡｌｉｇｎｍｅｎｔが考慮される。これらのプロパティに基づいて、ＶｉｅｗＢｏｘが、Ｘ次元およびＹ次元の両方で位置合せされる。ＨｏｒｉｚｏｎｔａｌＡｌｉｇｎｍｅｎｔがＬｅｆｔである場合には、ＶｉｅｗＢｏｘの左縁が、ＶｉｅｗＰｏｒｔの左縁に位置決めされる。ＨｏｒｉｚｏｎｔａｌＡｌｉｇｎｍｅｎｔがＣｅｎｔｅｒである場合には、ＶｉｅｗＢｏｘの中心が、ＶｉｅｗＰｏｒｔの中心に位置決めされ、Ｒｉｇｈｔの場合には、右縁が一致する。この処理が、Ｙ次元について繰り返される。
【０４１８】
ＶｉｅｗＢｏｘがＥｍｐｔｙの場合に、これは未設定とみなされる。未設定である場合には、ＣｏｎｔｅｎｔＵｎｉｔｓが考慮される。ＣｏｎｔｅｎｔＵｎｉｔｓがＡｂｓｏｌｕｔｅである場合に、スケーリングまたは相対位置は発生せず、内容は、変換なしでＶｉｅｗＰｏｒｔ内に描かれる。ＣｏｎｔｅｎｔＵｎｉｔｓがＲｅｌａｔｉｖｅＴｏＢｏｕｎｄｉｎｇＢｏｘである場合には、内容原点が、ＶｉｅｗＰｏｒｔのＯｒｉｇｉｎに位置合せされ、内容が、オブジェクトの境界ボックスの幅および高さによってスケーリングされる。
【０４１９】
空間をＴｉｌｅＢｒｕｓｈで塗り潰すとき、内容は、上記のようにＶｉｅｗＰｏｒｔにマッピングされ、ＶｉｅｗＰｏｒｔにクリッピングされる。これが、塗潰しのベースタイルを形成し、空間の残りは、ＢｒｕｓｈのＴｉｌｅＭｏｄｅに基づいて塗り潰される。設定されている場合に、Ｂｒｕｓｈの変換が適用され、この変換は、他のマッピング、スケーリング、相対位置などが行われた後に行われる。
【０４２０】
ＶｉｓｕａｌＢｒｕｓｈは、その内容がＶｉｓｕａｌによって指定されるＴｉｌｅＢｒｕｓｈである。このＢｒｕｓｈは、複雑なパターンを作成するのに使用することができ、あるいは、場面の他の部分の内容の追加のコピーを描くのに使用することができる。
【０４２１】
【表８０】
2007509426.tif 000121
【０４２２】
前述のように、ＶｉｓｕａｌＢｒｕｓｈは、マークアップ要素の単純構文を有しないが、複合構文を介して記述することができる。
【０４２３】
ＤｒａｗｉｎｇＢｒｕｓｈは、その内容がＤｒａｗｉｎｇによって指定されるＴｉｌｅＢｒｕｓｈである。このＢｒｕｓｈは、ＤｒａｗｉｎｇＣｏｎｔｅｘｔを介して作成された複雑なパターンを作成するのに使用することができる。
【０４２４】
【表８１−１】
2007509426.tif 000122
【０４２５】
【表８１−２】
2007509426.tif 000123
【０４２６】
前述のように、ＤｒａｗｉｎｇＢｒｕｓｈは、マークアップ要素の単純構文を有しないが、複合構文を介して記述することができる。
【０４２７】
ＩｍａｇｅＢｒｕｓｈは、ＩｍａｇｅＳｏｕｒｃｅによって指定された内容を有するＴｉｌｅＢｒｕｓｈである。このＢｒｕｓｈは、空間を画像で塗り潰すのに使用することができる。
【０４２８】
【表８２】
2007509426.tif 000124
【０４２９】
ＩｍａｇｅＢｒｕｓｈのマークアップ要素の単純構文を示す。
【０４３０】
ｉｍａｇｅ−ｂｒｕｓｈ：
”Ｉｍａｇｅ”  ｉｍａｇｅ−ｕｒｉ
ＶｉｄｅｏＢｒｕｓｈは、ＶｉｄｅｏＤａｔａによって指定された内容を有するＴｉｌｅＢｒｕｓｈである。このＢｒｕｓｈは、空間をＶｉｄｅｏで塗り潰すのに使用することができる。
【０４３１】
【表８３】
2007509426.tif 000125
【０４３２】
ＶｉｄｅｏＢｒｕｓｈのマークアップ要素の単純構文を示す。
【０４３３】
ｖｉｄｅｏ−ｂｒｕｓｈ：
”Ｖｉｄｅｏ”  ｖｉｄｅｏ−ｕｒｉ
ＮｉｎｅＧｒｉｄＢｒｕｓｈは、必ず内容画像でオブジェクト境界ボックスを塗り潰すＢｒｕｓｈであり、画像ストレッチは、純粋にビジュアルスケールを介して達成されるのではない。画像ソースが、４つの境界によって９つの長方形に分割される（したがってＮｉｎｅＧｒｉｄという名前になった）。この９つの領域のそれぞれの画像の内容が、オブジェクト境界ボックスを塗り潰すまで、０次元、１次元、または２次元でスケーリングされる。各セクションがスケーリングされる次元は、図２８に示されており、図２８は、上下左右の境界によって定義される９つのグリッドを示す、ＮｉｎｅＧｒｉｄの概念を表す。各グリッド４角形の矢印は、これらの内容がＶｉｅｗＰｏｒｔサイズに合わせて引き延ばされる次元を示す。
【０４３４】
上記で示した９つのグリッド領域の他に、任意選択の「第１０」グリッドがある。これは、ＶｉｅｗＰｏｒｔ内でセンタリングされ、スケーリングされない追加画像の形をとる。これを、ボタンなどの中央に形状を配置するのに用いることができる。この「第１０グリッド」を、グリフと呼び、ＧｌｙｐｈＩｍａｇｅＳｏｕｒｃｅプロパティによって表す。
【０４３５】
【表８４−１】
2007509426.tif 000126
【０４３６】
【表８４−２】
2007509426.tif 000127
【０４３７】
境界メンバが、画像ピクセル単位で画像の縁から数えられることに留意されたい。
【０４３８】
ＮｉｎｅＧｒｉｄＢｒｕｓｈのマークアップ要素の単純構文を示す。
【０４３９】
ｎｉｎｅ−ｇｒｉｄ−ｂｒｕｓｈ：
”ＮｉｎｅＧｒｉｄ”  ｉｍａｇｅ−ｕｒｉ  ｉｎｔ  ｉｎｔ  ｉｎｔ  ｉｎｔ  ［ｇｌｙｐｈ−ｉｍａｇｅ−ｕｒｉ］
４つの整数は、それぞれＬｅｆｔＢｏｒｄｅｒ、ＲｉｇｈｔＢｏｒｄｅｒ、ＴｏｐＢｏｒｄｅｒ、およびＢｏｔｔｏｍＢｏｒｄｅｒの値である。第１０グリッドまたはグリフの、最後のＵＲＩは、オプションである。
【０４４０】
Ｐｅｎは、Ｂｒｕｓｈと、空間／Ｇｅｏｍｅｔｒｙをストロークする方法を記述した他のパラメータとを取るオブジェクトである。概念上、Ｐｅｎは、Ｇｅｏｍｅｔｒｙからストローク領域を作成する方法を記述する。Ｇｅｏｍｅｔｒｙの縁、ＰｅｎのＴｈｉｃｋｎｅｓｓ、ＰｅｎＬｉｎｅＪｏｉｎ、ＰｅｎＬｉｎｅＣａｐなどに基づく新しい領域が作成される。この領域は、作成されたならば、Ｂｒｕｓｈで塗り潰される。
【０４４１】
【表８５−１】
2007509426.tif 000128
【０４４２】
【表８５−２】
2007509426.tif 000129
【０４４３】
【表８５−３】
2007509426.tif 000130
【０４４４】
ＰｅｎＬｉｎｅＣａｐは、ストローク線の終りの描き方を決定する。
【０４４５】
【表８６】
2007509426.tif 000131
【０４４６】
ＰｅｎＤａｓｈＣａｐは、破線のストローク線のそれぞれの終りの描き方を決定する。
【０４４７】
【表８７−１】
2007509426.tif 000132
【０４４８】
【表８７−２】
2007509426.tif 000133
【０４４９】
ＰｅｎＬｉｎｅＪｏｉｎは、線をストロークするときの接続点の描き方を決定する。
【０４５０】
【表８８】
2007509426.tif 000134
【０４５１】
ＤａｓｈＡｒｒａｙｓクラスには、共通の周知の破線スタイルへのアクセスを提供する静的プロパティが含まれる。
【０４５２】
【表８９】
2007509426.tif 000135
【０４５３】
（Ｃｏｌｏｒ）
カラーアーキテクチャは、Ｃｏｌｏｒがコンテキストを必要とすることを含むいくつかの一般原理に基づいて作られ、したがって、カラー値は、明示的に割り当てられたコンテキストまたはワークフロー内のカラー不適合度を最小にするための暗黙の仮定されるデフォルトを有する。さらに、カラープラットフォーム設計は、セキュリティ、信頼性、保守性、将来の拡張、および性能に関する長い寿命を有する最小限のコードパスおよびＡＰＩを必要とし、したがって、レンダリングコアを、主に、入ってくる内容ストリームがそれに変換され、出てゆくストリームがそれから変換されるｓｃＲＧＢコードパスに制限することができる（より低い品質を有する追加のｓＲＧＢレガシパスも許容される）。「ｓｃＲＧＢ」が、ＩＥＣ  ６１９６６−２−２国際規格に基づく内部ベクトルグラフィックスデフォルト表現を指すことに留意されたい（「ｓｃ」が意味するものについて公式の定義は提供されないが、本明細書では、合成処理最適の空間であることを明瞭にするのを助けるために、「ｓｔａｎｄａｒｄ  ｃｏｍｐｏｓｉｔｉｎｇ（標準合成）」を使用する）。
【０４５４】
性能は、リアルタイムレンダリングステージではなく、できる限りカラーオブジェクト定義／指定ステージの近くで複雑な処理を実行することを必要とする。これは、ＡＰＩへのカラーパラメータが、指定の際にｓｃＲＧＢに（本質的に即座に）変換され、非ｓｃＲＧＢ定義のオブジェクトについて、そのｓｃＲＧＢカラー値が維持され、同期化されることを必要とする。使用のそれぞれが、最も一般的な開発者の事例が最初に公開されるが、最も高度な事例が明瞭だが最小限のＡＰＩを有する階層化ＡＰＩを必要とする。したがって、ｓＲＧＢ  ＡＰＩが設けられ（内部で即座にｓｃＲＧＢに変換されるが）、ｓｃＲＧＢ  ＡＰＩが設けられ、最小限のコンテキスト関連ＡＰＩが設けられて、高度なＣＭＹＫ（シアン−マゼンタ−イエロー−ブラック）、モノクローム、ヒューマンビジュアルシステム（ｈｕｍａｎ  ｖｉｓｕａｌ  ｓｙｓｔｅｍ）、およびマルチチャネルソリューションをサポートする。ｓｃＲＧＢは、本質的に「無限」色域なので、追加の装置特性記述および域マッピングの解決策は、現実世界の装置に関してｓｃＲＧＢワークフローを「フックする」必要がある。
【０４５５】
色は、ほとんどの場合、通常、外部の物理的感覚によって引き起こされる心理学的知覚である。これは、コンピュータベースの色が、装置にまたがり、ユーザの間で、知覚される色を効果的に伝えるために、物理コンテキストを必要とすることを意味する。歴史的に、様々なテクノロジは、色アーキテクチャ実施形態の穏当なコンテキスト的意味を提供する際に一貫性がなく、例えば、これが、「赤」が、ある装置またはユーザにとって「オレンジ」を意味し、別の装置またはユーザにとって「ピンク」を意味することをもたらし、この不一致を解決する実現可能な方法はほとんどない。
【０４５６】
本アーキテクチャは、すべてのカラーオブジェクトに関する暗黙の（デフォルトを使用する）カラーコンテキストおよび明示的なカラーコンテキストの組合せを提供する。これは、コンテキスト的な意味を持たないカラーオブジェクトがないことを意味する。これは、不完全な技術であり、したがって、このアーキテクチャの態様は、技術が進歩するにつれて進化できる形で一貫性のあるカラーコンテキストを提供することである。ほとんどのコンピュータユーザ（およびほとんどの開発者）が、カラーマネジメントを扱うことを望まず、カラーが単に正しく働くことを好むことに留意されたい。
【０４５７】
一般に、アーキテクチャは、内部コードパスを最小にすることを試み、これは、一方は品質および将来のハードウェアに関し、他方はレガシおよびメモリ／性能制約に関する、２つの基本コードパスを内部で使用可能にすることによって、ある程度達成される。ＭＩＬコア内部レンダリング合成エンジンは、３２ｂｐｐ  ｓＲＧＢおよび１２８ｂｐｐ浮動小数点ｓｃＲＧＢをサポートする（６４ｂｐｐ  ｓｃＲＧＢも検討されており、６４ｂｐｐサポートの事例には、固定小数点で最もよく実装されるもの、浮動小数点、または整数で最もよく実装されるものがある）。
【０４５８】
本アーキテクチャは、キャプチャからディスプレイ、編集、記憶、および印刷への１２８ｂｐｐ  ｓｃＲＧＢパス（ディスプレイは、１２８ｂｐｐバックバッファおよび１０ｂｐｃ以上のフロントバッファになる）を提供し、性能、メモリ、および／または帯域幅のために品質を犠牲にするレガシ３２ｂｐｐ  ｓＲＧＢパスを許容する。
【０４５９】
本発明のカラーマネジメントは、装置およびアプリケーションに追加の柔軟性を提供することによって従来の短所を改善し、プロファイルベースカラーマネジメント解決策を提供する。最も一般的なシナリオは、ｓｃＲＧＢおよびｓｃＲＧＢカラーオブジェクトに基づいて、共通のＵＩ要素に関してカラー値の取得および設定をサポートし、ウェブ、マルチ媒体、およびコンピュータグラフィックスに関するほとんどの内容作成をサポートすることである。より一般的でないシナリオに、プロフェッショナル写真ワークフローに関する特定の作業空間プロファイルを用いるＲＧＢカラーコンテキストの使用、印刷前およびグラフィクス設計作業に関するカラーオブジェクトを編集するためのＣＭＹＫカラー値の使用、ニッチな印刷シナリオをサポートし、未定義の将来のワークフローをサポートする柔軟性を提供するモノクロームおよびマルチチャネルのカラーワークフローが含まれる。ＨＶＳＶ（ヒューマンビジュアルシステムベースのスペース）ワークフローは、あるニッチなプロフェッショナル写真編集シナリオをサポートする。
【０４６０】
品質およびビット深さにおいて進歩を続けるキャプチャセンサテクノロジと一致するために、イメージングは、現代のデジタルネイティブイニシアティブをサポートするために、すべての特徴／ＡＰＩについて少なくとも６４ｂｐｐのフォーマットをサポートする。本発明が、ベクトルグラフィックスの新しいアーキテクチャを実施するので、ベクトルグラフィックスは、チャネルあたり３２ビット浮動小数点のビット精度で実施される。この実施形態は、実際には、従来の８ｂｐｃカラーアクセスならびにグレイスケールインターフェースおよびＨＳＶインターフェースを提供するために、「隠される」。
【０４６１】
もう１つの型のカラーデータが、「ＣｏｒｎｆｌｏｗｅｒＢｌｕｅ」カラーまたは「Ｐａｎｔｏｎｅ」カラーなどのネームドカラー（ｎａｍｅｄ  ｃｏｌｏｒ）データである。伝統的なカラーマネジメントプロファイルを拡張することに基づくカラーコンテキストを提供することによって、非常に包括的で強力なカラーネーミングインターフェースが提供される。以前のＡＰＩおよび一般的な形式とのレガシ互換性を維持するために、デフォルトコンストラクタは、ｓＲＧＢ入力に偏っている。
【０４６２】
ベクトルグラフィックスの色空間サポートは、ネイティブｓｃＲＧＢサポート、明示的なカラーコンテキストを必要としないｓＲＧＢおよび類似する空間のプロパティサポート、明示的に関連するカラーコンテキストを必要としない、ＨＳＶ（色相、彩度、値）などのｓＲＧＢまたはｓｃＲＧＢに密に関係する色空間のメソッドサポート、暗黙のまたは明示的のいずれかの関連するカラーコンテキストに基づくパレットおよびインデックス付き色空間などのネームドカラーならびに関連色空間のメソッドサポート、追加のカラーチャネル、ＣＭＹＫ、ハイファイカラー（ＣＭＹＫと橙および緑）、ＣｃＭｍＹＫインクジェット色空間、および潜在的に将来のスペクトル色サポートなどの明示的に関連するカラーコンテキストを必要とする色空間のメソッドサポートに分割される。
【０４６３】
これらの色空間は、ＭＩＬコアまたは合成エンジンでのレンダリングのためにｓｃＲＧＢまたはｓＲＧＢに変換されるが、これらを、プログラム設計言語としてベクトルグラフィックマークアップ言語を使用して、保管するかプリンタに送る（ＣＭＹＫなど）ことができる。カラーマークアップ構文に、４つの基本指定機構すなわち、１６進、既知のカラー、ｓＲＧＢプロパティ、および高度なカラーコンテキストが含まれる。最初の３つでは、ｓＲＧＢ色空間カラーコンテキストが前提になる。
【０４６４】
下の例では、この４つの機構を使用して勾配が作成される。
【０４６５】
【表９０−１】
2007509426.tif 000136
【０４６６】
【表９０−２】
2007509426.tif 000137
【０４６７】
最初の背景色は、１６進数（＃ｅｅ７７１１）として指定されている。この１６進表現は、．ＮＥＴ  ｆｒａｍｅｗｏｒｋ  Ｖ１およびＷｉｎＦｏｒｍｓでカラーを指定する形と同一である。これは柔軟であって、４つの異なる変形：＃ＲＧＢ、＃ＡＲＧＢ、＃ＲＲＧＢＢＢ、または＃ＡＡＲＲＧＧＢＢを許容する。
【０４６８】
２番目の背景色は、既知の色（ＣｏｒｎＦｌｏｗｅｒＢｌｕｅ）として指定されている。この表現は、．ＮＥＴ  ｆｒａｍｅｗｏｒｋ  Ｖ１およびＷｉｎＦｏｒｍｓでカラーを指定する形と同一である。これは、ネームドカラー値に基づく。ネームドカラーソリューションによって、Ｐａｎｔｏｎｅ、Ｔｒｕｍａｔｃｈ、および他のネームドカラーをカラーコンテキストでサポートできるようになる。これは、アルファチャネル設定もサポートする。
【０４６９】
最初の勾配停止は、カラーコンテキスト（「ｓＧｒａｙ．ｉｃｃ  ０．５」）を使用して指定されている。このテキストストリングは、カラーコンテキストファイル名を指定し、これは、ＵＲＬまたはＵＲＩとすることができる。このサンプルは、プリントレンダリング時にＲＧＢ値をまずモノクローム値に変換することを必要としない、モノクローム印刷のクリーンなサポートを示すためのものである。
【０４７０】
２番目の勾配停止は、ｓＲＧＢプロパティ（Ａ＝「０．８」  Ｒ＝「０．２」  Ｇ＝「１」  Ｂ＝「０．２」）を使用して指定されている。この表現は、．ＮＥＴ  ｆｒａｍｅｗｏｒｋ  Ｖ１およびＷｉｎＦｏｒｍｓでの色の指定方法と同一である。
【０４７１】
３番目の勾配停止は、カラーコンテキスト（＝“ｍｓｗｏｐｉｎｔｅｎｔ８．ｉｃｍ  ０．９  ０．２  ０．１  ０．３”）を使用している。このテキストストリングは、ＵＲＬまたはＵＲＩとすることができるカラーコンテキストファイル名を指定し、アルファチャネル設定をサポートすることができる。このサンプルでは、Ｐｕｂｌｉｓｈｅｒおよび他のそのようなアプリケーションに必要な、ＣＭＹＫサポートが示されている。
【０４７２】
これらの例は、一緒に、カラー要件をサポートする非常に堅牢で明瞭な構文を提供する。カラーコンテキストを、グローバルに指定することができ、例えば性能最適化のために、内部カラー参照がこのグローバルコンテキストに従うことを要求できることに留意されたい。
【０４７３】
前述したように、カラーコンテキストは、ベクトルベースであれラスタベースであれ、カラーオブジェクトに必要である。粗いレベルでは、カラーコンテキストを、カラーオブジェクトの色空間と人間の視覚系との間の関係を規定するプロファイルとみなすことができる。カラーコンテキストは、ユーザの色空間とｓｃＲＧＢ色空間（またはヒューマンビジュアルシステムカラー）の間の関係に関する情報を提供する。これは、以前に効果的な形で実現可能ではなかった、ＣＭＹＫおよび他のカラー情報の「ラウンドトリップ」を可能にする。
【０４７４】
実際問題として、現在、ｓＲＧＢ、ｓｃＲＧＢ、ＡｄｏｂｅＲＧＢ、ＢｒｕｃｅＲＧＢ、ＡｐｐｌｅＲＧＢ、ＴｏｍＲＧＢ、ＣｏｒｂｉｓＲＧＢ、ＪｏｅＲＧＢ、ＨＳＶ、ＨＳＢ、ＸＹＺ、ＬＡＢ、ＬＵＶ、ＹＵＶ、ＹＣＣ、ＣＭＹＫ、ＣｃＭｍＹＫ、ＣＭＹＫＯＧ、ライトネスグレイスケール（ｌｉｇｈｔｎｅｓｓ  ｇｒａｙｓｃａｌｅ）、ルミナンスグレイスケール（ｌｕｍｉｎａｎｃｅ  ｇｒａｙｓｃａｌｅ）、および多数の他の色空間など、文字どおり数百個の異なる色空間が存在する。これらの個々の色空間の多くを、ガンマ、原色、白色点、およびビット精度を含む定義するセマンティクスを有する、赤、緑、および青の視覚的知覚への近似を含む３つのチャネルによって主に定義されるＲＧＢ空間などの色空間のクラスに分割することができる。ビット精度が必要なのは、より低い精度（８ビット毎チャネルなど）が、適度なエンコーディング効率を達成するために、通常は広範囲の非線形補償を必要とするからである。
【０４７５】
カラーコンテキストクラスを設けることによって、可能な色空間クラスの集合が、グレイスケール、ＲＧＢ、ＨＳＶ、ＣＭＹＫ、ＬＡＢ、ＬＣＨ、ＣｃＭｍＹＫ、ＣＭＹＫＯＧ、スペクトル色などのはるかに小さい集合と、芸術的効果に使用される二色網版空間、トライトーン（ｔｒｉｔｏｎｅ）空間、およびクワッドトーン（ｑｕａｄｔｏｎｅ）空間などの特殊効果空間に減らされる。同一の基礎になる意味を共有するが異なる座標系を提供する（直交幾何学と極幾何学に類似する）空間を組み合わせることによって、さらなる削減が可能である。これによって、ＨＳＶが、ＲＧＢ色空間クラスの最上位のメソッドになり、ＬＣＨが、ＬＡＢ色空間クラスの最上位のメソッドになる。
【０４７６】
特殊効果色空間をスペクトル色と組み合わせ、ＣｃＭｍＹＫおよびＣＭＹＫＯＧのサポートを含め、このコンテキストのカラー値を動的配列にすることが可能である。というのは、高度なユーザだけがこの特徴を使用するからである。色空間を、ｓＲＧＢ空間および他のＲＧＢ空間をサポートするｓｃＲＧＢと、カラーコンテキストを有するマルチチャネル色空間に減らすさらなる削減が可能である。これによって、ｓｃＲＧＢ空間およびマルチチャネル空間だけを含む、サポートすべき適度な数の基本色空間クラスが残される。
【０４７７】
ＣｏｌｏｒＣｏｎｔｅｘｔは、ベクトルグラフィックスのＣｏｌｏｒクラスまたはＩｍａｇｅＤａｔａオブジェクトのいずれかに関連する。もう１つの代替物が、Ｖｉｓｕａｌｓを単一のＣｏｌｏｒＣｏｎｔｅｘｔに制限することである。これは、多くの状況で色変換および検証の量を最適化するのに役立ち、アプリケーション開発者にとってより自然になる可能性があり、例えば、個々のコントロールは、複数のカラーシステムからの色を使用する可能性が低い。動的変更を許容する機構を介して複数のカラーの種類を明示的に使用する高度なアプリケーションについて、カラープロファイルを変更することがまだ許容されることに留意されたい。ＣｏｌｏｒＣｏｎｔｅｘｔを用いると、２つの装置域の間のレンダリング意図または色域マッピングを指定でき、したがってカラーオブジェクトに関連付けられるようになる。ＣｏｌｏｒＣｏｎｔｅｘｔは、単一のカラーオブジェクトだけを扱うので、宛先域を仮想装置とすることができる。これによって、ＣｏｌｏｒＣｏｎｔｅｘｔに、色空間のオブジェクト記述ならびに色の主観的なレンダリング意図の両方を含められるようになる。
【０４７８】
色名は、ＣｏｌｏｒＣｏｎｔｅｘｔの型と実際の色名に基づくカラー値の間のリンクを提供するカラーコンテキストに関連するプロファイルで実施される単純な検索テーブルである。これによって、カラーオブジェクトごとの異なるカラーネーミング辞書が可能になる。例えば、Ｔｒｕｍａｔｃｈなどの１タイプのネーミングシステムを、プロセスカラーオブジェクトに関連付け、Ｐａｎｔｏｎｅなどの別のタイプのネーミングシステムを、スポットカラーオブジェクトに関連付けることが可能になる。
【０４７９】
ｐｕｂｌｉｃのベクトルグラフィックスＣｏｌｏｒ型は、下位レベルシステムと一致して、データをその下位レベルシステムに送るときの変換を最小にすることによって、性能を最適化する。浮動小数点値の別々の「ネイティブ」（すなわちＣＭＹＫまたは類似物）セットが、カラーコンテキストに保管され、変更が行われるときに同期化される。ネイティブＣｏｌｏｒＣｏｎｔｅｘｔ  ｃｏｌｏｒＶａｌｕｅは、グレイスケール、ＲＧＢ、およびＣＭＹＫの色空間を透過的にサポートするための、ｆｌｏａｔの配列に基づく値型（構造体）である。ネイティブＣｏｌｏｒＣｏｎｔｅｘｔ  ＣｏｌｏｒＶａｌｕｅ配列は、動的であらねばならず、１つ、３つ、４つ、または８つのカラーチャネルに制限されない。これによって、この同一のアーキテクチャを有する、スペクトル色または縮約されたスペクトル色の処理解決策が可能になる。割り当ての費用が、時々部分的にのみ使用される５要素配列の費用に関してかなり高いが、これによって、将来の一貫性がありコヒーレントで柔軟な解決策が保証され、ｓｃＲＧＢワークフローが使用されるときに、費用がかからないことに留意されたい。Ａｌｐｈａ値は、異なる概念であり、ほとんどの使用で異なって扱われるので、ＣｏｌｏｒＣｏｎｔｅｘｔ  ＣｏｌｏｒＶａｌｕｅと別である。
【０４８０】
【表９１】
2007509426.tif 000138
【０４８１】
【表９２】
2007509426.tif 000139
【０４８２】
システムカラーＵＩオブジェクトのカラー値の入手が、他のより高度なタイプのテーマと同様に、他のコンテキストに依存する可能性があり、アプリケーションモデル／テーマＡＰＩを用いて他のシステムメトリックスと共に収集されなければならないことに留意されたい。
【０４８３】
【表９３】
2007509426.tif 000140
【０４８４】
ｓｃＲＧＢ値が、拡張されたダイナミックレンジおよび域をサポートするために、０．０未満、１．０超の範囲となり得ることに留意されたい。
【０４８５】
Ｃｏｌｏｒオブジェクトの演算子オーバーライドは、色の混合および追加が色空間依存なので、コンテキスト固有である。例えば、ルミナンスＲＧＢ空間は、加算的で線形であり、したがって、通常の数学演算が、かなり直観的であるが、ライトネスＲＧＢ空間ならびにＣＭＹＫ空間は、線形でも加法的でもなく、これによって、これらの演算が、異なる視覚的効果を有する。さらに、ほとんどのＣｏｌｏｒ演算は、所望の域を超える値をもたらすことができ、したがって、域マッピング補償を必要とする。これは、低品質のクランピング程度の単純なものとするか、かなり洗練されたものとすることができる。
【０４８６】
ｓｃＲＧＢが、物理的な光に基づき、線形かつ加算的に混合されるので、具体的にｓｃＲＧＢ  ＣｏｌｏｒＣｏｎｔｅｘｔに制限される場合、一部のアニメーション演算子オーバーロードを提供することができる。ＣＭＹＫ、ｓＲＧＢ、および他の色空間は、非常に異なる混合モデルを有する。
【０４８７】
【表９４】
2007509426.tif 000141
【０４８８】
Ｍｕｌｔｉｃｈａｎｎｅｌカラーに使用されるものと類似するメソッドを使用して、ｓＲＧＢまたはｓｃＲＧＢに密に関係する、ＨＳＢ、ＹＣＣ、ＹＵＶ、および類似する色空間をサポートすることもできる。
【０４８９】
【表９５】
2007509426.tif 000142
【０４９０】
ｓＲＧＢに基づくｒｇｂ形式およびａｒｇｂ形式のｆｌｏａｔ値は、０．０から１．０までのスケールで指定される。定義により、これらの値は、絶対にこの範囲の外にはならず、そのようにクランピングされなければならない。逆に、ｓｃＲＧＢベースの値は、０．０未満および１．０超でも有効である。これらの値は、宛先の装置が拡張された色域をサポートできない場合に限ってクリッピングされなければならない。これは、宛先粋に関連するプロファイルを照会することによって判定することができる。理想的には、ディスプレイについて、グラフィックハードウェアが、ＤＸの域管理機能を使用してこの問題を処理することができる。
【０４９１】
解析される文字列が無効である場合に、カラーは、ＡＲＧＢ＝（０．０，０．０，０．０，０．０）に初期化される。
【０４９２】
持続するときに、値は、色が既知の色として作成された場合には既知の色名として書き込まれる。そうでない場合に、アルファが１．０の場合にはｒｇｂ（ｆｌｏａｔ，ｆｌｏａｔ，ｆｌｏａｔ）形式が使用される。アルファが１．０でない場合には、ａｒｇｂ（ｆｌｏａｔ，ｆｌｏａｔ，ｆｌｏａｔ，ｆｌｏａｔ）形式が使用される。
【０４９３】
ラスタグラフィックスフォーマット、イメージングフォーマット、またはピクセルフォーマットは、上のベクトルグラフィックスソリューションと比較して異なる。単純に言えば、イメージング入力は、白黒からｓＲＧＢ、ｓｃＲＧＢ、ＣＭＹＫまでのサポートされる色空間の種類を有する、１ｂｐｐから１２８ｂｐｐまでのほとんどすべてとすることができる。したがって、ＩｍａｇｅＤａｔａのカラーソリューションは、ＩｍａｇｅＤａｔａフォーマットまたはピクセルフォーマットにＣｏｌｏｒＣｏｎｔｅｘｔを必要とする。これは、標準ファイルフォーマット内の組込みプロファイルまたは組込みガンマおよび色度情報から生成することができる。これによって、ガンマあるいは他の冗長なプロパティまたはフィールドをＩｍａｇｅＤａｔａクラスで提供する必要がなくなる。
【０４９４】
ＭＩＬＲｅｎｄｅｒコードは、３２ｂｐｃカラー指定（ｓｃＲＧＢ）を理解する。入力色変換は、レンダリングコードの上位で行われなければならない（しかし、必ずしも管理されていないコードの外ではない）。
【０４９５】
カラー値のアニメーションは、主に線形空間で行われなければならない。これは、線形化されたＨＳＶ空間またはｓｃＲＧＢとすることができるが、「バウンス（ｂｏｕｎｃｅ）」および他のチャネルごとのアニメーションが意味をもつためには、線形である必要がある。
【０４９６】
下記を含む３つのカラー精度（ｃｏｌｏｒ  ｆｉｄｅｌｉｔｙ）モードを説明する。
【０４９７】
フル−システムを介する３２ｂｐｃ；１２８ｂｐｐバックバッファ／１０−ｂｐｃ＋フロントバッファ；フル３２ｂｐｃ合成
ハイブリッド−３２ｂｐｃカラー仕様／補間；合成前の３２ｂｐｐまでのカラーのディザまたはクランプ
レガシ−３２ｂｐｃカラー仕様−即座に３２ｂｐｐに変換される；３２ｂｐｐ合成／出力
これらのモードは、２つのバックバッファフォーマットすなわち、１２８ｂｐｐ  １．０ガンマ（ｓｃＲＧＢ）および３２ｂｐｐ  ２．２ガンマ（ｓＲＧＢ）を用いてサポートされる。より少ないビット深さ（１６ｂｐｐディスプレイおよび８ｂｐｐディスプレイ）フロントバッファシナリオを処理するためのサポートも提供される。バックバッファは、合成での消失を防ぐためにＰｒｅｓｅｎｔにおいてディザリングされる。
【０４９８】
オブジェクトのＧｅｏｍｅｔｒｙクラスは、ＰｅｎおよびＢｒｕｓｈを用いる２Ｄベクトルベースデータのクリッピング、ヒットテスト、およびレンダリングに使用することができる。派生されるＧｅｏｍｅｔｒｙクラスは、より特定の構築および列挙のセマンティクスを提供する。複数の形状固有Ｇｅｏｍｅｔｒｙ型が提供され、より複雑な形状のＧｅｏｍｅｔｒｙの明示的定義を可能にする一般化されたＰａｔｈＧｅｏｍｅｔｒｙも提供される。ＧＤＩ＋に馴染んだ人にとって、これはＧｒａｐｈｉｃｓＰａｔｈに最も似ている。
【０４９９】
【表９６】
2007509426.tif 000143
【０５００】
Ｇｅｏｍｅｔｒｙは抽象基底クラスである。
【０５０１】
【表９７−１】
2007509426.tif 000144
【０５０２】
【表９７−２】
2007509426.tif 000145
【０５０３】
ｇｅｏｍｅｔｒｙに適用される変換を設定するために、Ｔｒａｎｓｆｏｒｍプロパティを設定する。
【０５０４】
ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎは、定義された領域に対する特定のｂｏｏｌｅａｎ演算を使用して組み合わされた複数のＧｅｏｍｅｔｒｙオブジェクトの集合である。このオブジェクトを用いると、ＰａｔｈＧｅｏｍｅｔｒｙ内のＰａｔｈＦｉｇｕｒｅオブジェクトを厳密に使用することが可能であるよりも簡単に、Ｇｅｏｍｅｔｒｙオブジェクトの視覚的組合せを構築できるようになる。
【０５０５】
組合せモード列挙によって、集合内の形状領域の組合せが指示される。Ｂｏｏｌｅａｎ演算子Ｕｎｉｏｎ、ＸＯＲ、およびＩｎｔｅｒｓｅｃｔは、交換可能であり、したがって、順序独立に形状に適用される。ＣｏｍｐｌｅｍｅｎｔおよびＥｘｃｌｕｄｅは、交換可能ではなく、したがって、第１形状と個々の残りの形状の間で定義される。言い換えると、｛ｇ１，ｇ２，ｇ３｝のｅｘｃｌｕｄｅ組合せは、（（ｇ１  ｅｘｃｌｕｄｅ  ｇ２）および（ｇ１  ｅｘｃｌｕｄｅ  ｇ３）として適用される。Ｃｏｍｐｌｅｍｅｎｔは、既存領域が新しい領域から除去された結果によって既存領域が置換されることを指定する。言い換えると、既存領域が、新しい領域から除外される。Ｅｘｃｌｕｄｅは、新しい領域が既存領域から除去された結果によって既存領域が置換されることを指定する。言い換えると、新しい領域が、既存領域から除外される。Ｉｎｔｅｒｓｅｃｔは、交差をとることによって領域を組み合わせることを指し、ｕｎｉｏｎは、両方の和集合をとることによって領域を組み合わせることを指し、Ｘｏｒは、一方または他方の領域に含まれ、両方には含まれない領域だけをとることによって領域を組み合わせることを指す。
【０５０６】
【表９８】
2007509426.tif 000146
【０５０７】
【表９９−１】
2007509426.tif 000147
【０５０８】
【表９９−２】
2007509426.tif 000148
【０５０９】
【表９９−３】
2007509426.tif 000149
【０５１０】
ＧｅｔＯｐｔｉｍｉｚｅｄＧｅｏｍｅｔｒｙ（）は、可能な場合に形状の集合を縮小し、その結果は、必ずしもＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎではない。これには、隣接する長方形形状の単一の長方形形状への組合せ、新しいパス形状を作成するための隣接するパス形状間のブール演算の実行、または同一の組合せモードを用いるＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎのフラット化などの最適化を含めることができる。形状が多数の異なるコンテキストで使用される状況では、これによって、処理および記憶の性能改善がもたらされる。
【０５１１】
次の例に、ＧｅｏｍｅｔｒｙＣｏｌｌｅｃｔｉｏｎを使用するマークアップ要素を示す。
【０５１２】
【表１００】
2007509426.tif 000150
【０５１３】
ＰａｔｈＧｅｏｍｅｔｒｙは、ＰａｔｈＦｉｇｕｒｅオブジェクトの集合である。ＰａｔｈＦｉｇｕｒｅオブジェクトの各々は、実際にその形状を定義する１つまたは複数のＰａｔｈＳｅｇｍｅｎｔオブジェクトからなる。ＰａｔｈＧｅｏｍｅｔｒｙの塗り潰される領域は、Ｆｉｌｌｅｄプロパティに真を設定された、含まれるＰａｔｈＦｉｇｕｒｅをとり、ＦｉｌｌＲｕｌｅを適用して、囲まれる領域を判定することによって定義される。図１３に、ＰａｔｈＧｅｏｍｅｔｒｙオブジェクトの関係を示す。
【０５１４】
ＦｉｌｌＲｕｌｅ列挙は、Ｇｅｏｍｅｔｒｙに含まれるＦｉｇｕｒｅオブジェクトの交差領域が、Ｇｅｏｍｅｔｒｙの結果の領域を形成するためにどのように組み合わされるかを指定する。
【０５１５】
【表１０１−１】
2007509426.tif 000151
【０５１６】
【表１０１−２】
2007509426.tif 000152
【０５１７】
ＥｖｅｎＯｄｄ規則は、キャンバス上の点から任意の向きで無限遠まで射線を描き、形状のセグメントがその射線と交差する場所を調べることによって、点の「インサイドネス（ｉｎｓｉｄｅｎｅｓｓ）」を判定する。０のカウントから開始して、セグメントが左から右へ射線と交差するたびに１を加算し、パスセグメントが右から左へ射線と交差するたびに１を減算する。交差を数えおわった後で、結果が０であるならば、その点はパスの外にある。そうでない場合には中にある。
【０５１８】
ＮｏｎＺｅｒｏ規則は、キャンバス上の点から任意の向きで無限遠まで射線を描き、射線が横切る所与の形状からのパスセグメントの数を数えることによって、点の「インサイドネス」を判定する。この数が奇数である場合に、点は内側にあり、偶数の場合に、点は外側にある。
【０５１９】
他の形状型を他の図に含めるためにパス形状に変換するには、ＡｄｄＧｅｏｍｅｔｒｙメソッドを使用する。これによって、幾何学的に入力形状と一致する形状が追加される。アニメーションにされない形状について、一致は正確であり、アニメートされる形状は、変換においてロッシイになる可能性がある。ロッシイ変換の理由は、入力形状のアニメーションにされるパラメータが、セグメントがおさまる形と一致しないことである。
【０５２０】
【表１０２】
2007509426.tif 000153
【０５２１】
結果のＰａｔｈＧｅｏｍｅｔｒｙの列挙および構造体は、入力形状と正確に一致することが保証されない。
【０５２２】
図の集合は、ＰａｔｈＧｅｏｍｅｔｒｙを定義する、ＰａｔｈＦｉｇｕｒｅオブジェクトおよび主内容の集合である。
【０５２３】
【表１０３−１】
2007509426.tif 000154
【０５２４】
【表１０３−２】
2007509426.tif 000155
【０５２５】
ＰａｔｈＦｉｇｕｒｅは、セグメント集合を定義する、Ｇｅｏｍｅｔｒｙのサブセクションである。このセグメント集合は、２次元ＰａｔｈＳｅｇｍｅｎｔオブジェクトの単一の接続されたシリーズである。ＰａｔｈＦｉｇｕｒｅは、定義領域を有する閉じた形状とするか、曲線を定義するが囲まれる領域がない接続された一連のＳｅｇｍｅｎｔとすることができる。ＰａｔｈＦｉｇｕｒｅクラスには、ＰａｔｈＳｅｇｍｅｎｔオブジェクトを必要としない、明示的なＡｒｃＴｏ／ＬｉｎｅＴｏ／（および他の）メソッド呼出しからのＰａｔｈＦｉｇｕｒｅのより単純な構築を可能にする複数の便利な関数が含まれる。明示的なＡｄｄＳｅｇｍｅｎｔ呼出しを使用して、構成されたＳｅｇｍｅｎｔを追加することができる。
【０５２６】
【表１０４−１】
2007509426.tif 000156
【０５２７】
【表１０４−２】
2007509426.tif 000157
【０５２８】
【表１０４−３】
2007509426.tif 000158
【０５２９】
図は、各セグメントが最後に追加された点に関して連続性を維持するので、始点を必要とする。始点を指定するには、ＳｔａｒｔＡｔ（ｐｔ）またはＡｄｄ（ｎｅｗ  ＳｔａｒｔＳｅｇｍｅｎｔ（ｐｔ））を呼び出す。セグメントを追加した後に、最後の点を始点に接続する、正しく閉じるセグメントを追加するために、ＣｌｏｓｅＦｉｇｕｒｅ（）またはＡｄｄ（ｎｅｗ  ＣｌｏｓｅＳｅｇｍｅｎｔ（））を使用する。開始セグメントと閉じるセグメントが、セグメント集合に現れる。
【０５３０】
ＰａｔｈＦｉｇｕｒｅが構築され、ＳｔａｒｔＳｅｇｍｅｎｔが集合の最初のセグメントでないか、存在する場合にＣｌｏｓｅＳｅｇｍｅｎｔが集合の最後のセグメントでない場合に、例外が送出される。ＳｔａｒｔＳｅｇｍｅｎｔおよびＣｌｏｓｅＳｅｇｍｅｎｔは、ｆｉｇｕｒｅ内の他の位置では有効でない。例外は、完全に空のセグメント集合である。
【０５３１】
ＰａｔｈＦｉｇｕｒｅ．ＩｓＦｉｌｌｅｄプロパティは、閉じた図に含まれる領域が、ヒットテスト、レンダリング、およびクリッピングに使用されるか否かを明示的に制御する。このプロパティに偽が設定されている場合には、ＰａｔｈＦｉｇｕｒｅの輪郭だけが使用され、それに含まれる領域は、ＰａｔｈＧｅｏｍｅｔｒｙの全体的な領域に寄与しない。このプロパティのデフォルト値は、真である。
【０５３２】
ＰａｔｈＦｉｇｕｒｅの内容を点として列挙するために、簡単な方法の１つが、ｆｉｇｕｒｅをフラット化し、結果のＰａｔｈＳｅｇｍｅｎｔＣｏｌｌｅｃｔｉｏｎを調べることである。フラット化のプロセスは、アニメーションおよび曲線セグメントパラメータに関してロッシイであるが、生の点データが、さらなる点処理のためにＰｏｌｙＬｉｎｅＳｅｇｍｅｎｔを介して公開される。
【０５３３】
ＰａｔｈＳｅｇｍｅｎｔＣｏｌｌｅｃｔｉｏｎは、ＰａｔｈＳｅｇｍｅｎｔオブジェクトと、ＰａｔｈＦｉｇｕｒｅを定義する主要な内容の集合である。
【０５３４】
【表１０５−１】
2007509426.tif 000159
【０５３５】
【表１０５−２】
2007509426.tif 000160
【０５３６】
【表１０５−３】
2007509426.tif 000161
【０５３７】
ＰａｔｈＳｅｇｍｅｎｔは、ＰａｔｈＦｉｇｕｒｅの輪郭のセクションを表す。単純な直線のセグメント、楕円弧のセグメント、３次ベジエセグメント、２次ベジエセグメントを一緒に組み合わせて、ＰａｔｈＦｉｇｕｒｅを形成することができる。
【０５３８】
【表１０６−１】
2007509426.tif 000162
【０５３９】
【表１０６−２】
2007509426.tif 000163
【０５４０】
【表１０６−３】
2007509426.tif 000164
【０５４１】
【表１０６−４】
2007509426.tif 000165
【０５４２】
【表１０６−５】
2007509426.tif 000166
【０５４３】
【表１０６−６】
2007509426.tif 000167
【０５４４】
ＰａｔｈＦｉｇｕｒｅに追加されるＰａｔｈＳｅｇｍｅｎｔオブジェクトのそれぞれは、ＰａｔｈＳｅｇｍｅｎｔ．ＩｓＳｔｒｏｋｅｄプロパティを有する。ＰａｔｈＳｅｇｍｅｎｔが、このプロパティに真を設定されている場合には、その特定のＰａｔｈＳｅｇｍｅｎｔは、Ｐｅｎを用いてレンダリングされるときにＰａｔｈＧｅｏｍｅｔｒｙのストロークされる領域に寄与する。これは、ヒットテストおよびＰａｔｈＧｅｏｍｅｔｒｙの明示的Ｗｉｄｅｎにも適用される。ＰａｔｈＦｉｇｕｒｅの、ストロークされるＰａｔｈＳｅｇｍｅｎｔセクションとストロークされないＰａｔｈＳｅｇｍｅｎｔセクションの間で切り替えるときの特定の挙動は、適当なダッシュキャップ（ｄａｓｈ  ｃａｐ）がＰａｔｈＳｅｇｍｅｎｔの両端に適用されるという点で、破線を指定されたＰｅｎの場合と同一である。
【０５４５】
次のサンプルに、ＰａｔｈＧｅｏｍｅｔｒｙ、ＰａｔｈＦｉｇｕｒｅ、およびＰａｔｈＳｅｇｍｅｎｔを使用するマークアップ要素を示す。
【０５４６】
【表１０７−１】
2007509426.tif 000168
【０５４７】
【表１０７−２】
2007509426.tif 000169
【０５４８】
ＲｅｃｔａｎｇｌｅＧｅｏｍｅｔｒｙは、長方形または角丸長方形ｇｅｏｍｅｔｒｙオブジェクトを定義する。ｒａｄｉｕｓＸおよびｒａｄｉｕｓＹは、丸められた角の軸に位置合せされた半径の長さを指す。
【０５４９】
【表１０８−１】
2007509426.tif 000170
【０５５０】
【表１０８−２】
2007509426.tif 000171
【０５５１】
次のサンプルに、ＲｅｃｔａｎｇｌｅＧｅｏｍｅｔｒｙを使用するマークアップ要素を示す。
【０５５２】
【表１０９−１】
2007509426.tif 000172
【０５５３】
【表１０９−２】
2007509426.tif 000173
【０５５４】
ＥｌｌｉｐｓｅＧｅｏｍｅｔｒｙは、軸に位置合せされたＸ軸およびＹ軸の長さを与えられた楕円形領域を定義する。
【０５５５】
【表１１０−１】
2007509426.tif 000174
【０５５６】
【表１１０−２】
2007509426.tif 000175
【０５５７】
次のサンプルは、ＥｌｌｉｐｓｅＧｅｏｍｅｔｒｙを使用するマークアップ要素を示す。
【０５５８】
【表１１１】
2007509426.tif 000176
【０５５９】
ＬｉｎｅＧｅｏｍｅｔｒｙは、２つの点の間の線分を定義し、したがって、塗潰し領域を含まない。
【０５６０】
【表１１２−１】
2007509426.tif 000177
【０５６１】
【表１１２−２】
2007509426.tif 000178
【０５６２】
次のサンプルは、ＬｉｎｅＧｅｏｍｅｔｒｙを使用するマークアップ要素を示す。
【０５６３】
【表１１３】
2007509426.tif 000179
【０５６４】
（イメージング）
ＩｍａｇｅＳｏｕｒｃｅは、イメージングパイプラインの基本構成要素を含む抽象クラスである。ＩｍａｇｅＳｏｕｒｃｅは、概念上、あるサイズおよび解像度のピクセルの単一で一定の集合を表す。例えば、ＩｍａｇｅＳｏｕｒｃｅは、Ｄｅｃｏｄｅｒが供給できる画像ファイルの単一フレームとすることができ、あるいは、それ自体のあるＩｍａｇｅＳｏｕｒｃｅを操作する変換の結果とすることができる。ＩｍａｇｅＳｏｕｒｃｅは、マルチフレームでもアニメーション作成でもない。ＩｍａｇｅＳｏｕｒｃｅは、変更可能であるが、これは、それ自体のプロパティを変更できるからではなく、そのサブクラスのプロパティを潜在的に変更できるからである。
【０５６５】
性能上の理由から、ＩｍａｇｅＳｏｕｒｃｅｓは、ＩＭＩＬＢｉｔｍａｐＳｏｕｒｃｅインターフェースを使用する、画像への管理されないアクセスの提供をサポートする。ＩｍａｇｅＳｏｕｒｃｅのサブクラスがこれを提供しない場合には、ＩｍａｇｅＳｏｕｒｃｅ基底クラスがそれを行う（ラッパークラスを使用して）。
【０５６６】
【表１１４−１】
2007509426.tif 000180
【０５６７】
【表１１４−２】
2007509426.tif 000181
【０５６８】
【表１１４−３】
2007509426.tif 000182
【０５６９】
ＩｍａｇｅＤａｔａは、ＩｍａｇｅＳｏｕｒｃｅのサブクラスである。ＩｍａｇｅＤａｔａは、複数の異なる画像のソースのＩｍａｇｅＳｏｕｒｃｅを実装する。
【０５７０】
【表１１５−１】
2007509426.tif 000183
【０５７１】
【表１１５−２】
2007509426.tif 000184
【０５７２】
ＩｍａｇｅＤａｔａは、デコードされた画像のシステムメモリでのキャッシング、指定されたソース長方形へ（キャッシュへ）の画像のクロッピング、および指定されたデコード幅および高さへ（キャッシュへ）の画像のサイズ変更を含むサービスを提供する。画像デコーディングシナリオについて、ＩｍａｇｅＤａｔａは、入力ストリームおよびｍｉｍｅ型に基づく、どのデコーダを使用するかまたは自動コーデックディスカバリの指定を可能にする。ＩｍａｇｅＤａｔａは、ＵＲＩから直接の画像の読み込みをサポートしない。ローダを使用して、ＩｍａｇｅＤａｔａを構築するのに使用できるストリームにＵＲＩをマッピングしなければならない。ＩｍａｇｅＤａｔａが構築されたならば、その変更可能なプロパティは、それに埋め込まれたサムネイル、メタデータ、およびピクセルデータだけである。他のプロパティは、非ミュータブルとみなされる。
【０５７３】
ＩｍａｇｅＤａｔａのピクセルデータは、（１）ＩｍａｇｅＤａｔａのＤｒａｗｉｎｇＣｏｎｔｅｘｔを入手し、ＤｒａｗｉｎｇＣｏｎｔｅｘｔを介して画像に描画するコマンドを発行すること、または（２）ＶｉｓｕａｌＭａｎａｇｅｒの宛先（ＲｅｎｄｅｒＴａｒｇｅｔ）としてＩｍａｇｅＤａｔａを使用し、ＩｍａｇｅＤａｔａにビジュアルツリー（場面）をレンダリングするコマンドを発行すること、という２つの形の１つを含めて、変更することができる。どちらの場合でも、描画は、メモリ内の画像に対して行われ、これは、ピクセルデータを、まずデコードし、メモリ内でキャッシングする必要があることを意味する。キャッシングされたメモリ画像だけが、変更され、画像ファイル自体は、（後にＩｍａｇｅＥｎｃｏｄｅｒを使用してＩｍａｇｅＤａｔａを画像ファイルにエンコードしない限り）影響を受けない。
【０５７４】
【表１１６−１】
2007509426.tif 000185
【０５７５】
【表１１６−２】
2007509426.tif 000186
【０５７６】
【表１１６−３】
2007509426.tif 000187
【０５７７】
【表１１６−４】
2007509426.tif 000188
【０５７８】
ＩｍａｇｅＤｅｃｏｄｅｒは、デコーダの基底クラスを提供する抽象クラスである。ＩｍａｇｅＤｅｃｏｄｅｒは、画像内のフレーム数を判定し、フレームを列挙（または索引付け）する形を提供する。上で述べたように、画像フレームは、それぞれがＩｍａｇｅＳｏｕｒｃｅである。組込みコーデックが、各要求されたフレームのＩｍａｇｅＤａｔａオブジェクトを作成する。アドインコーデックは、異なるサブクラスを使用して、フレームごとのＩｍａｇｅＳｏｕｒｃｅを返すことができる。ＩｍａｇｅＤｅｃｏｄｅｒは、ＩｍａｇｅＳｏｕｒｃｅ自体ではなく、１つまたは複数のＩｍａｇｅＳｏｕｒｃｅのコンテナである。画像の各フレームが、潜在的に異なる属性（異なるサイズ、異なる解像度など）を有することができることに留意されたい。
【０５７９】
【表１１７−１】
2007509426.tif 000189
【０５８０】
【表１１７−２】
2007509426.tif 000190
【０５８１】
【表１１７−３】
2007509426.tif 000191
【０５８２】
【表１１７−４】
2007509426.tif 000192
【０５８３】
ＩｍａｇｅＤｅｃｏｄｅｒＢｍｐ．ｃｓ、ＩｍａｇｅＤｅｃｏｄｅｒＧｉｆ．ｃｓ、ＩｍａｇｅＤｅｃｏｄｅｒＩｃｏｎ．ｃｓ、ＩｍａｇｅＤｅｃｏｄｅｒＪｐｅｇ．ｃｓ、ＩｍａｇｅＤｅｃｏｄｅｒＰｎｇ．ｃｓ、ＩｍａｇｅＤｅｃｏｄｅｒＴｉｆｆ．ｃｓ、およびＩｍａｇｅＤｅｃｏｄｅｒＷｍｐ．ｃｓを含む複数の組込みデコーダが、ＭＩＬと共に提供される。各デコーダが、ＩｍａｇｅＤｅｃｏｄｅｒと、次の例のように、デコーダを初期化するのにＳｙｓｔｅｍ．ＩＯ．Ｓｔｒｅａｍを使用する単一のコンストラクタを実装する。
【０５８４】
【表１１８】
2007509426.tif 000193
【０５８５】
ＩｍａｇｅＥｎｃｏｄｅｒは、それぞれが潜在的にそれ自体のメタデータおよびサムネイルを有するＩｍａｇｅＳｏｕｒｃｅ（画像フレーム）の集合である。フレームの集合全体に関連するグローバルサムネイルおよびメタデータも設けることができる。コーデックは、画像をエンコードする方法を決定するのに使用されるエンコーディングプロパティをサポートすることを選択することもできる。フレームの集合を、任意の個数の指定されたストリーム（一時に１つ）に保存（エンコード）することができる。集合を、消去し、その後、異なる集合を書き込み、もう一度保存することができる。
【０５８６】
【表１１９−１】
2007509426.tif 000194
【０５８７】
【表１１９−２】
2007509426.tif 000195
【０５８８】
【表１１９−３】
2007509426.tif 000196
【０５８９】
【表１１９−４】
2007509426.tif 000197
【０５９０】
ＩｍａｇｅＥｎｃｏｄｅｒＢｍｐ．ｃｓ、ＩｍａｇｅＥｎｃｏｄｅｒＧｉｆ．ｃｓ、ＩｍａｇｅＥｎｃｏｄｅｒＪｐｅｇ．ｃｓ、ＩｍａｇｅＥｎｃｏｄｅｒＰｎｇ．ｃｓ、ＩｍａｇｅＥｎｃｏｄｅｒＴｉｆｆ．ｃｓ、およびＩｍａｇｅＥｎｃｏｄｅｒＷｍｐ．ｃｓを含む複数の組込みエンコーダが、ＭＩＬと共に提供される。
【０５９１】
ＩｍａｇｅＳｉｚｅＯｐｔｉｏｎｓは、サムネイルのサイズおよびキャッシングされる画像のサイズを指定するのに使用される。オプションには、幅、高さ、オリジナル画像のアスペクト比を保存するか否か、および回転角度（９０°の倍数）が含まれる。
【０５９２】
【表１２０−１】
2007509426.tif 000198
【０５９３】
【表１２０−２】
2007509426.tif 000199
【０５９４】
【表１２０−３】
2007509426.tif 000200
【０５９５】
【表１２０−４】
2007509426.tif 000201
【０５９６】
次に、画像およびピクセルベースサーフェスのＰｉｘｅｌＦｏｒｍａｔ定義を示す。
【０５９７】
【表１２１−１】
2007509426.tif 000202
【０５９８】
【表１２１−２】
2007509426.tif 000203
【０５９９】
【表１２１−３】
2007509426.tif 000204
【０６００】
【表１２１−４】
2007509426.tif 000205
【０６０１】
各コーデック（ＩｍａｇｅＥｎｃｏｄｅｒおよびＩｍａｇｅＤｅｃｏｄｅｒ）は、ＣｏｄｅｃＩｎｆｏを供給する必要があり、このＣｏｄｅｃＩｎｆｏは、コーデックに関する情報を与え、関連するデコーダ／エンコーダのインスタンス作成メソッドを提供し、このコーデックが、供給されるＣｏｄｅｃＦｉｌｔｅｒと一致するか否かを判定するメソッドを提供する。
【０６０２】
【表１２２−１】
2007509426.tif 000206
【０６０３】
【表１２２−２】
2007509426.tif 000207
【０６０４】
ＣｏｄｅｃＩｎｆｏＢｍｐ．ｃｓ、ＣｏｄｅｃＩｎｆｏＧｉｆ．ｃｓ、ＣｏｄｅｃＩｎｆｏＩｃｏｎ．ｃｓ、ＣｏｄｅｃＩｎｆｏＪｐｅｇ．ｃｓ、ＣｏｄｅｃＩｎｆｏＰｎｇ．ｃｓ、ＣｏｄｅｃＩｎｆｏＴｉｆｆ．ｃｓ、およびＣｏｄｅｃＩｎｆｏＷｍｐ．ｃｓを含む組込みＣｏｄｅｃＩｎｆｏオブジェクトが、ＭＩＬと共に提供される。
【０６０５】
ＣｏｄｅｃＦｉｌｔｅｒは、コーデックエミュレータによって、指定された判断基準に基づいてコーデックを列挙するのに使用される。指定されない判断基準は、一致するコーデックを探すとき、無視される。例えば、ＭｉｍｅＴｙｐｅが設定されない場合、すべてのｍｉｍｅ型を有するコーデックが検討される。
【０６０６】
【表１２３−１】
2007509426.tif 000208
【０６０７】
【表１２３−２】
2007509426.tif 000209
【０６０８】
【表１２３−３】
2007509426.tif 000210
【０６０９】
エミュレータは、構築される（そのｃｔｏｒは内部ｃｔｏｒである）とき、ＣｏｄｅｃＦｉｌｔｅｒを与えられる。そのフィルタは、列挙するコーデックを判定するのに使用される。フィルタ（ある場合に）に一致するコーデックだけが列挙される。
【０６１０】
【表１２４】
2007509426.tif 000211
【０６１１】
ＩｍａｇｅＥｆｆｅｃｔは、ラスタベースイメージング効果の基底クラスである。ＩｍａｇｅＥｆｆｅｃｔは、０個以上の入力および０個以上の出力の集合とみなすことができる。ＩｍａｇｅＥｆｆｅｃｔへの入力および出力のすべてが、ＩｍａｇｅＳｏｕｒｃｅ型である。ＩｍａｇｅＥｆｆｅｃｔは、通常は、その入力およびプロパティを用いて初期化され、その後、その出力が、場面の一部を描画するのに使用されるか、ＩｍａｇｅＥｎｃｏｄｅｒのフレームとして使用される。組込み効果に、ＩｍａｇｅＥｆｆｅｃｔＢｌｕｒ、ＩｍａｇｅＥｆｆｅｃｔＦｌｉｐＲｏｔａｔｅ、ＩｍａｇｅＥｆｆｅｃｔＧａｍｍａＣｏｒｒｅｃｔ、ＩｍａｇｅＥｆｆｅｃｔＧｌｏｗ、ＩｍａｇｅＥｆｆｅｃｔＧｒａｙｓｃａｌｅ、ＩｍａｇｅＥｆｆｅｃｔＮｅｇａｔｅ、ＩｍａｇｅＥｆｆｅｃｔＳｈａｒｐｅｎ、およびＩｍａｇｅＥｆｆｅｃｔＴｉｎｔが含まれる（これに限定されない）。
【０６１２】
（Ｔｒａｎｓｆｏｒｍ）
図７に示すオブジェクトのＴｒａｎｓｆｏｒｍクラスは、ベクトルグラフィックスおよびラスタグラフィックスのスケーリング、回転、変換、および傾斜に使用することができる。派生されるＴｒａｎｓｆｏｒｍクラスは、フレンドリな使用法および列挙のセマンティクスを提供する。ｔｒａｎｓｆｏｒｍクラス階層は、クラスであり、アニメーションおよび列挙のセマンティクスをサポートすることによって、Ｍａｔｒｉｘ構造体と異なる。
【０６１３】
TransformCollection (enumerating semantics, etc.)
TransformCollection.AddScale(...)
Animate MatrixTransform
Ｔｒａｎｓｆｏｒｍは、抽象基底クラスである。
【０６１４】
【表１２５−１】
2007509426.tif 000212
【０６１５】
【表１２５−２】
2007509426.tif 000213
【０６１６】
ＴｒａｎｓｆｏｒｍＣｏｌｌｅｃｔｉｏｎは、その値が個々のＴｒａｎｓｆｏｒｍ値の行列積である、Ｔｒａｎｓｆｏｒｍオブジェクトの集合である。値は、左から右へ、集合の最初のアイテムと最後のアイテムに一致して構成される。
【０６１７】
【表１２６−１】
2007509426.tif 000214
【０６１８】
【表１２６−２】
2007509426.tif 000215
【０６１９】
【表１２６−３】
2007509426.tif 000216
【０６２０】
ＲｏｔａｔｅＴｒａｎｓｆｏｒｍは、特定の中心点（デフォルトは０，０である）の回りのある角度の回転を定義する。角度は、度単位で指定される。点ｘ，ｙの回りの回転角度のｓｔａｔｉｃ行列表現を次に示す。
【０６２１】
【表１２７】
2007509426.tif 000217
【０６２２】
【表１２８】
2007509426.tif 000218
【０６２３】
ＴｒａｎｓｌａｔｅＴｒａｎｓｆｏｒｍは、ｘ方向およびｙ方向の軸に位置合せされた並行移動を定義する。相対位置ｄｘ，ｄｙだけの並行移動のｓｔａｔｉｃ行列表現を次に示す。
【０６２４】
【表１２９】
2007509426.tif 000219
【０６２５】
【表１３０】
2007509426.tif 000220
【０６２６】
ＳｃａｌｅＴｒａｎｓｆｏｒｍは、中心点（デフォルトは０，０）の回りのｘ方向およびｙ方向のスケールを定義する。点ｘ，ｙに関するスケールｓｘ，ｓｙのｓｔａｔｉｃ行列表現を次に示す。
【０６２７】
【表１３１】
2007509426.tif 000221
【０６２８】
【表１３２−１】
2007509426.tif 000222
【０６２９】
【表１３２−２】
2007509426.tif 000223
【０６３０】
ＳｋｅｗＴｒａｎｓｆｏｒｍは、ｘ方向およびｙ方向に沿ったある角度の傾斜を定義する。傾斜角度は、度単位である。ある角度の傾斜のｓｔａｔｉｃ行列表現を次に示す。
【０６３１】
【表１３３】
2007509426.tif 000224
【０６３２】
【表１３４−１】
2007509426.tif 000225
【０６３３】
【表１３４−２】
2007509426.tif 000226
【０６３４】
ＭａｔｒｉｘＴｒａｎｓｆｏｒｍは、その数学的表現を介する変換を定義する。
【０６３５】
【表１３５−１】
2007509426.tif 000227
【０６３６】
【表１３５−２】
2007509426.tif 000228
【０６３７】
Ｔｒａｎｓｆｏｒｍ型のプロパティがマークアップ要素で指定されるとき、プロパティシステムは、Ｔｒａｎｓｆｏｒｍ型コンバータを使用して、ストリング表現を適当なＴｒａｎｓｆｏｒｍ派生オブジェクトに変換する。現在、この構文を使用してアニメーションにされるプロパティを記述する方法はない。
【０６３８】
その構文は、ベクトルグラフィックスであり、対応するＴｒａｎｓｆｏｒｍ構成は、次のように要約されるが、「＜＞」によって示されるパラメータは、オプションのパラメータを表す。
【０６３９】
・matrix(m11 m12 m21 m22 offsetX offsetY)
・AddMatrix(m11, m12, m21, m22, offsetX, offsetY)
・translate(tx <ty>)
・AddTranslate(tx, ty).
・ｔｙが指定されない場合、０であると仮定される。
【０６４０】
・scale(sx <sy>)
・AddScale(sx, sy).
・ｓｙが指定されない場合、ｓｘと同一であると仮定される。
【０６４１】
・rotate(angle <cx> <cy>)
・AddRotate(angle, Point(cx, cy)).
・ｃｘ，ｃｙが指定されない場合、０，０であると仮定される。
【０６４２】
・skewX(angle)
・AddSkew(angle, 0)
・skewY(angle)
・AddSkew(0, angle)
【０６４３】
【表１３６−１】
2007509426.tif 000229
【０６４４】
【表１３６−２】
2007509426.tif 000230
【０６４５】
【表１３６−３】
2007509426.tif 000231
【０６４６】
（Ｅｆｆｅｃｔｓ）
Ｅｆｆｅｃｔｓは、レンダリング中心の形で場面のビジュアル内容を変更する手段を提供する。例えば、ＩｍａｇｅＥｆｆｅｃｔｓ（ラスタに基づくビットマップ効果）は、場面の一部の画像に基づく、完全に合成された表現を操作する。Ｅｆｆｅｃｔｓは、ＩｍａｇｅＥｆｆｅｃｔｓ、ＢｌｅｎｄＭｏｄｅ、およびＶｅｃｔｏｒＥｆｆｅｃｔを含む様々な型に分解される。
【０６４７】
ＩｍａｇｅＥｆｆｅｃｔｓは、サブグラフまたはＥｌｅｍｅｎｔに適用することによってリテインモード場面で使用することができ、独立型の画像パイプラインで使用することができる。一般に、ＩｍａｇｅＥｆｆｅｃｔは、０個以上の入力および０個以上の出力を有し、この入力および出力は、ＩｍａｇｅＳｏｕｒｃｅ型である。即時モード画像パイプラインでは、ＩｍａｇｅＥｆｆｅｃｔが、その入力の属性を記述する他のプロパティの表面を処理できるので、出力がある必要はない。例えば、ＩｍａｇｅＥｆｆｅｃｔは、カラーヒストグラム情報または面検出情報を発することができる。リテインモード場面では、効果が適用されるサブグラフのレンダリングされた内容へのアクセスを提供する追加のメタ入力がある。
【０６４８】
【表１３７−１】
2007509426.tif 000232
【０６４９】
【表１３７−２】
2007509426.tif 000233
【０６５０】
【表１３７−３】
2007509426.tif 000234
【０６５１】
【表１３７−４】
2007509426.tif 000235
【０６５２】
ＢｌｅｎｄＭｏｄｅｓは、画像に基づく効果の特定の形である。ＢｌｅｎｄＭｏｄｅｓは、全般的にＩｍａｇｅＥｆｆｅｃｔｓと同一の形でリテインモード場面に適用することができる。したがって、ＶｉｓｕａｌのＥｌｅｍｅｎｔプロパティ（「ＢｌｅｎｄＭｏｄｅ」）ならびにＢｌｅｎｄＭｏｄｅプロパティ、ＩＤｒａｗｉｎｇＣｏｎｔｅｘｔのＰｕｓｈＢｌｅｎｄＭｏｄｅメソッド、およびＢｒｕｓｈのＢｌｅｎｄＭｏｄｅプロパティがある。ブレンドモードは、ソースが合成されるとき、ソースカラーと宛先カラーの組合せを実行する。ブレンドモードの例に、Ｍｕｌｔｉｐｌｙ、Ａｄｄなどが含まれる。ＶｅｃｔｏｒＥｆｆｅｃｔｓが、もう一種類の効果である。概要で説明したように、ＢｌｅｎｄＭｏｄｅｓは、画像が別の画像または場面に合成される形を制御する演算を記述する。ＢｌｅｎｄＭｏｄｅｓは、場面およびＢｒｕｓｈに適用することができる。各ＢｌｅｎｄＭｏｄｅは、ソースピクセルと宛先ピクセルを組み合わせる形を記述し、合成されるすべてのピクセルに適用される。ＢｌｅｎｄＭｏｄｅｓは、ソースがスケーリングまたは他の形で変換され、すべての効果（Ｏｐａｃｉｔｙを含む）が適用された後に適用される。ＢｌｅｎｄＭｏｄｅ演算が適用されるとき、ソースおよびデスティネーションが、事前に乗算されたアルファフォーマット（ｐｒｅ−ｍｕｌｔｉｐｌｉｅｄ  ａｌｐｈａ  ｆｏｒｍａｔ）であることに留意されたい。ＢｌｅｎｄＭｏｄｅを指定するには、プログラマは、ＢｌｅｎｄＭｏｄｅｓ  ｓｔａｔｉｃクラスで指定されるＢｌｅｎｄＭｏｄｅの１つを使用するか、ソース乗数および宛先乗数を明示的に設定することができる。一実施形態で、乗数が拡張可能でなく、パラメータを有しないので、乗数は、列挙型によって表される。
【０６５３】
【表１３８−１】
2007509426.tif 000236
【０６５４】
【表１３８−２】
2007509426.tif 000237
【０６５５】
【表１３８−３】
2007509426.tif 000238
【０６５６】
（ヒットテスト）
ヒットテストは、場面のビジュアルを選択するのに使用される。ある上位レベルシナリオに、なげ縄（ｌａｓｓｏ）選択とゴム紐（ｒｕｂｂｅｒ  ｂａｎｄ）選択、（フォーカスを切り替える次の要素を選択するのに使用される）キーボードナビゲーション、要素ツリー内のマウスフォーカスの判定、透明度を有する重複する要素の選択（画像など）、「ソートバブル（ｔｈｏｕｇｈｔ  ｂｕｂｂｌｅ）」ヒットテスト、ならびにテキスト内のキャラクタヒットの選択が含まれる。
【０６５７】
一般に、ヒットテストは、Ｃｏｒｅ、Ｆｒａｍｅｗｏｒｋ、およびＣｏｎｔｒｏｌｓの間の一貫性をもたらし、コントロールツリーの最上部から始め、点または形状によって１つのコントロールまたはコントロール群を返すことによって動作する。コントロールは、レンダリング形状、境界ボックス、アウトオブバンド形状（ヒット領域）、画像不透明度またはマスク、およびそれ自体のロジックを含むサポートサービスを用いて、ヒットされたか否かを定義することができる。コントロールは、ヒットに関する特定のヒット関連データ（例えば、直線、キャラクタ位置など）を返すことができる。
【０６５８】
ヒットテスト機構は、効率的な形でヒットテスト結果をフィルタリングすることができる。さらに、ヒットテスト機構は、他のタイプのＶｉｓｕａｌに拡張し、Ｖｉｓｕａｌ内のサブプリミティブまで解決する柔軟性を提供し、例えば、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌがその一例である。
【０６５９】
ヒットテストウォークは、ビジュアルツリーの深い右から左へのウォークである。３つの参加者すなわち、ヒットテスタ、ウォーカ、およびコントロール／ビジュアルがある。ヒットテスタは、２つのコールバックすなわち、ウォーカを導くコールバックと、あるヒットビジュアルで探索を早期終了させるコールバックを実装する。コントロールは、ヒットするものを定義する仮想メソッドを実装する。ウォーカは、システムの固定された部分であり、コールバック挙動に基づいて、本質的にコントロールがヒットしたかどうかを各コントロールに尋ねて、ビジュアルツリーを探索する。ヒットは、ｚ順で、上から下の形でコールバックを介して報告される。
【０６６０】
したがって、内部的に、ヒットテストにビジュアルツリーの探索が含まれる。下降するときに、ヒットテスタは、例えば形状を有するキャンバス、または内側キャンバスを有するドックパネルなど、要素レベル関係に関してフィルタリングを見る。ヒットが発生するときに、ヒットテスタは、さらなるヒットの処理（存在する場合に）を継続するか、停止することができる。
【０６６１】
ヒットウォーカの展望からの制御フロー論理を、次の擬似コードに示す。
【０６６２】
【表１３９】
2007509426.tif 000239
【０６６３】
ヒットテスタは、ｐｕｂｌｉｃメソッドを使用して、ヒットテストを開始し、挙動を制御する委任を提供する。デフォルト挙動は、すべてのビジュアルをテストし、最初のヒットを返すことである。結果の委任が与えられない場合には、例外を送出する。
【０６６４】
コントロールは、点および形状のＨｉｔＴｅｓｔＣｏｒｅをオーバーライドすることによって、ヒットテスト論理を判断する。ヒットテストが開始されるとき、内部ビジュアルツリーウォーカが、ＨｉｔＴｅｓｔＣｏｒｅを呼び出し、効果的にヒットされたか否かをコントロールに尋ねる。ＨｉｔＴｅｓｔＢｏｕｎｄｓは、ヒット領域の閉じた境界を反映し、探索を最適化するのに使用される。デフォルトビジュアル挙動は、レンダコンテキスト境界ボックスに対するテストである。デフォルトヒット境界は、レンダコンテキスト境界ボックスである。
【０６６５】
【表１４０−１】
2007509426.tif 000240
【０６６６】
【表１４０−２】
2007509426.tif 000241
【０６６７】
ヒットテスタは、ヒット点または形状と追加パラメータをＨｉｔＴｅｓｔＰａｒａｍｅｔｅｒｓで渡すことによってヒットテストを開始する。このクラスは、主に、設計を単純にし、拡張性を進行できるようにするために提供される。特殊なヒットテスト要求をこのクラスから派生させて、関係するコントロールに追加情報を渡すことができる。各コントロールは、点および形状に対する特定のＨｉｔＴｅｓｔＣｏｒｅを実装する。コントロールは、そのＨｉｔＴｅｓｔＣｏｒｅロジックを実装するとき、ヒットテストパラメータを尊重することが期待される。
【０６６８】
【表１４１−１】
2007509426.tif 000242
【０６６９】
【表１４１−２】
2007509426.tif 000243
【０６７０】
【表１４１−３】
2007509426.tif 000244
【０６７１】
コントロールは、ＨｉｔＴｅｓｔＲｅｓｕｌｔから派生することによって特定のデータを返す。例えば、テキストコントロールは、キャラクタ位置ヒットを返すことを望む場合がある。ＰｏｉｎｔＨｉｔＴｅｓｔＲｅｓｕｌｔに、ローカル座標空間の点が含まれる。ＧｅｏｍｅｔｒｙＨｉｔＴｅｓｔＲｅｓｕｌｔに、（オリジナルヒットテストの）ローカル座標空間の形状が含まれる。ビジュアル変換関数は、ヒット位置を先祖空間にマッピングすることができる。
【０６７２】
【表１４２−１】
2007509426.tif 000245
【０６７３】
【表１４２−２】
2007509426.tif 000246
【０６７４】
委任の使用を例示するために、まず匿名委任を使用して最初の一番上のヒットを求めるヒットテスタを検討されたい。
【０６７５】
【表１４３】
2007509426.tif 000247
【０６７６】
もう１つの例が、ヒットしたビジュアルのすべてを返すことを求めるヒットテスタである。
【０６７７】
【表１４４−１】
2007509426.tif 000248
【０６７８】
【表１４４−２】
2007509426.tif 000249
【０６７９】
ヒットテスタは、列挙を使用して、ヒットテストフィルタリングおよび結果の挙動を制御する。
【０６８０】
【表１４５】
2007509426.tif 000250
【０６８１】
ＨｉｔＴｅｓｔＦｉｌｔｅｒＢｅｈａｖｉｏｒ列挙は、ＳｋｉｐＣｈｉｌｄｒｅｎを指定することによって、子ビジュアルではなくこのビジュアルがヒットテストされるという点で、フィルタリング挙動を制御する。ＳｋｉｐＶｉｓｕａｌＡｎｄＣｈｉｌｄｒｅｎは、ビジュアルまたは子ビジュアルをヒットテストしないことを指定する。ＳｋｉｐＶｉｓｕａｌは、ビジュアルをヒットテストするのではなく、すべての子ビジュアルをヒットテストすることを指定する。Ｃｏｎｔｉｎｕｅは、このビジュアルおよびその子ビジュアルをヒットテストすることを指定する。Ｓｔｏｐは、ビジュアルツリーのビジュアルをヒットテストせず、呼出し元に返すことを指定する。
【０６８２】
ＨｉｔＴｅｓｔＲｅｓｕｌｔＢｅｈａｖｉｏｒ列挙は、ヒットテスタ挙動を制御する。
【０６８３】
【表１４６】
2007509426.tif 000251
【０６８４】
Ｓｔｏｐは、ヒットテストエントリに返し、さらなるフィルタ演算またはヒットテスト演算をスキップすることを指定する。Ｃｏｎｔｉｎｕｅは、次のビジュアルに対してヒットテストを実行することを指定する。
【０６８５】
ヒットテスト識別子を、肯定のヒット識別に関して特定の内容をマークするのに使用することができる。しかし、そのようなモデルは、レンダストリームを分解し、ウォークオーバーヘッドに追加され、ヒットテストのときに管理が難しいため、性能が低かった。要素とビジュアルを統一された型に組み合わせることによって、粒度の基礎レベルが、ビジュアル自体になり、コントロールが、望みの粒度のレベルを得るためにそれ自体を構成できるようになる。
【０６８６】
コントロール作成者は、ＨｉｔＴｅｓｔＣｏｒｅをオーバーライドし、それ自体の計算を行い、かつ／または下で説明するサービスを使用することによって、論理を記述する。
【０６８７】
次は、これらのサービスの能力を示す例である。
【０６８８】
第１の例では、コントロールのヒットセンシティブ領域を表すｐｕｂｌｉｃのＨｉｔＲｅｇｉｏｎプロパティを有するコントロールを示す。ヒット領域が、レンダリングされる内容と一致する必要がなく、応用例によって最適化できることに留意されたい。ヒット領域が設定されない（＿ｈｉｔＲｅｇｉｏｎ＝＝ｎｕｌｌ）場合、コントロールは、ヒットを判定するために基底実装サービスを延期する。
【０６８９】
【表１４７−１】
2007509426.tif 000252
【０６９０】
【表１４７−２】
2007509426.tif 000253
【０６９１】
ＩｓＨｉｔ挙動をオーバーライドするには、追加のサポートサービスを使用する。
【０６９２】
Ｇｅｏｍｅｔｒｙクラスは、その内側領域に対してヒットテストを実行する。
【０６９３】
【表１４８】
2007509426.tif 000254
【０６９４】
ビジュアルは、レンダリングされる内容（それ自体の）に対するヒットテストのためのｐｒｏｔｅｃｔｅｄ関数を提供する。ビジュアルが保持される場合、これによって、内容検証がトリガされる。このヘルパは、ビジュアルに保管された描画命令ストリームを一時に１命令ずつ検査し、レンダリングされる形状に関して各命令の点または形状をヒットテストする。
【０６９５】
【表１４９】
2007509426.tif 000255
【０６９６】
コードは、点の画像ピクセルがアルファ閾値を超える場合にリターンする。その点は、ビジュアル空間内にあり、変換は、ピクセルベーステストが行われる装置空間への変換である。
【０６９７】
public class ImageData: ImageSource
【０６９８】
【表１５０】
2007509426.tif 000256
【０６９９】
（アニメーション）
アニメーションシステムは、コンポーネントの２つの主要な集合すなわち、タイミングコントロールエンジンと、アニメーションオブジェクトの集合からなる。タイミングエンジンは、時間依存性挙動を示すすべてのオブジェクトによって使用することができるサービスであり、主な例は、アニメーションオブジェクトおよび音声媒体オブジェクトまたはビデオ媒体オブジェクトである。アニメーションオブジェクトは、タイムスパンを他のデータ型にマッピングする関数の組を実装し、このデータ型は、他の上位レベルオブジェクトへの入力として使用される。
【０７００】
グラフィカルアニメーションは、アニメーション集合をレンダリング動作に関連付けることによって達成される。例えば、ＩＤｒａｗｉｎｇＣｏｎｔｅｘｔ．ＤｒａｗＬｉｎｅメソッドは、ペンと２つの端点をとる。端点の１つを、ＰｏｉｎｔＡｎｉｍａｔｉｏｎオブジェクトの集合に関連付けることができ、この場合に、線が経時的に移動する。同様に、ペンは、ＣｏｌｏｒＡｎｉｍａｔｉｏｎオブジェクトの関連する集合を有することができる。その場合に、レンダリング動作で使用される各アニメーションが、時々「タイムライン」と称する、別々のクロックで動作することができる。アニメーションにされるプリミティブが描画されたならば、レンダリングシステムは、定期的な間隔で場面の再描画を処理する。フレームがレンダリングされるたびに、場面に含まれるアニメーションの現在値が、（ほとんどの場合にシステムクロックによって測定される）経過時間に基づいて計算され、アニメーションにされるプリミティブが再描画される。
【０７０１】
アニメーションのプログラミングは、システムによって提供されるアニメーションオブジェクトならびにこれらのアニメーションを駆動するタイミングエンジンの両方の理解を必要とする。次の用語が、このセクションの複数の場所で使用される。
【０７０２】
時間指定されたオブジェクト（ｔｉｍｅｄ  ｏｂｊｅｃｔ）が階層タイミングシステムに参加し、この階層タイミングシステムで、個々のタイムラインが、その親タイムラインに関するまたはトップレベルタイムラインの場合にルート「文書」（または「ページ」または「フレーム」）タイムラインに関する挙動を定義する属性を有するタイミングモデルが提供される。タイミング属性は、オブジェクトの時間挙動を定義するパラメータ群である。タイミング属性は、排他的に記述的であり、ランタイム状態を有しない。さらに、タイミング属性は、非ミュータブルである。
【０７０３】
タイムラインは、タイミング属性群に従ってランタイム状態を維持するタイミングエンティティのインスタンスである。タイムラインは、時間指定されたオブジェクトの「現在」と言う概念を定義する。タイミングツリーは、階層的な形で配置されたタイムラインの組を含むデータ構造である。タイムラインの間の関係は、継承規則群と、各タイムラインに関連するタイミング属性によって定義される。
【０７０４】
時間指定されたオブジェクトは、時間依存性挙動を示すオブジェクトである。時間指定されたオブジェクトの時間挙動の記述は、タイミング属性群によって指定され、そのランタイムタイミング状態は、１つまたは複数のタイムラインによって維持される。アニメーション関数は、入力として特定のデータ型のベース値をとり、出力として同一の型の値を作る関数である。アニメーション関数は、Ｔｉｍｅｌｉｎｅの現在時刻値など、他の暗黙のまたは明示的な入力パラメータをとってもとらなくてもよい。それに関して、アニメーション関数は、同一の入力が異なるときに異なる出力を作る場合があるという点で、一定でないものとすることができる。
【０７０５】
修飾子は、アニメーション関数を実施するオブジェクトであり、Ｅｌｅｍｅｎｔまたは他の複合オブジェクトのプロパティの値またはレンダリング呼出しへのパラメータを変更するのに使用される。時間指定された修飾子は、Ｔｉｍｅｌｉｎｅに関連する修飾子であり、そのアニメーション関数は、そのＴｉｍｅｌｉｎｅのランタイム状態に明示的に依存する。アニメーションは、アニメーション関数のある既知の集合を実装する時間指定された修飾子である。
【０７０６】
アニメーション集合は、同一のデータ型を処理する修飾子の集合である。アニメーション集合は、ある修飾子の出力を別の修飾子の入力に連鎖し、変更するパイプラインを作成する。集合全体が、１つの入力を取り、１つの出力を作るので、集合自体が、１つの修飾子として振る舞う。
【０７０７】
タイムラインは、ビデオクリップまたはアニメーションの再生などの時間依存性プロセスを制御するストップウォッチと考えることができる。タイムラインの属性で指定される時間は、何かに対する相対的な時間である。ほとんどの場合に、この時間は、親タイムラインに関するが、ツリーのルートのタイムラインに関しては、値が、「文書時間」に関し、文書時間は、アプリケーションが起動されるときあるいはページまたはフレームが誘導されるときに開始される暗黙のタイムラインである。タイムラインのクロックは、２つの形すなわち、開始点からの相対位置として、または０と１の間のプログレス比として公開される。後者は、単に、持続時間に対する現在時刻の比率である。
【０７０８】
最も単純なタイムラインは、開始時刻と持続時間である。例えば、３秒の開始時刻と５秒の持続時間を有するタイムラインは、基準ｔ＝０時（デフォルトで、アプリケーションがロードされる瞬間）の３秒後に「始まり」、その５秒後に「終了する」。この５秒間の間、タイムラインが「オン」であると言う。このタイムラインがアニメーションを制御する場合に、このアニメーションは、その時間の間は変化している（例えば移動している）が、その前と後は静的である。図２９に、３のＢｅｇｉｎ時刻および５のＤｕｒａｔｉｏｎを有するタイムラインを示す。
【０７０９】
タイムラインは、その挙動を繰り返すようにプログラムすることもできる。この繰り返しは、反復カウントまたは反復持続時間として指定することができる。タイムラインは、要求されたカウントまたは持続時間を満たすために、必要なだけ先頭から終りまで繰り返される。反復カウントが整数値でない場合には、最後の反復が、途中で中断される。図３０に、（アニメーションが、開始時刻の１７秒後または２０秒まで、５秒ごとに繰り返されることを意味する）Ｂｅｇｉｎ＝３、Ｄｕｒａｔｉｏｎ＝５、およびＲｅｐｅａｔＤｕｒａｔｉｏｎ＝１７のタイムラインを示す。
【０７１０】
タイムラインの開始時刻は、通常は、その親タイムライン（または文書時刻）に関するが、開始時刻を、別のタイムラインの先頭または終りに関して指定することもできる。その場合に、ソースタイムラインのすべての先頭（または終り）が、対象タイムラインの対応する始まりのスケジューリングを引き起こす。図３１に、別のタイムラインの３秒後に開始されるタイムラインを示す。
【０７１１】
タイムラインは、終点に達するとき、即座に「オフ」にされる。そのとき、そのタイムラインが制御する時間指定されたオブジェクトが、プレゼンテーションに対する影響を有しなくなる。例えば、時間指定されたオブジェクトが、アニメーションである場合に、制御するタイムラインが終点に達するとき、アニメーションが除去される、すなわち、ベース値に戻される。しかし、アニメーションの最終的な定常状態を最後の値で凍結することが望ましい場合がある。言い換えると、このタイムラインは、始点と終点の間で０から１まで進行するが、終点の後に、１のプログレスで「オン」のままになる。これを、「フィル」挙動と呼ぶ。図３２に、Ｂｅｇｉｎ＝３、Ｄｕｒａｔｉｏｎ＝５、およびＦｉｌｌ＝Ｆｒｅｅｚｅのタイムラインを示す。
【０７１２】
時間は、タイムラインの観点からは、０のプログレス値から１のプログレス値まで線形に流れる。しかし、タイムラインの内部の時間の経過とその親の内部の時間の経過との間の関係は、タイムラインで時間を逆転し、その結果、逆に流れるように見せることができ、時間が経過する速度を乗算係数によって加速または減速でき、かつ／またはプログレス曲線を変形し、その結果、０から１に線形に進行するのではなく、始点での静止状態から最高のプログレス速度まで加速し、その後、終点での静止状態に向かって減速することができるという点で変更することができる。これによって、このタイムラインによって制御されるアニメーションの「イーズイン、イーズアウト（ｅａｓｅ−ｉｎ，ｅａｓｅ−ｏｕｔ）」効果が作られる。
【０７１３】
具体的に言うと、プログレス／時間曲線は、デフォルトでは線形である。この線形曲線があるアニメーションの制御に使用されるとき、ユーザは、アニメーションが突然始まり、突然終わるので、始点と終点で「急に動く」効果を感じる。この場合に、タイムラインをプログラムして、滑らかな加速曲線を使用して、時間の経過を静止から最大速度まで加速するようにプログラムすることができる。同様に、時間をプログラムして、終点近くで０に向かって減速することができる。加速効果および減速効果は、加速フェーズまたは減速フェーズで費やされる持続時間の比率として指定される。この２つの値は、正であり、その合計は１を超えない。図３３に、Ｂｅｇｉｎ＝３、Ｄｕｒａｔｉｏｎ＝１０、Ａｃｃｅｌｅｒａｔｉｏｎ＝０．２、およびＤｅｃｅｌｅｒａｔｉｏｎ＝０．４のタイムラインを示す。
【０７１４】
１つの簡単な時間操作に、０から１のプログレス値に進み、０に戻るタイムラインのプログラミングが含まれる。その場合に、タイムラインは、指定された持続時間の２倍、一方は「順方向」部分、他方は「逆方向」部分の間、アクティブになる。図３４に、Ｂｅｇｉｎ＝３、Ｄｕｒａｔｉｏｎ＝５、およびＡｕｔｏＲｅｖｅｒｓｅ＝Ｔｒｕｅのタイムラインを示す。
【０７１５】
タイムラインに関する明白な時間の経過は、その親に関して、定数係数だけ高速または低速とすることができる。デフォルトで、この係数は１であり、タイムラインの時間と親の時間が同じ速度で進むことを意味する。その代わりに、この値が１より大きい場合には、タイムラインの時間は、親より速い速度で進む。例えば、３の係数によって、タイムラインが、始点と終点の間において、指定された持続時間より３倍速く進む。逆に、係数が０と１の間であるとき、時間はより遅い速度で進む。係数が負である場合には、タイムラインの時間は、必ずその親に対して逆に進むように見える。開始時刻自体が、親タイムラインの基準のフレーム内の相対位置であることに留意されたい。その結果、タイムラインの持続時間は速度係数によって影響されるが、開始時刻は影響されない。図３５に、Ｂｅｇｉｎ＝３、Ｄｕｒａｔｉｏｎ＝５、およびＳｐｅｅｄ＝０．５のタイムラインを示す。
【０７１６】
タイムラインを、ツリー構造で編成することができる。すべての文書、フレーム、またはウィンドウは、ある暗黙の「ルート」タイムラインを有し、これは、実世界の壁掛時計の時間を表すと考えることができる。しかし、ルートタイムラインの時刻ｔ＝０は、そのタイムラインが作成された時刻すなわち、文書がロードされたか、フレームが誘導されたか、ウィンドウが開かれた時刻である。
【０７１７】
タイミングシステムの階層的な性質を与えられて、時間の経過を、基準の３つのフレームの１つにおける発生と呼ぶことに意味が生じる。基準の単純フレームは、個々のタイムラインによって経験される基準のフレームである。基準のこのフレームでは、タイムラインのプログレス値が、必ずｔ＝０で０、ｔ＝ｄで１であり、ｄは、タイムラインの単純な持続時間である。タイムラインの持続時間は、必ず、基準の単純フレームで指定される。親タイムラインの基準のフレームは、所与のタイムラインの親のタイムラインに関する基準の単純フレームである。例えば、あるタイムラインのＢｅｇｉｎ時刻は、必ず、親タイムラインの基準のフレームで指定される。基準のグローバルフレームは、ルートタイムラインの基準の単純フレームである。基準のそのフレームでは、時刻ｔ＝５ｓが、タイムラインが作製されてから５秒後に発生し、１０ｓの持続時間が、正確に実世界の１０秒だけ続く。
【０７１８】
さらに、タイムラインがアクティブである場合に、その親タイムラインもアクティブである必要があることを含む、様々なタイミング制御規則がタイミングサブツリーに適用される。逆に、タイムラインがアクティブでない場合に、その子のどれもがアクティブであってはならず、開始することができない。タイムラインが明示的に一時停止される（ＩＴｉｍｉｎｇＣｏｎｔｒｏｌ．Ｐａｕｓｅメソッドへの呼び出しを介して）場合に、その子も、暗黙のうちに一時停止される。そのタイムラインが再開されるとき、明示的に一時停止されたのでないすべての子も再開される。（繰り返し点を超えることを含む様々な理由のいずれかで）タイムラインが開始される場合に、子は初期化される。
【０７１９】
タイムラインは、別のタイムラインを明示的に親とすることができ、この場合に、タイムラインツリーの形状は、明示的かつ明瞭である。しかし、多くの場合、あるデフォルトのタイミング親に基づいて、システムに自動的にタイムラインを親に指定させることが有用である。明示的に親に指定されないタイムラインを、オートペアレンティグされている（ａｕｔｏ−ｐａｒｅｎｔｅｄ）と言い、その有効な親タイムラインは、そのタイムラインの使われ方に依存する。２種類のオートペアレンティングすなわち、ビジュアルの親へのペアレンティングまたはルートへのペアレンティングがサポートされる。
【０７２０】
タイムラインのビジュアルの親は、タイムラインの使われ方によって暗黙のうちに決定される。例えば、タイムラインがカラーアニメーションを制御し、そのアニメーションが、あるビジュアルＶの背景として使用されるブラシをアニメーションにする場合に、Ｖが、そのタイムラインの「ビジュアルの親」である。そのＶｉｓｕａｌが、関連するデフォルトタイムラインを有する場合に、そのタイムラインが、この例のオリジナルのタイムラインの親である。そうでない場合に、Ｖｉｓｕａｌの親は、再帰的に調べられる。Ｖｉｓｕａｌツリーのルートは、必ず、ルートタイムラインに暗黙に関連し、したがって、Ｖｉｓｕａｌが、そのＶｉｓｕａｌツリーに含まれる場合に、そのツリー内の任意のオートペアレンティングされたタイムラインが、タイミングツリー内のどこかで親とされていることが保証される。しかし、ＶｉｓｕａｌがまだＶｉｓｕａｌツリーに含まれない場合には、そのタイムラインは、Ｖｉｓｕａｌがツリーに挿入されるなどのときまで、タイミングツリーの外部に留まる。
【０７２１】
デフォルトの「ルート」タイムラインは、ビジュアルの親子関係によって定義されるが、これは、その場合に、タイムラインを有する最も近いＶｉｓｕａｌの親が必ずしも使用されないことを除く。そうではなく、ルートの親子関係では、タイムラインが、必ずツリー内で最上位のＶｉｓｕａｌに関連する（これは、ＦｒａｍｅオブジェクトまたはＷｉｎｄｏｗオブジェクトであるか、ＶｉｓｕａｌＭａｎａｇｅｒに関連するルートＶｉｓｕａｌになる場合がある）。
【０７２２】
タイムラインが自動的にペアレンティングされたならば、暗黙のデフォルト親タイムラインを変更することが起きた場合、再ペアレンティングの必要が生じる場合がある。例えば、タイムラインの直接のビジュアルの親が、当初はそれ自体のデフォルトタイムラインを有しなかったが、後に設定された場合、タイムラインを再ペアレンティングする必要がある。この再ペアレンティングは、自動的に行われる。オートペアレンティングと再ペアレンティングは、後述するＩＡｎｉｍａｔａｂｌｅインターフェースによって実施される。
【０７２３】
タイムラインオブジェクトおよび時間指定されたオブジェクトは、複数の共通の挙動を共有する。例えば、アニメーションを、一時停止または再開することができ、アニメーションのリストを、アクティブまたは非アクティブにすることができる。一貫性を保つために、時間指定されたオブジェクトは、タイミングメソッドおよびタイミングプロパティへのアクセスを可能にする１つまたは複数のインターフェースを実装する。
【０７２４】
ＩＴｉｍｉｎｇＣｏｎｔｒｏｌインターフェースは、ランタイムに制御できる時間指定されたオブジェクトによって実装される。
【０７２５】
【表１５１−１】
2007509426.tif 000257
【０７２６】
【表１５１−２】
2007509426.tif 000258
【０７２７】
【表１５１−３】
2007509426.tif 000259
【０７２８】
次の表に、ＩＴｉｍｉｎｇＣｏｎｔｒｏｌインターフェースのセマンティクスを要約する。
【０７２９】
メソッド、プロパティ、またはイベント          意味
Ａｃｃｅｌｅｒａｔｉｏｎ                      時間加速フェーズで費やされる単純
持続時間の分数を表す、０と１の間
の値。この属性とＤｅｃｅｌｅｒａ
ｔｉｏｎ属性の合計が、１を超えて
はならない。
【０７３０】
ＡｕｔｏＲｅｖｅｒｓｅ                        この属性が「Ｔｒｕｅ」である場合
に、タイムラインは、始めから終り
まで進行し、即座に終りから始めに
逆に進行する。その場合に、タイム
ラインは、Ｄｕｒａｔｉｏｎ属性に
よって指定される時間の２倍だけア
クティブになる。
【０７３１】
Ｂｅｇｉｎ                                    このタイムラインが開始される時刻
。デフォルトで、この時刻は親タイ
ムラインの開始時刻であるが、他の
タイムラインの開始または終了に対
する相対位置を指定することもでき
る。後者の場合に、他のタイムライ
ンは、これと同一のタイムラインに
ペアレンティングされる。
【０７３２】
ＢｅｇｉｎＩｎ                                将来または過去の指定された時点で
のインタラクティブな開始をトリガ
する。パラメータは、このタイムラ
インの親タイムラインの基準のフレ
ームで指定される。親タイムライン
がアクティブでない場合には、この
メソッドは効果がない。
【０７３３】
Ｂｅｇｕｎ                                    オブジェクトが、内部状態が継続的
に変更される期間に入るときに必ず
送出される。
【０７３４】
Ｃｈａｎｇｅｄ                                修飾子の内部状態が変化するとき、
必ず修飾子によって送出される。
【０７３５】
Ｅｎｄｅｄ                                    オブジェクトが、内部状態が継続的
に変更される期間から出るとき、必
ず送出される。
【０７３６】
ＣｕｒｒｅｎｔＲｅｐｅａｔ                    タイムラインが繰り返される場合の
、タイムラインの現在の反復。最初
の反復は、反復１である。ＩｓＯｖ
ｅｒｒｉｄｉｎｇＢａｓｅＶａｌｕ
ｅが偽の場合には、このプロパティ
は０を返す。
【０７３７】
ＣｕｒｒｅｎｔＴｉｍｅ                        このタイムラインにローカルな現在
時刻。ＩｓＯｖｅｒｒｉｄｉｎｇＢ
ａｓｅＶａｌｕｅが偽の場合には、
このプロパティはＴｉｍｅ．Ｕｎｓ
ｐｅｃｉｆｉｅｄを返す。
【０７３８】
Ｄｅｃｅｌｅｒａｔｉｏｎ                      時間減速フェーズで費やされる単純
持続時間の分数を表す、０と１の間
の値。この属性とＡｃｃｅｌｅｒａ
ｔｉｏｎ属性の合計が１を超えては
ならない。
【０７３９】
Ｄｉｓａｂｌｅ                                このタイムラインを使用不能にし、
効果的にタイミングツリーから除去
する。
【０７４０】
Ｄｕｒａｔｉｏｎ                              始めから終りまでの単一期間の持続
時間。
【０７４１】
Ｅｎａｂｌｅ                                  このタイムラインを有効にし、効果
的にタイミングツリーに挿入する。
【０７４２】
このメソッドは、これがオートペア
レンテッドタイムラインであり、デ
フォルト親が指定されていない場合
には効果がない。
【０７４３】
Ｅｎｄ                                        このタイムラインの最大終了時間。
【０７４４】
この値が、Ｂｅｇｉｎプロパティと
Ｄｕｒａｔｉｏｎプロパティの合計
より小さい場合には、アクティブ化
期間が、この属性によって短く切ら
れる。さらに、この属性によって指
定される時刻の後の（スケジューリ
ングされたものまたはインタラクテ
ィブな）すべての開始は、無視され
る。
【０７４５】
ＥｎｄＩｎ                                    将来または過去の指定された点での
インタラクティブな終了をトリガす
る。パラメータは、このタイムライ
ンの親タイムラインの基準のフレー
ムで指定される。親タイムラインが
アクティブでない場合には、このメ
ソッドは効果がない。
【０７４６】
ＥｎｄＳｙｎｃ                                この属性は、タイムラインの暗黙の
持続時間を定義するのに使用され、
この持続時間は、Ｄｕｒａｔｉｏｎ
属性が明示的に指定されない場合に
使用される。タイムラインの暗黙の
持続時間は、それが制御する時間指
定されたオブジェクトによって、ま
たはそれを親とすることができる他
のタイムラインによって、定義する
ことができる。
【０７４７】
Ｆｉｌｌ                                      終了時刻が過ぎた後のタイムライン
の挙動。デフォルトで、タイムライ
ンは、始めから終りまでのみ「オン
」であるが、この属性に「Ｆｒｅｅ
ｚｅ」が設定されている場合には、
タイムラインは、終了時刻を過ぎて
もオンのままになる。その場合、終
了時刻の後のプログレス値は、終了
時刻の時の値になる。可能な値は、
Ｒｅｍｏｖｅ（グローバルデフォル
ト）、Ｆｒｅｅｚｅ、Ｈｏｌｄ、Ｔ
ｒａｎｓｉｔｉｏｎ、およびＡｕｔ
ｏである。
【０７４８】
ＦｉｌｌＤｅｆａｕｌｔ                        Ｆｉｌｌ属性のデフォルト値。Ｆｉ
ｌｌ属性が指定されない場合に、こ
の属性が、フィル挙動を決定するの
に使用される。さらに、（それ自体
のＦｉｌｌＤｅｆａｕｌｔ属性がセ
ットされない場合）このデフォルト
は、これを親とするタイムラインに
よって継承される。可能な値は、Ｆ
ｉｌｌ属性と同一である。
【０７４９】
ＩｓＣｈａｎｇｉｎｇ                          タイムラインがアクティブである場
合に真、そうでない場合に偽になる
。
【０７５０】
ＩｓＥｎａｂｌｅｄ                            タイムラインがタイミングサブツリ
ーの一部である場合に真、そうでな
い場合に偽になる。このプロパティ
が真である場合に、このタイムライ
ンがその一部であるサブツリー自体
が有効にされていることは、保証さ
れない。
【０７５１】
ＩｓＦｏｒｗａｒｄＰｒｏｇｒｅｓｓｉｎｇ      このタイムラインの進みが、壁掛時
計の時刻と比較して０から１に移動
する場合に真。このプロパティでは
、潜在的に逆のタイムラインでネス
トされることの効果が考慮される。
【０７５２】
ＩｓＯｖｅｒｒｉｄｉｎｇＢａｓｅ
Ｖａｌｕｅが偽の場合に、このプロ
パティは、このタイムラインの親タ
イムラインが返すのと同一の値を返
す。
【０７５３】
ＩｓＯｖｅｒｒｉｄｉｎｇＢａｓｅＶａｌｕｅ    このタイムラインがアクティブであ
るか、フィル期間である場合に真。
【０７５４】
ＩｓＰａｕｓｅｄ                              タイムラインが、アクティブである
が一時停止状態である場合に真。
【０７５５】
ＩｓＲｅｖｅｒｓｅｄ                          タイムラインが、タイムライン自体
の基準のローカルフレームからみて
逆転された期間である場合に真。こ
のプロパティは、潜在的に逆のタイ
ムラインでネストされることの効果
を考慮しない。ＩｓＯｖｅｒｒｉｄ
ｉｎｇＢａｓｅＶａｌｕｅが偽の場
合に、このプロパティは偽を返す。
【０７５６】
ＰａｒｅｎｔＴｉｍｅｌｉｎｅ                  このタイムラインのタイミング親で
あるタイムライン。これは、他のタ
イムラインへの参照であるか、２つ
の特殊な参照値すなわち、Ｔｉｍｅ
ｌｉｎｅ．ＶｉｓｕａｌＰａｒｅｎ
ｔまたはＴｉｍｅｌｉｎｅ．Ｒｏｏ
ｔＴｉｍｅｌｉｎｅの１つになる可
能性がある。このプロパティに、Ｔ
ｉｍｅｌｉｎｅ．ＶｉｓｕａｌＰａ
ｒｅｎｔが設定される場合に、この
タイムラインは、それが使用される
Ｖｉｓｕａｌに関連するタイムライ
ンに使用時にオートペアレンティン
グされる（Ｖｉｓｕａｌが関連する
ＤｅｆａｕｌｔＴｉｍｅｌｉｎｅを
有しない場合には、親Ｖｉｓｕａｌ
が再帰的に調べられる）。Ｔｉｍｅ
ｌｉｎｅ．ＲｏｏｔＴｉｍｅｌｉｎ
ｅが設定される場合には、このタイ
ムラインは、タイミングツリーの「
ルート」に使用時にオートペアレン
ティングされる。
【０７５７】
Ｐａｕｓｅ                                    このタイムラインおよびその子タイ
ムラインのすべてを一時停止する。
【０７５８】
このタイムラインがアクティブでな
い場合には、このメソッドは効果が
ない。
【０７５９】
Ｐａｕｓｅｄ                                  タイムラインまたはその子孫の１つ
が一時停止されるとき、必ず、その
タイムラインによって送出される。
【０７６０】
Ｐｒｏｇｒｅｓｓ                              タイムラインの現在のプログレス値
。ＩｓＯｖｅｒｒｉｄｉｎｇＢａｓ
ｅＶａｌｕｅが偽の場合に、このプ
ロパティは０を返す。どの場合でも
、このプロパティの戻り値は、両端
を含んで０と１の間の値である。
【０７６１】
ＲｅｐｅａｔＣｏｕｎｔ                        始めから終りまでの期間を繰り返さ
なければならない回数。これは、分
数値とすることができ、タイムライ
ンを永久に繰り返さなければならな
いことを示すための特殊な値ｆｌｏ
ａｔ．ＰｏｓｉｔｉｖｅＩｎｆｉｎ
ｉｔｙにすることができる。この属
性およびＲｅｐｅａｔＤｕｒａｔｉ
ｏｎ属性の両方が指定される場合に
は、有効な持続時間は、この２つの
うちの短い方になる。
【０７６２】
ＲｅｐｅａｔＤｕｒａｔｉｏｎ                  始めから終りまでの期間を繰り返さ
なければならない時間の長さ。これ
は、分数の反復カウントを暗示する
ことができ、あるいは、タイムライ
ンを永遠に繰り返さなければならな
いことを示す特殊な値Ｔｉｍｅ．Ｉ
ｎｄｅｆｉｎｉｔｅにすることがで
きる。この属性およびＲｅｐｅａｔ
Ｃｏｕｎｔ属性の両方が指定される
場合には、有効な持続時間は、この
２つのうちの短い方になる。
【０７６３】
Ｒｅｐｅａｔｅｄ                              タイムラインが単純持続期間を繰り
返すとき、必ずタイムラインによっ
て送出される。
【０７６４】
Ｒｅｓｔａｒｔ                                第２の（またはその後の）開始時刻
に達した時のタイムラインの挙動。
【０７６５】
デフォルトで、開始時刻は、すべて
のアクティブ期間を中断させ、タイ
ムラインの時刻ｔ＝０に戻るが、こ
の属性にＷｈｅｎＮｏｔＡｃｔｉｖ
ｅが設定されている場合、開始時刻
は、アクティブ期間に割り込まず、
無視される。可能な値は、Ａｌｗａ
ｙｓ、ＷｈｅｎＮｏｔＡｃｔｉｖｅ
、およびＮｅｖｅｒである。
【０７６６】
ＲｅｓｔａｒｔＤｅｆａｕｌｔ                  Ｒｅｓｔａｒｔ属性のデフォルト値
。Ｒｅｓｔａｒｔ属性が指定されな
い場合には、再開始挙動を決定する
のにこの属性が使用される。さらに
、このデフォルトは、（そのタイム
ラインがそれ自体のＲｅｓｔａｒｔ
Ｄｅｆａｕｌｔを設定しない場合に
）これを親とするタイムラインによ
って継承される。可能な値は、Ｒｅ
ｓｔａｒｔ属性と同一である。
【０７６７】
Ｒｅｓｕｍｅ                                  このタイムラインおよびその子タイ
ムラインを再開する。このタイムラ
インがアクティブでなく、一時停止
されている場合には、このメソッド
は効果がない。
【０７６８】
Ｒｅｓｕｍｅｄ                                再開されるときに必ずタイムライン
によって送出される。
【０７６９】
Ｒｅｖｅｒｓｅｄ                              時刻の方向が変更されるときに必ず
タイムラインによって送出される。
【０７７０】
Ｓｅｅｋ                                      （すべての子タイムラインに影響す
る可能性がある）このタイムライン
の現在時刻を変更する。このタイム
ラインがアクティブでない場合、こ
のメソッドは効果がない。
【０７７１】
Ｓｅｅｋｅｄ                                  シーク動作の結果として時刻が変更
されるとき、必ずタイムラインによ
って送出される。
【０７７２】
Ｓｐｅｅｄ                                    親タイムラインと比較した、このタ
イムラインについて時間が経過する
相対速度。例えば、１の値は普通の
速度を意味し、２の値は、時間が２
倍速く経過することを意味する（し
たがって、知覚される持続時間は、
Ｄｕｒａｔｉｏｎ属性によって指定
された時間の半分で終了する）。こ
の値は、負にすることができ、その
場合に、時間は、親タイムラインが
反転されたかのように、このタイム
ラインで逆方向に、終りから始めに
流れる。
【０７７３】
グラフィックス場面は、あるレンダリング動作に対してアニメーションにされるパラメータを指定することによるか、ある要素プロパティにアニメーションを追加することによってアニメーションにすることができる。アニメーションは、入力のある任意の集合（一般にそのうちの少なくとも１つが、タイムラインである）をとり、レンダリング演算に渡される正しい型の出力を作る関数である。例えば、ＰｏｉｎｔＡｎｉｍａｔｉｏｎは、タイムラインプログレス値をＰｏｉｎｔ値型に変換する。それと同時に、パラメータとして１つまたは複数のＰｏｉｎｔ値をとる様々なレンダリング演算も、ＰｏｉｎｔではなくＰｏｉｎｔＡｎｉｍａｔｉｏｎを受け取ることができ、この場合に、アニメーション関数が、各フレームで評価されて、そのフレームで使用されるＰｏｉｎｔが計算される。
【０７７４】
アニメーションは、集合にグループ化される。アニメーション集合は、パイプラインとして働き、入力としてプロパティのベース値をとり、その出力として、そのプロパティに使用されなければならない現在値を作る。集合は、０個以上のアニメーションオブジェクトを連鎖し、このオブジェクトのそれぞれは、入力値をとり、類似する型の出力を作ると言う類似するセマンティクスをサポートする。パイプラインが、規則的な間隔で評価され、出力がレンダリング演算で使用され、アニメーションの効果が作られる。
【０７７５】
アニメーションにできる値は、様々な型を有するので、様々な異なる型のアニメーションもある。しかし、すべてのアニメーションが、共通のパターンに従い、すべてが、共通のインターフェース群を実装する。Ａｎｉｍａｔｉｏｎオブジェクトは、クラスの３つのグループすなわち、修飾子、時間指定された修飾子、およびアニメーションに編成される。
【０７７６】
簡単なアニメーションでは、始点と終点の間で値を補間する。始点と終点の両方が指定されるとき、ベース値は、アニメーションが「オン」である時間に対して無視される。アニメーションが「オフ」であるときには、プロパティの値を、ベース値に戻すことができる。アニメーションは、それに関連するタイムラインが「オン」である限り「オン」であることに留意されたい。したがって、ｆｒｏｍ−ｔｏアニメーションは、Ｆｉｌｌタイミング属性に「Ｆｒｅｅｚｅ」を設定することによって、ベース値を永久にオーバーライドするようにすることができる。図３６に、Ｆｒｏｍ＝１０およびＴｏ＝７０の、ｙでアニメーションが作成される点を示す。
【０７７７】
始点または終点の、両方ではなく一方だけが指定される場合、プロパティのベース値が、他方の点の値に使用される。これは、前の例では冗長に思えるが、この例では、ベース値が無視されるのではなく、アニメーションに構成されるという点で、重要な相違がある。これによって、（プロパティが別のプロセスによって変更されるので）ベース値が変化する場合、またはアニメーションが別のアニメーションに連鎖される場合、興味深い効果を作ることができる。
【０７７８】
アニメーション機能を指定するもう１つの形が、ベース値からのデルタを指定することである。これは、概念上、ベース値からベース値＋デルタまで補間するｆｒｏｍ−ｔｏアニメーションに似ている。しかし、この場合に、始点と終点の両方が、ベース値を用いて構成される。
【０７７９】
アニメーションに関連するタイムラインが、繰り返されるように設定されている場合に、アニメーションは、始めから終りまで複数回実行される。図３７に、Ｆｒｏｍ＝１０、Ｂｙ＝６０、およびＲｅｐｅａｔＣｏｕｎｔ＝２のｙでアニメーションが作成される点を示す。反復ごとに同一の軌道を繰り返すのではなく、本質的にそれ自体と合成することによって、各反復の効果を累積するようにアニメーションをプログラムすることができる。図３８に、Ｆｒｏｍ＝１０、Ｂｙ＝６０、ＲｅｐｅａｔＣｏｕｎｔ＝２、およびＩｓＡｃｃｕｍｕｌａｔｉｎｇ＝Ｔｒｕｅのｙでアニメーションが作成される点を示す。
【０７８０】
ｆｒｏｍ−ｔｏアニメーションのデフォルト挙動は、アニメーションが作成されるプロパティのベース値を無視することであるが、この挙動を、加算的な挙動に変更することができ、その場合に、ｆｒｏｍ値およびｔｏ値の両方が、ベース値からのデルタになる。
【０７８１】
次の表に、基本的なアニメーション型を要約する。
【０７８２】
型            出力値
Ｆｒｏｍ          ｔ＝０の「Ｆｒｏｍ」値とｔ＝１のベース値。
【０７８３】
Ｔｏ              ｔ＝０のベース値とｔ＝１の「Ｔｏ」値。
【０７８４】
Ｆｒｏｍ−Ｔｏ    ｔ＝０の「Ｆｒｏｍ」値とｔ＝１の「Ｔｏ」値。
【０７８５】
Ｂｙ              ｔ＝０のベース値と、ｔ＝１のベース値と「Ｂｙ」値の合計。
【０７８６】
Ｆｒｏｍ−Ｂｙ    ｔ＝０の「Ｆｒｏｍ」値と、ｔ＝１の「Ｆｒｏｍ」値と「Ｂｙ」値
の合計。
【０７８７】
基本的なアニメーションでは、始点と終点の出力値が指定され、間の値の計算に線形補間が使用される。複雑なアニメーション機能について、その代わりに値のリストを指定することができる。各値は、キーフレームに対応する。単純な場合に、これらのキーフレームが、規則的な間隔で現れる。アニメーションは、キーフレームの間のペースを決められた間隔（ｐａｃｅｄ  ｓｐａｃｉｎｇ）を使用するようにプログラムすることもできる。ペースを決められた補間方法では、キーフレームの各対の間の間隔が、アニメーションが及ぶ「総距離」に対する２つのキー値の間の「距離」の比に比例する。これは、例えばｆｌｏａｔアニメーションまたはｐｏｉｎｔアニメーションなど、「距離」という意味のある概念を有する型のアニメーションについて可能である。その場合に、キーフレームの間の補間は、線形になる。第３のオプションは、まったく補間しないことであり、この場合に、出力値関数は、離散関数である。図３９に、ＫｅｙＶａｌｕｅｓ＝１０，９０，７０および様々な補間方法を用いてｙでアニメーションにされる点を示す。
【０７８８】
追加の制御のために、各キーフレームの時刻を、明示的に指定することができる。キーフレームの間の補間は、線形または離散とすることができる。キー時刻は、総アニメーション持続時間の比率として指定され、期間全体を含めなければならない。言い換えると、最初のキー時刻は０であり、線形補間の場合に、最後のキー時刻は１である。図４０に、ＫｅｙＶａｌｕｅｓ＝１０，９０，５０およびＫｅｙＴｉｍｅｓ＝０，．２，１の、ｙでアニメーションにされる点を示す。
【０７８９】
補間に関するさらなる制御のために、３次ベジエ曲線群を使用して、アニメーションに使用される時間曲線を記述することができる。これを、画面にレンダリングされるベジエ曲線と混同してはならない。この曲線は、タイミング曲線の形状を変更するのに使用され、キーフレーム値は、プログレス値に対して線形に補間される。このスプライン補間方法では、アニメーションに関連するタイムラインによって与えられる線形の０−１プログレス値を、非線形の０−１プログレス曲線に変換するフィルタが追加される。
【０７９０】
次の表に、アニメーション固有の属性とその意味のリストを含める。このリストは、すべてのアニメーションオブジェクトが従うテンプレートである。属性の型が「＜ＶａｌｕｅＴｙｐｅ＞」である場合に、実際のオブジェクトは、アニメーション型と一致する型を有する属性を公開する。例えば、ＣｏｌｏｒＡｎｉｍａｔｉｏｎオブジェクトは、この属性の型が「Ｃｏｌｏｒ」である。下にリストされた属性の他に、アニメーションオブジェクトは、ＩＴｉｍｉｎｇＡｔｔｒｉｂｕｔｅｓインターフェースで指定される属性をサポートする。
【０７９１】
【表１５２】
2007509426.tif 000260
【０７９２】
Ａｎｉｍａｔａｂｌｅクラスは、Ｃｈａｎｇｅａｂｌｅクラスから派生する。これは、媒体ソースなど、アニメーションにできるかアニメーションにされた値を含むことができるオブジェクトまたはオブジェクト集合によって、基底クラスとして使用される。Ｍｏｄｉｆｉｅｒ、ＴｉｍｅｄＭｏｄｉｆｉｅｒ、およびＡｎｉｍａｔｉｏｎは、個々のプロパティがアニメーション可能でないので、皮肉なことにＡｎｉｍａｔａｂｌｅではなくＣｈａｎｇｅａｂｌｅから派生する。
【０７９３】
【表１５３】
2007509426.tif 000261
【０７９４】
メソッド、プロパティ、またはイベント          意味
ＨａｓＡｎｉｍａｔｉｏｎｓ                    オブジェクトが経時的に変化できる
場合に真。一般に、オブジェクトが
アニメーション集合を保持する場合
に、このプロパティが真になる。
【０７９５】
ＩｓＡｎｉｍａｔｉｎｇ                        オブジェクトのアニメーションのい
ずれかが変化しつつある場合に真（
Ｍｏｄｉｆｉｅｒ．ＩｓＣｈａｎｇ
ｉｎｇを参照されたい）。
【０７９６】
ＩｓＯｖｅｒｒｉｄｉｎｇＢａｓｅＶａｌｕｅ    オブジェクトのアニメーションのい
ずれかが変化しつつあるか、ｆｉｌ
ｌ状態であり、したがって現在アク
ティブであり、オブジェクトを変更
している場合に真。
【０７９７】
ＧｅｔＣｕｒｒｅｎｔＶａｌｕｅ                このオブジェクトの瞬間値と同一の
値を有するが、経時的に変化しない
オブジェクトを返す。ＤｏｅｓＣｈ
ａｎｇｅプロパティが偽の場合に、
ＣｕｒｒｅｎｔＶａｌｕｅプロパテ
ィは、新しいコピーではなくオブジ
ェクト自体を返すことができる。
【０７９８】
ＳｅｔＤｅｆａｕｌｔＰａｒｅｎｔＴｉｍｅｌｉｎｅ
オートペアレンテッドタイムライン
の親であるタイムライン。このプロ
パティが設定される場合に、すべて
のオートペアレンティングされたタ
イムラインが、再ペアレンティグさ
れるが、タイムラインまたはオブジ
ェクトに関して、新しいクローンは
作成されない。
【０７９９】
Ｍｏｄｉｆｉｅｒクラス、したがってＴｉｍｅｄＭｏｄｉｆｉｅｒおよびＡｎｉｍａｔｉｏｎは、個々のプロパティがアニメーションにされてはならないので、ＡｎｉｍａｔａｂｌｅではなくＣｈａｎｇｅａｂｌｅから派生する。これによって、プログラマが、アニメーションのＦｒｏｍプロパティがアニメーションにされてはならないという事実が課される。
【０８００】
Ｍｏｄｉｆｉｅｒクラスは、ＵｎｃｈａｎｇｅａｂｌｅのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅプロパティ値を有することができない。ＭｏｄｉｆｉｅｒのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅのデフォルト値は、ＣｈａｎｇｅａｂｌｅＣｏｐｙであるが、ユーザがＭｏｄｉｆｉｅｒの再利用を望む場合に、ＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅを設定することもできる。ユーザがＳｔａｔｕｓＯｆＮｅｘｔＵｓｅにＣｈａｎｇｅａｂｌｅＲｅｆｅｒｅｎｃｅを設定する場合に、アタッチされたＭｏｄｉｆｉｅｒがＰａｒｅｎｔＴｉｍｅｌｉｎｅプロパティを設定されていなければ、例外が送出される。これによって、衝突する継承された親タイムラインを有する状況が回避される。アニメーションにされず、変更可能でないＡｎｉｍａｔａｂｌｅの枝は、ＵｎｃｈａｎｇｅａｂｌｅのＳｔａｔｕｓＯｆＮｅｘｔＵｓｅ値を有することができ、使用時に変更不能にすることができる。Ｆｒｏｍ、Ｔｏ、またはＢｙなどのＭｏｄｉｆｉｅｒクラスのプロパティは、そのＭｏｄｉｆｉｅｒの寿命全体を通じて変更可能のままになる。
【０８０１】
Ｍｏｄｉｆｉｅｒは、その寿命全体を通じて変更可能であり、したがって、ＭａｋｅＵｎｃｈａｎｇｅａｂｌｅは、これらのクラスに対して例外を送出する。現在アニメーションを含むＡｎｉｍａｔａｂｌｅについて、ＭａｋｅＵｎｃｈａｎｇｅａｂｌｅは例外を送出する。
【０８０２】
ユーザが、ＡｎｉｍａｔａｂｌｅクラスのＣｈａｎｇｅｄ通知に登録する場合に、ユーザは、プロパティ変更によるかアニメーションの性質を介するのいずれかで引き起こされた変更について通知を受ける。すなわち、ユーザは、Ａｎｉｍａｔａｂｌｅによって使用されるアニメーションに関連するＴｉｍｅｌｉｎｅが、提示される各フレームでシークされるか順方向に移動されるとき、変更通知を受け取る。
【０８０３】
独立にアニメーションにされるプロパティ（例えばＯｐａｃｉｔｙ）またはＡｎｉｍａｔａｂｌｅ（例えばＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ）の場合、ハンドラを供給したすべてのユーザに送られるＣｈａｎｇｅｄ通知は、コンポジタフレームレートではなく、ＵＩスレッドフレームレートで発生する。この場合のアニメーションの正確な値は、値が近くならなければならないが、画面にあるものと正確に同一である保証はない。
【０８０４】
アニメーションが、依存またはＭＩＬ依存である場合に、画面にあるものと一致する値を得ることは可能であるが、どの通知がレンダリングパスに対応するかを知ることは、現在不可能であり、したがって、どの通知が、表示されようとしている値を反映するかを知ることはできない。しばしば発生するように、レンダリングパス中にタイミングツリーが変更される場合には、ユーザが、複数の通知を受け取る可能性があり、したがって、どの通知が画面の結果的な値に対応するかをユーザが知る可能性は、さらに低くなる。
【０８０５】
修飾子は、ある型の、「ベース値」と称するオブジェクトを入力としてとり、入力と同一の型の別のオブジェクトを返す、ＧｅｔＶａｌｕｅメソッドを実装するオブジェクトである。出力の値は、入力と修飾子の内部状態の両方に依存する。具体的に言うと、これは、同一の入力を用いてＧｅｔＶａｌｕｅを複数回呼び出すことによって、同一の出力が返される保証がないことを意味する。グラフィカルアニメーションは、フレームごとに１回修飾子のＧｅｔＶａｌｕｅメソッドが呼び出され、各フレームの新しい値が作られるときに行われる。
【０８０６】
一般に、ＧｅｔＶａｌｕｅメソッドの戻り値に関する保証はなく、このメソッドは、呼び出されるたびに、異なる値を返す可能性がある。修飾子を消費するオブジェクトは、こうであることを仮定し、次の例のように修飾子を繰り返して呼び出すことができる。
【０８０７】
【表１５４】
2007509426.tif 000262
【０８０８】
しかし、実際には、修飾子が、その内部状態に応じて、同一の入力を与えられて同一の出力を作ると期待されるときがありえる。修飾子が「変化している」といわれるのは、ＧｅｔＶａｌｕｅの戻り値が呼び出しのたびに異なる可能性がある期間中である。ＧｅｔＶａｌｕｅの戻り値が各呼び出しで同一であるときには、「変化していない」。修飾子が「変化していない」場合に、その修飾子のユーザは、次の例のように、ＧｅｔＶａｌｕｅメソッドの戻り値を安全にキャッシングすることができ、多分、ＧｅｔＶａｌｕｅメソッドを繰り返して不必要に評価することを回避できる。
【０８０９】
【表１５５−１】
2007509426.tif 000263
【０８１０】
【表１５５−２】
2007509426.tif 000264
【０８１１】
抽象Ｍｏｄｉｆｉｅｒクラスが実装され、修飾子は、このクラスから継承する必要がある。このクラスは、ＧｅｔＶａｌｕｅメソッドおよびＧｅｔＵｎｉｑｕｅＩｎｓｔａｎｃｅメソッド以外のすべてのデフォルト実装を提供する。
【０８１２】
【表１５６−１】
2007509426.tif 000265
【０８１３】
【表１５６−２】
2007509426.tif 000266
【０８１４】
次の表に、Ｍｏｄｉｆｉｅｒクラスのセマンティクスを要約する。
【０８１５】
メソッド、プロパティ、またはイベント          意味
Ｃｈａｎｇｅｄ                                内部状態が変化したとき、必ずモデ
ィファイヤによって送出される。
【０８１６】
ＰａｒｅｎｔＴｉｍｅｌｉｎｅ                  この修飾子のオートペアレンティン
グされたタイムラインの親であるタ
イムライン。このプロパティが設定
される場合に、この修飾子のすべて
のオートペアレンティングされたタ
イムラインが、新しい親タイムライ
ンに再ペアレンティングされる。
【０８１７】
ＧｅｔＵｎｉｑｕｅＩｎｓｔａｎｃｅ            他のインスタンスと別々にそれ自体
のランタイム状態を維持できる、こ
の修飾子のインスタンスを返す。こ
の修飾子にオートペアレンティング
されたタイムラインが含まれる場合
、返されるインスタンスは、パラメ
ータとして渡されたタイムラインに
ペアレンティングされたタイムライ
ンを有する。
【０８１８】
ＧｅｔＶａｌｕｅ                              引数として渡されたベース値と修飾
子の内部状態に基づいて、この修飾
子の現在の出力値を計算する。Ｉｓ
ＯｖｅｒｒｉｄｉｎｇＢａｓｅＶａ
ｌｕｅプロパティが偽である場合に
、この関数は、ベース値を返すこと
が保証される。
【０８１９】
ＩｓＣｈａｎｇｉｎｇ                          修飾子が現在変化しつつある場合に
真、非変化期間中である場合に偽。
【０８２０】
このフラグは、ＣｈａｎｇｅＢｅｇ
ｕｎイベントおよびＣｈａｎｇｅＥ
ｎｄｅｄイベントと共に最もよく使
用される。このフラグが真である場
合、ＩｓＯｖｅｒｒｉｄｉｎｇＢａ
ｓｅＶａｌｕｅも真になる必要があ
る。
【０８２１】
ＩｓＯｖｅｒｒｉｄｉｎｇＢａｓｅＶａｌｕｅ    ＧｅｔＶａｌｕｅメソッドの戻り値
が、修飾子によって現在影響されつ
つある場合に真。この値が偽のとき
、ＧｅｔＶａｌｕｅは、引数として
渡されたものと同一のオブジェクト
を返すことが保証される。修飾子が
、ベース値をオーバーライドしてい
るが変更していない場合があること
に留意されたい。
【０８２２】
ＵｓｅｓＢａｓｅＶａｌｕｅ                    ＧｅｔＶａｌｕｅの戻り値がベース
値に依存する場合に真。このプロパ
ティが偽である場合、それは、修飾
子がベース値を完全に無視すること
を意味する。修飾子がリストに含ま
れる場合、このプロパティは、いく
つかの場合に修飾子のサブセットだ
けを評価する必要がある場合の最適
化を可能にする。
【０８２３】
さらに、Ｍｏｄｉｆｉｅｒから継承するが、インターフェースメソッドの型安全バージョンを公開する、型固有クラスの集合が実装される。次の例に、ＦｌｏａｔＭｏｄｉｆｉｅｒクラスを示す。
【０８２４】
【表１５７】
2007509426.tif 000267
【０８２５】
時間指定された修飾子は、少なくとも部分的にＴｉｍｅｌｉｎｅオブジェクトによって挙動が制御される修飾子である。前述の修飾子規則が適用されるが、さらに、時間指定された修飾子は、その修飾子のタイムラインの制御を公開するためにＩＴｉｍｉｎｇＣｏｎｔｒｏｌインターフェースを実装する。抽象ＴｉｍｅＭｏｄｉｆｉｅｒクラスはない。その代わりに、型固有クラスは、型固有のＭｏｄｉｆｉｅｒクラスから継承する。次の例に、ＦｌｏａｔＴｉｍｅｄＭｏｄｉｆｉｅｒクラスを示す。
【０８２６】
【表１５８−１】
2007509426.tif 000268
【０８２７】
【表１５８−２】
2007509426.tif 000269
【０８２８】
ＭｏｄｉｆｉｅｒおよびＩＴｉｍｉｎｇＣｏｎｔｒｏｌインターフェースが、類似するメソッド、プロパティ、およびイベントを有することに留意されたい。ＴｉｍｅｄＭｏｄｉｆｉｅｒは、これらに関する単一の実装を公開する。ＴｉｍｅｄＭｏｄｉｆｉｅｒは、そうする必要はないが、制御するＴｉｍｅｌｉｎｅにすべての呼出しを転送することによって、ＩＴｉｍｉｎｇＣｏｎｔｒｏｌを実装することができる。型固有ＴｉｍｅｄＭｏｄｉｆｉｅｒ実装によって提供されるＩＴｉｍｉｎｇＣｏｎｔｒｏｌのデフォルト実装は、制御するＴｉｍｅｌｉｎｅに呼出しを転送する。
【０８２９】
アニメーションは、特定のアニメーション関数を実装する時間指定された修飾子である。
【０８３０】
【表１５９−１】
2007509426.tif 000270
【０８３１】
【表１５９−２】
2007509426.tif 000271
【０８３２】
アニメーション集合は、アニメーションオブジェクト（＜Ｔｙｐｅ＞Ｍｏｄｉｆｉｅｒから継承する）のリストであり、第１のオブジェクトからのＧｅｔＶａｌｕｅメソッドの出力が、第２のオブジェクトのＧｅｔＶａｌｕｅメソッドのベース値パラメータとして使用され、以下同様である。柔軟性のために、アニメーション集合に含まれるオブジェクトは、実際には、型を指定されたＭｏｄｉｆｉｅｒの型である。集合は、全体として、ＩＭｏｄｉｆｉｅｒ．ＧｅｔＶａｌｕｅに似て見えるＧｅｔＶａｌｕｅメソッドをサポートする。実際に、アニメーション集合は、ＩＭｏｄｉｆｉｅｒインターフェースのほとんどをサポートするが、「ＵｓｅｓＢａｓｅＶａｌｕｅ」プロパティをサポートしない（このプロパティは、集合全体として「真」であると必ず仮定される）ので、実際にはＩＭｏｄｉｆｉｅｒを実装しない。
【０８３３】
【表１６０−１】
2007509426.tif 000272
【０８３４】
【表１６０−２】
2007509426.tif 000273
【０８３５】
アニメーション集合から実行されたイベントは、合体される。
【０８３６】
パスアニメーションは、ＴｉｍｅｄＭａｔｒｉｘＭｏｄｉｆｉｅｒの特殊化である。ＭａｔｒｉｘＭｏｄｉｆｉｅｒを、ＭａｔｒｉｘＴｒａｎｓｆｏｒｍと共に使用することができる。ＭａｔｒｉｘＴｒａｎｓｆｏｒｍは、ＭａｔｒｉｘプロパティおよびＭａｔｒｉｘＡｎｉｍａｔｉｏｎｓプロパティを有し、  ＰａｔｈＡｎｉｍａｔｉｏｎは、ＭａｔｒｉｘＭｏｄｉｆｉｅｒなので、ＭａｔｒｉｘＡｎｉｍａｔｉｏｎとして使用することができる。
【０８３７】
【表１６１】
2007509426.tif 000274
【０８３８】
メソッド、プロパティ、またはイベント          意味
Ｇｅｏｍｅｔｒｙ                              これは、任意の形状とすることがで
きる。楕円に関して、プログレス０
の適当な始点が選択される。形状が
、多数の下位形状を有する場合に、
それらのパスのそれぞれを、形状内
で定義される順番で移動することが
できる。
【０８３９】
ＤｏｅｓＲｏｔａｔｅＷｉｔｈＴａｎｇｅｎｔ    このプロパティに偽が設定されてい
る場合に、オブジェクトは、回転な
しで形状パスに沿って移動する。真
が設定されている場合、オブジェク
トは、所与の位置でパスのタンジェ
ントに一致するように回転する。
【０８４０】
マークアップ要素の使用法。
【０８４１】
【表１６２】
2007509426.tif 000275
【０８４２】
アニメーションにできるすべてのリソース、メソッド、またはオブジェクトは、Ａｎｉｍａｔａｂｌｅインターフェースを実装することを含む、複数の規則に従う。型「Ｂａｒ」の「Ｆｏｏ」という名前のアニメーション可能プロパティ（またはパラメータ）のすべてについて、型「ＢａｒＡｎｉｍａｔｉｏｎＣｏｌｌｅｃｔｉｏｎ」の「ＦｏｏＡｎｉｍａｔｉｏｎｓ」という名前のもう１つのプロパティ（またはパラメータ）がある。アニメーションが望まれる場合に、必ず、アニメーション集合が使用される。基本的なＭｏｄｉｆｉｅｒオブジェクトまたはＡｎｉｍａｔｉｏｎオブジェクトは、アニメーション合成が除外されているので、直接には使用されない。
【０８４３】
リソースを、個々のプロパティにアニメーション集合を追加することによってアニメーションにすることができる。次の例に、アニメーションカラーを有するＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈを作成する方法を示す。
【０８４４】
【表１６３】
2007509426.tif 000276
【０８４５】
アニメーションにするリソースは、レンダリング演算で、またはＥｌｅｍｅｎｔプロパティの値として使用することができる。
【０８４６】
レンダリング演算は、コンテキスト描画メソッド呼出しにアニメーション集合を追加するか、アニメーションにするリソースを使用することによってアニメーションにすることができる。次の例に、アニメーションにされた不透明値を描画コンテキストにプッシュする方法を示す。
【０８４７】
【表１６４】
2007509426.tif 000277
【０８４８】
Ｅｌｅｍｅｎｔは、Ｅｌｅｍｅｎｔプロパティにアニメーション集合を追加することによってアニメーションにすることができる。次の例に、Ｃ＃でボタンの幅をアニメーションにする方法を示す。
【０８４９】
【表１６５−１】
2007509426.tif 000278
【０８５０】
【表１６５−２】
2007509426.tif 000279
【０８５１】
次に、ＸＡＭＬの同一の例を示す。
【０８５２】
【表１６６】
2007509426.tif 000280
【０８５３】
アニメーション（またはアニメーションにされたリソース）が使用されるとき、必ず、アニメーション（またはリソース）が、クローンを作成され（浅い効率的な形で）て、一意の独立に制御可能なタイムラインを有する宛先が提供される。この挙動の副作用は、オリジナルのアニメーションが、ビジュアル場面の一部でなく、したがって、ＩＴｉｍｉｎｇＣｏｎｔｒｏｌインターフェースを介する制御呼出しに応答しないことである。この効果を達成するために、呼出し側のコードは、まずアニメーションを使用し、次にアニメーションを読み戻す。読み戻される値をキャッシングし、タイミング制御に使用することができる。次の例に、アニメーションを制御する予定のコードが従うことのできるパターンを示す。
【０８５４】
【表１６７−１】
2007509426.tif 000281
【０８５５】
【表１６７−２】
2007509426.tif 000282
【０８５６】
ユーザは、基底クラスとしてＡｎｉｍａｔｉｏｎＥｆｆｅｃｔを使用して新しいクラスを作成して、ＡｎｉｍａｔｉｏｎＥｆｆｅｃｔを実装する。ユーザは、自分のＡｎｉｍａｔｉｏｎＥｆｆｅｃｔのビルダも作成する必要がある。
【０８５７】
【表１６８】
2007509426.tif 000283
【０８５８】
メソッド、プロパティ、またはイベント          意味
Ｉｎｖａｌｉｄａｔｅ                          ユーザは、自分のＡｎｉｍａｔｉｏ
ｎＥｆｆｅｃｔを次のＲｅｎｄｅｒ
ＱｕｅｕｅＩｔｅｍ中に処理される
ＡｎｉｍａｔｉｏｎＥｆｆｅｃｔの
リストに置き、ＲｅｎｄｅｒＱｕｅ
ｕｅＩｔｅｍが確実にスケジューリ
ングされるようにしたいとき、これ
を呼び出す。無効なアニメーション
のリストは、ＲｅｎｄｅｒＱｕｅｕ
ｅＩｔｅｍの始めに初期化される
。
【０８５９】
ＩｎｖａｌｉｄａｔｅＰａｓｓｉｖｅ            ユーザは、自分のＡｎｉｍａｔｉｏ
ｎＥｆｆｅｃｔを次のＲｅｎｄｅｒ
ＱｕｅｕｅＩｔｅｍ中に処理される
ＡｎｉｍａｔｉｏｎＥｆｆｅｃｔの
リストに置きたいが、Ｒｅｎｄｅｒ
ＱｕｅｕｅＩｔｅｍをスケジューリ
ングさせたくないとき、これを呼び
出す。
【０８６０】
ＩｓＩｎｖａｌｉｄ                            アニメーションが、現在、次のＲｅ
ｎｄｅｒＱｕｅｕｅＩｔｅｍ中に処
理されるＡｎｉｍａｔｉｏｎＥｆｆ
ｅｃｔのリストに含まれる場合に真
を返す。Ｉｎｖａｌｉｄａｔｅが呼
び出されたので真になる可能性があ
る。
【０８６１】
Ｅｌｅｍｅｎｔ                                これは、ＡｎｉｍａｔｉｏｎＥｆｆ
ｅｃｔが付加されるＥｌｅｍｅｎｔ
である。ＡｎｉｍａｔｉｏｎＥｆｆ
ｅｃｔがＥｌｅｍｅｎｔに付加され
た場合には、例外が送出される。ユ
ーザは、ＯｎＡｔｔａｃｈが呼び出
されるまで設定を行ってはならない
。
【０８６２】
ＡｔｔａｃｈＩｍｐｌ                          ＡｎｉｍａｔｉｏｎＥｆｆｅｃｔは
、要素に付加されるとき、自動的に
そのＡｎｉｍａｔｉｏｎＥｆｆｅｃ
ｔのクローンが作成され、新しいク
ローンが、要素のＡｎｉｍａｔｉｏ
ｎＥｆｆｅｃｔの集合に追加され、
ＯｎＡｔｔａｃｈが呼び出される。
【０８６３】
この時点で、ＡｎｉｍａｔｉｏｎＥ
ｆｆｅｃｔのｐｒｏｔｅｃｔｅｄ  
Ｅｌｅｍｅｎｔプロパティが設定さ
れる。ユーザが、集合にＡｎｉｍａ
ｔｉｏｎＥｆｆｅｃｔを追加した場
合に、新しいＡｎｉｍａｔｉｏｎＥ
ｆｆｅｃｔのＯｎＡｔｔａｃｈだけ
が呼び出される。ＯｎＡｔｔａｃｈ
が呼び出されるとき、Ｅｌｅｍｅｎ
ｔが、そのマークアッププロパティ
を設定されているか、Ｅｌｅｍｅｎ
ｔの子のすべてがあることは保証さ
れない。ＡｎｉｍａｔｉｏｎＥｆｆ
ｅｃｔのクローンが作成される。Ｅ
ｌｅｍｅｎｔを、すべての機能を呼
び出すときにＡｎｉｍａｔｉｏｎＥ
ｆｆｅｃｔに渡すことができるが、
ＡｎｉｍａｔｉｏｎＥｆｆｅｃｔが
Ｅｌｅｍｅｎｔを最も必要とする場
合の他の要素からのイベントのイベ
ントハンドラにＥｌｅｍｅｎｔを渡
すことはできない。Ａｎｉｍａｔｉ
ｏｎＥｆｆｅｃｔは、他の要素のイ
ベントハンドラを設定することがで
き、なおかつ、それがこのＥｌｅｍ
ｅｎｔに割り当てられていることを
知る必要がある。
【０８６４】
ＤｅｔａｃｈＩｍｐｌ                          これは、ＡｎｉｍａｔｉｏｎＥｆｆ
ｅｃｔがＥｌｅｍｅｎｔから切り離
されるときにＡｎｉｍａｔｉｏｎＥ
ｆｆｅｃｔに対して呼び出される。
【０８６５】
ＰｒｅＬａｙｏｕｔＲｅａｄＩｍｐｌ            これは、ＲｅｎｄｅｒＱｕｅｕｅＩ
ｔｅｍでレイアウトを実行する前に
、ＡｎｉｍａｔｉｏｎＥｆｆｅｃｔ
がダーティである場合、Ａｎｉｍａ
ｔｉｏｎＥｆｆｅｃｔに対して呼び
出される。これは、Ａｎｉｍａｔｉ
ｏｎＥｆｆｅｃｔが必要な値を読み
取るべき時である。読取と書込が別
々である理由は、読取が、レイアウ
トを即座に実行させ、すべてのＡｎ
ｉｍａｔｉｏｎＥｆｆｅｃｔが、読
取と書込をこの順番で行うと、処理
全体が低速になるからである。
【０８６６】
ＰｒｅＬａｙｏｕｔＷｒｉｔｅＩｍｐｌ          これは、ＲｅｎｄｅｒＱｕｅｕｅＩ
ｔｅｍでレイアウトを実行する前に
、ＡｎｉｍａｔｉｏｎＥｆｆｅｃｔ
がダーティである場合、Ａｎｉｍａ
ｔｉｏｎＥｆｆｅｃｔに対して呼び
出される。ＡｎｉｍａｔｉｏｎＥｆ
ｆｅｃｔが処理される順番は保証さ
れないが、すべてのダーティＡｎｉ
ｍａｔｉｏｎＥｆｆｅｃｔが、呼び
出される前にＯｎＰｒｅＬａｙｏｕ
ｔＲｅａｄを呼び出されることは保
証される。
【０８６７】
ＰｏｓｔＬａｙｏｕｔＲｅａｄＩｍｐｌ          これは、ＲｅｎｄｅｒＱｕｅｕｅＩ
ｔｅｍでレイアウトを実行した後に
、ＡｎｉｍａｔｉｏｎＥｆｆｅｃｔ
がダーティである場合、Ａｎｉｍａ
ｔｉｏｎＥｆｆｅｃｔに対して呼び
出される。ＩｓＡｌｗａｙｓＤｉｒ
ｔｙフラグがセットされていない場
合には、このＡｎｉｍａｔｉｏｎＥ
ｆｆｅｃｔのダーティフラグに偽が
設定されており、次のＲｅｎｄｅｒ
ＱｕｅｕｅＩｔｅｍ中に処理される
ＡｎｉｍａｔｉｏｎＥｆｆｅｃｔの
リストから除去される。Ａｎｉｍａ
ｔｉｏｎＥｆｆｅｃｔがこのメソッ
ドでＳｅｔＤｉｒｔｙを呼び出す場
合に、次のＲｅｎｄｅｒＱｕｅｕｅ
Ｉｔｅｍ中の処理について、Ａｎｉ
ｍａｔｉｏｎＥｆｆｅｃｔが効果的
にダーティに保たれる。Ａｎｉｍａ
ｔｉｏｎＥｆｆｅｃｔがダーティの
ままでいることを望む場合に、Ｉｓ
ＡｌｗａｙｓＤｉｒｔｙフラグを設
定する方がはるかに効率的である。
【０８６８】
（プリミティブ型）
ＭＩＬの基礎の長さ単位は、ｄｏｕｂｌｅであり、これによって、他のプリミティブ型およびＡＰＩは、ｄｏｕｂｌｅに基づく。一般に、これらのｄｏｕｂｌｅは、当初に１／９６インチ（約０．２６５ｍｍ）と等しいユーザ単位として評価される。カラーに関して、カラーチャネルの各々が、ｄｏｕｂｌｅではなくｆｌｏａｔによって表される。角度測定値に関して、ｄｏｕｂｌｅ値は度単位である。ｆｌｏａｔまたはｄｏｕｂｌｅが時間測定値として評価されるときには、秒であると仮定される。
【０８６９】
Ｔｉｍｅ構造体は、特定の時点または時間のスパンを表す。さらに、「Ｉｎｄｅｆｉｎｉｔｅ」と称する特殊な時間値が、無限に将来の時点または無限に長い時間のスパンのいずれかを表す。時間値はプロパティシステムで使用されるように設計されており、したがって、「Ｕｎｓｐｅｃｉｆｉｅｄ」と称する特殊な値を使用して、プロパティを消去するか、プロパティが設定されていないことを明示的に示すことができる。時間値は、内部では整数カウントとして保管される。
【０８７０】
【表１６９】
2007509426.tif 000284
【０８７１】
上記の文法の他に、「分」および「秒」を、有効とみなされるために「００」から「５９」までの範囲で指定する必要があることに留意されたい。また、「ｔｉｍｅｃｏｕｎｔ−ｖａｌｕｅ」フォーマットが無単位で使用される場合に、その値は、秒単位と仮定される。次は、Ｔｉｍｅ値とその意味の例である。
【０８７２】
Ｔｉｍｅ                  値
０２：３０：０３          ２時間３０分３秒
５０：００：１０．２５    ５０時間１０秒２５０ミリ秒
０２：３３                ２分３３秒
００：１０．５            １０秒５００ミリ秒
３．２ｈ                  ３時間１２分
４５ｍｉｎ                ４５分
３０ｓ                    ３０秒
５．４５ｍｓ              ５．４５ミリ秒
１２．４６７              １２秒４６７ミリ秒
１ｄ                      １日
Ｔｉｍｅ構造体は、単一のＴｉｍｅ値を保管するのに使用される。
【０８７３】
【表１７０−１】
2007509426.tif 000285
【０８７４】
【表１７０−２】
2007509426.tif 000286
【０８７５】
他の基本型を下に示すが、次の表記が使用される。
【０８７６】
・＊：０個以上
・＋：１個以上
・？：０個または１個
・｛ｎ｝：ｎ回
・（）：グループ化
・｜：代替物を区切る
・二重引用符はリテラルを囲む
【０８７７】
【表１７１−１】
2007509426.tif 000287
【０８７８】
【表１７１−２】
2007509426.tif 000288
【０８７９】
色のマークアップ構文
【０８８０】
【表１７２】
2007509426.tif 000289
【０８８１】
Ｃｏｌｏｒｓオブジェクトには、ＲｅｄおよびＢｌｕｅなどの周知の多数の色を含む静的メンバが含まれる。
【０８８２】
【表１７３−１】
2007509426.tif 000290
【０８８３】
【表１７３−２】
2007509426.tif 000291
【０８８４】
【表１７３−３】
2007509426.tif 000292
【０８８５】
【表１７３−４】
2007509426.tif 000293
【０８８６】
【表１７３−５】
2007509426.tif 000294
【０８８７】
ｐｏｉｎｔ構造体を下に示す。
【０８８８】
【表１７４−１】
2007509426.tif 000295
【０８８９】
【表１７４−２】
2007509426.tif 000296
【０８９０】
ｐｏｉｎｔオブジェクトのマークアップ構文。
【０８９１】
【表１７５】
2007509426.tif 000297
【０８９２】
Ｖｅｃｔｏｒオブジェクトを下に示す。
【０８９３】
【表１７６−１】
2007509426.tif 000298
【０８９４】
【表１７６−２】
2007509426.tif 000299
【０８９５】
【表１７６−３】
2007509426.tif 000300
【０８９６】
Ｖｅｃｔｏｒオブジェクトのマークアップ構文。
【０８９７】
【表１７７】
2007509426.tif 000301
【０８９８】
ｓｉｚｅが、Ｖｅｃｔｏｒではなく、したがって、加算、減算、または変換を行えないことに留意されたい。また、ｓｉｚｅは、負の幅または負の高さを有することができない。それを設定する試みが行われた場合には、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎが送出される。
【０８９９】
長方形に関して、Ｒｅｃｔａｎｇｌｅ要素と衝突しないように、Ｒｅｃｔａｎｇｌｅではなく名前Ｒｅｃｔが使用される。負の幅および高さを指定することは可能であるが、長方形を正規化する標準的な形はなく、長方形に対する多数の演算が、非直観的な結果を与える可能性がある。ＲｅｃｔのＷｉｄｔｈおよびＨｅｉｇｈｔに非負の値を設定することはできない。そのような値がコンストラクタに渡された場合には、結果が正規化される。ＷｉｄｔｈまたはＨｅｉｇｈｔに負の値が設定された場合には、ＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎがもたらされる。
【０９００】
Ｒｅｃｔには、その内側の点ならびにその辺にあるすべての点が含まれる。したがって、Ｒｅｃｔの辺は、包含的である。その結果、０  Ｗｉｄｔｈまたは０  ＨｅｉｇｈｔのＲｅｃｔは、Ｒｅｃｔによって表される１次元の線分の点の集合が含まれるので、空ではない。ＷｉｄｔｈとＨｅｉｇｈｔの両方が０である場合には、Ｒｅｃｔに、そのＬｏｃａｔｉｏｎにある１つのＰｏｉｎｔが含まれる。これは、真に空のＲｅｃｔが、特殊な値であり、ｓｔａｔｉｃ  ＥｍｐｔｙＲｅｃｔプロパティを介してアクセスできることを意味する。空のＲｅｃｔのＷｉｄｔｈプロパティおよびＨｅｉｇｈｔプロパティは、負の無限大（この両方が負になり得る唯一の場合）を返し、ＸプロパティおよびＹプロパティは、正の無限大を返し、これらのプロパティのどれもが、変更不能になる。これは、「空」の幅と通常の高さ、またはその逆を有することがなくなることを保証するためである。
【０９０１】
【表１７８−１】
2007509426.tif 000302
【０９０２】
【表１７８−２】
2007509426.tif 000303
【０９０３】
【表１７８−３】
2007509426.tif 000304
【０９０４】
リストに示すように、ｒｅｃｔは、複数のメソッドを備える。ＩｓＥｍｐｔｙは、インスタンスが空のＲｅｃｔと等しい場合に真を返す。ＦｒｏｍＬＴＲＢメソッドは、本質的に、（左、上、左右、上下）を用いて初期化された長方形を返す。Ｃｏｎｔａｉｎｓメソッドは、Ｒｅｃｔが空でなく、ｐ．ｘ≧ｒ．ｘ、ｐ．ｘ≦ｒ．ｘ＋ｒ．ｗｉｄｔｈ、ｐ．ｙ≧ｒ．ｙ、かつｐ．ｙ≦ｒ．ｙ＋ｒ．ｈｅｉｇｈｔである場合に真を返す。これは、長方形が負の幅または負の高さを有する場合に、このメソッドが偽を返すことを意味する。
【０９０５】
ＩｎｔｅｒｓｅｃｔｓＷｉｔｈは、両方のＲｅｃｔが空でなく、ｒ１．ｘ≦ｒ２．ｘ＋ｒ２．ｗｉｄｔｈ、ｒ２．ｘ≦ｒ１．ｘ＋ｒ１．ｗｉｄｔｈ、ｒ１．ｙ≦ｒ２．ｙ＋ｒ２．ｈｅｉｇｈｔ、かつｒ２．ｙ≦ｒ１．ｙ＋ｒ１．ｈｅｉｇｈｔである場合に真を返す。２つの長方形の交差は、ｌｅｆｔ寸法およびｔｏｐ寸法の最大値と、ｒｉｇｈｔ寸法およびｂｏｔｔｏｍ寸法の最小値をとることによって計算される。どちらかのＲｅｃｔが空の場合には、ＥｍｐｔｙＲｅｃｔが返される。
【０９０６】
２つの長方形の和集合は、ｌｅｆｔ寸法およびｔｏｐ寸法の最小値と、ｒｉｇｈｔ寸法およびｂｏｔｔｏｍ寸法の最大値をとることによって計算される。どちらかのＲｅｃｔが空の場合には、他方のＲｅｃｔが返される。
【０９０７】
Ｏｆｆｓｅｔメソッドについて、相対位置は、長方形の位置に単純に加算される。このメソッドは、Ｒｅｃｔが空の場合には効果がない。
【０９０８】
Ｉｎｆｌａｔｅについて、膨張量は、すべての側面に同等に適用される。ｒ．ｘ＝ｒ．ｘ−ｓ．ｗｉｄｔｈ；ｒ．ｙ＝ｒ．ｙ−ｓ．ｈｅｉｇｈｔ；ｒ．ｗｉｄｔｈ＝ｒ．ｗｉｄｔｈ＋２＊ｓ．ｗｉｄｔｈ；およびｒ．ｈｅｉｇｈｔ＝ｒ．ｈｅｉｇｈｔ＋２＊ｓ．ｈｅｉｇｈｔを含む調整が行われる。空のＲｅｃｔは位置を有しないので、このメソッドは、Ｒｅｃｔが空の場合には効果がない。
【０９０９】
次のマークアップ構文では、ｘ、ｙ、ｗｉｄｔｈ、およびｈｅｉｇｈｔを指定する。これが、Ｓｙｓｔｅｍ．Ｄｒａｗｉｎｇ．Ｒｅｃｔａｎｇｌｅの型コンバータが行うことと同等であることに留意されたい。
【０９１０】
【表１７９】
2007509426.tif 000305
【０９１１】
２Ｄ計算の行列は、３×３行列として表される。ＭＩＬは、行ベクトル構文を使用する。ｍｉｌは、アフィン変換だけが可能であり、したがって、３×３行列全体ではなく、６つの値だけが必要である。これらは、次のように命名され、定義される。
【０９１２】
【表１８０】
2007509426.tif 000306
【０９１３】
行列が、点と掛け合わされるときに、その点が、新しい座標系から前の座標系に変換される。
【０９１４】
【表１８１】
2007509426.tif 000307
【０９１５】
変換を、任意のレベルまでネストすることができる。新しい変換が適用される場合、その適用は、必ず、現在の変換行列に前からかけることと同一である。
【０９１６】
【表１８２】
2007509426.tif 000308
【０９１７】
ＡＰＩのほとんどの場所で、Ｍａｔｒｉｘが直接には受け取られない。そうではなく、Ｔｒａｎｓｆｏｒｍクラスが、深い形でアニメーションをサポートする。
【０９１８】
【表１８３−１】
2007509426.tif 000309
【０９１９】
【表１８３−２】
2007509426.tif 000310
【０９２０】
【表１８３−３】
2007509426.tif 000311
【０９２１】
マークアップ構文について、順序は、Ｍ１１、Ｍ１２、Ｍ２１、Ｍ２２、ＯｆｆｓｅｔＸ、およびＯｆｆｓｅｔＹである。
【０９２２】
【表１８４】
2007509426.tif 000312
【０９２３】
（３次元ビジュアルおよび３次元要素）
このセクションは、主に、アプリケーションが使用する媒体統合レイヤを介して簡単な３次元効果を提供する３次元効果を対象とする。そのような効果は、リモーティング、印刷、デスクトップの合成を統合し、ならびにＭＩＬアーキテクチャおよび要素モデル、およびＭＩＬにまたがる媒体の合成可能性においてきれいに加わる。例えば、ビジネスビジュアライゼーションは、３次元プレゼンテーションおよび対話性のある要件を有する。これは、数千個または数万個のオブジェクトへのヒットテスト分解能を必要とする可能性があり、図４１に示された画像のように見える可能性があるインタラクティブビジュアライゼーションをもたらす。
【０９２４】
本明細書で説明する特徴は、一般に、モデリングツールを介して提供される機能性ではなく、ランタイムのレンダリングおよび対話を対象とする。提供されるモデリング機能性は、アニメーションまたはランタイム構築がランタイムに公開される必要がある状況を対象とする。例えば、実際にはモデリング機能であるが、３Ｄテキスト押出しを提供することができる。というのは、アプリケーションが、テキストをデータバインドすることを望み、したがって、これがランタイム機能であることを要求するからである。
【０９２５】
上で説明したように、ＭＩＬシステムのＶｉｓｕａｌは、最終的にレンダリングされるものの２Ｄ合成ツリーを表す。ＵｉＥｌｅｍｅｎｔおよびＣｏｎｔｒｏｌｓが、Ｖｉｓｕａｌであることに留意されたい。さらに、Ｖｉｓｕａｌは、Ｖｉｓｕａｌ自体の内容の（ペインタのアルゴリズムに関して）前にレンダリングされる子Ｖｉｓｕａｌの集合を有する。前述したように、ＲｅｔａｉｎｅｄＶｉｓｕａｌ、ＳｕｒｆａｃｅＶｉｓｕａｌ、ＨｗｎｄＶｉｓｕａｌなどを含む、具象Ｖｉｓｕａｌサブクラスの種類がある。ＲｅｔａｉｎｅｄＶｉｓｕａｌは、ユーザがＶｉｓｕａｌに直接に作成するか、レイアウトシステムからＯｎＲｅｎｄｅｒ（）コールバックを受け取った結果として作成するかのいずれかである、２Ｄ描画命令群を表す。
【０９２６】
理解されるように、３Ｄは、２Ｄビジュアルの世界に自然におさまる。このために、２Ｄの対応物と同様に、描画コンテキストをオープンし、描画コンテキストにレンダリングすることによって強制的に塗り潰される描画命令のリストを表すＲｅｔａｉｎｅｄ３ＤＶｉｓｕａｌが提供される。これは、効果的に、シーングラフまたはメタファイル、あるいはＶｉｓｕａｌ自体への命令リストを構築する。
【０９２７】
Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌは、本質的に、光、場面の２Ｄ投影を定義するカメラ、投影をマッピングするためのローカル座標空間内の長方形の２次元ビューポート、ならびにアンチエイリアススイッチ、フォグスイッチ、およびその類似物などの他の環境パラメータを含む、３次元（レンダリング命令／シーングラフ／メタファイル）データの集合である。
【０９２８】
オンデマンドのＯｎＲｅｎｄｅｒ（）機能が、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌについて提供されないことに留意されたい。この機能性は、２Ｄの世界で描かれるデータの量を管理するのを助けるために、２Ｄについて存在する。２Ｄと同様に、レンダリングは、ＤｒａｗｉｎｇＣｏｎｔｅｘｔを介して行われ、「即時モードフィーリング」呼出しが行われる。例えば、２Ｄで、次のコードを描画コンテキストに含めることができる。
【０９２９】
【表１８５−１】
2007509426.tif 000313
【０９３０】
【表１８５−２】
2007509426.tif 000314
【０９３１】
２Ｄとの一貫性を保つために、次のような類似するモデルが、３Ｄで提供される。
【０９３２】
【表１８６】
2007509426.tif 000315
【０９３３】
レンダリングのこのモデルが、（「命令」が単純に保存される）リテインモード３Ｄビジュアルおよび（レンダリングが直接に行われわれ、カメラが前もって確立される必要がある）即時モード３Ｄビジュアルの両方で良好に働くことに留意されたい。実際に、リテインモードの場合に、内部的に行われることは、３Ｄモデリング階層が構築され、保持されることである。その代わりに、即時モードの場合には、そのようなことが行われず、命令が直接に発行されており、コンテキストスタック（例えば変換用）が維持されている。
【０９３４】
次のコードは、３Ｄ  Ｖｉｓｕａｌ  ＡＰＩを用いるプログラミングを示す例である。この例では、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌを作成し、レンダリングされる描画コンテキストを入手し、プリミティブおよびライトをレンダリングし、カメラを設定し、コントロールの仮想子にビジュアルを追加する。
【０９３５】
【表１８７−１】
2007509426.tif 000316
【０９３６】
【表１８７−２】
2007509426.tif 000317
【０９３７】
３Ｄへの２Ｄの統合は、重要な特徴であり、これによって、２Ｄ  ＵＩに、３Ｄの世界で対話させ、３Ｄサーフェスにマッピングするなど、非常に興味深いシナリオが可能になる。２Ｄは、別々の形で３Ｄに統合される。１つの形が、３Ｄプリミティブへのテクスチャとしての統合である。すべてのＡｖａｌｏｎ  ２Ｄ  Ｂｒｕｓｈ（ならびにより複雑なマテリアル指定）を使用して、３Ｄにテクスチャリングすることができる。これの特殊な場合が、任意のＶｉｓｕａｌ（したがって、ＣｏｎｔｒｏｌｓまたはアプリケーションＵＩ全体）をホスティングできるＶｉｓｕａｌＢｒｕｓｈである。ヒットテストを解決し、それを行うことを望むアプリケーションのビジュアルへのさらなるヒットテストを行う機構が設けられ、ある場合に、ヒットテスト分解能が、Ｖｉｓｕａｌがライブになり得るものである。Ｖｉｓｕａｌ自体はビットマップではないので、Ｖｉｓｕａｌ内の２Ｄ形状をとり、それを３Ｄにし、したがってテクスチャとして２Ｄビットマップではなく３Ｄベクトルグラフィックスを使用するなど、より洗練された技法を介して、Ｖｉｓｕａｌテクスチャリングを実施することができることに留意されたい。
【０９３８】
２Ｄを３Ｄに統合するもう１つの形が、３Ｄコンテキストに対するレンダリング命令としての統合である。遠近法の効果なしで、特定のｚ深さ、例えば球面、２Ｄビジュアル、および立方体へ、画面に位置合せされ、スケーリングされない２Ｄビジュアルを単純にレンダリングでき、なおかつ、それらが同一のｚバッファを共有でき、したがって、例えば、球面が１つの２Ｄ  ＵＩを通過できるようにすることも望ましい。これは、Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔの「ＤｒａｗＶｉｓｕａｌ」命令によって公開される。
【０９３９】
本明細書で説明するように、Ａｎｉｍａｔｉｏｎは、直観的に動作しなければならず、２Ｄアニメーション技法は、直接に３Ｄに変換可能である。例外は、タイムラインの有理化である。
【０９４０】
上記では、描画命令がコンテキストに発行される、使用法の強制的レンダリングスタイルを示した。これは、宣言的な使用法ではなく、したがって、この強制的手法は、宣言的マークアップ要素に適当ではない。
【０９４１】
上記の機構には、外部で明示的に構築される３Ｄモデルがないので（内部的にある場合であっても）、プログラマは、３Ｄモデルをアドレッシングできず、その内容を列挙することができない。その結果、入力としてモデルを取り、新しいモデルを生成する「効果」を記述する場所がない。
【０９４２】
３Ｄ「リソース」を作り、２Ｄと同様にＢｒｕｓｈ、Ｐｅｎ、Ｇｅｏｍｅｔｒｙ、Ｐａｔｈなどを用いて使用する宣言的な形を提供するために、３Ｄ命令ストリームに入るものをユーザが構築できるようにする複数の型が設けられ、構築されるオブジェクトを、コンテキストを使用するのではなく、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌに設定することができる。
【０９４３】
例えば、上のＤｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔに基づくサンプルコードを、次のように書きなおすことができる。
【０９４４】
【表１８８−１】
2007509426.tif 000318
【０９４５】
【表１８８−２】
2007509426.tif 000319
【０９４６】
この場合に、モデルが、作成されており、その後、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌに割り当てられる。ＰｕｓｈＴｒａｎｓｆｏｒｍ／Ｐｏｐ対が、それ自体が変換とその下のＭｏｄｅｌを有するＭｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎの構成に置換されている。モデリング手法と強制的コンテキストに基づく手法との両方を提供することによって、ビジュアル内容の要素レベル宣言的マークアップ、ビジュアル列挙、場面グラフ効果、および変更可能性が提供され、これらの手法は、アーキテクチャとして実行可能な形で行われる。
【０９４７】
モデリングクラスツリーのルートは、Ｍｏｄｅｌ３Ｄであり、これは、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌに付加できる３次元モデルを表す。最終的に、ライト、メッシュ、．Ｘファイルストリーム（したがって、これは、ファイル、リソース、メモリなどから与えることができる）、モデルのグループ、および３Ｄ位置決めされた２Ｄビジュアルのすべてが、モデルである。したがって、次の階層がある。
【０９４８】
【表１８９】
2007509426.tif 000320
【０９４９】
Ｍｏｄｅｌ３Ｄクラス自体は、３Ｄ境界ボックスの取得、Ｍｏｄｅｌ３ＤのＴｒａｎｓｆｏｒｍの取得および設定、シェーディングモードなどの他の「ノード」レベルプロパティの取得および設定、ならびにｈｉｔＴｅｓｔＯｂｊｅｃｔの取得および設定を含む、複数の演算をサポートする。明示的な３Ｄ開始のヒットテストが、３Ｄ場面内で公開されていないことに留意されたい。言い換えると、任意の指向性射線を３Ｄ場面に投影して、何がヒットするかを調べるＡＰＩがない。ヒットテスト機能性は、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌ内の２Ｄ投影に対してヒットテストを実行することによってアクセスされる。
【０９５０】
３Ｄの組込みは、３Ｄ座標系を用いる２Ｄ座標系の有理化について課題を提示する。２Ｄでは、座標系が左上に原点を有し、＋ｘが右、＋ｙが下である。
【０９５１】
３Ｄ座標系は、右手系とすることができ、この場合に、＋ｚは画面から手前に向かい、＋ｘは右（２Ｄと同一）、＋ｙは上（２Ｄと異なる）である。これは、３Ｄグラフィックスコンテキストの左手座標系が、多数の不要なプログラミングエラーを作る傾向があるからである。現代のハードウェアが、頂点シェーダをダウンロードする能力を有し、したがって、望みのすべての座標系変換を使用することが可能にされることに留意されたい。
【０９５２】
座標系有理化のもう１つの態様が、テクスチャが存在するｕ，ｖ空間である。ｕ，ｖ空間に関する特定のデフォルト変換はないが、「＋ｖが下」のモデルは、「＋ｖが上」（テクスチャが上下反対に見える）を有するモデルよりも多数の、テクスチャリングを介する２Ｄ  ＵＩの直接マッピングが可能である。テクスチャリングされるモデルが正しい方位のｕ，ｖグリッドを有しない場合、ＭａｔｅｒｉａｌのＢｒｕｓｈのＴｒａｎｓｆｏｒｍプロパティを使用して打ち消すことができる。
【０９５３】
テキストが３Ｄで魅力的に見える最も実行可能な形を調べるために、多数の実験が実行された（これが、必ずしも幅、高さ、および奥行きを有する「３Ｄテキスト」を意味しないことに留意されたい）。このために、アプリケーションは、３Ｄで使用されるテキスト（および他の任意の２Ｄ要素）を保持する２Ｄ  Ｖｉｓｕａｌを構築し、そのＶｉｓｕａｌがオーバーサンプリングされる（例えば４倍から８倍）ようにし、プレーンまたは任意の３ＤオブジェクトへのＭａｔｅｒｉａｌとしてこのＶｉｓｕａｌを使用することができる。結果のテクスチャリングが異方性の場合に、その結果が、魅力的なテキストである。
【０９５４】
このセクションで指定する宣言型（例えば、ベクトル、点、ライト、メッシュ、マテリアル、プリミティブ、変換など）のすべてが、標準ＸＡＭＬ  ＣＬＲクラス型宣言機構を使用して、ＸＡＭＬに基づくマークアップ要素を介して簡単に記述可能であることに留意されたい。型は、ＴｙｐｅＣｏｎｖｅｒｔｅｒを有することができるが、そうでない場合に、型は、ＸＡＭＬが提供する、標準の単純プロパティ記述機構および複合プロパティ記述機構を介してマークアップ要素で指定可能である。ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定が、ＸＡＭＬに現れる型の純粋に文字列に基づく表現を解釈するためのものであることに留意されたい。したがって、例えば、ＳｃａｌｅＴｒａｎｓｆｏｒｍ３Ｄで使用されるＶｅｃｔｏｒ３Ｄについて、ＸＡＭＬマークアップは、次のようになる。
【０９５５】
【表１９０】
2007509426.tif 000321
【０９５６】
「ＳｃａｌｅＴｒａｎｓｆｏｒｍ３Ｄ」および「ｓｃａｌｅＶｅｃｔｏｒ」が、汎用ＸＡＭＬパーサによって解析され、理解されるが、「１，２，８」が、Ｖｅｃｔｏｒ３ＤのＴｙｐｅＣｏｎｖｅｒｔｅｒに供給され、（それが、ＳｃａｌｅＴｒａｎｓｆｏｒｍ３Ｄの「ＳｃａｌｅＶｅｃｔｏｒ」プロパティの型なので）Ｖｅｃｔｏｒ３Ｄを生成すると期待されることに留意されたい。さらに、型ごとに明示的にリストされはしないが、これらの型が、下記のメソッドを有することに留意されたい（ここではＶｅｃｔｏｒ３Ｄについて示すが、他の型にも適用可能である）。
【０９５７】
【表１９１】
2007509426.tif 000322
【０９５８】
Ｃｈａｎｇｅａｂｌｅから（直接にまたは間接に）派生するすべての型が、「ｐｕｂｌｉｃ  ｎｅｗ  ＭｙＴｙｐｅ  Ｃｏｐｙ（）」メソッドを有する必要がある。これらのプリミティブ型は、単に、このセクションで説明する他の型をサポートするために存在する。これらのプリミティブ型は、可能な場合には必ず、２Ｄで使用されるプリミティブ型の鏡像になり、この類似性が、これらの型の設計目標である。
【０９５９】
Ｐｏｉｎｔ３Ｄオブジェクトは、２ＤのＰｏｉｎｔ型Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｐｏｉｎｔの直接の類似物である。
【０９６０】
【表１９２】
2007509426.tif 000323
【０９６１】
【表１９３】
2007509426.tif 000324
【０９６２】
Ｖｅｃｔｏｒ３Ｄは、２Ｄ  Ｖｅｃｔｏｒ型Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｖｅｃｔｏｒの直接の類似物である。
【０９６３】
【表１９４−１】
2007509426.tif 000325
【０９６４】
【表１９４−２】
2007509426.tif 000326
【０９６５】
【表１９５】
2007509426.tif 000327
【０９６６】
Ｐｏｉｎｔ４Ｄは、３Ｄ点に第４のｗ成分を追加し、非アフィンＭａｔｒｉｘ３Ｄを介する変換に使用される。１の「ｗ」成分がＰｏｉｎｔ３Ｄに変換され、０の「ｗ」成分がＶｅｃｔｏｒ３Ｄに変換されるので、Ｖｅｃｔｏｒ４Ｄはない。
【０９６７】
【表１９６−１】
2007509426.tif 000328
【０９６８】
【表１９６−２】
2007509426.tif 000329
【０９６９】
【表１９７】
2007509426.tif 000330
【０９７０】
Ｑｕａｔｅｒｎｉｏｎ（４元数）は、３次元の回転を表す別個の３Ｄエンティティである。その能力は、４元数の間で補間して（したがってアニメーションにして）滑らかな信頼性のある補間を達成できることに由来する。特定の補間機構を、球面線形補間と称する。
【０９７１】
Ｑｕａｔｅｒｎｉｏｎは、その成分（ｘ，ｙ，ｚ，ｗ）の直接指定から、または軸／角度表現として構築することができる。第１の表現は、正規化されていない４元数をもたらし、これに関して、ある種の演算は意味をなさない（例えば、軸と角度の抽出）。
【０９７２】
Ｑｕａｔｅｒｎｉｏｎの構成要素は、Ｑｕａｔｅｒｎｉｏｎが構築されたならば設定することができない。というのは、それを行うことに潜在的な曖昧さがあるからであり、例えば、正規化されないＱｕａｔｅｒｎｉｏｎのＡｎｇｌｅを設定することには意味がない。
【０９７３】
【表１９８−１】
2007509426.tif 000331
【０９７４】
【表１９８−２】
2007509426.tif 000332
【０９７５】
【表１９９−１】
2007509426.tif 000333
【０９７６】
【表１９９−２】
2007509426.tif 000334
【０９７７】
Ｍａｔｒｉｘ３Ｄは、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｍａｔｒｉｘの３Ｄ類似物である。Ｍａｔｒｉｘと同様に、ほとんどのＡＰＩが、Ｍａｔｒｉｘ３ＤではなくＴｒａｎｓｆｏｒｍ３Ｄをとり、Ｔｒａｎｓｆｏｒｍ３Ｄは、深い形のアニメーションをサポートする。３Ｄ計算の行列は、４×４行列として表される。ＭＩＬでは、行ベクトル構文を使用する。
【０９７８】
【表２００】
2007509426.tif 000335
【０９７９】
行列が点とかけあわされるとき、その点が、新しい座標系から以前の座標系に変換される。
【０９８０】
変換は、任意のレベルまでネストすることができる。新しい変換が適用されるとき、その適用は、必ず、現在の変換行列に前からかけることと同一である。
【０９８１】
【表２０１−１】
2007509426.tif 000336
【０９８２】
【表２０１−２】
2007509426.tif 000337
【０９８３】
【表２０１−３】
2007509426.tif 000338
【０９８４】
【表２０１−４】
2007509426.tif 000339
【０９８５】
Ｔｒａｎｓｆｏｒｍ３Ｄは、２ＤのＴｒａｎｓｆｏｒｍに似て、３Ｄ変換の特定の型を表す具象サブクラスを有する抽象基底クラスである。Ｔｒａｎｓｆｏｒｍ３Ｄの特定のサブクラスは、アニメーションが送られる場所でもある。
【０９８６】
一実施形態での、Ｔｒａｎｓｆｏｒｍ３Ｄの階層全体を下に示す。
【０９８７】
【表２０２】
2007509426.tif 000340
【０９８８】
ルートのＴｒａｎｓｆｏｒｍ３Ｄは、Ｔｒａｎｓｆｏｒｍの特定のクラスを構築する静的メソッドを有する（このＴｒａｎｓｆｏｒｍはより広義とすることができるので、Ｍａｔｒｉｘ３Ｄ表現を公開しないことに留意されたい）。
【０９８９】
【表２０３−１】
2007509426.tif 000341
【０９９０】
【表２０３−２】
2007509426.tif 000342
【０９９１】
Ｐｏｉｎｔ３Ｄ／Ｖｅｃｔｏｒ３ＤをとるＴｒａｎｓｆｏｒｍ（）メソッドは、変換がアフィン変換でない場合に例外を送出することに留意されたい。
【０９９２】
Ｔｒａｎｓｆｏｒｍ３ＤＣｏｌｌｅｃｔｉｏｎは、ＴｒａｎｓｆｏｒｍＣｏｌｌｅｃｔｉｏｎを模倣し、上でＣｒｅａｔｅ＊メソッドが変更されたのと同じ形でＡｄｄ＊メソッドが変更される。
【０９９３】
【表２０４】
2007509426.tif 000343
【０９９４】
ＡｆｆｉｎｅＴｒａｎｓｆｏｒｍ３Ｄは、具象アフィン３Ｄ変換（変換、傾斜、回転、スケーリング）が派生される基底クラスであり、Ｍａｔｒｉｘ３Ｄへの読取アクセスを公開する。
【０９９５】
【表２０５】
2007509426.tif 000344
【０９９６】
ＴｒａｎｓｌａｔｅＴｒａｎｓｆｏｒｍ３Ｄ：
【０９９７】
【表２０６】
2007509426.tif 000345
【０９９８】
ＳｃａｌｅＴｒａｎｓｆｏｒｍ３Ｄ：
【０９９９】
【表２０７−１】
2007509426.tif 000346
【１０００】
【表２０７−２】
2007509426.tif 000347
【１００１】
ＲｏｔａｔｅＴｒａｎｓｆｏｒｍ３Ｄは、回転の軸という概念（従って４元数の使用）の導入に起因して、２Ｄ回転からの単純なマッピング以上のものである。
【１００２】
【表２０８−１】
2007509426.tif 000348
【１００３】
【表２０８−２】
2007509426.tif 000349
【１００４】
Ｑｕａｔｅｒｉｏｎプロパティだけがアニメーション可能であることに留意されたい。一般に、軸／角度のアニメーションは、うまく働かない傾向がある。４元数をアニメーションにする方がよく、４元数のベース値から軸および角度を抽出することができる。固定軸に対する角度を単純にアニメーションにしたい場合に、これを指定する簡単な方法は、この位置を表す２つの４元数を構築し、その間でアニメーションにすることである。
【１００５】
ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ３Ｄは、Ｍａｔｒｉｘ３Ｄから直接にＴｒａｎｓｆｏｒｍ３Ｄを構築することができる。
【１００６】
【表２０９】
2007509426.tif 000350
【１００７】
Ｔｒａｎｓｆｏｒｍ３Ｄ型プロパティが、マークアップ要素で指定されるとき、プロパティシステムは、Ｔｒａｎｓｆｏｒｍ型コンバータを使用して、ストリング表現を適当なＴｒａｎｓｆｏｒｍ派生オブジェクトに変換する。アニメーションにされるプロパティは、この構文を使用しては記述されないが、複合プロパティ構文を、アニメーション記述に使用することができる。
【１００８】
構文は、２ＤのＴｒａｎｓｆｏｒｍをモデルとし、「＜＞」は、オプションパラメータを表す。
【１００９】
【表２１０】
2007509426.tif 000351
【１０１０】
次が、例の文法である。
【１０１１】
【表２１１−１】
2007509426.tif 000352
【１０１２】
【表２１１−２】
2007509426.tif 000353
【１０１３】
Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌは、Ｖｉｓｕａｌから派生し、その際に、不透明度、２Ｄの幾何学的クリッピング、２ＤのＢｌｅｎｄＭｏｄｅ、ヒットテストＡＰＩ、２Ｄの境界照会、およびＶｉｓｕａｌツリーへの参加を含むプロパティを得る。不透明度、クリップ、ブレンドモード、および境界が、３Ｄ場面の２Ｄ投影に適用されることに留意されたい。
【１０１４】
【表２１２】
2007509426.tif 000354
【１０１５】
ＶｉｅｗＰｏｒｔボックスは、Ｃａｍｅｒａ／Ｍｏｄｅｌ組合せによって決定される投影が２Ｄローカル座標空間にマッピングされる場所を確立する。Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌにＢｏｕｎｄｓ３Ｄメソッドがないことに留意されたい。これは、Ｍｏｄｅｌｓ．Ｂｏｕｎｄｓとして使用可能である。
【１０１６】
Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔは、２ＤのＤｒａｗｉｎｇＣｏｎｔｅｘｔに非常によく類似し、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌのＭｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎからＲｅｎｄｅｒＯｐｅｎ／ＲｅｎｄｅｒＡｐｐｅｎｄを介してアクセス可能である。これは、命令を内部で保持するが、即時モードレンダリングコンテキストに似ている。
【１０１７】
【表２１３】
2007509426.tif 000355
【１０１８】
これらのＤｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔ演算のセマンティックスの特定の詳細を、Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔが便利であるＭｏｄｅｌｉｎｇ  ＡＰＩに関して下記で説明する。例えば、ＤｒａｗＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ（ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３ＤＳｏｕｒｃｅ  ｐｒｉｍｉｔｉｖｅＳｏｕｒｃｅ，ｏｂｊｅｃｔＨｉｔＴｅｓｔＴｏｋｅｎ）は、ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄを作成し、現在累積されているＭｏｄｅｌ３Ｄ（コンテキストに対するＰｕｓｈ／Ｐｏｐメソッドによって操作される）に追加する。
【１０１９】
ＤｒａｗＭｏｄｅｌ（）が、Ｍｏｄｅｌ３Ｄをコンテキストに「描画」できるようにする、「コンテキスト」の世界と「モデリング」の世界の間のもう１つの分かれ目の点である。Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔからの明示的な「リードバック」はない。というのは、Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔが、Ｍｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎにバッキングさせ、その集合を必要に応じて列挙できるからである。
【１０２０】
モデリングＡＰＩは、（継承したメンバを示さない）これらのクラスのｐｕｂｌｉｃかつｐｒｏｔｅｃｔｅｄなＡＰＩであり、Ｍｏｄｅｌ３Ｄは、それからすべてが構築される抽象モデルである。
【１０２１】
【表２１４】
2007509426.tif 000356
【１０２２】
Ｍｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎは、モデルの組合せが構築される場であり、単位として扱われ、任意選択として、それらのモデルに変換または他の属性を適用する。
【１０２３】
【表２１５−１】
2007509426.tif 000357
【１０２４】
【表２１５−２】
2007509426.tif 000358
【１０２５】
Ｍｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎが、ＲｅｎｄｅｒＯｐｅｎ／Ａｐｐｅｎｄも有し、このＲｅｎｄｅｒＯｐｅｎ／ＡｐｐｅｎｄがＤｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔを返すことに留意されたい。このコンテキストを使用することによって、ＭｏｄｅｌＣｏｌｌｅｃｔｉｏｎ自体が変更される。ＲｅｎｄｅｒＯｐｅｎ（）とＲｅｎｄｅｒＡｐｐｅｎｄ（）の間の相違は、ＲｅｎｄｅｒＯｐｅｎ（）がまず集合を消去することである。さらに、この実装で、一時に１つのＤｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔだけを、Ｍｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎでオープンすることができ、オープンされるときに、アプリケーションが、そのＭｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎの内容に直接にアクセス（読取または書込）することはできない。
【１０２６】
Ｌｉｇｈｔは、Ｍｏｄｅｌ３Ｄである。これには、Ａｍｂｉｅｎｔ、Ｐｏｓｉｔｉｏｎａｌ、Ｄｉｒｅｃｔｉｏｎａｌ、およびＳｐｏｔのライトが含まれる。Ｌｉｇｈｔは、モデリング階層の一部であるという追加のプロパティを有し、したがって、座標空間変換の対象である。ライトの環境色、拡散色、およびスペキュラ色が提供される。階層的にスコープを指定されるか、スコープを特定のボリュームに指定されるライトはないことに留意されたい。適切なライト階層を下に示す。
【１０２７】
【表２１６】
2007509426.tif 000359
【１０２８】
基底ｌｉｇｈｔクラスは抽象クラスである。
【１０２９】
【表２１７】
2007509426.tif 000360
【１０３０】
環境ライトは、形状にかかわらずにオブジェクトを均一に照らす。
【１０３１】
【表２１８】
2007509426.tif 000361
【１０３２】
指向性ライトは、空間内の位置を持たず、それを定義するベクトルによって指定される特定の方向に光を射す。
【１０３３】
【表２１９−１】
2007509426.tif 000362
【１０３４】
【表２１９−２】
2007509426.tif 000363
【１０３５】
方向は、正規化の必要はないが、非０の大きさを有する必要がある。
【１０３６】
位置ライトは、空間内の位置を有し、すべての方向に光を射す。ライトのフォールオフは、減衰プロパティおよび範囲プロパティによって制御される。
【１０３７】
【表２２０−１】
2007509426.tif 000364
【１０３８】
【表２２０−２】
2007509426.tif 000365
【１０３９】
ＰｏｉｎｔＬｉｇｈｔが、それからＳｐｏｔＬｉｇｈｔを派生できるようにするが、サードパーティが派生できなくするために、ｓｔｒｏｎｇｎａｍｅ継承確認要求を有する必要があることに留意されたい。
【１０４０】
ＳｐｏｔＬｉｇｈｔは、位置、範囲、および減衰を有するので、ＰｏｉｎｔＬｉｇｈｔから派生するが、方向およびライトの「円錐」を制御するパラメータも追加されている。「円錐」を制御するために、ｏｕｔｅｒＣｏｎｅＡｎｇｌｅ（その外は照らされない）およびｉｎｎｅｒＣｏｎｅＡｎｇｌｅ（その中のすべてのものが完全に照らされる）を指定する必要がある。内側の円錐の外と外側の円錐との間の照明は、線形に減少する（内側の円錐の縁と外側の円錐の縁との間の「角度」減少があり、光の位置に関する距離での減少が、減衰および範囲によって影響されることに留意されたい）。
【１０４１】
【表２２１−１】
2007509426.tif 000366
【１０４２】
【表２２１−２】
2007509426.tif 000367
【１０４３】
ＭＩＬ  ＡＰＩのすべてのものと同様に、角度が度単位で指定されることに留意されたい。
【１０４４】
Ｐｒｉｍｉｔｉｖｅ３Ｄは、ツリー内のレンダリングをもたらすリーフノードである。具象クラスは、明示的に指定されたメッシュならびに読み込まれたプリミティブ（．ｘファイル）を持ち込む。コンストラクタは内部コンストラクタである（拡張性は、ＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄを介して使用可能である）。
【１０４５】
【表２２２】
2007509426.tif 000368
【１０４６】
ＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄは、メッシュおよびマテリアルを用いるモデリング用である。
【１０４７】
【表２２３】
2007509426.tif 000369
【１０４８】
ＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄが、リーフ形状であり、それ自体ではなくＭｅｓｈが含まれることに留意されたい。これは、１つのＭｅｓｈを、メッシュデータを複製せずに、異なるヒットテストの対象になる異なるマテリアルを有する複数のＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄの間で共有できることを意味する。
【１０４９】
ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄは、持ち込まれ、適当な内部形式に変換される（潜在的にマテリアルおよびアニメーションを有する）外部から獲得されたプリミティブを表す。これは、固定モデルとして扱われる。この正規の例が、．Ｘファイルであり、明示的にＸＦｉｌｅを読み込む、ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３ＤＳｏｕｒｃｅのサブクラスがある。
【１０５０】
【表２２４】
2007509426.tif 000370
【１０５１】
．ｘファイルは、場面に共通して含まれると期待されるので、次のように、これを表す単純なＴｙｐｅＣｏｎｖｅｒｔｅｒフォーマットがサポートされる。
【１０５２】
【表２２５】
2007509426.tif 000371
【１０５３】
ＶｉｓｕａｌＭｏｄｅｌ３Ｄは、すべてのＶｉｓｕａｌ（定義により２Ｄ）をとり、場面に配置する。レンダリングされるとき、ＶｉｓｕａｌＭｏｄｅｌ３Ｄは、画面に位置合せされ、サイズは影響を受けないが、カメラから特定のｚ平面にある。Ｖｉｓｕａｌは、インタラクティブなままである。
【１０５４】
【表２２６】
2007509426.tif 000372
【１０５５】
ＶｉｓｕａｌＭｏｄｅｌ３Ｄのレンダリングでは、まず、ＣｅｎｔｅｒＰｏｉｎｔがワールド座標に変換される。次に、Ｖｉｓｕａｌを、スクリーンに位置合せされた形でピクセルバッファにレンダリングし、変換されたＣｅｎｔｅｒＰｏｉｎｔのｚは、ビジュアルの中心が配置される場所になる。カメラが動く場合に、ＶｉｓｕａｌＭｏｄｅｌ３Ｄは、画面上で同一の面積を占め、表向きであり、ライトまたは類似物によって影響されない。場面の残りに対するビジュアルのこのカメラ移動中の固定点は、配置がビジュアルの中心に基づいて行われるので、ビジュアルの中心である。
【１０５６】
提供されるＶｉｓｕａｌは、完全にインタラクティブであり、効果的に、それを含むＲｅｔａｉｎｅｄ３ＤＶｉｓｕａｌに「ペアレンティング」され、これは、Ｖｉｓｕａｌが単一の親だけを有することができるのと同様に、所与のＶｉｓｕａｌを任意のＶｉｓｕａｌＭｏｄｅｌ３Ｄで１回だけ使用できることを意味する。これが、インタラクティブＶｉｓｕａｌを３Ｄに組み込む２つの機構の１つであることに留意されたい。他方の機構は、ＶｉｓｕａｌＭａｔｅｒｉａｌを使用し、プリミティブに対してこれを使用することである。
【１０５７】
ＤｒａｗＭｅｓｈおよびＤｒａｗＶｉｓｕａｌの両方が、ｈｉｔＴｅｓｔＴｏｋｅｎ「オブジェクト」をとる。これは、３Ｄ  Ｖｉｓｕａｌがヒットしたとき、ＩＶｉｓｕａｌ．ＨｉｔＴｅｓｔ（）によって返される。これは、その後、３Ｄでヒットしたものの曖昧さをなくすのに使用される。ここで、各ＤｒａｗＭｅｓｈが、同一のメッシュを得る場合であっても、各ＤｒａｗＭｅｓｈに異なる「ｈｉｔＴｅｓｔＴｏｋｅｎ」を与えることができるので、「ピックパス」が必要でないことに留意されたい。
【１０５８】
一実施形態で、ＨｉｔＴｅｓｔｉｎｇは、Ｄｉｒｅｃｔ３Ｄ  ＲａｙＩｎｔｅｒｓｅｃｔユーティリティを介して実施され、このユーティリティは、ヒットまでの距離、ヒットポイントのｕ，ｖ座標を提供し、初期ヒットオブジェクトの先のヒットテストを可能にする。ヒットテスト結果が、ヒットされたプリミティブのｕ，ｖ座標を与えるのに十分な情報を有して、どのテクスチャにラップされていてもヒットテスト照会への変換が可能になることに留意されたい。さらに、ＶｉｓｕａｌＭｏｄｅｌ３Ｄについて、ならびにＶｉｓｕａｌＭａｔｅｒｉａｌの使用について、ヒットテストは、正しいマッピング点にある２Ｄビジュアルに進行する。ヒットテストコンテキストが外側の２Ｄ環境から来ることを可能にすることによるこの結果は、３Ｄ環境を介して継続され、ネストした２Ｄ環境でもう一度選択され、潜在的に永久に継続する。これの最終結果は、このパススルーを提供するとき、生の、テクスチャマッピングされたＡｖａｌｏｎ  ２Ｄコントロールへのユーザインタラクションが正しく動作することである。
【１０５９】
本発明は、外部ソースからの３Ｄプリミティブの読み込みという一般的な概念をサポートする。ｖ１でのこれの一実施形態は、．ｘファイルフォーマットに由来する。
【１０６０】
【表２２７】
2007509426.tif 000373
【１０６１】
．Ｘファイルは、ＸＦｉｌｅ３ＤＳｏｕｒｃｅとしてこのシステムに入り、ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄの構築に使用される。．Ｘファイルは、別々のデータ型に分離され、その結果、複数のＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄで使用でき、共有できるようになる。．ｘファイルの適当な変換および処理は、これの構築時に行うか、延期することができる。．ｘファイルが、１単位として読み込まれ、その内部のどれもが、別々にアドレッシング可能でないことに留意されたい。
【１０６２】
【表２２８】
2007509426.tif 000374
【１０６３】
Ｍｅｓｈ３Ｄプリミティブは、プログラムによって構築できる（インデックス付き指定とインデックスなし指定の両方が可能である）単純な三角形プリミティブである。これが、プリミティブの最も一般的な使用法と期待されるもの（すなわち、位置、法線、色、およびテクスチャの情報であり、後の３つはオプション）をサポートすることに留意されたい。メッシュは、三角形、直線、または点のいずれとして表示されるかの選択も可能である。メッシュは、解釈するインデックスの３つのトポロジすなわち、三角形リスト、三角形ストリップ、および三角形ファンもサポートする。
【１０６４】
Ｍｅｓｈ３Ｄによって直接にサポートされない頂点フォーマットおよび他のプリミティブ構成について、．ｘファイルを構築し、読み込むことができる。
【１０６５】
【表２２９−１】
2007509426.tif 000375
【１０６６】
【表２２９−２】
2007509426.tif 000376
【１０６７】
ＭｅｓｈＰｒｉｍｉｔｉｖｅＴｙｐｅは次のように定義される。
【１０６８】
【表２３０】
2007509426.tif 000377
【１０６９】
Ｍｅｓｈ３Ｄの頂点ごとのデータは、Ｐｏｓｉｔｉｏｎｓ、Ｎｏｒｍａｌｓ、Ｃｏｌｏｒｓ、およびＴｅｘｔｕｒｅＣｏｏｒｄｉｎａｔｅｓに分割される。このうちで、Ｐｏｓｉｔｉｏｎｓだけが必須である。他のいずれかが提供される場合、それらは、Ｐｏｓｉｔｉｏｎｓ集合と正確に同一の長さを有する必要があり、そうでない場合には例外が送出される。
【１０７０】
Ｎｏｒｍａｌは、提供される場合に、正規化されていると仮定される。システムは、トポロジ／近接に基づいて法線を計算することを試みず、その代わりに、法線が望まれる場合に、法線を供給する必要があることに留意されたい。
【１０７１】
ＴｒｉａｎｇｌｅＩｎｄｉｃｅｓ集合は、メッシュを構成する三角形の頂点ごとの情報を判定するために頂点データに索引付けするメンバを有する。この集合は、ＭｅｓｈＰｒｉｍｉｔｉｖｅＴｙｐｅの設定に基づいて解釈される。ＴｒｉａｎｇｌｅＬｉｓｔについて、ＴｒｉａｎｇｌｅＩｎｄｉｃｅｓ集合の３つの要素のすべてが、新しい三角形を定義する。ＴｒｉａｎｇｌｅＦａｎについて、インデックス０、１、２が、第１の三角形を決定し、各後続のインデックスｉが、頂点０，ｉ，ｉ−１によって与えられる新しい三角形を決定する。ＴｒｉａｎｇｌｅＳｔｒｉｐについて、インデックス０、１、２が、第１の三角形を決定し、各後続のインデックスｉが、頂点ｉ−２，ｉ−１，ｉによって与えられる新しい三角形を決定する。ＬｉｎｅＬｉｓｔ、ＬｉｎｅＳｔｒｉｐ、およびＰｏｉｎｔＬｉｓｔは、類似する補間を有するが、レンダリングは、三角形ではなく直線および点に関する。
【１０７２】
ＴｒｉａｎｇｌｅＩｎｄｉｃｅｓがｎｕｌｌの場合に、Ｍｅｓｈは索引なしのプリミティブとして実施され、これは、長さｎのＰｏｓｉｔｉｏｎｓ集合の値０、１、．．．、ｎ−２、ｎ−１を保持するＴｒｉａｎｇｌｅＩｎｄｉｃｅｓと同等である。
【１０７３】
Ｍｅｓｈの構築時に、この実装は、このメッシュを表す最適のＤ３Ｄ構造を作成する。ここで、実際のＣｏｌｌｅｃｔｉｏｎデータ構造体を、Ｍｅｓｈ実装によって放棄して、データの重複を防ぐことができる。ある他の機構（例えばＲｅｔａｉｎｅｄ３ＤＶｉｓｕａｌモデル階層のトラバース）を介してアクセスされる場合のメッシュの後続のリードバックは、オリジナルデータを保持するのではなく、保持されるＤ３Ｄ情報からデータを再構築する可能性が高い。
【１０７４】
メッシュは、Ｃｈａｎｇｅａｂｌｅから（Ａｎｉｍａｔａｂｌｅを介して）派生し、したがって、変更可能である。実装では、頂点および索引データへの設定をトラップし、これらの変更をＤ３Ｄデータ構造に伝搬させる必要がある。メッシュ内の頂点またはインデックスデータの宣言的アニメーションの明示的サポートはない。言い換えると、例えばＰｏｉｎｔ３ＤＡｎｉｍａｔｉｏｎＣｏｌｌｅｃｔｉｏｎｓはない。これは、例えば２Ｄポリラインパスとの一貫性を有する。
【１０７５】
他の型に似て、ＸＡＭＬ複合プロパティ構文を使用して、Ｍｅｓｈ３Ｄを定義する集合を指定することができる。しかし、これは、非実際的で冗長になる可能性があり、したがって、指定をより簡潔にするために、ＴｙｐｅＣｏｎｖｅｒｔｅｒが提供される。
【１０７６】
メッシュで定義される各集合は、解析され集合の作成に使用される数の単一の文字列をとることができる。例えば、位置と色だけを有するインデックス付き三角形ストリップを表すＭｅｓｈを、次のように指定することができる。
【１０７７】
【表２３１】
2007509426.tif 000378
【１０７８】
もちろん、これらのどれであっても、複合プロパティ構文ではるかに冗長に表すことができる。
【１０７９】
Ｐｒｉｍｉｔｉｖｅ３Ｄを構築するメソッドは、外見を定義するＭａｔｅｒｉａｌをとる。Ｍａｔｅｒｉａｌは、３つの具象サブクラス、ＢｒｕｓｈＭａｔｅｒｉａｌ、ＶｉｓｕａｌＭａｔｅｒｉａｌ、およびＡｄｖａｎｃｅｄＭａｔｅｒｉａｌを有する抽象基底クラスである。ＢｒｕｓｈＭａｔｅｒｉａｌおよびＶｉｓｕａｌＭａｔｅｒｉａｌの両方が、もう１つのＢａｓｉｃＭａｔｅｒｉａｌと称する抽象クラスのサブクラスである。したがって
【１０８０】
【表２３２】
2007509426.tif 000379
【１０８１】
ＢｒｕｓｈＭａｔｅｒｉａｌメソッドは、単一のＢｒｕｓｈをとるが、透明の達成（ピクセルごとまたはスカラのいずれか）、テクスチャ変換を有すること（アニメートされるものであっても）、ビデオテクスチャの使用、暗黙の自動生成されるミップマップなどを含む広範囲の効果に使用することができる。具体的に言うと、単色、画像、勾配、または別のＶｉｓｕａｌのテクスチャリングについて、ＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ、ＩｍａｇｅＢｒｕｓｈ、ＧｒａｄｉｅｎｔＢｒｕｓｈ、またはＶｉｓｕａｌＢｒｕｓｈが、ＢｒｕｓｈＭａｔｅｒｉａｌの作成に使用される。
【１０８２】
ＶｉｓｕａｌＭａｔｅｒｉａｌメソッドは、Ｖｉｓｕａｌからマテリアルを構築するように設計されている。このマテリアルは、入力が、それが組み込まれる３ＤワールドからＶｉｓｕａｌに渡されるという意味でインタラクティブである。これとＶｉｓｕａｌＢｒｕｓｈを有するＢｒｕｓｈＭａｔｅｒｉａｌの間の相違は、ＢｒｕｓｈＭａｔｅｒｉａｌがインタラクティブでないことである。
【１０８３】
ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌクラスは、ＢｒｕｓｈＭａｔｅｒｉａｌまたはＶｉｓｕａｌＭａｔｅｒｉａｌを単純に使用するよりかなり複雑であるが、さらなる柔軟性を提供する。
【１０８４】
【表２３３−１】
2007509426.tif 000380
【１０８５】
【表２３３−２】
2007509426.tif 000381
【１０８６】
マテリアルは、Ｂｒｕｓｈに基づくことによって、柔軟性および「概念の経済」を得る。例えば、ビデオテクスチャ、勾配テクスチャなどを反映する別々のＴｅｘｔｕｒｅ階層は不要である。というのは、これらのすべてがＢｒｕｓｈとして指定可能であるからである。Ｂｒｕｓｈは、すでに、アルファマスクとスカラ不透明値の両方をカプセル化しており、その結果、この両方が、テクスチャリングに使用可能になる。Ｂｒｕｓｈは、すでに２Ｄ  Ｔｒａｎｓｆｏｒｍを関連付けられており、これは、テクスチャリングの場合に、テクスチャにマッピングするためにメッシュ内のｕｖ座標を変換するテクスチャ変換と解釈される。Ｂｒｕｓｈは、木目シェーダなどのストック手続きシェーダを置くのによい場所である。これは、フィルまたはペンとして２Ｄで使用可能であり、テクスチャとして３Ｄで使用可能である。手続きシェーダのために３Ｄ空間で特定のＡＰＩサポートを与える必要はない。
【１０８７】
ピクセルシェーダおよび頂点シェーダは、「ストック」シェーダとして提供でき、その多くがパラメータ化されることに留意されたい。ＡＰＩでこれらをアクセス可能にする形は、２Ｄの世界で意味をなすシェーダについて、それらをＢｒｕｓｈの具象サブクラスとして公開し、そのパラメータ化を、クラスのコンストラクタを介してまたはクラスのプロパティとして表現することである。これらを、２Ｄオブジェクトに適用することができる。３Ｄでのみ意味をなすシェーダは、Ｍａｔｅｒｉａｌの具象サブクラスとして（多分ＢａｓｉｃＭａｔｅｒｉａｌのサブクラスとして）公開され、これらは、コンストラクタを介してパラメータ化することもできる。この公開によって、シェーダを３Ｄ（および適当な場合に２Ｄ）メッシュに適用できるようになる。
【１０８８】
上で説明したように、ＢｒｕｓｈＭａｔｅｒｉａｌは、Ｂｒｕｓｈをカプセル化する。Ｐｒｉｍｉｔｉｖｅ３Ｄに適用されるＢｒｕｓｈＭａｔｅｒｉａｌは、テクスチャとして扱われる。テクスチャは、直接にマッピングされる、すなわち、マッピングされるプリミティブの２Ｄのｕ，ｖ座標が、テクスチャ変換によって変更されたＴｅｘｔｕｒｅの対応するｘ，ｙ座標に直接に索引付けされる。他の２Ｄと同様に、テクスチャの座標系が、左上の（０，０）から走り、正のｙが下を指すことに留意されたい。
【１０８９】
Ｂｒｕｓｈに使用されるＶｉｓｕａｌＢｒｕｓｈは、入力を受け入れないが、それに対するアニメーションおよびそれに対して行われる構造的変更に従って更新される。ＭａｔｅｒｉａｌとしてＶｉｓｕａｌを使用し、なおかつ入力を受け取るためには、本明細書で説明するように、ＶｉｓｕａｌＭａｔｅｒｉａｌを使用する。
【１０９０】
【表２３４】
2007509426.tif 000382
【１０９１】
上で説明したように、ＶｉｓｕａｌＭａｔｅｒｉａｌは、インタラクティブＶｉｓｕａｌをカプセル化する。これは、Ｖｉｓｕａｌがテクスチャリングされた形で生きているという点で、Ｖｉｓｕａｌと共に使用されるＢｒｕｓｈＭａｔｅｒｉａｌと異なる。マッピングが、プリミティブに関連するｕ，ｖグリッドに基づくので、ユーザ入力がその２Ｄ対応物に対する完全な忠実度を有しない状況があることに留意されたい。例えば、２Ｄコントロールがマウスをキャプチャする（例えばスクロールバー挙動を実施するため）マウスキャプチャシナリオを検討されたい。このシナリオでは、マウスは、スクロールバーから離れることが許されるが、システムは、例えばマウスがスクロールバーに関してどのｙ位置にあるかを計算し、正しく演算することができる。コントロールが、ｕ，ｖグリッドを有するプリミティブにテクスチャリングされ、マウスがプリミティブから離れる状況では、一般に、この判定を行う方法がない。これの解消を加えながら行えることがあるが、これは、一般に、２Ｄ空間へのマッピングの制限になる。Ｖｉｓｕａｌが、効果的に、ルートＲｅｔａｉｎｅｄ３ＤＶｉｓｕａｌに何らかの形でペアレンティングされることに留意されたい。一実施形態で、フレームワークがコントロールの単一のペアレンティグに基づくという事実に起因して、複数のＭａｔｅｒｉａｌで単一のＵｉＥｌｅｍｅｎｔを使用することが不正であり、複数の場所でＶｉｓｕａｌＭａｔｅｒｉａｌを使用することも不正である。
【１０９２】
【表２３５】
2007509426.tif 000383
【１０９３】
ＢｒｕｓｈＭａｔｅｒｉａｌ／ＶｉｓｕａｌＭａｔｅｒｉａｌおよびＢｕｍｐＭａｐは、ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌを定義するのに使用される。
【１０９４】
【表２３６−１】
2007509426.tif 000384
【１０９５】
【表２３６−２】
2007509426.tif 000385
【１０９６】
ＥｎｖｉｒｏｎｍｅｎｔＭａｐが、キューブマッピングを可能にする特定のフォーマットであると期待されるテクスチャであることに留意されたい。具体的に言うと、立方体マップの６つの面を、（Ｂｒｕｓｈの３×２グリッドに似た形で）Ｔｅｘｔｕｒｅに関連するＢｒｕｓｈのセクションで表す必要がある。Ａｍｂｉｅｎｔプロパティ、Ｄｉｆｆｕｓｅプロパティ、およびＳｐｅｃｕｌａｒプロパティが、ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌ自体として指定することを許容されないので、一般的なＭａｔｅｒｉａｌではなくＢａｓｉｃＭａｔｅｒｉａｌをとることに留意されたい。さらに、ＶｉｓｕａｌＭａｔｅｒｉａｌが提供する対話性が、環境マップについて意味をなさないので、環境マップは、専らＢｒｕｓｈＭａｔｅｒｉａｌであることに留意されたい。
【１０９７】
バンプマップは、テクスチャに似て、プリミティブのテクスチャ座標を介して３Ｄプリミティブにマッピングされるグリッドである。しかし、補間されたデータは、表面の法線に対する動揺として解釈され、プリミティブの「でこぼこの」外見をもたらす。これを達成するために、バンプマップは、法線の動揺および潜在的に他の情報などの情報を運び、色情報または透明度情報は運ばない。このゆえに、バンプマップとしてＢｒｕｓｈを使用することは不適切である。したがって、特定のピクセルフォーマットのＩｍａｇｅＳｏｕｒｃｅとして、新しいＢｕｍｐＭａｐクラスを設けることができる。
【１０９８】
Ｍａｔｅｒｉａｌは、Ｂｒｕｓｈの文字列指定を自動的にＢｒｕｓｈＭａｔｅｒｉａｌに昇格させることができる単純なＴｙｐｅＣｏｎｖｅｒｔｅｒを提供する。
【１０９９】
【表２３７】
2007509426.tif 000386
【１１００】
これによって、次のような指定が可能になる。
【１１０１】
【表２３８】
2007509426.tif 000387
【１１０２】
形状階層内の任意のレベルに組込み可能でないモデルの環境パラメータを設けることができる。例えば、フォグは、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌでＦｏｇプロパティを設定することによって場面に追加することができ、例えば、使用可能なＦｏｇは「ピクセルフォグ」である。Ｆｏｇは、下に示すように、抽象クラスおよび階層として表される。
【１１０３】
【表２３９−１】
2007509426.tif 000388
【１１０４】
【表２３９−２】
2007509426.tif 000389
【１１０５】
ｆｏｇＤｅｎｓｉｔｙは、０から１までの範囲であり、フォグの密度の正規化表現である。ｆｏｇＳｔａｒｔおよびｆｏｇＥｎｄには、装置空間［０，１］で指定されるｚ深さが含まれ、フォグが始まる場所および終わる場所を表す。
【１１０６】
Ｃａｍｅｒａは、３Ｄモデルを２Ｄビジュアルに投影する機構である。Ｃａｍｅｒａ自体は抽象型であり、２つの具象サブ型ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａおよびＭａｔｒｉｘＣａｍｅｒａがある。ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａは、Ｐｏｓｉｔｉｏｎ、ＬｏｏｋＡｔＰｏｉｎｔ、およびＦｉｅｌｄＯｆＶｉｅｗなどのよく理解されたパラメータをとって、Ｃａｍｅｒａを構築する。ＭａｔｒｉｘＣａｍｅｒａは、Ｗｏｒｌｄ−Ｔｏ−Ｄｅｖｉｃｅ変換を定義するのに使用されるＭａｔｒｉｘ３Ｄをとる。
【１１０７】
【表２４０−１】
2007509426.tif 000390
【１１０８】
【表２４０−２】
2007509426.tif 000391
【１１０９】
Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌでは、Ｃａｍｅｒａは、Ｍｏｄｅｌ３Ｄへのビューを提供するのに使用され、結果の投影が、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌで確立された２Ｄ  ＶｉｅｗＰｏｒｔにマッピングされる。Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌの２Ｄ境界ボックスが、単純に３Ｄモデルの３Ｄ境界ボックスに投影され、凸の、軸を位置合せされた外被によってラップされ、ビジュアルで確立されたクリップまでクリッピングされることに留意されたい。
【１１１０】
ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａは、Ｐｏｓｉｔｉｏｎ、ＬｏｏｋＡｔＰｏｉｎｔ、およびＦｉｅｌｄＯｆＶｉｅｗなどのパラメータからカメラを構築する手段である。ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａは、透視投影と正投影との両方をカプセル化する。図４２に、ビューイングおよび位置を示すＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａの関連する態様のよい表示を示す（ＦｉｅｌｄＯｆＶｉｅｗは水平方向でなければならない）。
【１１１１】
【表２４１−１】
2007509426.tif 000392
【１１１２】
【表２４１−２】
2007509426.tif 000393
【１１１３】
ＦｉｅｌｄＯｆＶｉｅｗが、水平の視野を表し、度単位で指定される（他のＭＩＬ角度と同様に）ことに留意されたい。ＮｅａｒおよびＦａｒのＰｌａｎｅＤｉｓｔａｎｃｅは、ＬｏｏｋＤｉｒｅｃｔｉｏｎベクトルに沿ったカメラのＰｏｓｉｔｉｏｎからの３Ｄワールド座標での距離を表す。ＮｅａｒＰｌａｎｅＤｉｓｔａｎｃｅは、０をデフォルトとし、ＦａｒＰｌａｎｅＤｉｓｔａｎｃｅは、無限大をデフォルトとする。
【１１１４】
実際の投影の際に、ＮｅａｒＰｌａｎｅＤｉｓｔａｎｃｅおよびＦａｒＰｌａｎｅＤｉｓｔａｎｃｅがまだ０および無限大である場合に、モデルが検査され、その境界ボリュームが、カメラ投影に従って投影される。結果の境界ボリュームが、検査され、その結果、ニアプレーン距離に、カメラ位置に最も近いＬｏｏｋＤｉｒｅｃｔｉｏｎに垂直な、境界ボリュームの平面が設定される。これは、最も遠い平面が使用される以外は、ファープレーンについても同一である。これは、ｚバッファ分解能の最適利用をもたらすと同時に、モデル全体が表示される。ＩｓＯｒｔｈｏｇｒａｐｈｉｃが真である場合には、正投影が使用され、ＦｉｅｌｄＯｆＶｉｅｗは無視される。
【１１１５】
ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａのパラメータによって定義される「投影面」が、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌのＶｉｅｗＰｏｒｔ長方形にマッピングされ、それが、３−空間から２−空間への最終的な推移を表すことに留意されたい。
【１１１６】
ＣａｍｅｒａのＭａｔｒｉｘＣａｍｅｒａサブクラスは、投影変換としてＭａｔｒｉｘを直接に指定する手段を提供する。これは、それ自体の投影行列計算機構を有するアプリケーションに有用である。
【１１１７】
【表２４２】
2007509426.tif 000394
【１１１８】
ＭｉｎｉｍｕｍＺ値およびＭａｘｉｍｕｍＺ値によって、ｚバッファ範囲が直接に制御されることに留意されたい。これらは、投影行列としてのＭａｔｒｉｘの適用の後に検討される。
【１１１９】
結果の投影は、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌのＶｉｅｗＰｏｒｔ長方形にマッピングされ、３空間から２空間への最終的な推移を表す。
【１１２０】
次は、ＸＡＭＬでのＭｏｄｅｌ３Ｄ階層全体の指定を示す、より完全なマークアップ要素である。構文の一部を変更できることに留意されたい。
【１１２１】
次の例では、２つの読み込まれる．ｘファイルおよびその一方の回転変換（ｚ軸回りで４５°）と、０，１，０の、上にある単一の白い点光源を有するＭｏｄｅｌとを単純に作成する。
【１１２２】
【表２４３】
2007509426.tif 000395
【１１２３】
このマークアップ要素は、ファイル、ストリーム、リソース、または適当なエンティティにあるものとすることができる。クライアントプログラムは、そのＸＡＭＬのロードを呼び出し、それによって、完全なＭｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎが作成されて、望み通りにアプリケーションによって使用される。
【１１２４】
次の例は、複合プロパティＸＡＭＬ構文の使用を介する、明示的に宣言されたＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄを提供する。メッシュは、黄色から赤へのＬｉｎｅａｒＧｒａｄｉｅｎｔを用いてテクスチャリングされる。この場面にはライトもある。
【１１２５】
【表２４４−１】
2007509426.tif 000396
【１１２６】
【表２４４−２】
2007509426.tif 000397
【１１２７】
この例では、第１の．ｘファイルをとり、ＸＡＭＬ指定のアニメーションに追加する。この特定の例では、５秒間で．ｘファイルを１倍から２．５倍にスケーリングし、逆転する均一なスケールを追加し、これを無限に繰り返す。この例では、スケールのスローイン／スローアウトのために加速／減速も使用している。
【１１２８】
【表２４５−１】
2007509426.tif 000398
【１１２９】
【表２４５−２】
2007509426.tif 000399
【１１３０】
この例では、．ｘファイルを読み込み、マテリアルとして生のＵＩに適用する。
【１１３１】
【表２４６】
2007509426.tif 000400
【１１３２】
ＸＡＭＬは、リソースを参照する構文をサポートする。この文脈での「リソース」は、広義の用語であり、ＸＡＭＬファイルの「リソース」セクションならびに管理されるアセンブリの管理されるリソース「フォーク」からの読み込みの両方を意味する。両方の機構がサポートされ、リソースを共有するために、複数の場所からリソースを参照することができる。ネイティブＷｉｎ３２リソースを直接に読み込む機構は現在ないが、ＩＲｅｓｏｕｒｃｅＬｏａｄｅｒインターフェースの実装によってそれが可能になる。
【１１３３】
これは、ＸＡＭＬには直接に関連しないが、メッシュおよびマテリアルなどを共有するアプリケーションを構成する方法に関連する。３Ｄ「モデリング」オブジェクト（Ｌｉｇｈｔ、Ｍｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎ、ＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄ、Ｍａｔｅｒｉａｌ、Ｍｅｓｈ３Ｄ、Ｂｒｕｓｈなど）が、型Ｃｈａｎｇｅａｂｌｅであることに留意されたい。前述のように、変更可能な値は、概念上深いコピーを作るが、実際にはオンデマンドの浅いクローン作成を行うＣｏｐｙ（）メソッドを提供する。このＣｏｐｙ（）メソッドを使用することによって、オブジェクトのサブパーツを変更できるようにしながらの、オブジェクトの最適の共有がもたらされる。
【１１３４】
Ｒｅｃｔａｎｇｌｅ、Ｐｏｌｙｇｏｎ、Ｅｌｌｉｐｓｅなどの２次元「形状」は、それ自体がＵｉＥｌｅｍｅｎｔであるＳｈａｐｅクラスを介してＷｉｎｄｏｗｓ（登録商標）Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋに導入される。Ｒｅｃｔａｎｇｌｅなどの形状は、Ｃａｎｖａｓに置くことができ、Ｃａｎｖａｓ自体は、形状のコンテナとしての使用を意図されたＵｉＥｌｅｍｅｎｔである。次が、１つの例である。
【１１３５】
【表２４７】
2007509426.tif 000401
【１１３６】
この例では、ＣａｎｖａｓがＵｉＥｌｅｍｅｎｔであり、ＲｅｃｔａｎｇｌｅおよびＬｉｎｅのそれぞれが、ＵｉＥｌｅｍｅｎｔである。この例では、Ｃａｎｖａｓに含まれるすべてのものが、ＵｉＥｌｅｍｅｎｔである。
【１１３７】
しかし、次の例に示された、マークアップ要素でのＰａｔｈの組合せを検討されたい。
【１１３８】
【表２４８】
2007509426.tif 000402
【１１３９】
この例では、ＣｉｒｃｌｅＧｅｏｍｅｔｒｙ、ＲｅｃｔａｎｇｌｅＧｅｏｍｅｔｒｙ（すなわち、Ｐａｔｈ．Ｄａｔａの中にあるもの）自体はＵｉＥｌｅｍｅｎｔではないが、ＰａｔｈコンテナはＵｉＥｌｅｍｅｎｔである。
【１１４０】
要素レベル「３Ｄ  Ｓｈａｐｅ」は、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌの３Ｄ特性が、Ｖｉｓｕａｌ自体を超えないという問題を提示する。すなわち、２つのＶｉｓｕａｌの内容は、絶対にｚ方向に浸透しあわない（例えば、リンゴのビジュアルを貫通する矢印のビジュアルを有することはできない）。ＣｏｎｔｒｏｌおよびＳｈａｐｅはＶｉｓｕａｌから派生するので、これは、互いに浸透しあうＣｏｎｔｒｏｌまたはＳｈａｐｅを有することのサポートがないことも意味する。これらは、必ず、その内容の２Ｄ投影である。
【１１４１】
Ｅｌｅｍｅｎｔレベルで互いに浸透しあう３Ｄ「オブジェクト」を有するため、およびそれをマークアップ要素で表現するために、必要な相互浸透を有する複雑な３Ｄモデルを含めることができるＶｉｅｗＰｏｒｔ３Ｄ要素が提供される。しかし、これは、他のＶｉｅｗＰｏｒｔ３Ｄとｚ方向で相互作用するのではない（３Ｄ空間への２Ｄビューポートなので、ＶｉｅｗＰｏｒｔ３Ｄと呼ばれる）。
【１１４２】
ＶｉｅｗＰｏｒｔ３Ｄは、Ｓｈａｐｅが派生するのと同一のクラス（ＦｒａｍｅｗｏｒｋＥｌｅｍｅｎｔまたはＣｏｎｔｒｏｌ）から派生する。Ｓｈａｐｅが、Ｆｉｌｌ、Ｓｔｒｏｋｅなど、３Ｄでは意味をなさないプロパティを有するので、ＶｉｅｗＰｏｒｔ３ＤをＳｈａｐｅから派生させてはならないことに留意されたい。したがって、ＶｉｅｗＰｏｒｔ３Ｄ、Ｓｈａｐｅ、およびＩｍａｇｅは、兄弟である。ＶｉｅｗＰｏｒｔ３Ｄは、Ｓｈａｐｅに存在するプロパティの一部（Ｔｏｐ、Ｌｅｆｔ、Ｗｉｄｔｈ、Ｈｅｉｇｈｔ、Ｔｒａｎｓｆｏｒｍ、およびＣｌｉｐ）を含む、設定できる複数のプロパティを有する。これらのプロパティは、３Ｄでは関係しないが、３Ｄの２Ｄ投影では意味をなし、これは、ＶｉｅｗＰｏｒｔ３Ｄであり、このＶｉｅｗＰｏｒｔ３Ｄは、ＵｉＥｌｅｍｅｎｔである。
【１１４３】
ＶｉｅｗＰｏｒｔ３Ｄは、それに関連付けられたＣａｍｅｒａ（および適当なデフォルトが供給される）ならびにフォグなどの３Ｄ場面全体のプロパティ（すなわち、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌにもあるプロパティ）も有する。ＶｉｅｗＰｏｒｔ３Ｄは、形状を介して提示される３Ｄオブジェクトの集合を表す、Ｍｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎ値のプロパティ（それ自体がＭｏｄｅｌ３Ｄである）も有する。このモデルには、ライトも含まれる。アプリケーションがｚで相互作用できるようにすることを望むものは、どれでも、単一のＶｉｅｗＰｏｒｔ３Ｄに関するこの単一のＭｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎに置かれる。
【１１４４】
カメラが指定されない場合には、Ｔｏｐ、Ｌｅｆｔ、Ｗｉｄｔｈ、およびＨｅｉｇｈｔによって決定されるＶｉｅｗＰｏｒｔ３Ｄ境界がモデルによって満たされ、ニア／ファークリップ平面がモデルの直前と直後に設定され、カメラがｚ軸を向いており、ｙが上になるよう投影を提供するデフォルトカメラが使用される。ライトが指定されない場合には、ｙ軸の下を指す白の指向性ライトが、暗黙のうちに使用される。
【１１４５】
ＶｉｅｗＰｏｒｔ３Ｄのマークアップ要素は、上で示したＰａｔｈのマークアップ要素に似ている。というのは、上のマークアップ要素が、非ＵｉＥｌｅｍｅｎｔがＰａｔｈマークアップ要素の中で指定される例であるからである。次が、ＶｉｅｗＰｏｒｔ３Ｄマークアップ要素の例である。
【１１４６】
【表２４９−１】
2007509426.tif 000403
【１１４７】
【表２４９−２】
2007509426.tif 000404
【１１４８】
＜Ｖｉｅｗｐｏｒｔ３Ｄ＞タグ内に、Ｍｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎ値のメンバが、個々のマークアップ要素で指定されたＭｏｄｅｌ３Ｄから取り込まれている。この例のタグとＭｏｄｅｌ３Ｄのサブクラスの間の１対１マッピングがあることに留意されたい。例えば、この例の２番目のＭｅｓｈは、マークアップ要素で指定されたコントロール（この例ではＢｕｔｔｏｎ）を含むＶｉｓｕａｌマテリアルを有する。このコントロールは、完全にインタラクティブであり、ＯｎＣｌｉｃｋなどを指定することができる。
【１１４９】
ＶｉｅｗＰｏｒｔ３Ｄの直接の子ノードは、「デフォルト」集合がＭｏｄｅｌｓ集合なので、Ｍｏｄｅｌ３Ｄである。この構文は、一般に、複合プロパティ構文で＜ＶｉｅｗＰｏｒｔ３Ｄ．Ｍｏｄｅｌ＞の指定を必要とするように変更することができる。このマークアップ要素は、通常の２Ｄマークアップが従うのと同一のリソースのパスに従って、例えば、Ｍａｔｅｒｉａｌを定義し、複数の場所でそれを使用する。その機能性は、一般的なリソース機構によって提供される。
【１１５０】
一般に、ヒットテストは、ＵｉＥｌｅｍｅｎｔまたはＣｏｎｔｒｏｌのレベルで行われる。しかし、ヒットテストは、全体としてＶｉｅｗＰｏｒｔ３Ｄに制限され、さもなければ、ヒットテストは、複数のＶｉｅｗＰｏｒｔ３Ｄへのモデルの分割とそれらに対するヒットテストを必要とする。しかし、複数のＶｉｅｗＰｏｒｔ３Ｄに分割されるや否や、モデルは、同一の３Ｄ環境の一部ではなくなる。これは、マークアップ要素またはコードでＭｏｄｅｌ３Ｄの個々のメンバに対してイベントハンドラを指定できるようにすることならびに「ｉｄ」によって解決される。ヒットテストを解決するときに、適当なメソッドが呼び出され（センダは、まだ全体としてＶｉｅｗＰｏｒｔ３Ｄである）、識別子が、ＥｖｅｎｔＡｒｇｓの一部として渡される。アプリケーションは、異なるイベントハンドラで、または「ｉｄ」の切り替えによってのいずれかで、論理を分離することができなければならない。
【１１５１】
ＶｉｓｕａｌＭａｔｅｒｉａｌの使用は、ヒットテストが組み込まれた要素に進行しなければならないことのシステムへの指示である。システムは、それが実際に行われることを保証する。したがって、ヒットテスト動作は、２Ｄから３Ｄに推移し、２Ｄに戻る。次は、ＶｉｅｗＰｏｒｔ３ＤのＡＰＩ仕様である。
【１１５２】
【表２５０−１】
2007509426.tif 000405
【１１５３】
【表２５０−２】
2007509426.tif 000406
【１１５４】
３Ｄで正しく透明性を行うために、プリミティブ（および、限度内で、個々の三角形）が、後ろから前にソートされ、これによって、ｚバッファが参加しなくなる。これは、正しい混合を保証するのに必要である。
【１１５５】
ＥｍｂｅｄｄｉｎｇＨｏｓｔＶｉｓｕａｌも提供される。これは、外部当事者が構築できないＶｉｓｕａｌのサブクラスであり、内部的に構築することだけができる。ＥｍｂｅｄｄｉｎｇＨｏｓｔＶｉｓｕａｌには、指定されたＶｉｓｕａｌが、親子以外のあるＶｉｓｕａｌ対Ｖｉｓｕａｌ関係の「組み込みホスト」として使用されていることを表すＶｉｓｕａｌが含まれる。３Ｄ場面に組み込まれた２Ｄ  Ｖｉｓｕａｌが、これのもう１つの例である。Ｅｆｆｅｃｔｓを、Ｖｉｓｕａｌの間の非親子関係のもう１つの例とすることができる。
【１１５６】
定義を次に示す。
【１１５７】
【表２５１】
2007509426.tif 000407
【１１５８】
ＥｍｂｅｄｄｉｎｇＨｏｓｔＶｉｓｕａｌ「親」に対する関係は、通常の親子関係にならないように定義されるので、これは、均一のマッピングがないので、Ｖｉｓｕａｌの間のＴｒａｎｓｆｏｒｍの抽出などの読取サービスが意味をなさないことを意味する。これらの動作は、３Ｄサブシステム自体によって処理されるが、その機構が、Ｒｅｔａｉｎｅｄ３ＤＶｉｓｕａｌに特有であることに留意されたい。
【１１５９】
（媒体）
ＭｅｄｉａＤａｔａは、添付の付録にも記載されているが、次のオブジェクトを介する音声／ビデオ内容の再生に使用することができる。
【１１６０】
【表２５２−１】
2007509426.tif 000408
【１１６１】
【表２５２−２】
2007509426.tif 000409
【１１６２】
【表２５２−３】
2007509426.tif 000410
【１１６３】
ＡｕｄｉｏＤａｔａオブジェクトは、音声データのために提供される。
【１１６４】
【表２５３−１】
2007509426.tif 000411
【１１６５】
【表２５３−２】
2007509426.tif 000412
【１１６６】
【表２５３−３】
2007509426.tif 000413
【１１６７】
【表２５３−４】
2007509426.tif 000414
【１１６８】
ＶｉｄｅｏＤａｔａオブジェクトは、ビデオデータのために提供される。
【１１６９】
【表２５４−１】
2007509426.tif 000415
【１１７０】
【表２５４−２】
2007509426.tif 000416
【１１７１】
要素レベルのＶｉｄｅｏオブジェクトも提供される。
【１１７２】
【表２５５−１】
2007509426.tif 000417
【１１７３】
【表２５５−２】
2007509426.tif 000418
【１１７４】
要素レベルのＡｕｄｉｏオブジェクトも提供される。
【１１７５】
【表２５６】
2007509426.tif 000419
【１１７６】
（結論）
前述の詳細な説明のように、プログラムコードにシーングラフとインターフェースする能力を与えるインターフェースおよびオブジェクトモデルを含む媒体統合レイヤが提供される。このシステム、方法、およびオブジェクトモデルは、使用が簡単でありながら、強力、柔軟、かつ拡張可能である。
【１１７７】
本発明は、様々な修正構成および代替構成を許すが、そのある例の実施形態を、図面に示し、上記で詳細に説明した。しかし、本発明を、開示された特定の形態に限定することは意図されておらず、逆に、その意図が、本発明の趣旨および範囲に含まれるすべての修正形態、代替構成、および同等物を含むことであることを理解されたい。
【図面の簡単な説明】
【１１７８】
【図１】本発明を組み込むことができる例示的なコンピュータシステムを示すブロック図である。
【図２】本発明を組み込むことができるグラフィックスレイヤアーキテクチャを全般的に示すブロック図である。
【図３】本発明の態様による、ビジュアルのシーングラフと、グラフィックスコマンドおよび他のデータを供給するためにシーングラフをトラバースすることによるなどのシーングラフを処理する関連コンポーネントを示す図である。
【図４】本発明の態様に従って構成された、バリデーションビジュアル、ドローイングビジュアル、および関連するＩｎｓｔｒｕｃｔｉｏｎ  Ｌｉｓｔのシーングラフを示す図である。
【図５】本発明の態様による、オブジェクトモデルのビジュアルクラスを示す図である。
【図６】本発明の態様による、オブジェクトモデルの様々な他のオブジェクトを示す図である。
【図７】本発明の態様による、変換クラス階層を示す図である。
【図８】本発明の態様による、形状スケールでのビジュアルのデータの変換を表す図である。
【図９】本発明の態様による、不均一スケールでのビジュアルのデータの変換を表す図である。
【図１０】本発明の態様による、オブジェクトモデルの形状クラスを示す図である。
【図１１】本発明の態様による、ＰａｔｈＧｅｏｍｅｔｒｙ構造体を示す図である。
【図１２】本発明の態様による、プリミティブによって作られる例のグラフィックスを示す、ビジュアルおよびＩｎｓｔｒｕｃｔｉｏｎ  Ｌｉｓｔのシーングラフを示す図である。
【図１３】本発明の態様による、オブジェクトモデルのブラシクラスを示す図である。
【図１４】本発明の態様による、型のミュータビリティを制御するために要求が状態機械によって処理される変更可能アーキテクチャを全般的に示すブロック図である。
【図１５】本発明の態様による、プロパティ状態がミュータブルな型の挙動をどのように制御するかを示す状態図である。
【図１６】本発明の態様による、プロパティ状態がミュータブルな型の挙動をどのように制御するかを示す状態図である。
【図１７】本発明の態様による、プロパティ状態がミュータブルな型の挙動をどのように制御するかを示す状態図である。
【図１８】本発明の態様による、プロパティが例のコードの状態推移およびクローン作成挙動をどのように制御するかを示す、例のシーングラフのオブジェクトの階層表現を示す図である。
【図１９】本発明の態様による、プロパティが例のコードの状態推移およびクローン作成挙動をどのように制御するかを示す、例のシーングラフのオブジェクトの階層表現を示す図である。
【図２０】本発明の態様による、プロパティが例のコードの状態推移およびクローン作成挙動をどのように制御するかを示す、例のシーングラフのオブジェクトの階層表現を示す図である。
【図２１】本発明の態様による、プロパティが例のコードの状態推移およびクローン作成挙動をどのように制御するかを示す、例のシーングラフのオブジェクトの階層表現を示す図である。
【図２２】本発明の態様による、プロパティが例のコードの状態推移およびクローン作成挙動をどのように制御するかを示す、例のシーングラフのオブジェクトの階層表現を示す図である。
【図２３】本発明の態様による、プロパティが例のコードの状態推移およびクローン作成挙動をどのように制御するかを示す、例のシーングラフのオブジェクトの階層表現を示す図である。
【図２４】本発明の態様による、リニア勾配ブラシオブジェクトのデータから生じるレンダリングされたグラフィックを示す図である。
【図２５】本発明の態様による、ラジアル勾配ブラシオブジェクトのデータから生じるレンダリングされたグラフィックを示す図である。
【図２６】本発明の態様による、様々なストレッチ値を有することから生じるレンダリングされたグラフィックを示す図である。
【図２７】本発明の態様による、様々なタイル値を有することから生じるレンダリングされたグラフィックを示す図である。
【図２８】本発明の態様による、レンダリングされたナイングリッドブラシオブジェクトを示す図である。
【図２９】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図３０】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図３１】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図３２】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図３３】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図３４】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図３５】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図３６】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図３７】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図３８】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図３９】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図４０】本発明の態様による、アニメーションに使用される例のタイムラインのグラフィカル表現を示す図である。
【図４１】本発明の態様による、３次元ビジュアルを介して構築される例の３次元画像を示す図である。
【図４２】本発明の態様による、３次元サポートを提供する３次元概念を示す図である。
【図１】
2007509426.tif 000420
【図２】
2007509426.tif 000421
【図３】
2007509426.tif 000422
【図４】
2007509426.tif 000423
【図５】
2007509426.tif 000424
【図６】
2007509426.tif 000425
【図７】
2007509426.tif 000426
【図８】
2007509426.tif 000427
【図９】
2007509426.tif 000428
【図１０】
2007509426.tif 000429
【図１１】
2007509426.tif 000430
【図１２】
2007509426.tif 000431
【図１３】
2007509426.tif 000432
【図１４】
2007509426.tif 000433
【図１５】
2007509426.tif 000434
【図１６】
2007509426.tif 000435
【図１７】
2007509426.tif 000436
【図１８】
2007509426.tif 000437
【図１９】
2007509426.tif 000438
【図２０】
2007509426.tif 000439
【図２１】
2007509426.tif 000440
【図２２】
2007509426.tif 000441
【図２３】
2007509426.tif 000442
【図２４】
2007509426.tif 000443
【図２５】
2007509426.tif 000444
【図２６】
2007509426.tif 000445
【図２７】
2007509426.tif 000446
【図２８】
2007509426.tif 000447
【図２９】
2007509426.tif 000448
【図３０】
2007509426.tif 000449
【図３１】
2007509426.tif 000450
【図３２】
2007509426.tif 000451
【図３３】
2007509426.tif 000452
【図３４】
2007509426.tif 000453
【図３５】
2007509426.tif 000454
【図３６】
2007509426.tif 000455
【図３７】
2007509426.tif 000456
【図３８】
2007509426.tif 000457
【図３９】
2007509426.tif 000458
【図４０】
2007509426.tif 000459
【図４１】
2007509426.tif 000460
【図４２】
2007509426.tif 000461
【国際調査報告】
2007509426.tif 000462