コンピューティングシステムにおいて、プログラム及びウインドウデスクトップマネージャから呼出しを受け取り、前記プログラムと前記ウィンドウデスクトップマネージャとのうちの一方に対応する階層データ構造を構築するビジュアルシステムと、前記ビジュアルシステムからコマンドを受け取り、前記コマンドに応答してコンポジタデータ構造を構築して、グラフィックス出力を提供する、統一された合成エンジンであって、前記コンポジタデータ構造が、前記ビジュアルシステムによって構築された前記階層データ構造に対応する、統一された合成エンジンと、前記ビジュアルシステムからの前記コマンドを前記統一された合成エンジンへ送るよう構成された変更キューと、前記統一された合成エンジンからの要求と通知を前記ビジュアルシステムへ送るよう構成された通知キューであって、リソースルックアップに失敗した場合に前記統一された合成エンジンによってポストされる通知キューと、を含むことを特徴とするシステム。前記ビジュアルシステム内部に含まれるマスタリソーステーブルであって、前記プログラムと前記デスクトップウインドウマネージャとうちの一方によって使用されるリソースの第1のリストを含むマスタリソーステーブルと、前記統一された合成エンジン内部に含まれるスレーブリソーステーブルであって、前記統一された合成エンジンに提供されるリソースの第2のリストを含み、前記マスタリソーステーブルによって管理されるスレーブリソーステーブルとをさらに含むことを特徴とする、請求項1に記載のシステム。リソースの前記第2のリストは、リソースの前記第1のリストと比べた場合、リソースの包括的なリストであることを特徴とする、請求項2に記載のシステム。前記マスタリソーステーブルは、前記スレーブリソーステーブルのリソースの存続期間を、シリアル化された要求を介して明示的に制御することを特徴とする、請求項2に記載のシステム。前記統一された合成エンジンが前記デスクトップウインドウマネージャに応答して動作する場合と、前記統一された合成エンジンがプログラムに応答して動作する場合とにおいて、同一のライブラリが同一の合成を実行していることを特徴とする、請求項1に記載のシステム。前記デスクトップウインドウマネージャに応答する場合に、前記統一された合成エンジンによって使用されるためのプロトコルは、前記プログラムに応答する場合に、前記統一された合成エンジンによって使用されるためのプロトコルの機能サブセットを含むことを特徴とする、請求項1に記載のシステム。前記スレーブリソーステーブルリソースは、単一の合成スレッド上でアクセスされることを特徴とする、請求項1に記載のシステム。前記統一された合成エンジンは、単一のスレッドとして実行され、定数合成ループの中で実行されることを特徴とする、請求項1に記載のシステム。追加のビジュアルシステムをさらに含み、前記ビジュアルシステムと前記追加のビジュアルシステムとによってシーンが合成されるように、前記ビジュアルシステムと前記追加のビジュアルシステムと前記統一された合成エンジンと通信することを特徴とする、請求項1に記載のシステム。追加の統一された合成エンジンをさらに含み、前記ビジュアルシステムに対応する複数のグラフィックス出力が生成されるように、前記ビジュアルシステムが前記統一された合成エンジン及び前記追加の統一された合成エンジンと通信することを特徴とする、請求項1に記載のシステム。コンピューティングシステムにおける方法であって、プログラム及びデスクトップウインドウマネージャから呼出しを受け取り、前記呼出しに応答して、ビジュアルシステムにより、前記プログラムと前記デスクトップウィンドウマネージャとのうちの一方に対応する階層データ構造を構築するステップと、前記階層データ構造に対する変更を表す情報を、統一された合成エンジンに通信するステップと、前記統一された合成エンジンに、前記階層データ構造に関係するマスタリソーステーブルに対応するリソースセットを通信するステップと、前記通信された情報に基づき、前記統一された合成エンジンによって構築されたコンポジタデータ構造の中の情報を更新するステップと、前記通信されたリソースセットに基づき、前記コンポジタデータ構造に関係するスレーブリソーステーブルを更新するステップと、前記コンポジタデータ構造を処理して、グラフィックス情報を出力するステップと、前記統一された合成エンジンがリソースルックアップに失敗した場合に、前記統一された合成エンジンから前記ビジュアルシステムへ、要求と通知とを送るステップと、を含むことを特徴とする方法。階層データ構造を構築する前記ステップは、前記コンポジタデータ構造の処理と比べて非同期で実行されて、前記出力グラフィックス情報を生成することを特徴とする、請求項11に記載の方法。前記スレーブリソーステーブルは、前記マスタリソーステーブルと比べた場合、リソースの包括的なリストであるリソースリストを含むことを特徴とする、請求項11に記載の方法。前記マスタリソーステーブルに応答して、前記スレーブリソーステーブルの存続期間を制御するステップをさらに含むことを特徴とする、請求項11に記載の方法。前記統一された合成エンジンが前記デスクトップウインドウマネージャに応答して動作する場合、第1のライブラリに従って前記統一された合成エンジンを使用して合成を実行し、前記統一された合成エンジンがプログラムに応答して動作する場合、前記第1のライブラリに従って前記統一された合成エンジンを使用して合成を実行するステップをさらに含むことを特徴とする、請求項11に記載の方法。前記デスクトップウインドウマネージャに応答する場合に前記統一された合成エンジンによって使用されるプロトコルは、前記プログラムに応答する場合に前記統一された合成エンジンによって使用される前記プロトコルの機能サブセットを含むことを特徴とする、請求項11に記載の方法。単一の合成スレッド上で前記スレーブリソーステーブルのリソースにアクセスするステップをさらに含むことを特徴とする、請求項11に記載の方法。前記統一された合成エンジンを、単一のスレッドとして、定数合成ループの中で実行するステップをさらに含むことを特徴とする、請求項11に記載の方法。前記グラフィックス出力情報が追加のプログラムに対応するように、追加の情報と追加のリソースセットとを前記統一された合成エンジンに通信するステップをさらに含むことを特徴とする、請求項11に記載の方法。プログラムとデスクトップウインドウマネージャとのうちのいずれか一方に対応する複数のグラフィックス出力情報が生成されるように、前記情報とリソースセットとを複数の統一された合成エンジンに通信することを特徴とする、請求項11に記載の方法。以上の改良点は、グラフィックス処理技術において相当な利益をもたらすが、いくつかの改良点は、未だに実現されていない。簡単に述べると、本発明は、これまで別々であった合成サービスを結合することを一般に行う、統一された合成エンジンのためのシステムおよび方法を提供する。統一された合成エンジンは、アプリケーションプログラミングインタフェースAPIに関連してインプロセスin-processでも、デスクトップコンポジタcompositorとしてデスクトップ上でも使用される合成サービスを提供する。統一された合成エンジンは、これまでの2つの合成作業の作業、すなわち、単一のアプリケーションのコンテンツを合成するインプロセス利用を目的とするAPI合成エンジンと、ウインドウのすべてのウインドウを合成して、最終表示を作成することを目的とするデスクトップ合成エンジンとを結合する。デスクトップ合成エンジンとAPI合成エンジンは、異なる役割、および異なる使用シナリオを有する。デスクトップ合成エンジンは、他のプロセスによってレンダリングされたコンテンツを合成し、最小限の独自のコンテンツをレンダリングして、ウインドウフレームを実施し、レガシウインドウマネージャ例えば、User32と緊密に連携するのに使用される。API合成エンジンは、レンダリングを制御し、単一のアプリケーションに関するコンテンツのすべてを合成し、効率的なリモート処理remotingのための機構を提供するのに使用される。API合成エンジンおよびデスクトップ合成エンジンに関する使用要件の最近の変更により、API合成エンジンが、他のプロセス、およびレガシの子ウインドウからのコンテンツをホストすることが要求され、デスクトップ合成エンジンが、ウインドウフレームをリモート処理することが要求されることになった。2つの合成作業を結合することにより、コード重複が削減され、試験カバレッジが向上し、レガシウインドウ相互運用性、リモート処理、およびマルチドキュメントインタフェースMultipleDocumentingInterfacingMDIのような、さもなければ複雑である、拡張をもたらす特徴enablingfeaturesが単純化される。本発明は、統一された合成エンジンUCE;UnifiedCompositionEngineのためのシステムおよび方法を実質的に対象とする。本発明は、コード重複を実質的に削減して、アプリケーションレベルとデスクトップレベルの両方でグラフィックス出力を合成するための方法を提供する。以下の説明は、3つの部分に分けられる。説明の第1の部分は、本発明が機能することが可能な例示的なコンピューティング環境を説明する。説明の第2の部分は、例示的なグラフィックスアーキテクチャを説明する。説明の第3の部分は、本発明の1つの例示的な実施形態を説明する。例示的なコンピューティング環境図1は、本発明を実施することができる適切なコンピューティングシステム環境100の実施例を示す。コンピュータシステム環境100は、適切なコンピューティング環境の一実施例に過ぎず、本発明の用法または機能の範囲について何ら限定を示唆するものではない。また、コンピューティング環境100が、例示的な動作環境100に示したコンポーネントのいずれの1つ、または組合せに関連する依存関係または要件も有すると解釈してはならない。本発明は、多数の他の汎用または専用のコンピューティングシステム環境またはコンピューティングシステム構成で機能する。本発明で使用するのに適する可能性がある周知のコンピューティングシステム、コンピューティング環境、および/またはコンピューティング構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家庭用電化製品、ネットワークPC、ミニコンピュータ、メインフレームコンピュータ、以上のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれるが、以上には限定されない。本発明は、コンピュータによって実行される、プログラムモジュールなどの、コンピュータ実行可能命令の一般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行する、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。また、本発明は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される、分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含む、ローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体の両方の中に配置することができる。図1を参照すると、本発明を実施するための例示的なシステムが、コンピュータ110の形態で汎用コンピューティングデバイスを含む。コンピュータ110のコンポーネントには、処理装置120、システムメモリ130、ならびにシステムメモリから処理装置120までを含む様々なシステムコンポーネントを結合するシステムバス121が含まれることが可能であるが、以上には限定されない。システムバス121は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のいずれであってもよい。例として、限定としてではなく、そのようなアーキテクチャには、インダストリスタンダードアーキテクチャIndustryStandardArchitectureISAバス、マイクロチャネルアーキテクチャMicroChannelArchitectureMCAバス、エンハンストISAEnhancedISAEISAバス、ビデオエレクトロニクススタンダーズアソシエーションVideoElectronicsStandardsAssociationVESAローカルバス、アクセレレーテッドグラフィックポートAcceleratedGraphicsPortAGPバスおよびメザニンMezzanineバスとしても知られるペリフェラルコンポーネントインターコネクトPeripheralComponentInterconnectPCIバスが含まれる。コンピュータ110は、通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ110がアクセスすることができる任意の利用可能な媒体であることが可能であり、揮発性媒体と不揮発性媒体、リムーバブルな媒体とリムーバブルでない媒体がともに含まれる。例として、限定としてではなく、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことが可能である。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を格納するために、任意の方法または技術で実装された揮発性媒体と不揮発性媒体、リムーバブルな媒体とリムーバブルでない媒体がともに含まれる。コンピュータ記憶媒体には、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD-ROM、デジタルバーサタイルディスクDVDまたは他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、あるいは所望の情報を格納するのに使用することができ、コンピュータ110がアクセスできる他の任意の媒体が含まれるが、以上には限定されない。通信媒体は、通常、搬送波などの変調されたデータ信号、または他のトランスポート機構でコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを実現し、あらゆる情報配信媒体が含まれる。変調されたデータ信号という用語は、信号内に情報を符号化するような形で特性の1つまたは複数が設定、または変更されている信号を意味する。例として、限定としてではなく、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、ならびに音響媒体、RF媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。また、前述した媒体のいずれの媒体の組合せも、コンピュータ可読媒体の範囲に含められなければならない。システムメモリ130は、読み取り専用メモリROM131やランダムアクセスメモリRAM132などの揮発性メモリおよび/または不揮発性メモリの形態で、コンピュータ可読媒体を含む。起動中などにコンピュータ110内部の要素間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム133BIOSが、通常、ROM131の中に格納される。RAM132は、通常、処理装置120が、即時にアクセスすることができ、かつ/または現在、処理しているデータおよび/またはプログラムモジュールを含む。例として、限定としてではなく、図1は、オペレーティングシステム134、アプリケーションプログラム135、他のプログラムモジュール136、およびプログラムデータ137を示す。コンピュータ110は、その他のリムーバブルな/リムーバブルでない、揮発性/不揮発性のコンピュータ記憶媒体も含むことが可能である。単に例として、図1は、リムーバブルでない不揮発性の磁気媒体に対して読み取りまたは書き込みを行うハードディスクドライブ141、リムーバブルな不揮発性の磁気ディスク152に対して読み取りまたは書き込みを行う磁気ディスクドライブ151、およびCD-ROMまたは他の光媒体などのリムーバブルな不揮発性の光ディスク156に対して読み取りまたは書き込みを行う光ディスクドライブ155を示す。例示的な動作環境において使用することができるその他のリムーバブルな/リムーバブルでない、揮発性/不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタルバーサタイルディスク、デジタルビデオテープ、ソリッドステートRAM、ソリッドステートROMなどが含まれるが、以上には限定されない。ハードディスクドライブ141は、通常、インタフェース140のような、リムーバブルでないメモリインタフェースを介してシステムバス121に接続され、磁気ディスクドライブ151および光ディスクドライブ155は、通常、インタフェース150のような、リムーバブルなメモリインタフェースでシステムバス121に接続される。前述し、図1に示したドライブ、および関連するコンピュータ記憶媒体により、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージが、コンピュータ110に提供される。図1で、例えば、ハードディスクドライブ141が、オペレーティングシステム144、アプリケーションプログラム145、その他のプログラムモジュール146、およびプログラムデータ147を格納しているのが示されている。以上のコンポーネントは、オペレーティングシステム134、アプリケーションプログラム135、その他のプログラムモジュール136、およびプログラムデータ137と同一であることも、異なることも可能であることに留意されたい。オペレーティングシステム144、アプリケーションプログラム145、その他のプログラムモジュール146、およびプログラムデータ147に、ここでは、少なくとも、それらが異なるコピーであることを示すために異なる符号を与えている。ユーザは、タブレット電子デジタイザ164、マイク163、キーボード162、ならびにマウス、トラックボール、またはタッチパッドと一般に呼ばれるポインティングデバイス161などの入力デバイスを介して、コマンドおよび情報をコンピュータ20に入力することができる。その他の入力デバイス図示せずには、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどが含まれることが可能である。以上、およびその他の入力デバイスは、しばしば、システムバスに結合されたユーザ入力インタフェース160を介して処理装置120に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバスUSBなどの他のインタフェースおよびバス構造で接続してもよい。また、モニタ191、または他のタイプのディスプレイデバイスも、ビデオインタフェース190のようなインタフェースを介して、システムバス121に接続される。また、モニタ191は、タッチスクリーンインタフェース192のようなインタフェースを介して、コンピュータシステム110に手書きするなどして、デジタル化された入力を入力することができるタッチスクリーンパネル193などと一体化することもできる。モニタおよび/またはタッチスクリーンパネルは、タッチスクリーンパネル193が、実質的にタブレット164の役割をするタブレット型パーソナルコンピュータの場合のように、コンピューティングデバイス110が組み込まれた筐体に物理的に結合することができることに留意されたい。さらに、コンピューティングデバイス110のようなコンピュータは、出力周辺インタフェース194などを介して接続することができる、スピーカ195やプリンタ196などの、他の周辺出力デバイスも含むことが可能である。コンピュータ110は、リモートコンピュータ180のような1つまたは複数のリモートコンピュータに対する論理接続を使用する、ネットワーク化された環境において動作することができる。リモートコンピュータ180は、パーソナルコンピュータ、サーバ、ルータ、ネットワークPC、ピアデバイス、またはその他の一般的なネットワークノードであることが可能であり、通常、コンピュータ110に関連して前述した要素の多く、またはすべてを含むが、メモリ記憶装置181だけを図1に示している。図1に示す論理接続は、ローカルエリアネットワークLAN171およびワイドエリアネットワークWAN173を含むが、その他のネットワークも含むことが可能である。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。LANネットワーキング環境で使用される場合、コンピュータ110は、ネットワークインタフェースまたはネットワークアダプタ170を介してLAN171に接続される。WANネットワーキング環境で使用される場合、コンピュータ110は、通常、インターネットなどのWAN173を介して通信を確立するためのモデム172、またはその他の手段を含む。内部にあることも、外部にあることも可能なモデム172は、ユーザ入力インタフェース160、またはその他の適切な機構を介してシステムバス121に接続することができる。ネットワーク化された環境では、コンピュータ110に関連して示すプログラムモジュール、またはプログラムモジュールの諸部分は、リモートメモリ記憶装置の中に格納することができる。例として、限定としてではなく、図1は、リモートアプリケーションプログラム185が、メモリデバイス181上に存在する場合を示す。図示したネットワーク接続は、例示的であり、コンピュータ間で通信リンクを確立する他の手段も使用できることが理解されよう。例示的なグラフィックスアーキテクチャ説明する1つの実施形態においては、本発明は、一般に、メディアインテグレーションレイヤmediaintegrationlayerスタックに組み込まれ、このスタックの中に、アプリケーションプログラム、デスクトップシステムなどが、ビジュアルAPIレイヤに対する呼出しを直接に行うことにより、または解釈されて、ビジュアルAPIレイヤに対する呼出しになるマークアップを提供することにより、高レベルのビジュアルシステムへの様々なデータをサブミットする。ビジュアルシステムは、ビジュアルシステムにサブミットされたデータに基づき、階層シーングラフを構築し、何らかのレンダリング時に、そのシーングラフを処理して、コマンド、およびその他のデータにして、スタック内のコンポジタサービスと非同期で通信して、それらのコマンドおよび、その他のデータを独自の保持されるデータ構造にする。より低レベルのコンポジタシステムは、場合により、複数のビジュアルシステムクライアントからの通信を結合して、グラフィックスサブシステムによって理解されるグラフィックスコマンド、ならびに保持されたグラフィックスデータの諸部分を変更するアニメーションコマンドまたはアニメーション間隔にすることができる。より低いレベルのコンポジタシステムは、グラフィックスハードウェアのリフレッシュレートに相当する例えば、そのレートの、またはそのレートに近い速度で、グラフィックスサブシステムに、それらのグラフィックスコマンドを提供する。本発明の一態様は、一般に、システムディスプレイ上でグラフィック出力をレンダリングするために、プログラムコードによって開始された描画命令、およびその他の情報例えば、イメージビットマップを受け取り、処理することを目的とする。この目的で、本発明は、様々なコンポーネント、データ構造、および通信プロトコルで実施されるシステムおよび方法を提供し、システムおよび方法は一緒になって、例えば、ビジュアルシステムに関連するユーザインタフェーススレッドおよびレンダリングスレッドにおいて、より高いレベルの合成エンジンを可能にして、より低いレベルのアニメーション-合成エンジン、つまり、コンポジタにデータを提供する。ビジュアルシステムは、関数例えば、アプリケーションプログラミングインタフェース、つまり、APIをアプリケーションプログラムなどに提供して、それらのプログラムが、データ構造、描画プリミティブコマンド、およびその他のグラフィックス関連データで、シーングラフをポピュレートすることができるようにする。図2は、API合成エンジンに関する一般的な階層アーキテクチャ200を示す。図2に示すとおり、プログラムコード202例えば、アプリケーションプログラムまたはオペレーティングシステムコンポーネントなどが、イメージング204を介すること、ベクトルグラフィック要素206を介すること、および/またはビジュアルアプリケーションプログラミングインタフェースAPIレイヤ212に対して直接に行われる関数/メソッド呼出しを介することなどを含む、1つまたは複数の様々な形でグラフィックスデータを出力するように、開発されることが可能である。ベクトルグラフィック要素の使用は、MarkupLanguageandObjectModelforVectorGraphicsという名称の前述した特許出願で説明しており、他方、APIレイヤとの直接対話は、VisualandSceneGraphInterfacesという名称の、前述した同時係属出願でさらに説明している。一般に、イメージング機構204は、イメージ、例えば、ビットマップを読み込むため、編集するため、および保存するための機構をプログラムコード202に提供する。それらのイメージは、システムの他の諸部分によって使用されることが可能であり、プリミティブ描画コードを使用して、イメージを直接描画する方法も存在する。ベクトルグラフィックス要素206が、ビジュアルシステムのオブジェクトモデルと一致する、グラフィックスを描画する別の方法を提供する。ベクトルグラフィック要素206は、マークアップ言語を介して作成することができ、そのマークアップ言語を、要素/プロパティシステム208およびプレゼンタシステム210が処理して、ビジュアルAPIレイヤ212に対する適切な呼出しを行う。一般に、ベクトルグラフィック要素206は、構文解析されて、オブジェクトモデルのオブジェクトになり、それらのオブジェクトから、シーングラフが描かれ、それらのオブジェクトは、要素/プロパティシステム208およびプレゼンタシステム210を介して、要素レベルを介してシーングラフに提供されても、より効率的な形で、ソースレベルで提供されてもよい。1つの実施形態では、グラフィックスレイヤアーキテクチャ200は、ビジュアルAPI212に対する直接の呼出し、間接的な呼出しを介して構築された、階層化されたオブジェクトを含むシーングラフ216を含むか、または別の形で、そのようなシーングラフ216に関連するビジュアルシステム214を含む。一般に、シーングラフは、API呼出しによって生成された構造上の特質、および特定のレンダリングデータをモデル化し、アプリケーションがクエリを行う、読み取られたサービスまたはプロパティのセットも提供する。一般に、ビジュアルAPIレイヤ212は、オブジェクトを作成する能力、オブジェクトの開閉を行って、オブジェクトにデータを提供する能力などを含め、シーングラフ216に対するインタフェースをプログラムコードおよびプレゼンタシステムに提供する。つまり、ビジュアルシステム214は、統一されたメディアAPIレイヤ212を公開し、レイヤ212により、開発者は、グラフィックス情報を表示するグラフィックスおよびメディアに関する意図を表現し、十分な情報を基礎にあるプラットフォームに提供して、プラットフォームが、プログラムコードに関するハードウェアの使用を最適化できるようにすることができる。例えば、基礎にあるプラットフォームは、キャッシング、リソースネゴシエーション、およびメディア統合を担う。本発明の態様によれば、以下に説明するとおり、ビジュアルシステム214は、コンポジタより低いレベルの合成-アニメーションエンジン218のクライアントとして動作し、適切なデータをコンポジタに通信して、所望のフレームがレンダリングされるようにする。一般に、ビジュアルシステム214は、コンポジタ218より計算リソースを多く使用する動作を通常、実行するユーザインタフェースコンポーネントを含み、このため、ビジュアルシステム214のこの態様は、通常、コンポジタの動作速度に対して、比較的、より遅い速度で動作する。本明細書で使用する、高レベルおよび低レベルという用語は、一般に、高位のコンポーネントに対してソフトウェアコンポーネントがより低位であるほど、そのコンポーネントは、ハードウェアにより近い、他のコンピューティングシナリオにおいて使用される用語と同様であることに留意されたい。このため、例えば、ビジュアルシステムの高レベルの合成-アニメーションエンジンコードから送られたグラフィックス情報は、低レベルのデスクトップ合成-アニメーションエンジンにおいて受け取られることが可能であり、その情報は、ハードウェアを含むグラフィックスサブシステム222にグラフィックスデータを送るのに使用される。本発明の態様によれば、ビジュアルシステム212は、シーン変更データなどの様々な情報、アニメーション関数データなどの命令、ならびに、場合により、レンダリングスレッドによって処理されて、コンポジタ218に提供されるデータになるその他のデータ例えば、ビットマップに対するポインタを非同期で通信する。つまり、ビジュアルシステム212は、以下に説明するとおり、複数のデスクトップアプリケーションにわたって共有される、より低いレベルの合成システム218に基礎を置く、ユーザインタフェーススレッドおよびレンダリングスレッドを含む。このより低いレベルの合成システム218は、デバイスリフレッシュレートに適合し、システム218にコンテンツを送るアプリケーションとは別個のプロセス内に存在する。個々のクライアントアプリケーションのビジュアルシステムからのこの切り離しにより、個別のアプリケーションアニメーションの費用が、システムスケジューラによって適切に裁定され、扱われることが可能になる。さらに、アプリケーション常駐の合成エンジンスレッドは、専用のスレッドを、類似したアプリケーション常駐の合成スレッドに共通であるカテゴリにグループ化することができる。例えば、CPUスケジューリング確保システムを使用して、CPU消費パーセンテージに関する上限および下限を、システム上で実行されているアプリケーションに適用することができる。以下に説明するとおり、ビジュアルシステム214は、タイミング-アニメーションシステム220と統合されて、宣言型またはその他のアニメーション制御例えば、アニメーション関数、アニメーション間隔、およびその他のパラメータ、およびタイミング制御をもたらす。アニメーションシステムは、アニメートanimate値が、例えば、要素プロパティレベル、ビジュアルAPIレイヤ212の内部、およびその他のリソースの任意のリソース内を含め、システム内の実質的にどこにでも送られることを可能にすることに留意されたい。タイミングシステムは、要素レベルおよびビジュアルレベルで公開される。コンポジタ218は、シーンの合成、アニメ化、およびレンダリングを管理し、そのシーンが、次に、グラフィックスサブシステム222に提供される。1つの実施形態では、ビジュアルシステムは、アニメーション機能および合成機能を提供する第2のスレッド同一のプロセス内のと連携して動作するユーザインタフェーススレッドを含む。このため、複数のアプリケーションのシーンからのグラフィックスのレンダリングを実施する合成コンポーネント異なるプロセス内のから切り離された合成コンポーネントが、各ビジュアルシステム内に存在する。ときとして、レンダリングの一部が、より高いレベルで行われ、例えば、より低いレイヤが、複数のアプリケーションからの要求に対応している間に、ビジュアルシステムが、アプリケーションごとにインスタンス化され、これにより、イメージング機構を介して、時間がかかるレンダリング、またはアプリケーション固有のレンダリングを、より高いレベルで実行して、ビットマップに対する参照をコンポジタ218に送ることが可能であることが有利であることに留意されたい。この場合、API合成エンジンとデスクトップ合成エンジンの両方の間で共同で行われるsharedのが、API合成エンジンに関して前述した、より低いレベルの合成である。API合成エンジンとデスクトップ合成エンジンの両方に関する、より低いレベルの合成を結合することにより、本発明の統一された合成エンジンがもたらされる。統一された合成エンジンは、例示的な実施形態の説明で以下に説明するとおり、API合成エンジンとデスクトップ合成エンジンの両方に関するリソース管理を行って、表示のためのシーンを生成する。図3に示すとおり、ローカルで表示される出力の代替として、またはそのような出力に加えて、コンポジタ218または類似のコンポジタは、プリンタ232などに固定イメージデータを送るために、レンダリング命令およびアニメーション命令を適切なフォーマットで、より低いレベルの印刷コードprintingcode230に与えてもよく、かつ/またはリモートマシン238に伝送するために、レンダリング命令、および単純なアニメーション間隔を適切なフォーマットで、より低いレベルの端末トランスポートサーバ236に与えてもよい。また、より豊かな情報が、ネットワークを介して送られてもよく、例えば、リモートマシンに、ネットワークトラフィックなしに、マウスロールオーバRollover効果をローカルで扱わせることが望ましい可能性があることに留意されたい。例示的な実施形態図4は、本発明による、統一された合成エンジンを利用するための概略アーキテクチャを示す。統一された合成エンジンのアーキテクチャは、マスタリソーステーブル402と、ビジュアルツリー404と、合成デバイスインタフェース406と、変更キュー408と、通知キュー410と、合成ツリー412と、スレーブリソーステーブル414とを含む。統一された合成エンジンアーキテクチャは、2つのレイヤに論理的に分けられる。すなわち、上位レイヤ、またはクライアントレイヤ401すなわち、ビジュアルシステムが、統一された合成エンジンの主要なクライアントであるビジュアルツリー404すなわち、階層データ構造を含み、下位レイヤは、統一された合成エンジン自体420である。ビジュアルツリー404は、統一された合成エンジンと、統一された合成エンジンのメインクライアントの間の対話、ならびにクライアントによって保持されるリソーステーブル例えば、402、414と、統一された合成エンジンの間の対話をもたらす。本発明によれば、ビジュアルツリー404は、統一された合成エンジン420のクライアントとしてのデスクトップウインドウマネージャで置き換えることができる。デスクトップウインドウマネージャは、統一された合成エンジン420が、デスクトップ合成エンジンとして使用されている場合にクライアントである。ビジュアルツリー404とデスクトップウインドウマネージャが、統一された合成エンジン420のクライアントである場合に関して、今度は同一のライブラリが、同一の合成を実行する。アプリケーションのビジュアルツリーとデスクトップウインドウマネージャに関して、異なる処理が実行され、異なる処理はそれぞれ、異なるデータを扱うがすなわち、ペイロードが異なる、統一された合成エンジン420に関するプロトコルは、変わらない。一実施形態では、デスクトップウインドウマネージャで使用するためのプロトコルは、アプリケーションがクライアントである場合に利用可能なプロトコルの機能サブセットfunctionalsubsetを含む。実施例として、クライアントレイヤ401と統一された合成エンジン420の間の対話、ならびにリソース管理を、アプリケーションがクライアントである状況に関して、以下に説明する。ビジュアルツリー404は、表示されるべきシーンのアプリケーションまたはドキュメントによる表現を表す。このシーンは、非常に大きいことが可能であり、場合により、現在、可視であるものよりもはるかに大きいことが可能である。各ビジュアル例えば、405のコンテンツは、レンダリング命令のリスト、つまり、RenderData、ならびに形状、ポイント、ペン、ブラシ、イメージなどの各ビジュアルが使用するリソースによって定義される。それらのリソースは、各リソースに関する、デバイスおよび解像度とは独立のデータを含み、一部のケースでは、集合またはリソースに依存する形態を含むマスタリソーステーブル402によって管理される。マスタリソーステーブル402は、リソースの存続期間を管理することを担う例えば、参照カウントを介して。ビジュアルツリーが表示されるようになるまで、ビジュアルツリー例えば、404またはリソースに関する情報は、統一された合成エンジン420に全く伝送されない。ビジュアルツリー例えば、404は、レンダ目標に関連付けられると、そのツリーの表現を適切なリソースとともに、統一された合成エンジン420に送る。通信は、合成デバイスインタフェース406の変更キュー408を介して、非同期である。本明細書で、まとめて合成ツリー412すなわち、コンポジタデータ構造と呼ぶ、ビジュアルツリー404の潜在的に可視のサブセットが、統一された合成エンジン420の中で表現される。ビジュアルツリーは、既知の解像度レンダ目標に結び付けられると、表示される。したがって、オブジェクトからレンダ目標空間への完全な変形が、クライアントに関して知られている。統一された合成エンジン420に送られるリソースは、コールバック、または要求される実現realizationが送られることなしに、統一された合成エンジン420によって直接実現可能である。TextやImagesのようなリソースは、実現するのが高価であり処理オーバーヘッドの点で、したがって、ビジュアルツリー404において、適切なレンダ準備完了ready-to-render形態に変換される。リソースを、容易にレンダリングされることが可能な形態に変換することにより、統一された合成エンジン420における合成に関するオーバーヘッドが節約される。また、リソースは、リソースが、ユーザコードに対するコールバックを要求する場合、ビジュアルツリー404においても実現される。必要な場合に、統一された合成エンジン420によって正しい解像度に効率的に細分されることが可能なGeometryのような、他のリソースは、統一された合成エンジン420自体によって実現される。統一された合成エンジン420は、スレーブリソーステーブル414の中でリソースを管理する。一実施形態では、スレーブリソーステーブル414は、パフォーマンスを向上させるように、いずれの形態でも参照カウントを実行しない。これは、スレーブリソーステーブル414リソースが、合成デバイスに関する単一の合成スレッド上でアクセスされるために可能である。一実施形態では、スレーブリソーステーブル414の中のすべてのリソースは、マスタリソーステーブル402の中にも存在する。マスタリソーステーブル402は、シリアル化された変更キュー408要求を介して、スレーブリソーステーブル414リソースの存続期間を明示的に制御する。統一された合成エンジン420は、ハンドルによってリソースを参照する。一実施形態では、リソースルックアップが失敗した場合、統一された合成エンジン420は、通知キュー410にメッセージをポストし、そのリソースを要求する処理を単に飛ばして進む。統一された合成エンジン420は、単一のスレッドとして実行され、定数合成ループの中で実行される。図示した統一された合成アーキテクチャに関する本発明の一態様は、アーキテクチャによるリソースの使用である。リソースは、異なる解像度および/または物理的デバイスに関して異なる実現を要求するシーンをレンダリングするために必要とされ、合成ツリー内で複数回、使用され、あるいは、アニメーションを介するなどして、ユーザとは独立に変化することが可能である任意のオブジェクトと定義することができる。リソースは、統一された合成エンジン420の中、およびクライアントレイヤ401において、テーブル例えば、マスタリソーステーブル402の中のレコードとして表現され、ハンドルによって参照される。リソースを使用するオブジェクトは、ハンドルによってそれを行う。ハンドルは、実際のオブジェクトに対するポインタを獲得するために、リソーステーブル例えば、マスタリソーステーブル402の中で探すことができる。リソースは、自らをシリアル化し、更新を適用し、特定の解像度およびデバイスに関する実現を提供することができる。リソースは、一般に、描画リソース、値リソース、および構造リソースなどの、いくつかのタイプに分けられる。描画リソースは、レンダリングレイヤによって定義されたオブジェクトであり、このレイヤによって直接消費されることが可能である。描画リソースの例には、RenderData、Bitmap、Image、Glyphrun、Geometry、およびBrushが含まれる。描画リソースは、単純なカテゴリと複雑なカテゴリにさらに分けることができる。非常に低く、不変のレンダリング費用を有する描画リソースは、合成中に、デバイスおよび解像度とは独立のソースデータから直接実現することができる。Geometryは、単純な描画リソースである。というのは、Geometryは、統一された合成エンジン420の合成ループの中で、最終の要求される解像度に効率的に細分されることが可能だからである。これに対して、複雑な描画リソースは、複雑な計算、ユーザコードに対するコールバック、または実現を生成する入出力を要する。一実施形態では、複雑な描画リソースは、統一された合成エンジン420によっては実現されない。代わりに、適切な実現は、合成に先立って、クライアントレイヤ401において提供される。イメージは、複雑なリソースの例である。イメージは、ディスクから読み取られ、復号化され、適切な解像度でサンプリングされ、フィルタ処理される。値リソースは、別のリソースによって使用される単純な変更可能な値、またはアニメート値を表す。値リソースの例が、Double、Point、Color、およびTransformである。例えば、RenderDataリソースは、Pointリソースを参照して、アプリケーションによるアニメーション指示または強制指示imperativedirectionを介してポイントの1つが変化することが予期される場所に、線を引くことができる。値リソースは、静的であっても、アニメanimateであってもよい。値リソースがアニメである場合、値リソースは、値が時間とともにどのように変化するかを定義するアニメーション間隔データを含む。構造リソースは、合成プロセスにおいて役割を果たすが、直接的には、レンダリングの一部ではないオブジェクトである。それらのオブジェクトは、リソースとして実施されて、変更キューを介して更新に参加することができるようになり、値リソースを使用して内部値を更新する。一部の現在、明らかにされている構造リソースには、CompositionNodeおよびRenderTargetsが含まれる。一般に、リソースは、実現されてからでないと、使用することができない。実現は、所与の解像度に適切であり、特定のデバイスによって使用する準備ができたリソースの表現として述べることができる。実現の例は、特定の解像度および変形のためにトライアングルに細分され、場合により、ビデオカード上の頂点バッファに既に読み込まれている形状である。実現は、統一された合成エンジン420の中でオンデマンドで作成されるか、またはクライアントレイヤ401において作成され、統一された合成エンジン420に送られる。要求されるリソース実現を見つけることができない、または作成することができない場合、通知は、通知キュー410を介して、クライアントレベル401に対してキューに入れられる。通知は、必要とされるリソースハンドル、変形、およびデバイス、ならびに使用される実現の変形を示す。リソース自体と同様に重要であるのが、リソースが、どのように管理されるかである。リソースは、いくつかの潜在的に矛盾する要件を有する。すなわち、リソースが可能な限り早く削除されるようにする効率的な存続期間管理、リソースが大きい可能性があるので、効率的なメモリ格納、マルチスレッドセーフハンドル処理、見込まれるリソースが欠落している場合でも機能する堅牢なコード、ならびに円滑な合成を確実にする実現の効率的なルックアップである。図示する統一された合成エンジンアーキテクチャは、要件が、2つのセットに分割されることを可能にし、マスタリソーステーブル402が、要件の第1を満たし、スレーブリソーステーブル414が、第2の要件セットを満たす。マスタリソーステーブル402は、安全な効率的メモリ管理のために、完全に参照カウントが行われ、スレッド-セーフに同期される。参照カウントとは、特定のリソースが利用された回数を指す。これに対して、スレーブリソーステーブル414は、単一のスレッド上で実行され、参照およびロックがない設計を利用する。マスタリソーステーブル402は、クライアントレイヤ401アプリケーション内部で使用されるリソースのすべてを管理する。マスタリソーステーブル402は、ハンドルを配ること、ハンドルレコード、リソース、および実現の参照カウントを行うこと、リソースをスレーブリソーステーブル414に送り、スレーブリソーステーブル414リソースの存続期間を制御することを担う。マスタリソーステーブル402は、ほとんどが、現在、表示されている、数万のオブジェクトを管理することができるが、ビジュアルツリー404は、リソースが、表示のために利用されるまで、リソースを作成しない。ビジュアルツリー404は、表示されると、順に調べられwalked、必要なリソースが、統一された合成エンジン420に送られ、エンジン420において、リソースは、スレーブリソーステーブル414の中で管理される。特定のリソースが、合成のためにもはや必要とされなくなると、ビジュアルツリー404は、そのリソースを削除するように合成デバイス例えば、図2の218に通信する。アプリケーションが、複数の閲覧者にマルチキャストする場合、ビジュアルツリー404は、同一の情報を複数の合成デバイスに送る。マスタリソーステーブル412は、いずれの合成デバイスが、各リソースの表現を保持しているかを常に把握している。本発明の一態様では、リソースデータは、クライアントレイヤ401と統一された合成エンジン420の間で共有される。リソースデータは、読み取り専用と分類された共有データが作成されると、共有されることが可能であり、共有データは、統一された合成エンジン420にコピーする前に完了し、ビジュアルツリー404は、共有データの存続期間を制御し、統一された合成エンジン420オブジェクトは、ビジュアルツリー404からの明示的な要求によって最初に削除される。以上の要件セットにより、スレーブリソーステーブル414の中のデータが、マスタリソーステーブル402と整合性のある状態に留まることが確実になる。図5は、本発明による単一のアプリケーションドメインのための複数の統一された合成エンジンUCEに関する概略アーキテクチャを示す。このアーキテクチャは、クライアントレイヤにおいて単一のアプリケーションドメインを含むが、アプリケーションと連携したシーンを合成するための複数の統一された合成エンジンを含む。論理的合成デバイス例えば、UCECに対する合成デバイスが、アプリケーションすなわち、合成クライアントと、複数の統一された合成エンジンのそれぞれの間の接続を定義する。このアーキテクチャを使用することができる場合の例は、単一のアプリケーションが、ネットワークを介して複数のマシン上で表示される、リモートアシスタンス、またはその他の状況の場合である。単一のアプリケーションドメインに関連して使用することができる統一された合成エンジンの数は、図示した3に限定されず、所望に応じて、任意の数であることが可能である。図6は、本発明による単一の統一された合成エンジンのための複数のアプリケーションドメインに関する概略アーキテクチャを示す。このアーキテクチャは、クライアントレイヤにおいて複数のアプリケーションドメインを含むが、複数のアプリケーションと連携してシーンを合成するための、単一の統一された合成エンジンを含む。論理的合成デバイス例えば、UCECに対する合成デバイスが、アプリケーションすなわち、合成クライアントのそれぞれと、統一された合成エンジンの間の接続を定義する。このアーキテクチャを使用することができる場合の例は、独自のドメインをそれぞれが有することを要求される、単一のコンピューティングデバイス上の複数のアプリケーションの場合である。単一の統一された合成エンジンに関連して使用することができるアプリケーションドメインの数は、図示した3つに限定されず、所望に応じて、任意の数であることが可能である。以上の明細、実施例、およびデータにより、本発明の合成の製造および使用の完全な説明が提供された。本発明の多くの実施形態を、本発明の趣旨および範囲を逸脱することなく、実施することができるので、本発明は、添付の特許請求の範囲に存する。