JP2011129153A - グラフィックス処理システムにおける統一された合成エンジンのためのシステムおよび方法 - Google Patents

Abstract

【課題】別々であった合成サービスを結合したシステムを提供する。
【解決手段】コンピュータシステムは、プログラム及びウインドウデスクトップマネージャから呼出しを受け取り、それらのうちの一方に対応する階層データ構造を構築するビジュアルシステム４０１と、ビジュアルシステム４０１からコマンドを受け取り、コマンドに応答してコンポジタデータ構造４１２を構築して、グラフィックス出力を提供する統一された合成エンジン４２０と、ビジュアルシステム４０１からのコマンドを統一された合成エンジン４２０へ送る変更キュー４０８と、統一された合成エンジン４２０からの要求と通知をビジュアルシステム４０１へ送る通知キュー４１０とを備える。リソースルックアップに失敗した場合、通知キュー４１０は統一された合成エンジン４２０によってポストされる。
【選択図】図４

Description

本発明は、グラフィックス処理システムにおける統一された合成エンジンのためのシステムおよび方法に関する。

現在のコンピューティングシステムでは、グラフィックスハードウェアおよびビデオハードウェアの能力は、速いペースで増加している。実際、ある範囲では、現在のコンピューティングシステムにおけるグラフィックスシステムは、単純なグラフィックスサブシステムというよりむしろコプロセッサと見なすことができる。同時に、消費者は、例えば、モニタを見ているか、テレビを見ているか、またはセルラー電話ディスプレイを見ているかに関わらず、表示されるイメージにますます高い品質を期待している。

しかし、メモリおよびバス速度は、メインプロセッサおよび／またはグラフィックスプロセッサにおける進歩に追いついていない。その結果、コンピュータシステム上でグラフィックスにアクセスする従来の直接モードモデルの限界に達している。同時に、開発者および消費者は、従来のグラフィックウインドウ表示（ｇｒａｐｈｉｃａｌｗｉｎｄｏｗｉｎｇ）アーキテクチャでは満たすことができない、新たな機能および特殊効果を求めている。

グラフィックスハードウェアを活用するように、いくつかのゲームプログラムグが設計されてきたが、そのようなゲームプログラムは、主に、ゲームが、同時に実行されている可能性がある他のプログラムに関心を払う必要がないという点で、デスクトップアプリケーションプログラムなどの要件とは異なる要件で動作する。そのようなゲームプログラムとは異なり、アプリケーションは、グラフィックスリソース、およびその他のシステムリソースを他のアプリケーションと共用する必要がある。しかし、アプリケーションは、一般に、グラフィックス処理に関して、協調的なマシン全体の共有モデルで書かれない。

例えば、デスクトップアプリケーションでアニメーションを実行することは、現在、専用の単一目的コード、または別のアプリケーションの使用を要する。その場合でも、複数ウインドウ表示の（ｍｕｌｔｉｐｌｅｗｉｎｄｏｗｅｄ）環境で滑らかなアニメーションを実現することは、不可能ではないとしても、困難である。一般に、これは、滑らかな高速のアニメーションを実現することが、アニメーションパラメータを更新し、シーンを再び描くこと（これは、データ構造をトラバースして（ｔｒａｖｅｒｓｅ）、描くことを要する）を、高いフレームレートで、理想的には、グラフィックスデバイスのハードウェアリフレッシュレートで行うことを要するからである。しかし、アニメーションパラメータを更新し、シーンを定義するデータ構造をトラバースして、描くことは、一般に、コンピュータリソースを多く使用する（ｃｏｍｐｕｔａｔｉｏｎａｌｌｙ−ｉｎｔｅｎｓｉｖｅ）。シーンが大きいほど、またはシーンに動きが多い（ａｎｉｍａｔｅ）ほど、計算要件が大きくなり、これにより、滑らかにアニメ化することができるシーンの複雑さが制限される。

この問題をいっそう大きくするのが、アニメーションの各フレームは、グラフィックスハードウェアがディスプレイリフレッシュを実行すると、提示のために計算され、描かれ、準備される必要があるという要件である。フレームが、ハードウェアによって要求された時点で準備されていない場合、結果は、フレームがドロップされる、または遅延されることである。十分な数のフレームがドロップされた場合、アニメ化された表示には、顕著なぎくしゃくした動き（ｓｔｕｔｔｅｒ）が存在する。また、フレーム準備が、リフレッシュレートと同期されない場合、テアリングとして知られる、望ましくない効果が生じる可能性がある。実際には、現在のマルチタスキングオペレーティングシステムは、システム上の多くのタスクの間で計算リソースを分ける。しかし、オペレーティングシステムタスクスケジューラによってフレーム処理のために与えられる時間は、グラフィックスハードウェアのフレームレートとめったに揃わない。その結果、十分な計算リソースが存在する場合でも、アニメーションシステムは、スケジューリング問題に起因して、依然、フレームを抜かす（ｍｉｓｓ）可能性がある。例えば、アニメーションタスクが、あまりにも遅れて実行されるようにスケジュールされる可能性があり、あるいは、１つのフレームを完了する前に割り込みがかけられて（ｐｒｅｅｍｔｐｔｅｄ）、スクリーンの次のハードウェアリフレッシュに関する次のフレームを提供するのに間に合うように再スケジュールされない可能性がある。以上の問題は、アニメ化されたグラフィックスが、非同期で生成されたフレームのビデオソース、またはその他のソースと合成される必要がある場合、さらに複雑になる。

一般に、フレームを準備するための以前の（例えば、ＷＭ＿ＰＡＩＮＴ）モデルは、複雑なグラフィックス効果（複雑なアニメーションなどの）が所望される場合、リフレッシュレートに遅れをとらないようにするのに、あまりにも多くのデータ処理を要する。その結果、複雑なグラフィックス効果が、従来のモデルで試みられると、次のフレームに間に合うように知覚される視覚的効果をもたらす、次のフレームにおける変更を完了させるのではなく、変更が、異なるフレームにわたって追加されて、視覚的に、目立った形で望ましくない結果を生じさせる可能性がある。

グラフィックス出力を制御するための新たなモデルが、米国特許出願明細書で説明されている。その新たなモデルは、グラフィックス処理技術において、いくつかの重要な改良点を提供する。例えば、（特許文献１）は、一般に、複数レベルのグラフィックス処理のシステムおよび方法を対象としており、そのシステムおよび方法では、より高いレベルのコンポーネント（例えば、オペレーティングシステム）が、単純化されたデータ構造および／またはグラフィックスコマンドを低レベルのデスクトップ合成コンポーネントに送るために、シーングラフを構築する、アニメーションパラメータを更新する、シーングラフのデータ構造をトラバースするという、計算リソースを多く使用する諸態様を、比較的低い動作速度で実行する。高レベルの処理により、データが大幅に単純化されるため、低レベルのコンポーネントは、グラフィックスサブシステムのフレームリフレッシュレートに相当する速度のような、より速い速度（高レベルのコンポーネントと比べて）で動作して、データを処理して、グラフィックスサブシステムのための一定した出力データにすることができる。
米国特許出願第１０／１８４，７９５号明細書

以上の改良点は、グラフィックス処理技術において相当な利益をもたらすが、いくつかの改良点は、未だに実現されていない。

簡単に述べると、本発明は、これまで別々であった合成サービスを結合することを一般に行う、統一された合成エンジンのためのシステムおよび方法を提供する。統一された合成エンジンは、アプリケーションプログラミングインタフェース（ＡＰＩ）に関連してインプロセス（ｉｎ−ｐｒｏｃｅｓｓ）でも、デスクトップコンポジタ（ｃｏｍｐｏｓｉｔｏｒ）としてデスクトップ上でも使用される合成サービスを提供する。統一された合成エンジンは、これまでの２つの合成作業の作業、すなわち、単一のアプリケーションのコンテンツを合成するインプロセス利用を目的とするＡＰＩ合成エンジンと、ウインドウのすべてのウインドウを合成して、最終表示を作成することを目的とするデスクトップ合成エンジンとを結合する。デスクトップ合成エンジンとＡＰＩ合成エンジンは、異なる役割、および異なる使用シナリオを有する。デスクトップ合成エンジンは、他のプロセスによってレンダリングされたコンテンツを合成し、最小限の独自のコンテンツをレンダリングして、ウインドウフレームを実施し、レガシウインドウマネージャ（例えば、Ｕｓｅｒ３２）と緊密に連携するのに使用される。ＡＰＩ合成エンジンは、レンダリングを制御し、単一のアプリケーションに関するコンテンツのすべてを合成し、効率的なリモート処理（ｒｅｍｏｔｉｎｇ）のための機構を提供するのに使用される。ＡＰＩ合成エンジンおよびデスクトップ合成エンジンに関する使用要件の最近の変更により、ＡＰＩ合成エンジンが、他のプロセス、およびレガシの子ウインドウからのコンテンツをホストすることが要求され、デスクトップ合成エンジンが、ウインドウフレームをリモート処理することが要求されることになった。２つの合成作業を結合することにより、コード重複が削減され、試験カバレッジが向上し、レガシウインドウ相互運用性、リモート処理、およびマルチドキュメントインタフェース（ＭｕｌｔｉｐｌｅＤｏｃｕｍｅｎｔｉｎｇ Ｉｎｔｅｒｆａｃｉｎｇ）（ＭＤＩ）のような、さもなければ複雑である、拡張をもたらす特徴（ｅｎａｂｌｉｎｇｆｅａｔｕｒｅｓ）が単純化される。

本発明の例示的な実施形態において使用されることが可能な典型的なコンピューティングデバイスを示す図である。 本発明によるＡＰＩ合成エンジンに関する一般的な階層アーキテクチャを示す図である。 本発明を組み込むことができるメディアインテグレーションレイヤアーキテクチャを示すブロック図である。 本発明による統一された合成エンジンを利用するための概略アーキテクチャを示す図である。 本発明による単一のアプリケーションドメインのための複数の統一された合成エンジンに関する概略アーキテクチャを示す図である。 本発明による単一の統一された合成エンジンのための複数のアプリケーションドメインに関する概略アーキテクチャを示す図である。

本発明は、統一された合成エンジン（ＵＣＥ；Ｕｎｉｆｉｅｄ Ｃｏｍｐｏｓｉｔｉｏｎ Ｅｎｇｉｎｅ）のためのシステムおよび方法を実質的に対象とする。本発明は、コード重複を実質的に削減して、アプリケーションレベルとデスクトップレベルの両方でグラフィックス出力を合成するための方法を提供する。

以下の説明は、３つの部分に分けられる。説明の第１の部分は、本発明が機能することが可能な例示的なコンピューティング環境を説明する。説明の第２の部分は、例示的なグラフィックスアーキテクチャを説明する。説明の第３の部分は、本発明の１つの例示的な実施形態を説明する。

（例示的なコンピューティング環境）
図１は、本発明を実施することができる適切なコンピューティングシステム環境１００の実施例を示す。コンピュータシステム環境１００は、適切なコンピューティング環境の一実施例に過ぎず、本発明の用法または機能の範囲について何ら限定を示唆するものではない。また、コンピューティング環境１００が、例示的な動作環境１００に示したコンポーネントのいずれの１つ、または組合せに関連する依存関係または要件も有すると解釈してはならない。

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

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

図１を参照すると、本発明を実施するための例示的なシステムが、コンピュータ１１０の形態で汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントには、処理装置１２０、システムメモリ１３０、ならびにシステムメモリから処理装置１２０までを含む様々なシステムコンポーネントを結合するシステムバス１２１が含まれることが可能であるが、以上には限定されない。システムバス１２１は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のいずれであってもよい。例として、限定としてではなく、そのようなアーキテクチャには、インダストリスタンダードアーキテクチャ（ＩｎｄｕｓｔｒｙＳｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭｉｃｒｏＣｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＭＣＡ）バス、エンハンストＩＳＡ（ＥｎｈａｎｃｅｄＩＳＡ）（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダーズアソシエーション（ＶｉｄｅｏＥｌｅｃｔｒｏｎｉｃｓ ＳｔａｎｄａｒｄｓＡｓｓｏｃｉａｔｉｏｎ）（ＶＥＳＡ）ローカルバス、アクセレレーテッドグラフィックポート（ＡｃｃｅｌｅｒａｔｅｄＧｒａｐｈｉｃｓ Ｐｏｒｔ）（ＡＧＰ）バスおよびメザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られるペリフェラルコンポーネントインターコネクト（ＰｅｒｉｐｈｅｒａｌＣｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）（ＰＣＩ）バスが含まれる。

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

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

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

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

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

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

（例示的なグラフィックスアーキテクチャ）
説明する１つの実施形態においては、本発明は、一般に、メディアインテグレーションレイヤ（ｍｅｄｉａｉｎｔｅｇｒａｔｉｏｎ ｌａｙｅｒ）スタックに組み込まれ、このスタックの中に、アプリケーションプログラム、デスクトップシステムなどが、ビジュアルＡＰＩレイヤに対する呼出しを直接に行うことにより、または解釈されて、ビジュアルＡＰＩレイヤに対する呼出しになるマークアップを提供することにより、高レベルのビジュアルシステムへの様々なデータをサブミットする。ビジュアルシステムは、ビジュアルシステムにサブミットされたデータに基づき、階層シーングラフを構築し、何らかのレンダリング時に、そのシーングラフを処理して、コマンド、およびその他のデータにして、スタック内のコンポジタサービスと非同期で通信して、それらのコマンドおよび、その他のデータを独自の保持されるデータ構造にする。より低レベルのコンポジタシステムは、場合により、複数のビジュアルシステム（クライアント）からの通信を結合して、グラフィックスサブシステムによって理解されるグラフィックスコマンド、ならびに保持されたグラフィックスデータの諸部分を変更するアニメーションコマンドまたはアニメーション間隔にすることができる。より低いレベルのコンポジタシステムは、グラフィックスハードウェアのリフレッシュレートに相当する（例えば、そのレートの、またはそのレートに近い）速度で、グラフィックスサブシステムに、それらのグラフィックスコマンドを提供する。

本発明の一態様は、一般に、システムディスプレイ上でグラフィック出力をレンダリングするために、プログラムコードによって開始された描画命令、およびその他の情報（例えば、イメージビットマップ）を受け取り、処理することを目的とする。この目的で、本発明は、様々なコンポーネント、データ構造、および通信プロトコルで実施されるシステムおよび方法を提供し、システムおよび方法は一緒になって、例えば、ビジュアルシステムに関連するユーザインタフェーススレッドおよびレンダリングスレッドにおいて、より高いレベルの合成エンジンを可能にして、より低いレベルのアニメーション−合成エンジン、つまり、コンポジタにデータを提供する。ビジュアルシステムは、関数（例えば、アプリケーションプログラミングインタフェース、つまり、ＡＰＩ）をアプリケーションプログラムなどに提供して、それらのプログラムが、データ構造、描画プリミティブ（コマンド）、およびその他のグラフィックス関連データで、シーングラフをポピュレートすることができるようにする。

図２は、ＡＰＩ合成エンジンに関する一般的な階層アーキテクチャ２００を示す。図２に示すとおり、プログラムコード２０２（例えば、アプリケーションプログラムまたはオペレーティングシステムコンポーネントなど）が、イメージング２０４を介すること、ベクトルグラフィック要素２０６を介すること、および／またはビジュアルアプリケーションプログラミングインタフェース（ＡＰＩ）レイヤ２１２に対して直接に行われる関数／メソッド呼出しを介することなどを含む、１つまたは複数の様々な形でグラフィックスデータを出力するように、開発されることが可能である。ベクトルグラフィック要素の使用は、「ＭａｒｋｕｐＬａｎｇｕａｇｅ ａｎｄ Ｏｂｊｅｃｔ Ｍｏｄｅｌ ｆｏｒＶｅｃｔｏｒ Ｇｒａｐｈｉｃｓ」という名称の前述した特許出願で説明しており、他方、ＡＰＩレイヤとの直接対話は、「Ｖｉｓｕａｌａｎｄ Ｓｃｅｎｅ Ｇｒａｐｈ Ｉｎｔｅｒｆａｃｅｓ」という名称の、前述した同時係属出願でさらに説明している。

一般に、イメージング機構２０４は、イメージ、例えば、ビットマップを読み込むため、編集するため、および保存するための機構をプログラムコード２０２に提供する。それらのイメージは、システムの他の諸部分によって使用されることが可能であり、プリミティブ描画コードを使用して、イメージを直接描画する方法も存在する。ベクトルグラフィックス要素２０６が、ビジュアルシステムのオブジェクトモデルと一致する、グラフィックスを描画する別の方法を提供する。ベクトルグラフィック要素２０６は、マークアップ言語を介して作成することができ、そのマークアップ言語を、要素／プロパティシステム２０８およびプレゼンタシステム２１０が処理して、ビジュアルＡＰＩレイヤ２１２に対する適切な呼出しを行う。一般に、ベクトルグラフィック要素２０６は、構文解析されて、オブジェクトモデルのオブジェクトになり、それらのオブジェクトから、シーングラフが描かれ、それらのオブジェクトは、要素／プロパティシステム２０８およびプレゼンタシステム２１０を介して、要素レベルを介してシーングラフに提供されても、より効率的な形で、ソースレベルで提供されてもよい。

１つの実施形態では、グラフィックスレイヤアーキテクチャ２００は、ビジュアルＡＰＩ２１２に対する直接の呼出し、間接的な呼出しを介して構築された、階層化されたオブジェクトを含むシーングラフ２１６を含むか、または別の形で、そのようなシーングラフ２１６に関連するビジュアルシステム２１４を含む。一般に、シーングラフは、ＡＰＩ呼出しによって生成された構造上の特質、および特定のレンダリングデータをモデル化し、アプリケーションがクエリを行う、読み取られたサービスまたはプロパティのセットも提供する。一般に、ビジュアルＡＰＩレイヤ２１２は、オブジェクトを作成する能力、オブジェクトの開閉を行って、オブジェクトにデータを提供する能力などを含め、シーングラフ２１６に対するインタフェースをプログラムコード（およびプレゼンタシステム）に提供する。つまり、ビジュアルシステム２１４は、統一されたメディアＡＰＩレイヤ２１２を公開し、レイヤ２１２により、開発者は、グラフィックス情報を表示するグラフィックスおよびメディアに関する意図を表現し、十分な情報を基礎にあるプラットフォームに提供して、プラットフォームが、プログラムコードに関するハードウェアの使用を最適化できるようにすることができる。例えば、基礎にあるプラットフォームは、キャッシング、リソースネゴシエーション、およびメディア統合を担う。

本発明の態様によれば、以下に説明するとおり、ビジュアルシステム２１４は、コンポジタ（より低いレベルの合成−アニメーションエンジン）２１８のクライアントとして動作し、適切なデータをコンポジタに通信して、所望のフレームがレンダリングされるようにする。一般に、ビジュアルシステム２１４は、コンポジタ２１８より計算リソースを多く使用する動作を通常、実行するユーザインタフェースコンポーネントを含み、このため、ビジュアルシステム２１４のこの態様は、通常、コンポジタの動作速度に対して、比較的、より遅い速度で動作する。本明細書で使用する、「高レベル」および「低レベル」という用語は、一般に、高位のコンポーネントに対してソフトウェアコンポーネントがより低位であるほど、そのコンポーネントは、ハードウェアにより近い、他のコンピューティングシナリオにおいて使用される用語と同様であることに留意されたい。このため、例えば、ビジュアルシステムの高レベルの合成−アニメーションエンジンコードから送られたグラフィックス情報は、低レベルのデスクトップ合成−アニメーションエンジンにおいて受け取られることが可能であり、その情報は、ハードウェアを含むグラフィックスサブシステム２２２にグラフィックスデータを送るのに使用される。

本発明の態様によれば、ビジュアルシステム２１２は、シーン変更データなどの様々な情報、アニメーション関数データなどの命令、ならびに、場合により、レンダリングスレッドによって処理されて、コンポジタ２１８に提供されるデータになるその他のデータ（例えば、ビットマップに対するポインタ）を（非同期で）通信する。つまり、ビジュアルシステム２１２は、以下に説明するとおり、複数のデスクトップアプリケーションにわたって共有される、より低いレベルの合成システム２１８に基礎を置く、ユーザインタフェーススレッドおよびレンダリングスレッドを含む。このより低いレベルの合成システム２１８は、デバイスリフレッシュレートに適合し、システム２１８にコンテンツを送るアプリケーションとは別個のプロセス内に存在する。個々のクライアント（アプリケーションの）ビジュアルシステムからのこの切り離しにより、個別のアプリケーションアニメーションの費用が、システムスケジューラによって適切に裁定され、扱われることが可能になる。さらに、アプリケーション常駐の合成エンジン（スレッド）は、専用のスレッドを、類似したアプリケーション常駐の合成スレッドに共通であるカテゴリにグループ化することができる。例えば、ＣＰＵスケジューリング確保システムを使用して、ＣＰＵ消費パーセンテージに関する上限および下限を、システム上で実行されているアプリケーションに適用することができる。

以下に説明するとおり、ビジュアルシステム２１４は、タイミング−アニメーションシステム２２０と統合されて、宣言型（またはその他の）アニメーション制御（例えば、アニメーション関数、アニメーション間隔、およびその他のパラメータ）、およびタイミング制御をもたらす。アニメーションシステムは、アニメート（ａｎｉｍａｔｅ）値が、例えば、要素プロパティレベル、ビジュアルＡＰＩレイヤ２１２の内部、およびその他のリソースの任意のリソース内を含め、システム内の実質的にどこにでも送られることを可能にすることに留意されたい。タイミングシステムは、要素レベルおよびビジュアルレベルで公開される。

コンポジタ２１８は、シーンの合成、アニメ化、およびレンダリングを管理し、そのシーンが、次に、グラフィックスサブシステム２２２に提供される。１つの実施形態では、ビジュアルシステムは、アニメーション機能および合成機能を提供する第２のスレッド（同一のプロセス内の）と連携して動作するユーザインタフェーススレッドを含む。このため、複数のアプリケーションのシーンからのグラフィックスのレンダリングを実施する合成コンポーネント（異なるプロセス内の）から切り離された合成コンポーネントが、各ビジュアルシステム内に存在する。ときとして、レンダリングの一部が、より高いレベルで行われ、例えば、より低いレイヤが、複数のアプリケーションからの要求に対応している間に、ビジュアルシステムが、アプリケーションごとにインスタンス化され、これにより、イメージング機構を介して、時間がかかるレンダリング、またはアプリケーション固有のレンダリングを、より高いレベルで実行して、ビットマップに対する参照をコンポジタ２１８に送ることが可能であることが有利であることに留意されたい。

この場合、ＡＰＩ合成エンジンとデスクトップ合成エンジンの両方の間で共同で行われる（ｓｈａｒｅｄ）のが、ＡＰＩ合成エンジンに関して前述した、より低いレベルの合成である。ＡＰＩ合成エンジンとデスクトップ合成エンジンの両方に関する、より低いレベルの合成を結合することにより、本発明の統一された合成エンジンがもたらされる。統一された合成エンジンは、例示的な実施形態の説明で以下に説明するとおり、ＡＰＩ合成エンジンとデスクトップ合成エンジンの両方に関するリソース管理を行って、表示のためのシーンを生成する。

図３に示すとおり、ローカルで表示される出力の代替として、またはそのような出力に加えて、コンポジタ２１８（または類似のコンポジタ）は、プリンタ２３２などに固定イメージデータを送るために、レンダリング命令およびアニメーション命令を適切なフォーマットで、より低いレベルの印刷コード（ｐｒｉｎｔｉｎｇｃｏｄｅ）２３０に与えてもよく、かつ／またはリモートマシン２３８に伝送するために、レンダリング命令、および単純なアニメーション間隔を適切なフォーマットで、より低いレベルの端末トランスポートサーバ２３６に与えてもよい。また、より豊かな情報が、ネットワークを介して送られてもよく、例えば、リモートマシンに、ネットワークトラフィックなしに、マウスロールオーバ（Ｒｏｌｌｏｖｅｒ）効果をローカルで扱わせることが望ましい可能性があることに留意されたい。

（例示的な実施形態）
図４は、本発明による、統一された合成エンジンを利用するための概略アーキテクチャを示す。統一された合成エンジンのアーキテクチャは、マスタリソーステーブル４０２と、ビジュアルツリー４０４と、合成デバイスインタフェース４０６と、変更キュー４０８と、通知キュー４１０と、合成ツリー４１２と、スレーブリソーステーブル４１４とを含む。

統一された合成エンジンアーキテクチャは、２つのレイヤに論理的に分けられる。すなわち、上位レイヤ、またはクライアントレイヤ４０１（すなわち、ビジュアルシステム）が、統一された合成エンジンの主要なクライアントであるビジュアルツリー４０４（すなわち、階層データ構造）を含み、下位レイヤは、統一された合成エンジン自体４２０である。ビジュアルツリー４０４は、統一された合成エンジンと、統一された合成エンジンのメインクライアントの間の対話、ならびにクライアントによって保持されるリソーステーブル（例えば、４０２、４１４）と、統一された合成エンジンの間の対話をもたらす。

本発明によれば、ビジュアルツリー４０４は、統一された合成エンジン４２０のクライアントとしてのデスクトップウインドウマネージャで置き換えることができる。デスクトップウインドウマネージャは、統一された合成エンジン４２０が、デスクトップ合成エンジンとして使用されている場合にクライアントである。ビジュアルツリー４０４とデスクトップウインドウマネージャが、統一された合成エンジン４２０のクライアントである場合に関して、今度は同一のライブラリが、同一の合成を実行する。アプリケーションのビジュアルツリーとデスクトップウインドウマネージャに関して、異なる処理が実行され、異なる処理はそれぞれ、異なるデータを扱うが（すなわち、ペイロードが異なる）、統一された合成エンジン４２０に関するプロトコルは、変わらない。一実施形態では、デスクトップウインドウマネージャで使用するためのプロトコルは、アプリケーションがクライアントである場合に利用可能なプロトコルの機能サブセット（ｆｕｎｃｔｉｏｎａｌｓｕｂｓｅｔ）を含む。

実施例として、クライアントレイヤ４０１と統一された合成エンジン４２０の間の対話、ならびにリソース管理を、アプリケーションがクライアントである状況に関して、以下に説明する。ビジュアルツリー４０４は、表示されるべきシーンのアプリケーションまたはドキュメントによる表現を表す。このシーンは、非常に大きいことが可能であり、場合により、現在、可視であるものよりもはるかに大きいことが可能である。各ビジュアル（例えば、４０５）のコンテンツは、レンダリング命令のリスト、つまり、ＲｅｎｄｅｒＤａｔａ、ならびに形状、ポイント、ペン、ブラシ、イメージなどの各ビジュアルが使用するリソースによって定義される。それらのリソースは、各リソースに関する、デバイスおよび解像度とは独立のデータを含み、一部のケースでは、集合またはリソースに依存する形態を含むマスタリソーステーブル４０２によって管理される。マスタリソーステーブル４０２は、リソースの存続期間を管理することを担う（例えば、参照カウントを介して）。

ビジュアルツリーが表示されるようになるまで、ビジュアルツリー（例えば、４０４）またはリソースに関する情報は、統一された合成エンジン４２０に全く伝送されない。ビジュアルツリー（例えば、４０４）は、レンダ目標に関連付けられると、そのツリーの表現を適切なリソースとともに、統一された合成エンジン４２０に送る。通信は、合成デバイスインタフェース４０６の変更キュー４０８を介して、非同期である。本明細書で、まとめて合成ツリー４１２（すなわち、コンポジタデータ構造）と呼ぶ、ビジュアルツリー４０４の潜在的に可視のサブセットが、統一された合成エンジン４２０の中で表現される。ビジュアルツリーは、既知の解像度レンダ目標に結び付けられると、表示される。したがって、オブジェクトからレンダ目標空間への完全な変形が、クライアントに関して知られている。

統一された合成エンジン４２０に送られるリソースは、コールバック、または要求される実現（ｒｅａｌｉｚａｔｉｏｎ）が送られることなしに、統一された合成エンジン４２０によって直接実現可能である。「Ｔｅｘｔ」や「Ｉｍａｇｅｓ」のようなリソースは、実現するのが高価であり（処理オーバーヘッドの点で）、したがって、ビジュアルツリー４０４において、適切な「レンダ準備完了（ｒｅａｄｙ−ｔｏ−ｒｅｎｄｅｒ）」形態に変換される。リソースを、容易にレンダリングされることが可能な形態に変換することにより、統一された合成エンジン４２０における合成に関するオーバーヘッドが節約される。また、リソースは、リソースが、ユーザコードに対するコールバックを要求する場合、ビジュアルツリー４０４においても実現される。必要な場合に、統一された合成エンジン４２０によって正しい解像度に効率的に細分されることが可能な「Ｇｅｏｍｅｔｒｙ」のような、他のリソースは、統一された合成エンジン４２０自体によって実現される。

統一された合成エンジン４２０は、スレーブリソーステーブル４１４の中でリソースを管理する。一実施形態では、スレーブリソーステーブル４１４は、パフォーマンスを向上させるように、いずれの形態でも参照カウントを実行しない。これは、スレーブリソーステーブル４１４リソースが、合成デバイスに関する単一の合成スレッド上でアクセスされるために可能である。一実施形態では、スレーブリソーステーブル４１４の中のすべてのリソースは、マスタリソーステーブル４０２の中にも存在する。マスタリソーステーブル４０２は、シリアル化された変更キュー４０８要求を介して、スレーブリソーステーブル４１４リソースの存続期間を明示的に制御する。統一された合成エンジン４２０は、ハンドルによってリソースを参照する。一実施形態では、リソースルックアップが失敗した場合、統一された合成エンジン４２０は、通知キュー４１０にメッセージをポストし、そのリソースを要求する処理を単に飛ばして進む。統一された合成エンジン４２０は、単一のスレッドとして実行され、定数合成ループの中で実行される。

図示した統一された合成アーキテクチャに関する本発明の一態様は、アーキテクチャによるリソースの使用である。リソースは、「異なる解像度および／または物理的デバイスに関して異なる実現を要求するシーンをレンダリングするために必要とされ、合成ツリー内で複数回、使用され、あるいは、アニメーションを介するなどして、ユーザとは独立に変化することが可能である任意のオブジェクト」と定義することができる。リソースは、統一された合成エンジン４２０の中、およびクライアントレイヤ４０１において、テーブル（例えば、マスタリソーステーブル４０２）の中のレコードとして表現され、ハンドルによって参照される。リソースを使用するオブジェクトは、ハンドルによってそれを行う。ハンドルは、実際のオブジェクトに対するポインタを獲得するために、リソーステーブル（例えば、マスタリソーステーブル４０２）の中で探すことができる。リソースは、自らをシリアル化し、更新を適用し、特定の解像度およびデバイスに関する実現を提供することができる。

リソースは、一般に、描画リソース、値リソース、および構造リソースなどの、いくつかのタイプに分けられる。描画リソースは、レンダリングレイヤによって定義されたオブジェクトであり、このレイヤによって直接消費されることが可能である。描画リソースの例には、ＲｅｎｄｅｒＤａｔａ、Ｂｉｔｍａｐ、Ｉｍａｇｅ、Ｇｌｙｐｈｒｕｎ、Ｇｅｏｍｅｔｒｙ、およびＢｒｕｓｈが含まれる。描画リソースは、単純なカテゴリと複雑なカテゴリにさらに分けることができる。

非常に低く、不変のレンダリング費用を有する描画リソースは、合成中に、デバイスおよび解像度とは独立のソースデータから直接実現することができる。Ｇｅｏｍｅｔｒｙは、単純な描画リソースである。というのは、Ｇｅｏｍｅｔｒｙは、統一された合成エンジン４２０の合成ループの中で、最終の要求される解像度に効率的に細分されることが可能だからである。これに対して、複雑な描画リソースは、複雑な計算、ユーザコードに対するコールバック、または実現を生成する入出力を要する。一実施形態では、複雑な描画リソースは、統一された合成エンジン４２０によっては実現されない。代わりに、適切な実現は、合成に先立って、クライアントレイヤ４０１において提供される。「イメージ」は、複雑なリソースの例である。イメージは、ディスクから読み取られ、復号化され、適切な解像度でサンプリングされ、フィルタ処理される。

値リソースは、別のリソースによって使用される単純な変更可能な値、またはアニメート値を表す。値リソースの例が、Ｄｏｕｂｌｅ、Ｐｏｉｎｔ、Ｃｏｌｏｒ、およびＴｒａｎｓｆｏｒｍである。例えば、ＲｅｎｄｅｒＤａｔａリソースは、Ｐｏｉｎｔリソースを参照して、アプリケーションによるアニメーション指示または強制指示（ｉｍｐｅｒａｔｉｖｅｄｉｒｅｃｔｉｏｎ）を介してポイントの１つが変化することが予期される場所に、線を引くことができる。値リソースは、静的であっても、アニメ（ａｎｉｍａｔｅ）であってもよい。値リソースがアニメである場合、値リソースは、値が時間とともにどのように変化するかを定義するアニメーション間隔データを含む。

構造リソースは、合成プロセスにおいて役割を果たすが、直接的には、レンダリングの一部ではないオブジェクトである。それらのオブジェクトは、リソースとして実施されて、変更キューを介して更新に参加することができるようになり、値リソースを使用して内部値を更新する。一部の現在、明らかにされている構造リソースには、ＣｏｍｐｏｓｉｔｉｏｎＮｏｄｅおよびＲｅｎｄｅｒ Ｔａｒｇｅｔｓが含まれる。

一般に、リソースは、実現されてからでないと、使用することができない。実現は、「所与の解像度に適切であり、特定のデバイスによって使用する準備ができたリソースの表現」として述べることができる。実現の例は、特定の解像度および変形のためにトライアングルに細分され、場合により、ビデオカード上の頂点バッファに既に読み込まれている形状である。実現は、統一された合成エンジン４２０の中でオンデマンドで作成されるか、またはクライアントレイヤ４０１において作成され、統一された合成エンジン４２０に送られる。要求されるリソース実現を見つけることができない、または作成することができない場合、通知は、通知キュー４１０を介して、クライアントレベル４０１に対してキューに入れられる。通知は、必要とされるリソースハンドル、変形、およびデバイス、ならびに使用される実現の変形を示す。

リソース自体と同様に重要であるのが、リソースが、どのように管理されるかである。リソースは、いくつかの潜在的に矛盾する要件を有する。すなわち、リソースが可能な限り早く削除されるようにする効率的な存続期間管理、リソースが大きい可能性があるので、効率的なメモリ格納、マルチスレッドセーフハンドル処理、見込まれるリソースが欠落している場合でも機能する堅牢なコード、ならびに円滑な合成を確実にする実現の効率的なルックアップである。図示する統一された合成エンジンアーキテクチャは、要件が、２つのセットに分割されることを可能にし、マスタリソーステーブル４０２が、要件の第１を満たし、スレーブリソーステーブル４１４が、第２の要件セットを満たす。

マスタリソーステーブル４０２は、安全な効率的メモリ管理のために、完全に参照カウントが行われ、スレッド−セーフに同期される。参照カウントとは、特定のリソースが利用された回数を指す。これに対して、スレーブリソーステーブル４１４は、単一のスレッド上で実行され、参照およびロックがない設計を利用する。

マスタリソーステーブル４０２は、クライアントレイヤ４０１アプリケーション内部で使用されるリソースのすべてを管理する。マスタリソーステーブル４０２は、ハンドルを配ること、ハンドルレコード、リソース、および実現の参照カウントを行うこと、リソースをスレーブリソーステーブル４１４に送り、スレーブリソーステーブル４１４リソースの存続期間を制御することを担う。マスタリソーステーブル４０２は、ほとんどが、現在、表示されている、数万のオブジェクトを管理することができるが、ビジュアルツリー４０４は、リソースが、表示のために利用されるまで、リソースを作成しない。ビジュアルツリー４０４は、表示されると、順に調べられ（ｗａｌｋｅｄ）、必要なリソースが、統一された合成エンジン４２０に送られ、エンジン４２０において、リソースは、スレーブリソーステーブル４１４の中で管理される。特定のリソースが、合成のためにもはや必要とされなくなると、ビジュアルツリー４０４は、そのリソースを削除するように合成デバイス（例えば、図２の２１８）に通信する。アプリケーションが、複数の閲覧者にマルチキャストする場合、ビジュアルツリー４０４は、同一の情報を複数の合成デバイスに送る。マスタリソーステーブル４１２は、いずれの合成デバイスが、各リソースの表現を保持しているかを常に把握している。

本発明の一態様では、リソースデータは、クライアントレイヤ４０１と統一された合成エンジン４２０の間で共有される。リソースデータは、「読み取り専用」と分類された共有データが作成されると、共有されることが可能であり、共有データは、統一された合成エンジン４２０に「コピーする」前に完了し、ビジュアルツリー４０４は、共有データの存続期間を制御し、統一された合成エンジン４２０オブジェクトは、ビジュアルツリー４０４からの明示的な要求によって最初に削除される。以上の要件セットにより、スレーブリソーステーブル４１４の中のデータが、マスタリソーステーブル４０２と整合性のある状態に留まることが確実になる。

図５は、本発明による単一のアプリケーションドメインのための複数の統一された合成エンジン（ＵＣＥ）に関する概略アーキテクチャを示す。このアーキテクチャは、クライアントレイヤにおいて単一のアプリケーションドメインを含むが、アプリケーションと連携したシーンを合成するための複数の統一された合成エンジンを含む。論理的合成デバイス（例えば、ＵＣＥＣに対する合成デバイス）が、アプリケーション（すなわち、合成クライアント）と、複数の統一された合成エンジンのそれぞれの間の接続を定義する。このアーキテクチャを使用することができる場合の例は、単一のアプリケーションが、ネットワークを介して複数のマシン上で表示される、リモートアシスタンス、またはその他の状況の場合である。単一のアプリケーションドメインに関連して使用することができる統一された合成エンジンの数は、図示した３に限定されず、所望に応じて、任意の数であることが可能である。

図６は、本発明による単一の統一された合成エンジンのための複数のアプリケーションドメインに関する概略アーキテクチャを示す。このアーキテクチャは、クライアントレイヤにおいて複数のアプリケーションドメインを含むが、複数のアプリケーションと連携してシーンを合成するための、単一の統一された合成エンジンを含む。論理的合成デバイス（例えば、ＵＣＥＣに対する合成デバイス）が、アプリケーション（すなわち、合成クライアント）のそれぞれと、統一された合成エンジンの間の接続を定義する。このアーキテクチャを使用することができる場合の例は、独自のドメインをそれぞれが有することを要求される、単一のコンピューティングデバイス上の複数のアプリケーションの場合である。単一の統一された合成エンジンに関連して使用することができるアプリケーションドメインの数は、図示した３つに限定されず、所望に応じて、任意の数であることが可能である。

以上の明細、実施例、およびデータにより、本発明の合成の製造および使用の完全な説明が提供された。本発明の多くの実施形態を、本発明の趣旨および範囲を逸脱することなく、実施することができるので、本発明は、添付の特許請求の範囲に存する。

Claims (20)

1. コンピューティングシステムにおいて、
   プログラム及びウインドウデスクトップマネージャから呼出しを受け取り、前記プログラムと前記ウィンドウデスクトップマネージャとのうちの一方に対応する階層データ構造を構築するビジュアルシステムと、
   前記ビジュアルシステムからコマンドを受け取り、前記コマンドに応答してコンポジタデータ構造を構築して、グラフィックス出力を提供する、統一された合成エンジンであって、前記コンポジタデータ構造が、前記ビジュアルシステムによって構築された前記階層データ構造に対応する、統一された合成エンジンと、
   前記ビジュアルシステムからの前記コマンドを前記統一された合成エンジンへ送るよう構成された変更キューと、
   前記統一された合成エンジンからの要求と通知を前記ビジュアルシステムへ送るよう構成された通知キューであって、リソースルックアップに失敗した場合に前記統一された合成エンジンによってポストされる通知キューと、
   を含むことを特徴とするシステム。
2. 前記ビジュアルシステム内部に含まれるマスタリソーステーブルであって、前記プログラムと前記デスクトップウインドウマネージャとうちの一方によって使用されるリソースの第１のリストを含むマスタリソーステーブルと、
   前記統一された合成エンジン内部に含まれるスレーブリソーステーブルであって、前記統一された合成エンジンに提供されるリソースの第２のリストを含み、前記マスタリソーステーブルによって管理されるスレーブリソーステーブルと
   をさらに含むことを特徴とする、請求項１に記載のシステム。
3. リソースの前記第２のリストは、リソースの前記第１のリストと比べた場合、リソースの包括的なリストであることを特徴とする、請求項２に記載のシステム。
4. 前記マスタリソーステーブルは、前記スレーブリソーステーブルのリソースの存続期間を、シリアル化された要求を介して明示的に制御することを特徴とする、請求項２に記載のシステム。
5. 前記統一された合成エンジンが前記デスクトップウインドウマネージャに応答して動作する場合と、前記統一された合成エンジンがプログラムに応答して動作する場合とにおいて、同一のライブラリが同一の合成を実行していることを特徴とする、請求項１に記載のシステム。
6. 前記デスクトップウインドウマネージャに応答する場合に、前記統一された合成エンジンによって使用されるためのプロトコルは、前記プログラムに応答する場合に、前記統一された合成エンジンによって使用されるためのプロトコルの機能サブセットを含むことを特徴とする、請求項１に記載のシステム。
7. 前記スレーブリソーステーブルリソースは、単一の合成スレッド上でアクセスされることを特徴とする、請求項１に記載のシステム。
8. 前記統一された合成エンジンは、単一のスレッドとして実行され、定数合成ループの中で実行されることを特徴とする、請求項１に記載のシステム。
9. 追加のビジュアルシステムをさらに含み、前記ビジュアルシステムと前記追加のビジュアルシステムとによってシーンが合成されるように、前記ビジュアルシステムと前記追加のビジュアルシステムと前記統一された合成エンジンと通信することを特徴とする、請求項１に記載のシステム。
10. 追加の統一された合成エンジンをさらに含み、前記ビジュアルシステムに対応する複数のグラフィックス出力が生成されるように、前記ビジュアルシステムが前記統一された合成エンジン及び前記追加の統一された合成エンジンと通信することを特徴とする、請求項１に記載のシステム。
11. コンピューティングシステムにおける方法であって、
    プログラム及びデスクトップウインドウマネージャから呼出しを受け取り、前記呼出しに応答して、ビジュアルシステムにより、前記プログラムと前記デスクトップウィンドウマネージャとのうちの一方に対応する階層データ構造を構築するステップと、
    前記階層データ構造に対する変更を表す情報を、統一された合成エンジンに通信するステップと、
    前記統一された合成エンジンに、前記階層データ構造に関係するマスタリソーステーブルに対応するリソースセットを通信するステップと、
    前記通信された情報に基づき、前記統一された合成エンジンによって構築されたコンポジタデータ構造の中の情報を更新するステップと、
    前記通信されたリソースセットに基づき、前記コンポジタデータ構造に関係するスレーブリソーステーブルを更新するステップと、
    前記コンポジタデータ構造を処理して、グラフィックス情報を出力するステップと、
    前記統一された合成エンジンがリソースルックアップに失敗した場合に、前記統一された合成エンジンから前記ビジュアルシステムへ、要求と通知とを送るステップと、
    を含むことを特徴とする方法。
12. 階層データ構造を構築する前記ステップは、前記コンポジタデータ構造の処理と比べて非同期で実行されて、前記出力グラフィックス情報を生成することを特徴とする、請求項１１に記載の方法。
13. 前記スレーブリソーステーブルは、前記マスタリソーステーブルと比べた場合、リソースの包括的なリストであるリソースリストを含むことを特徴とする、請求項１１に記載の方法。
14. 前記マスタリソーステーブルに応答して、前記スレーブリソーステーブルの存続期間を制御するステップをさらに含むことを特徴とする、請求項１１に記載の方法。
15. 前記統一された合成エンジンが前記デスクトップウインドウマネージャに応答して動作する場合、第１のライブラリに従って前記統一された合成エンジンを使用して合成を実行し、前記統一された合成エンジンがプログラムに応答して動作する場合、前記第１のライブラリに従って前記統一された合成エンジンを使用して合成を実行するステップをさらに含むことを特徴とする、請求項１１に記載の方法。
16. 前記デスクトップウインドウマネージャに応答する場合に前記統一された合成エンジンによって使用されるプロトコルは、前記プログラムに応答する場合に前記統一された合成エンジンによって使用される前記プロトコルの機能サブセットを含むことを特徴とする、請求項１１に記載の方法。
17. 単一の合成スレッド上で前記スレーブリソーステーブルのリソースにアクセスするステップをさらに含むことを特徴とする、請求項１１に記載の方法。
18. 前記統一された合成エンジンを、単一のスレッドとして、定数合成ループの中で実行するステップをさらに含むことを特徴とする、請求項１１に記載の方法。
19. 前記グラフィックス出力情報が追加のプログラムに対応するように、追加の情報と追加のリソースセットとを前記統一された合成エンジンに通信するステップをさらに含むことを特徴とする、請求項１１に記載の方法。
20. プログラムとデスクトップウインドウマネージャとのうちのいずれか一方に対応する複数のグラフィックス出力情報が生成されるように、前記情報とリソースセットとを複数の統一された合成エンジンに通信することを特徴とする、請求項１１に記載の方法。