JP2007522535A - 動的ウィンドウ構成 - Google Patents

Abstract

合成デスクトップモデルのオペレーティングシステムを使用するコンピュータ上にデスクトップを描画するための方法およびシステムを開示する。合成デスクトップウィンドウマネージャは、アプリケーションプログラムから基本オブジェクトおよび１つまたは複数のコンテンツオブジェクトのコンテンツオブジェクト情報を受け取ると、ウィンドウをバッファメモリに描画し、高度なグラフィックスハードウェアおよびビジュアル効果を利用して、それらが描画されるコンテンツに基づいてウィンドウを描画する。各ウィンドウのフレーム部分は、表示されるフレームの下にあるデスクトップのコンテンツに基づくすりガラスの外観を有するビットマップのピクセルシェーディングを行うことにより生成することができる。オペレーティングシステムが非レガシアプリケーションウィンドウと整合するように見えるようにレガシアプリケーションにより生成されるウィンドウを描き、描画することができるようなレガシサポートが提供される。

Description

本発明は、一般に、コンピュータオペレーティングシステムのグラフィカルユーザインターフェースに関する。より詳細には、本発明は、ウィンドウ毎に、複数かつ／または不規則な形状のクライアントおよび非クライアントコンテンツの領域を各ウィンドウ内にもつ機能を可能にさせるメカニズムを実現する。

コンピュータのオペレーティングシステムは、通常、グラフィカルユーザインターフェース（ＧＵＩ）をエンドユーザに提供するシェルを有する。このシェルは、ユーザとオペレーティングシステムとの間の直接通信を実現するソフトウェアコンポーネントの１つまたはそれらの組み合わせからなる。グラフィカルユーザインターフェースは、通常、ユーザがオペレーティングシステムと対話するためのアイコン指向のおよび／またはメニュー駆動型の環境を提供し、多くの場合、デスクトップメタファ（ｄｅｓｋｔｏｐ ｍｅｔａｐｈｏｒ）に基づく。より具体的に述べると、グラフィカルユーザインターフェースは、机に向かって仕事をするという現実世界の活動をモデル化するように設計されている。デスクトップ環境は、通常、単一の表示装置のサーフェス全体を占有するか、または複数の表示装置にまたがることができ、アイコン、メニュー、カーソル、およびウィンドウなどの従属するユーザインターフェースオブジェクトのホストとなる。

デスクトップ環境によりホストされる種類の描画オブジェクトの中には、ウィンドウとして知られる、視覚的に線引きされた画面領域がある。ウィンドウは、通常、固有のユーザ活動に対し専用となっており、サードパーティのソフトウェアアプリケーションまたはシステムアプリケーションのいずれかにより作成され管理される。各ウィンドウは、特定のアプリケーションプログラムの制御の下で仮想表示装置であるかのように動作し、そのコンテンツを独立して表示する。ウィンドウは、通常、サイズ変更、表示画面上での移動、および完全にまたは部分的に互いに重なるように積み重ねた配置を対話的に行うことができる。一部のウィンドウ操作環境では、ウィンドウは、アイコンへとサイズを最小化する、またはサイズを最大化して表示面全体を占有するなどの控えめな視覚的状態または動作状態をとることができる。デスクトップウィンドウのコレクション（ｃｏｌｌｅｃｔｉｏｎ）は、一般に、当業ではＺオーダと呼ぶ、上から下への表示順序を割り当てられ、ウィンドウは画面上で同じ投影位置を占有するＺオーダに関して自ウィンドウよりも下位の他のすべてのウィンドウの上に載る。単一の、選択されたウィンドウは、いつでも「フォーカス」を持ち、ユーザの入力を受け入れられる。ユーザは、マウスまたはその他のポインタデバイスを使ってウィンドウをクリックするか、またはシステム定義のキーボードショートカットまたはキーの組み合わせを使用することにより、入力フォーカスを他のウィンドウに導くことができる。これにより、ユーザは、実際の机の上に任意に積み重ねられる、または配置できる紙の書類およびその他の品目を管理する現実世界のシナリオに似た方法で複数のアプリケーションプログラム、ファイル、およびドキュメントを使って効率よく働くことができる。

従来の多数のグラフィカルユーザインターフェースデスクトップ実装の欠点は、視覚的にリッチなコンテンツを表示する能力、またはグラフィック描画技術の機能強化を十分に引き出すための能力が限られていることである。このような機能強化には、物理的にモデル化された（照明、陰影、テクスチャ、透明、反射、および屈折）、２および３次元のコンテンツおよび滑らかな高性能アニメーションのリアルタイムの描画が含まれる。デスクトップ上でグラフィック描画機能強化を利用するために使用可能なサービスが限られることと対照的に、Ｗｉｎｄｏｗｓ（登録商標）ブランドのオペレーティングシステムおよび類似のオペレーティングシステムのシェルのグラフィカルユーザインターフェース内でウィンドウ表示または全画面表示されて動作する所定のアプリケーションプログラムでは視覚的にリッチなコンテンツの表示が可能である。このようなコンテンツを表示する種類のアプリケーションプログラムには、リアルタイムの３Ｄアニメーションおよび効果を使用するビデオゲーム、レイトレーサなどの高度なグラフィカルオーサリングツール、および高度な２Ｄおよび３Ｄパブリッシングアプリケーションがある。これらのプログラムのビジュアル出力は、アプリケーションウィンドウのコンテンツ領域に制約されるか、または他のウィンドウおよびデスクトップ自体を除いて全画面で描画されるため、アプリケーションプログラムのリッチなグラフィック出力はデスクトップ環境の表示に全く寄与しない。

コンピュータのオペレーティングシステムは、アイコン、メニュー、カーソル、ウィンドウ、およびデスクトップなどのユーザインターフェースオブジェクトの管理、マウスおよびキーボードなどの入力装置からのイベントの調停（ａｒｂｉｔｒａｔｉｎｇ）、およびソフトウェアアプリケーションへのユーザインターフェースサービスの提供に関与するソフトウェアレイヤを採用している。このソフトウェアレイヤは、デスクトップウィンドウマネージャ（ＤＷＭ）と呼ばれる。デスクトップウィンドウマネージャ（ＤＷＭ）の描画ロジック、入力イベントのルーティング、およびアプリケーションプログラミングインターフェース（ＡＰＩ）は全体として、ユーザインターフェースポリシーを具体化し、同様に、オペレーティングシステムの総合的なユーザエクスペリエンス（ｅｘｐｅｒｉｅｎｃｅ）を規定する。現在までリッチなビジュアルデスクトップがなかった主な理由は、ＤＷＭがデスクトップを管理し描画する方法にあった。従来のＤＷＭの実装では、デスクトップを描画するのに「無効化（ｉｎｖａｌｉｄａｔｉｏｎ）」モデルを採用しているが、それは主にビデオおよびシステムメモリのリソースならびにＣＰＵおよびＧＰＵの処理能力を節約して使う必要性から発達したものである。

無効化モデルでは、ウィンドウのサイズ変更または移動が行われる、またはアプリケーション側でウィンドウの全部または一部を再描画したい場合、表示の影響を受ける部分が「無効化」される。ＤＷＭでは、ウィンドウのサイズ変更または移動の影響を受ける領域を内部的に無効化するが、自ウィンドウの全部または一部を再描画しようと試みるアプリケーションは、オペレーティングシステムに対し、ＡＰＩを介して、自ウィンドウの指定領域を無効化するよう指令する。いずれの場合も、ＤＷＭが画面上の更新が実際に必要になっている要求領域の一部（ｓｕｂｓｅｔ）を決定することにより無効化要求を処理する。ＤＷＭは、通常、ターゲットウィンドウに関連付けられている交差領域、ターゲットの上にかぶさる他のウィンドウ、影響を受けるウィンドウに関連付けられているクリッピング領域、および表示の目に見える境界の保持されているリストを調べることによりこれを達成する。ＤＷＭは、その後、それぞれの影響を受けるアプリケーションに、禁止されている上から下への順序で更新の必要のある領域を指定する描画メッセージを送る。アプリケーションは、その指定領域を受け入れるか、または無視するかを選択することができる。ローカルの更新領域の外でアプリケーションにより実行される描画は、グラフィカルデバイスインターフェース（ＧＤＩ）などの低レベルのグラフィック描画エンジンにより提供されるサービスを使用してＤＷＭによって自動的にクリッピングされる。

無効化メッセージングモデルの利点は、表示メモリを節約できることにある。つまり、無効化ベースのＤＷＭは、現在表示されているコンテンツの下にあるかもしれないものを「覚えておく」ことをせずに、単一のデスクトップの描画に十分なバッファメモリを維持するだけでよい。しかし、デスクトップ上のウィンドウは上から下への順序で描画されるため、ＧＤＩを介した非矩形ウィンドウおよびリッチな２Ｄアニメーションなどの機能は、表示サーフェスの複雑な領域および／または広範囲に及ぶサンプリングを伴うＣＰＵの大規模な計算を必要とするが（したがって、グラフィックスハードウェアベースの高速化の可能性が制限される）、透明化、陰影、３Ｄグラフィックス、および高度な照明効果などの他の機能は、極めて困難であり、大量の資源を消費する。

例えば、従来ＵＳＥＲとして知られているＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ＸＰウィンドウマネージャは、Ｗｉｏｎｄｏｗｓ（登録商標）ブランドオペレーティングシステムの出現以来、グラフィカルユーザインターフェースサブシステム（現在ではＷｉｎ３２と呼ばれている）の主要なコンポーネントとして役目を果たしてきた。ＵＳＥＲでは、２次元グラフィックスデバイスインターフェース（ＤＧＩ）グラフィック描画エンジンを使用して、表示装置に描画を行う。ＧＤＩは、Ｗｉｎ３２の他の主要サブコンポーネントである、オリジナルのＷｉｎｄｏｗｓ（登録商標）ブランドのオペレーティングシステムの中に存在する描画技術に基づいている。ＵＳＥＲは、ＧＤＩクリッピング領域および２Ｄ描画プリミティブと連携し、無効化メッセージングモデルを使用してそれぞれのウィンドウを表示装置に描画する。デスクトップを描画する際のＵＳＥＲの主要な動作として、デスクトップ描画の無効化モデルにより、ビジュアル更新が必要な表示領域を識別すること、ならびに、描画する必要があることおよび描画する位置をアプリケーションに通知することがある。

デスクトップの描画で次に発展したのは、デスクトップ合成（ｄｅｓｋｔｏｐ ｃｏｍｐｏｓｉｔｉｎｇ）と呼ばれる下から上への描画手法である。合成ＤＷＭ（ｃｏｍｐｏｓｉｔｉｎｇ ＤＷＭ）、つまりＣＤＷＭでは、デスクトップは下位レイヤから上位レイヤへと描画される。つまり、デスクトップの背景が最初に描画され、その後、デスクトップ上に直接配置されているアイコン、フォルダ、およびコンテンツが続き、そして、１レベル上のフォルダ、というように描画されて行く。デスクトップを下から上に描画することにより、繰り返される各レイヤは、そのコンテンツを下にあるレイヤに基づかせることができる。しかし、デスクトップ合成は、ＣＤＷＭがデスクトップに描画される各アイテムのコピーをメモリ内に保持するためメモリを大量に使用する処理である。最近の市場の変化と製造技術により高度なビデオハードウェアおよびコンピュータメモリがかなり手頃な価格になる前には、映画向けの特殊効果の準備のためなど、合成エンジンを実装することができるのは商業用の高価なハイエンドコンピューティングシステムだけであった。

ミッドエンドおよびローエンドのコンピュータのビデオハードウェアの発展は、普及しているオペレーティングシステムに用意されているグラフィカルサービスによって主に促進されてきた。しかし、普及しているオペレーティングシステムで利用できるグラフィカルサービスは、旧式のアプリケーションソフトウェアおよび手の届く値段のビデオハードウェアの限られた機能との互換性を維持する必要性を含むさまざまな理由からあまり高度なものではなかった。しかし、最近、リアルタイム３Ｄコンピュータゲームは、小売りのビデオハードウェア発展の主要な市場推進役としてオペレーティングシステムを追い越し、短期間のうちに、並外れた高度な水準に達した。リアルタイムのハードウェアベースの３Ｄ高速化機能は、現在では、消費者にとって妥当な価格で入手可能になっている。したがって、かつては非常に高度なものと考えられていた、高速なテクスチャおよび照明アルゴリズム、３Ｄ変換、およびＧＰＵの直接プログラミング機能などのグラフィックスハードウェア機能が容易に利用できる。現在、一般的に、ゲームソフトウェアおよび非常に専門的なグラフィックスアプリケーションのみがこのような機能を積極的に活用しており、またそうするためには、レガシＷｉｎ３２ウィンドウマネージャ（ＵＳＥＲ）およびＧＤＩをバイパスする必要がある。

合成デスクトップモデルを実装する際のもう１つの障害は、無効化モデルＤＷＭとともに使用するように書かれているレガシアプリケーションが合成環境では正常に機能しないということである。これは、レガシアプリケーションのコアの描画ロジックがオペレーティングシステムの無効化モデルＤＷＭ ＡＰＩに基づいているためである。つまり、レガシアプリケーションは、ユーザの対話操作または内部状態の変化に直接応答してウィンドウのコンテンツを描画するのではなく、オペレーティングシステムまたは自身の無効化要求により生成される描画メッセージを受け取ったときのみ描画するものとなっている。最も困難な改善法は、合成ＤＷＭがアプリケーションの代わりにレガシＧＵＩプラットフォームを代理とする手段を考案することからなる。これよりも単純な代替手段は、アプリケーションを合成デスクトップ環境から除外する（当分野で「サンドボクシング（ｓａｎｄ ｂｏｘｉｎｇ）」として知られている方法）、または単にレガシアプリケーションの互換性を完全に放棄してしまうという方法からなる。

現状では、非クライアント領域内にあるＵＩ要素は、アプリケーションにより修正することはできない。さらに、標準フレームレイアウトに対しクエリ、修正、または選択的オーバーライドを実行する、または非クライアント要素を個別に描画する直接的で堅牢な手段はない。例えば、アプリケーション側でシステムアイコンまたは非クライアントボタン（例えば、元のサイズに戻す、最大化、最小化、閉じる）を再配置し、カスタム非クライアントボタンを追加または追跡するための実用的な方法はない。さらに、アプリケーションは、アプリケーション側にウィンドウの非クライアント領域全体（クライアント領域とともに）に対する描画およびヒットテスト（ｈｉｔ−ｔｅｓｔｉｎｇ）の責任を負わせたいのでない限り、単一の矩形領域（クライアント領域）にアプリケーションコンテンツを配置することに制限される。既存のＵＳＥＲフレームワーク内のこれらの制約を緩めると、制約を見込み、またそれに依存する多数の一般的に利用されているレガシアプリケーションが使用できなくなるであろう。

そこで、合成モデルを使用してデスクトップを描画するリッチなフル機能のオペレーティングシステムを実現させ、動的ウィンドウアーキテクチャを許容するデスクトップウィンドウマネージャを実現させることは、技術の進歩となるであろう。レガシアプリケーションも動的アーキテクチャモデルで動作するように、動的ウィンドウアーキテクチャを許容ししかもレガシアプリケーションをサポートするデスクトップウィンドウマネージャを実現すると技術の進歩となるであろう。

以下では、本発明のいくつかの態様の基本的な理解を与えるために、本発明の概要を簡単に述べる。この概要は、本発明の広範な全体像ではない。この要約は、本発明の鍵となる要素やクリティカルな要素を特定したり、本発明の範囲を線引きすることを意図していない。以下の概要は、後述の詳細な説明の前置きとして、本発明のいくつかの概念を簡単な形態で述べるにすぎない。

上述の従来技術における制限を克服するために、また本明細書を読み理解した後に明白になるであろう他の制限を克服するために、本発明は、高度なグラフィックスおよび描画機能を備える合成デスクトップを対象とする。

本発明の第１の例示されている態様は、動的な構成を持つウィンドウを描画するデータ処理システムを提供する。データ処理システムは、プロパティが格納されているウィンドウ毎に、基本オブジェクトのプロパティおよび少なくとも１つのコンテンツオブジェクトに対するプロパティを含むウィンドウプロパティを格納するメモリを有する。データ処理システムは、さらに、プロパティが格納される各ウィンドウのウィンドウプロパティに基づいてデスクトップを構成する合成デスクトップウィンドウマネージャのソフトウェアモジュールも有する。

本発明の他の態様では、ウィンドウが一様でない動的構成を有するウィンドウ情報を格納するためのデータ構造を提供する。データ構造は、ウィンドウの基本オブジェクトの基本オブジェクトプロパティを格納する第１のデータフィールド、およびウィンドウの１つまたは複数のコンテンツオブジェクトに対するコンテンツオブジェクトプロパティを格納する第２のデータフィールドを含む。

添付の図面と合わせて、以下の説明を参照すると、本発明およびその利点をより完全な理解を得ることができ、また図面では類似の参照番号は類似の機能を示している。

さまざまな実施形態の以下の説明では、これに関して一部をなし、本発明を実施できるさまざまな実施形態を図で示す付属の図面を参照する。他の実施形態を利用し、本発明の範囲および精神から逸脱することなく構造的および機能的な修正を加えることができることは当然理解されよう。

本発明は、好ましい描画モデルとしてデスクトップ合成を使用するデスクトップウィンドウマネージャ（ＤＷＭ）を提供する。本発明のデスクトップウィンドウマネージャは、本明細書では、合成デスクトップウィンドウマネージャ（ＣＤＷＭ）と呼ぶ。ＣＤＷＭは、合成サブシステムと合わせて、統一合成エンジン（ＵＣＥ）（Ｕｎｉｆｉｅｄ Ｃｏｍｐｏｓｉｔｉｎｇ Ｅｎｇｉｎｅ）と呼ばれ、３Ｄグラフィックスおよびアニメーション、シャドウ、透明化、高度な照明手法、およびデスクトップ上のその他のリッチなビジュアル機能を備える。本明細書で本質的に使用される合成描画モデルは、描画における無効化ステップをなくし、描画およびその他の通知メッセージの送信の必要性を最小化するかなくすが、それは、システムがそれぞれのウィンドウを必要に応じ描画するのに十分な状態情報を保有しているからである。

例示されている動作環境
図１は、本発明を実施するのに適しているコンピューティングシステム環境１００の一例を示す図である。コンピューティングシステム環境１００は、適当なコンピューティング環境の一例にすぎず、本発明の用途または機能性の範囲に関する制限を示唆する意図はない。コンピューティング環境１００は、例示的なオペレーティング環境１００に示されている１つのコンポーネントまたはその組み合わせに関係する何らかの依存または要求のいずれも有するものとして解釈すべきでない。

本発明は、他の数多くの汎用または専用のコンピューティングシステム環境または構成で使用できる。本発明での使用に適した周知のコンピューティングシステム、環境、および／または構成の例として、それだけに限定はされないがパーソナルコンピュータ、サーバコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、タブレットＰＣ、またはラップトップＰＣなどの携帯型およびハンドヘルド型の装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたは装置のいずれかを含む分散コンピューティング環境、などが挙げられる。

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

図１に関して、本発明を実施する例示的なシステムは、コンピュータ１１０の形態の汎用コンピューティング装置を備える。コンピュータ１１０が備えるコンポーネントとしては、それだけに限定はされないが、処理装置１２０、システムメモリ１３０、およびシステムメモリを備えるさまざまなシステムコンポーネントを処理装置１２０に接続するシステムバス１２１などが挙げられる。システムバス１２１には、メモリバスまたはメモリコントローラ、周辺機器バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含む数種類のバス構造のいずれかであってよい。例えば、限定するものではないが、このようなアーキテクチャとしては、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、Ａｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）バス、およびメザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られているＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが挙げられる。

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

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

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

図１に例示されている上記のドライブおよび関連するコンピュータ記憶媒体は、コンピュータ１１０用のコンピュータ読み取り可能な命令、データ構造、プログラムモジュール、およびその他のデータの記憶を備える。例えば、図１では、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして例示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同じである場合もあれば異なる場合もあることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７に対しては、ここで、異なる番号を割り当てて、最低でも、それが異なるコピーであることを示している。ユーザは、キーボード１６２、およびマウス、トラックボール、またはタッチパッドと一般に呼ばれるポインティングデバイス１６１などの入力装置を介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力装置やその他の入力装置は、システムバスに接続されているユーザ入力インターフェース１６０を介して処理装置１２０に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造により接続することもできる。モニタ１８４またはその他の種類の表示装置も、ビデオインターフェース１８３などのインターフェースを介してシステムバス１２１に接続される。コンピュータ１１０は、ユーザがペン入力装置１８６を使用して入力できる、モニタ１８４と併用するデジタイザ１８５も備えることができる。モニタのほかに、コンピュータは、スピーカ１８９およびプリンタ１８８などの他の周辺出力装置も備えることができ、これらは出力周辺インターフェース１８７を介して接続することができる。

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

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

例示されている実施形態
本発明では、合成デスクトップウィンドウマネージャ（ＣＤＷＭ）を使用し、合成デスクトップモデル、つまり、下から上への描画方法を使用してデスクトップ表示を描画し保持することができる。ＣＤＷＭは、将来参照できるようにバッファメモリ領域内にコンテンツを保持することができる。ＣＤＷＭは、デスクトップを下から上へ、デスクトップの背景から始めて重なり合うウィンドウを経て、逆Ｚオーダで描画することによりデスクトップを合成する。デスクトップを構成している間、ＣＤＷＭは、描画されているウィンドウの下にあるコンテンツに一部基づいて、また他の環境要因（例えば、光源、反射特性）にも一部基づいて、各ウィンドウを描画することができる。例えば、ＣＤＷＭは、ＡＲＧＢ形式のテクスチャのアルファチャネルを使用して、ウィンドウに透明性を付与し、仮想光源に基づいてウィンドウのコンテンツの一部（例えば、フレーム）を選択的に強調することができる。

ＣＤＷＭは、オペレーティングシステム１３４、１４４の一部として存在するか、またはオペレーティングシステムとは独立して、例えば他のプログラムモジュール１３６、１４６に存在することができる。さらに、ＣＤＷＭは、本明細書では統一合成エンジン（ＵＣＥ）と呼ばれる、以下および、すべての目的に関して全体が参照により本明細書に組み込まれる、２００３年１０月２３日に出願された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ ａ Ｕｎｉｆｉｅｄ Ｃｏｍｐｏｓｉｔｉｏｎ Ｅｎｇｉｎｅ ｉｎ ａ Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｓｙｓｔｅｍ」という名称の同時係属特許出願番号（法定代理人整理番号５００３７．２０１ＵＳ０１）において詳しく説明されている、低レベルのグラフィックス合成サブシステムに頼ることができる。例示されている一実施形態では、ＵＣＥは、ワシントン州レッドモンドのマイクロソフト社のＤｉｒｅｃｔ３Ｄ（登録商標）およびＤｉｒｅｃｔＸ（登録商標）技術に基づくか、または使用する。他の実施形態では、カリフォルニア州マウンテンビューのシリコン グラフィクス社によるＯｐｅｎＧＬ（登録商標）グラフィックスエンジンに基づくＸ Ｗｉｎｄｏｗプラットフォームのバリエーションなどの他のグラフィックス合成サブシステムを使用することができる。ＵＣＥは、３Ｄグラフィックスおよびアニメーション、透明性、シャドウ、照明効果、バンプマッピング（ｂｕｍｐ ｍａｐｐｉｎｇ）、環境マッピング、およびデスクトップ上のその他のリッチなビジュアル機能を可能にする。

図１Ｂは、デスクトップ合成プラットフォームの例示的実施形態によるコンポーネントアーキテクチャを示している。合成デスクトップウィンドウマネージャ（ＣＤＷＭ）１９０は、合成ウェア（ｃｏｍｐｏｓｉｔｉｏｎ−ｗａｒｅ）アプリケーションソフトウェア１９１が、ＣＤＷＭウィンドウならびにコンテンツ作成および管理サービスをそれを通じて得るためのアプリケーションプログラミングインターフェース１９０ａ、レガシウィンドウ操作グラフィックスサブシステム１９２が、個々のウィンドウのリダイレクトされたグラフィックス出力に影響を及ぼす変更に関する更新通知をそれを通じて送信するためのサブシステムプログラミングインターフェース１９０ｂ（ウィンドウグラフィック出力のリダイレクトについては、以下で詳述する）、およびウィンドウおよびその関連するコンテンツなどのデスクトップＵＩオブジェクトのＺオーダリポジトリ（Ｚ−ｏｒｄｅｒｅｄ ｒｅｐｏｓｉｔｏｒｙ）を保持するＵＩオブジェクトマネージャ１９０ｃを含むことができる。ＵＩオブジェクトマネージャは、テーママネージャ１９３と通信し、リソース、オブジェクト挙動属性（ｏｂｊｅｃｔ ｂｅｈａｖｉｏｒａｌ ａｔｔｒｉｂｕｔｅｓ）、およびアクティブなデスクトップテーマに関連付けられているレンダリングメトリック（ｒｅｎｄｅｒｉｎｇ ｍｅｔｒｉｃ）を取得することができる。

レガシグラフィカルユーザインターフェースサブシステム１９２は、レガシウィンドウマネージャ１９２ａおよびレガシグラフィックスデバイスインターフェース１９２ｂを含むことができる。レガシウィンドウマネージャ１９２ａは、ＣＤＷＭが出現する以前に開発されたソフトウェアアプリケーション用の無効化モデルウィンドウ操作（ｗｉｎｄｏｗｉｎｇ）およびデスクトップサービスを提供する。レガシグラフィックスデバイスインターフェース１９２ｂは、２Ｄグラフィックスサービスをレガシアプリケーションだけでなくレガシウィンドウマネージャにも提供する。デスクトップを描画するための無効化モデルに基づくレガシグラフィックスデバイスインターフェースは、３Ｄ、ハードウェア高速化描画プリミティブ、および変換のサポートを欠く場合があり、ビットマップコピーおよび転送オペレーションのピクセル毎のアルファチャネルの透明性（ｔｒａｎｓｐａｒｅｎｃｙ）をネイティブ機能としてサポートしないかもしれない。レガシウィンドウマネージャ１９２ａおよびグラフィカルデバイスインターフェース１９２ｂは共に、無効化モデルを使用するお気に入りのまたは重要なソフトウェアアプリケーションを実行する機能を犠牲にせずに、オペレーティングシステムのアップグレードを望むユーザの所有コストを低減するために役目を果たし続ける。エンドユーザに対し目立ったペナルティがほとんどまたは全く生じない方法で、レガシアプリケーションウィンドウと合成ウェアアプリケーションウィンドウとが継ぎ目なく並ぶ統合を実現するために、合成プロセスへのレガシグラフィカルユーザインターフェースサブシステム１９２のアクティブな関与がある。実際、レガシアプリケーションの認知されているプラットフォーム環境は、合成されたデスクトップに対する堅牢性（ｒｏｂｕｓｔｎｅｓｓ）を損なわないようにするために、変化しないのが好ましいが、それでもレガシウィンドウがデスクトップに描画される基本的な方法は、基本的に変更されるであろう。本発明では、本明細書でウィンドウグラフィック出力のリダイレクトとして説明される機能を付加することによりどのようにこれが実現されるか説明する。

統一合成エンジン（ＵＣＥ）１９４は、プログラミングインターフェース１９４ａを介してＣＤＷＭから発行された描画命令および合体した（ｃｏａｌｅｓｃｅ）リソースを使用可能にする（ｓｅｒｖｉｃｅ）ことができる。広い意味で、ＣＤＷＭに関するＵＣＥの役割は、レガシウィンドウマネージャ１９２ａに関するレガシグラフィックスデバイスインターフェース１９２ｂの役割に似ている。ＵＣＥプログラミングインターフェース１９４ａは、ＣＤＷＭを提供し、そして最終的にアプリケーションが、抽象インターフェースをさまざまなグラフィックスサービスに提供する。これらのＵＣＥサービスには、リソース管理、複数表示シナリオからのカプセル化、およびリモートデスクトップサポートがある。

ＣＤＷＭの書き込み動作と描画動作間のグラフィックスリソースの競合は、内部のリソースマネージャ１９４ｂにより調停することができる。リソース更新および描画サービスの要求は、プログラミングインターフェースサブコンポーネント１９４ａによりＵＣＥの要求キュー１９４ｃに置かれる。これらの要求は、システムにインストールされている表示装置のリフレッシュレートと一致する間隔で描画モジュール１９４ｄにより非同期で処理することができる。したがって、ＵＣＥ１９４の描画モジュール１９４ｄは、ＣＤＷＭ要求をキューから取り出し、必要に応じてリソースマネージャ１９４ｂに格納されているリソースにアクセスして操作し、３Ｄグラフィックスインターフェース１９５への表示画面固有の描画命令を組み立てて送出することができる。

デスクトップを複数の表示画面に描画するには、異種表示装置間の、リフレッシュ速度、ピクセル形式サポート、およびデバイス座標マッピングの相違の抽象化を必要とする。ＵＣＥでは、この抽象化を実現することができる。

ＵＣＥは、さらに、リモートデスクトップ構成においてネットワーク接続でグラフィックスデータを送出する責務も有する。一方の特定のシステムのデスクトップを他のシステムのデスクトップから効率よく離すために、リソース競合を回避し、性能の最適化を成立させ、セキュリティを堅牢なものとしなければならない。これらの責務は、ＵＣＥにもありうる。

３Ｄグラフィックスインターフェース１９５は、Ｄｉｒｅｃｔ３Ｄ（登録商標）、ＯｐｅｎＧＬ（登録商標）などの低レベルの直接モード（ステートレス）グラフィックスサービスを備えることができる。３Ｄグラフィックスインターフェースの目的は、特定のグラフィックスハードウェア構成の機能にわたる抽象インターフェースを実現することである。３Ｄグラフィックスインターフェースは、単一の表示装置のために働き、ＵＣＥは、複数のデバイスドライバ１９６を介してマルチディスプレイシステムの複数のグラフィックス出力装置１９７の間に、ＣＤＷＭの描画命令を解析し分配することができる。

図１Ｂに示されているコンポーネントアーキテクチャは、例示的な実施形態のアーキテクチャであることに留意されたい。図は、本発明が含むことができる機能を図示することを意図している。これらの機能は、プラットフォームの機能および所望の機能セットに従って、図に表されているものよりも少ないまたはより多い数のソフトウェアコンポーネントの間に分配することができる。例えば、テーマ管理を欠くシステムでは、別のテーママネージャからではなく、おそらくＣＤＷＭ自体により管理される静的リソースとして、システムからすべてのストックリソースを派生させる場合もある。差し込み可能な（ｐｌｕｇａｂｌｅ）ウィンドウマネージャを許容するプラットフォームでは、ＣＤＷＭ内のアプリケーションプログラミングインターフェース１９０ａを差し込み可能ウィンドウマネージャインターフェース（Ｐｌｕｇａｂｌｅ Ｗｉｎｄｏｗ Ｍａｎａｇｅｒ Ｉｎｔｅｒｆａｃｅ）で置き換えて、合成ＵＩオブジェクトおよびリソース管理の詳細を抽象化することができる。他の考えられる変更形態では、レガシアプリケーションとの互換性が必要なければ、サブシステムプログラミングインターフェース１９０ｂをなくしてもよい。
図１Ｂに示されているＵＣＥ １９４のサブコンポーネントは、別々のプロセスに分解するか、ＣＤＷＭ自体の中に折り込むか、または３Ｄグラフィックスインターフェースに統合することができる。したがって、幅広い特定のコンポーネント設計が可能であり、それぞれが本発明を含む機能全体または機能の一部を実行することができる。

図２は、本発明の例示的態様によるデスクトップ合成を実行する一般的な方法を例示している。ステップ２０１から２０５は、合成デスクトップウィンドウマネージャ（ＣＤＷＭ）ＡＰＩを使用してウィンドウおよびウィンドウのコンテンツを作成し管理する合成を意識したアプリケーションの相互作用を説明している。ステップ２０７および２０９は、レガシウィンドウコンテンツを合成するための従来の無効化モデルウィンドウマネージャアプリケーションとＣＤＷＭ間の相互作用を示している。

ステップ２０１で、合成デスクトップマネージャ（ＣＤＷＭ）は、合成を意識したアプリケーションから、（１）合成ウィンドウを作成し、（２）コンテンツオブジェクトを付ける要求を受け取る。本発明は、ウィンドウ毎に単一のコンテンツオブジェクトに限られるわけではなく、アプリケーション側で、ＣＤＷＭ ＡＰＩを介してウィンドウを動的に作成し、ウィンドウに任意の個数のコンテンツオブジェクトを付ける（それだけでなく分離および破壊する）ことができる。コンテンツオブジェクトは、追加のテクスチャ（ライトマップ（ｌｉｇｈｔ ｍａｐ）、鏡面マップ（ｓｐｅｃｕｌａｒ ｍａｐ）、バンプ／通常マップ（ｂｕｍｐ／ｎｏｒｍａｌ ｍａｐ）など）、ライト（ｌｉｇｈｔｓ）、およびピクセルシェーダ（ｐｉｘｅｌ ｓｈａｄｅｒ）などのオプションのアクセサリリソースとともに、アプリケーション定義メッシュまたはシステム定義メッシュにマッピングされた拡散テクスチャ（ｄｉｆｆｕｓｅ ｔｅｘｔｕｒｅ）として使用される指定されたサイズおよびピクセル形式のラスタサーフェスからなる。拡散コンテンツテクスチャのピクセル形式は、システムにインストールされているビデオハードウェアでサポートされている形式であればどのようなものでもよいが、今の説明を目的として、３２ビットＡＲＧＢとすることができる。この形式を要求する場合、アプリケーションは、コンテンツピクセルの透明レベルを変えるのにアルファ（Ａ）チャネルを使用することができ、したがって最終の描画でソースピクセルとともに調節するデスクトップ背景情報の量の微調整を行うことができることを暗黙のうちに知ることができる。ステップ２０３で、ＣＤＷＭは、ＣＤＷＭ実装コンテンツオブジェクトを付けるウィンドウに対する状態ブロック（ｓｔａｔｅ ｂｌｏｃｋ）を割り当てる。コンテンツオブジェクトは、要求されたリソースを割り当てるか、またはアプリケーションにより転送されたリソースを添付し、ＵＣＥに対しこれらのリソースを整列させて（ｍａｒｓｈａｌ）、ＵＣＥ更新要求後直ちにアクセスできるようにする。ステップ２０５で、アプリケーションは、ウィンドウまたはウィンドウのコンテンツに対する余計な変更についてＣＤＷＭに通知する。これらの変更は、いずれかのウィンドウまたはコンテンツの状態に影響を及ぼす可能性があるが、簡単のため、例示では、３つの共通更新要求、つまりコンテンツサイズ、ウィンドウ位置またはスケール、あるいはコンテンツの拡散テクスチャのピクセルに対する変更を示している。

レガシウィンドウを合成するプロセスは、デスクトップ合成の初期化から始まり、ＣＤＷＭ １９０は、それぞれのレガシウィンドウのグラフィック出力を一時メモリロケーションにリダイレクトする要求をレガシウィンドウ操作およびグラフィックサブシステム１９２に送る（ステップ２０７）。ステップ２０７は、より一般的には、レガシウィンドウおよびグラフィックサブシステムを「合成モード」にあるものとして説明することができるが、それぞれの個別ウィンドウの描画は、別のメモリバッファにリダイレクトされる。例示されている一実施形態では、レガシグラフィカルユーザインターフェースサブシステム１９２は、ウィンドウの描画にかかわるグラフィックス命令の出力をウィンドウと関連付けられたビットマップメモリサーフェスにリダイレクトする。しかし、本発明は、ネイティブの描画命令および関連するパラメータを保持する機能、ならびにターゲットの表示装置に対する次のビデオフレームを合成するプロセスの実行中にＵＣＥでそれらの命令を実行することも包含している。これらのリダイレクトバッファ（サーフェスまたは描画命令ブロック）は、ＣＤＷＭまたはレガシウィンドウマネージャ１９２ａのいずれかにより管理することができるが、この例示を目的として、サーフェスリソースはＣＤＷＭで集中管理される。それぞれのリダイレクトバッファは、ウィンドウに対する拡散コンテンツテクスチャリソースを構成するか、またはそれを生成するために使用される。レガシウィンドウマネージャ１９２ａは、ＣＤＷＭウィンドウおよびコンテンツ作成ＡＰＩを呼び出す必要はなく、通知用のレガシサブシステム−ＣＤＷＭ通信チャネルは、アプリケーションインターフェースのチャネルと異なり、ＣＤＷＭは、既存のレガシウィンドウプロパティから合成ウィンドウ属性（フレームおよび枠のスタイル、キャプションなど）および状態（非表示／表示、最小化／最大化など）を導出する。ステップ２０９で、レガシウィンドウマネージャ１９２ａは、ビジュアルな更新を必要とする可能性のあるリダイレクトされたウィンドウコンテンツテクスチャに影響を及ぼす何らかの変更についてＣＤＷＭ １９０に通知する。

ステップ２１１、２１９、および２２３で、ＣＤＷＭ １９０は、サイズ、位置／スケール、およびピクセルレベルテクスチャの更新要求のうちから判別し、それに応じて動作する。サイズ更新（ステップ２１１）では、ＣＤＷＭはまず、フレームがターゲットウィンドウに関連付けられているかどうかを判別する（ステップ２１３）。フレームがウィンドウに関連付けられている場合（ステップ２１５）、ＣＤＷＭは、合成を意識したアプリケーションにより明示的に与えられた２次元または３次元のエクステント（ｅｘｔｅｎｔ）、またはレガシおよびＣＤＷＭウィンドウのメトリクス（ｍｅｔｒｉｃｓ）とリダイレクトされたレガシサーフェスの更新された次元の組み合わせに基づいてフレームプリミティブの適切なサイズおよび向きを決定する。フレームサイズが決定されると、ＣＤＷＭは、フレームメッシュ内の頂点の位置情報に適切な変更を加え、頂点データバッファをＵＣＥに転送する。ＵＣＥは、非同期処理を行うため、メッシュ更新ディレクティブおよび新しい頂点情報をキューに入れる。ウィンドウにフレームがない場合、ステップ２１５をバイパスすることができる。フレーム付きまたはフレームなしのウィンドウの場合、コンテンツ領域に影響を及ぼすサイズの変更は、ＣＤＷＭが、コンテンツメッシュのサイズを変更し、ＵＣＥへの適切なメッシュ更新要求およびデータをキューに入れることを引き起こす（ステップ２１７）。

位置（回転を含む）またはスケールの更新（ステップ２１９）では、ＣＤＷＭは、非同期処理のために、新しい変換パラメータを決定し、ＵＣＥへの変換リソース更新要求をデータとともにキューに入れる（ステップ２２１）。リソースは、最低でも、４×４変換行列からなるが、フィルタ処理された変換をサポートするため追加データを含むこともできる。

ステップ２２３で、ＣＤＷＭは、拡散コンテンツテクスチャのピクセルデータへの変更を伴う更新要求を受け取る、つまり、アプリケーションはすでにそのウィンドウ内でコンテンツを更新している。ステップ２２５で、ＣＤＷＭは、非同期処理のため、ＵＣＥへの新しいピクセル情報をキューに入れることによりこの要求を使用可能にする（ｓｅｒｖｉｃｅ）。

追加の更新要求は、図２に示されているもののほかにもサポートできることは当業者であれば理解されるであろう。例えば、ウィンドウのアイコンまたはキャプションのテキストに対する変更はまた、それぞれウィンドウに関連付けられたＣＤＷＭ管理されたアイコンまたはキャプションコンテンツオブジェクトの再描画を必要とする場合がある。ウィンドウ入力フォーカスは、フレームの外観に反映され、したがって、レガシウィンドウの場合、レガシウィンドウマネージャが、入力フォーカス変更更新を、フレームを再描画し場合によっては他のコンテンツもそれに応じて再描画するＣＤＷＭに送ることができる。

ステップ２２７で、ＵＣＥはＣＤＷＭから入ってくる合成およびリソース更新を処理し、デスクトップの合成に関与するそれぞれのアクティブなビデオグラフィックスアダプタのビデオリフレッシュレートと同期する間隔で、表示サイズのバッキングバッファへデスクトップ（またはマルチディスプレイ構成における該当する部分）を再描画する。これは、３Ｄグラフィックスエンジン（Ｍｉｃｒｏｓｏｆｔ Ｄｉｒｅｃｔ３Ｄ（登録商標）など）により提供される直接モードの描画サービスを使用して実行され、これはデスクトップを順に１次（ｐｒｉｍａｒｙ）表示サーフェスに転送する。

ウィンドウを３Ｄで描画するために、ＣＤＷＭは、さまざまなコンポーネントを使用してウィンドウ構成を定義し、基本コンテンツオブジェクトおよび１つまたは複数の子コンテンツオブジェクトを含むようにできる。基本コンテンツオブジェクトは、ウィンドウのフレーム、つまり枠を定義し、基本ジオメトリ、基本エクステント、基本マテリアルプロパティ、および基本コンテンツマージンからなる。基本コンテンツオブジェクトおよび子コンテンツオブジェクトは、それぞれシステムにより完全に定義し管理することができ、またカスタムコンテンツ要素の場合には、アプリケーションにより管理することができる。コンテンツオブジェクトについて、以下で詳述する。

図３は、本発明の例示的態様によるアプリケーションウィンドウを例示している。
アプリケーションウィンドウ３０１は、さまざまな領域およびコンポーネントを含むことができる。ウィンドウ３０１のフレームまたは基本コンテンツ３０３は、ボタン３０５（例えば、ウィンドウを元のサイズに戻す、最大化する、最小化する、閉じるなどのために使用される）、指示アイコン３０７、スクロールバー３０９、メニューバー３１１、およびウィンドウキャプションテキスト３１３を含む子コンテンツをホストすることができる。１次コンテンツオブジェクト領域３１５は、レガシウィンドウおよびグラフィカルユーザインターフェースサブシステムから得られるリダイレクトバッファから派生させるか、または合成を意識した自アプリケーションにより作成し、標準の基本コンテンツに添付し、描画することができる。当業者であれば、図３が、基本的なウィンドウ要素を単に例示しているにすぎないこと、また追加もしくは異なるウィンドウ要素がさらに、またはそれとは別に使用できることは理解されよう。さらに、それとは別にウィンドウフレーム要素をアプリケーション側で用意し、例えば、アプリケーションプログラミングと異なるルックアンドフィールを与えることができる。一例として、アプリケーションプログラム側でカスタム子コンテンツオブジェクトとしてスクロールバー要素を備え、そのアプリケーションプログラムに特有の外観と挙動を表すようにするものがある。さらに、アプリケーションは、ＣＤＷＭ ＡＰＩを使用してストックフレーム要素のうちの１つまたは複数を取り除くか、または再配置することを選択することができる。アプリケーションは、単一の１次コンテンツ領域に限られる必要はないが、これは従来技術では広く見られる制限である。

ＣＤＷＭは、単一ウィンドウに関連付けられた複数のアプリケーション作成および描画コンテンツ領域をサポートすることができる。アプリケーションに固有のユーザエクスペリエンスを提供する機能を備えるために、本発明の１つまたは複数の実施形態では、ＣＤＷＭは、ウィンドウを描画する仕方に、柔軟性を与えるものとなっている。つまり、ＣＤＷＭでは、各アプリケーションを単一の矩形のクライアントコンテンツ領域に制限するのではなく、アプリケーション側でそれぞれ任意の形状を持つ複数のカスタムコンテンツオブジェクトを定義できるようにすることで、アプリケーションがウィンドウの既定の構成を変更することを可能とする。

したがって、各ＣＤＷＭウィンドウは、基本コンテンツオブジェクト（つまり、フレーム）および１つまたは複数の子コンテンツオブジェクトのコレクションで構成することができる。各コンテンツオブジェクトは、唯一の一組のコンテンツ属性により定義することができ、またオプションによりキーボードおよびマウスイベントを受け取るように構成することができる。ＣＤＷＭは、アプリケーションで定義されたコンテンツに局所的な３Ｄ座標に関してマウスのヒットテスト点をマッピングし、マウスイベント通知をアプリケーションに送る。コンテンツオブジェクトは、システムにより完全に管理できるか、またはカスタムコンテンツ要素の場合には、アプリケーションにより管理することができる。システム管理されたコンテンツオブジェクトの例としては、アプリケーション指示アイコン、フレームボタン（例えば、最小化、元に戻す、閉じる）、キャプションテキスト、ならびに所定のメニューバーおよびスクロールバーがある。アプリケーション管理されたコンテンツオブジェクトは、アプリケーションが１次ビジュアル出力を描画するコンテンツオブジェクト、例えば、ワードプロセッサによるテキスト、表計算アプリケーションによる数値グリッド、写真編集アプリケーションによる画像がある。

コンテンツテクスチャは、システムにより管理されるビットマップであるか、またはカスタムコンテンツの場合では、アプリケーションである。コンテンツテクスチャは、１回の反復でコンテンツジオメトリに直線的にマッピングすることができる。アスペクト比は、コンテンツジオメトリにより決定することができ、テクスチャ座標はコンテンツジオメトリで公開することができる。コンテンツの倍率は、コンテンツテクスチャのジオメトリへのマッピングに影響を及ぼす拡大縮小変換により制御することができる。ＣＤＷＭは、システムに備えられているメニューオプション、スライダコントロール、および／またはマウスとキーボードの組み合わせなど、ユーザがそれにより拡大縮小係数（ｚｏｏｍ ｆａｃｔｏｒ）を調整することができる既定の対話的メカニズムを備えることができる。

各再描画の前に、システムは、アプリケーション（またはストックコンテンツオブジェクトの場合にはシステム）の裁量により、拡散テクスチャがピクセル毎のアルファをサポートする形式であるコンテンツサーフェスをゼロアルファ（ｚｅｒｏ ａｌｐｈａ）に初期化することができる。したがって、下にある基本コンテンツオブジェクトは、コンテンツサーフェスの描画されていない領域に表示することができる。これは、アプリケーションが描画する前にコンテンツサーフェスを消去する必要がないため、プログラミングモデルおよびユーザエクスペリエンスの両方を強化し、ユーザはウィンドウ内のフリッカーおよび陳腐なまたは描画されていない領域を免れる。

いくつかの実施形態では、所定のコンテンツオブジェクト、特にアプリケーションがその１次グラフィック出力を描画するコンテンツオブジェクトは、それらに関連するマテリアルプロパティを持たない場合があるが、それは、ユーザの気を散らす方法でまたはユーザの活動に干渉する別の方法で、コンテンツを光または環境と相互作用させることが望ましくないからである。コンテンツオブジェクトのビジュアルな外観は、このような実施形態においてそのテクスチャ、ジオメトリ、および場合によっては頂点毎もしくはピクセル毎のアルファ値だけにより決定することができる。

図６は、本明細書で説明しているような動的非標準構成を持つウィンドウ６０１の一例を示している。ウィンドウ６０１は、非標準形状（つまり、非矩形）の基本フレームオブジェクト６０３、非標準位置（ウィンドウの右上角以外の位置）に配置されている非標準形状（矩形でない）のフレームボタンオブジェクト６０５、非標準位置（ウィンドウの左上角以外の位置）にあるシステム提供の指示（ｉｎｄｉｃａｔｉｖｅ）フレームアイコンオブジェクト６０７、および非標準位置（フレームの上段で左寄せされていない）にもあるフレームウィンドウキャプションオブジェクト６１３を有する。図６では、ウィンドウに関連付けられているアプリケーションは、２つの１次コンテンツオブジェクト領域６１５ａおよび６１５ｂを定義している。１次コンテンツオブジェクト領域６１５ａは、規則正しい形状（つまり、矩形）であるが、１次コンテンツオブジェクト領域６１５ｂは、不規則な、非矩形形状である。ウィンドウ６０１は、例えばブラウズする状況において、それぞれ戻るおよび進むナビゲーションコントロールを備える、アプリケーションにより定義されるフレームボタンオブジェクト６１７および６１９を含むこともできる。

ＣＤＷＭは、アプリケーションウィンドウ３０１の基本部分を３次元（３Ｄ）オブジェクトとして描画することができる。３Ｄメッシュプリミティブは、ウィンドウブジェクトの形状（基本ジオメトリ）を定義するために使用することができ、１次拡散テクスチャ（ｐｒｉｍａｒｙ ｄｉｆｕｓｅ ｔｅｘｔｕｒｅ）は、メッシュの３Ｄジオメトリにマッピングすることができ、照明（ｌｉｇｈｔｉｎｇ）、シェーディング、屈折、ぼかし、ならびに補助テクスチャを含む他の特殊効果パラメータおよびリソースを含むことができるオプションのマテリアルプロパティは、描画プロセス実行時に適用することができる。補助テクスチャは、この技術分野で周知のグラフィック効果のためのリソースとして使用され、デスクトップ環境内の光源、カーソル、およびその他のＵＩオブジェクトとの「ライブの（ｌｉｖｅ）」物理的にモデル化された相互作用を実現することができる。したがって、テクスチャは、ピクセル毎の３Ｄ通常情報源（通常／バンプ マッピング）、ライトマスク（環境光、拡散光、および鏡面光のフィルタ）、反射源（例えば、ウィンドウ上で動かしたときのカーソルの反射）、静的環境マップなどとして役立つことができる。

基本ジオメトリの頂点形式は、オプションにより、ＡＲＧＢ形式の３２ビットの拡散カラー成分とテクスチャ座標ペア｛ｔｕ_ｎ，ｔｖ_ｎ｝を含み、上述のように、最大ｎ個までのテクスチャをメッシュジオメトリにマッピングすることができる。当技術分野で確立しているように、ｔｕおよびｔｖの各整数増分量により、それぞれの次元のテクスチャの反復を定義することができる。例えば、｛０．０，０．０｝（テクスチャの左、上）から｛１．０，１．０｝（テクスチャの右、下）までの値の範囲は、メッシュ全体にわたる単一の反復を表すが、｛０．０，０．０｝から｛６．０，４．０｝までの範囲は、ｘ次元については６回の反復、ｙ次元については４回の反復を定義する。

コンテンツエクステントは、境界エクステント｛ｘ_ｌｅｆｔ，ｙ_ｔｏｐ，ｚ_{ｆｒｏｎｔ}，ｘ_{ｒｉｇｈｔ}，ｙ_{ｂｏｔｔｏｍ}，ｚ_ｂａｃｋ｝を定義する３次元の点のペア、または基本ジオメトリを含む最小のボックスの座標として定義することができる。これは、２Ｄ境界ウィンドウ矩形｛ｘ_ｌｅｆｔ，ｙ_ｔｏｐ，ｘ_{ｒｉｇｈｔ}，ｙ_{ｂｏｔｔｏｍ}｝と似ている。三つ組み｛ｘ_ｌｅｆｔ−ｘ_{ｒｉｇｈｔ}，ｙ_ｔｏｐ−ｙ_{ｂｏｔｔｏｍ}，ｚ_ｂａｃｋ−ｚ_ｂａｃｋ｝は、コンテンツのエクステントの幅、高さ、および深さを定義する。エクステントは、システムにより計算され管理され、コンテンツのサイズおよびローカル位置を表す。

ウィンドウブジェクトがサイズ変更可能であれば、基本コンテンツのエクステントを操作することは、ＣＤＷＭがウィンドウのサイズを変更するための手段となる。辺と角の輪郭を保持するために、サイズ変更可能なメッシュ内のそれぞれの頂点の位置は、単純に新しいエクステントに合わせて拡大縮小することはできない。メッシュのサイズ変更を微調整できるようにするために、適用可能なパラメータとともに定義済み頂点位置フィルタ関数を、アプリケーションによりウィンドウ作成時に指定するか、またはＣＤＷＭにより既定として選択することができる。頂点サイズ変更フィルタ関数の役割は、境界エクステントが変更されたときターゲットメッシュ内のそれぞれの頂点の動作の仕方を決定することである。すべてのフィルタ関数は、各メンバの頂点に対して、各次元（ｘ，ｙ，ｚ）における変位方向と大きさを決定しなければならない。

最も単純なフィルタ関数は、方向（正または負）および大きさ（新しいエクステントに関して拡大縮小、または３Ｄ空間内のメッシュの境界ボックスの６面のうちの１つの量に等しい量により補正（ｏｆｆｓｅｔ））を決定する。各頂点のサイズ変更動作での挙動の仕方は、頂点毎、次元毎に頂点自体に関連付けられたプロパティとして記述するか、またはジオメトリに関して全体としてメッシュに対し定義することができる。後者の方法の一例は、６つのサイズ設定（ｓｉｚｉｎｇ）マージン平面を定めるベクトルのペア｛ｍｘ_ｌｅｆｔ，ｍｙ_ｔｏｐ，ｍｚ_{ｆｒｏｎｔ}，ｍｘ_{ｒｉｇｈｔ}，ｍｙ_{ｂｏｔｔｏｍ}，ｍｚ_ｂａｃｋ｝であり、それぞれメッシュ境界ボックスの１面に関連付けられ、実際には、境界ボックスの体積を２７個の立方体部分領域に分割している。サイズ設定マージン値は、メッシュのサイズに関係なく一定にするか、または境界ボックスの初期サイズに基づいて計算することができる。任意のメッシュサイズ変更動作では、上、左、前の立方体部分領域（｛ｘ_ｌｅｆｔ，ｙ_ｔｏｐ，ｚ_{ｆｒｏｎｔ}，ｍｘ_ｌｅｆｔ，ｍｙ_ｔｏｐ，ｍｚ_{ｆｒｏｎｔ}｝により囲まれている）内の頂点は、境界エクステントの上−左−前の角と同じ大きさおよび方向により補正される。真ん中の立方体部分領域（｛ｍｘ_ｌｅｆｔ，ｍｙ_ｔｏｐ，ｍｚ_{ｆｒｏｎｔ}，ｍｘ_{ｒｉｇｈｔ}，ｍｙ_{ｂｏｔｔｏｍ}，ｍｚ_ｂａｃｋ｝で囲まれている）にある頂点は、その部分領域の新しいエクステントに関して拡大縮小される。前、中心の立方体部分領域内にある頂点は、ｘおよびｙ次元のその部分領域の新しいエクステントに関して拡大縮小されるが、メッシュの前Ｚ境界平面と同じ大きさで、かつ同じ方向に変位される。

上述の原理を分かりやすくするために、図７では、２次元空間内のメッシュサイズ変更動作の一例を示している。ウィンドウ７０１は、角の半径７０７がある丸型の角を持つ。ウィンドウサイズ変更動作が単に、ウィンドウのベースとなるメッシュを拡大縮小するだけであれば、角の半径はメッシュとともに拡大縮小する。しかし、角の丸みが拡大縮小された場合、丸くなっている角の半径が大きすぎたり小さすぎたりし、ユーザエクスペリエンスを損ない、ユーザインターフェースの使い勝手を悪化する可能性がある。そこで、ウィンドウ７０１がサイズ変更されても、角の丸みは変化しないのが好ましい。角の丸みが拡大縮小されないようにするため、メッシュを１つの次元について３セグメント（適宜ｘ、ｙ、ｚ）に分割することができる。そこで、本例では、ウィンドウは９つの象限（ｑｕａｄｒａｎｔ）７０３ａ〜ｉに分割される。３Ｄ空間では、ウィンドウは、２７個の領域に分割することができる。それぞれの次元は、等分に分割するか、または不均等に分割し、それにより、サイズ均等の領域またはサイズ不均等の領域を容認することができる。領域がサイズ不均等であれば、境界ボックスにより囲まれた領域は、拡大縮小すべきでないマテリアルを含むのに必要なだけ小さくすることができる。

ウィンドウサイズ変更動作では、象限は、この象限が境界ボックスにより囲まれている各次元で補正され、象限が領域仕切（ｒｅｇｉｏｎ ｄｉｖｉｄｅｒ）７０５ａ〜ｄにより囲まれている各次元で拡大縮小される。例えば、領域７０３ａ、７０３ｃ、７０３ｇ、および７０３ｉは、ＸおよびＹの両方の次元で少なくとも１つの側面で境界ボックスにより囲まれ、領域７０３ａ、７０３ｃ、７０３ｇ、および７０３ｉ内のメッシュ頂点は、ウィンドウがサイズ変更されるのと同じ、境界ボックスからのオフセットを保持する。領域７０３ｂおよび７０３ｈは、Ｙ（垂直）次元では少なくとも１つの側面で境界ボックスにより囲まれるが、Ｘ（水平）次元では領域仕切７０５によってのみ囲まれる。そこで、領域７０３ｂおよび７０３ｈ内のメッシュ頂点は、Ｙ次元でオフセットを保持するが、Ｘ次元では拡大縮小される。領域７０３ｄおよび７０３ｆは、Ｘ（水平）次元では少なくとも１つの側面で境界ボックスにより囲まれるが、Ｙ（垂直）次元では領域仕切７０５によってのみ囲まれる。そこで、領域７０３ｄおよび７０３ｆ内のメッシュ頂点は、Ｘ次元でオフセットを保持するが、Ｙ次元では拡大縮小される。領域７０３ｅは、Ｘ次元とＹ次元の両方で、仕切線７０５により囲まれ、領域７０３ｅ内に入るメッシュ頂点は、Ｘ次元とＹ次元の両方で拡大縮小される。当業者であれば、前の段落で説明しているように、Ｚ次元を含めることによりこのアルゴリズムを３次元に拡張できることを理解されよう。

メッシュサイズ変更フィルタ関数の別の形態では、頂点の位置が任意の方向で拡大縮小または補正するかを判別するために、サイズ設定マージンなどの大域的な幾何学的構造に依存せず、手書きの（ｈａｎｄ−ａｕｔｈｏｒｅｄ）頂点メタデータを解釈することができる。このような関数は、メッシュサイズ変更時に尾根と谷などの複雑なサーフェストポロジーを保存するために使用することができる。メッシュサイズ変更フィルタ関数の別の形態では、各次元で頂点を直線的または非直線的に変位させることができ、区別ビット（ｄｉｓｃｒｉｍｉｎａｔｉｏｎ ｂｉｔｓ）および関数係数（ｆｕｎｃｔｉｏｎ ｃｏｅｆｆｉｃｉｅｎｔｓ）は頂点毎のメタデータとして格納される。このような関数では、メッシュサイズ変更に付随して、直線的もしくは非負直線的、局所化された、または一般化された膨張もしくは潰れなどの効果を可能にする。

基本コンテンツマージンは、子コンテンツが制約される境界を定義する。コンテンツマージンは、サイズ設定マージンと同じようにして定義された３次元境界とすることができる。しかし、サイズ設定マージンとは異なり、コンテンツマージンは、ウィンドウのスケールに合わせて直線的に拡大縮小することができ、メッシュサイズ変更には影響を及ぼさないかもしれない。

抽象マテリアルプロパティの値に応じて指定された、ローカルおよびデスクトップの大域的リソースおよびパラメータは、ピクセルシェーダと組み合わせることで、ＣＤＷＭが物理的モデル化デスクトップコンテンツの描画を実施するためのデータおよびメカニズムを含む。

高水準コンテンツマテリアルプロパティでは、コンテンツが光および周囲環境と相互作用する仕方を定義する。すりガラスなどの複雑なマテリアルの描画では、ビデオハードウェアでは元々サポートしていない手法を使用することがある。結果として、ＣＤＷＭは、少数の定義済みピクセルシェーダのうちの１つを使用してマテリアルプロパティを実装する。ピクセルシェーダは、メッシュプリミティブ内の光源、テクスチャ、および頂点だけでなく変換およびメトリクスなどのパラメータも含む、定義済みのリソースの集まりに基づいて、表示前にピクセルの値を操作する表示ハードウェアにロードされる小さなルーチンである。ＣＤＷＭは、定義済みピクセルシェーダのコレクションの中から、特定のオブジェクトマテリアルプロパティの集合を描画するのに適したシェーダを選択することができ、これらは環境色（強さおよび透明度）、拡散色（強さおよび透明度）、鏡面色（強さおよび透明度）、反射スカラ、屈折率、拡散テクスチャ、ならびにバンプテクスチャを含み、それぞれにいて後述する。デスクトップグローバルプロパティを使用することにより、目の位置、大域的光源、環境マップなどの大域的環境プロパティを定義することができる。これらのデスクトップグローバルプロパティを定義するリソースおよびパラメータを、基本ウィンドウマテリアルプロパティとともに、ウィンドウ描画直前のアクティブピクセルシェーダへのパラメータとして３Ｄグラフィックスインターフェースに送ることができる。

環境色は、すべての方向からオブジェクトのサーフェスに当たる光をシミュレートするものである。ＣＤＷＭ管理されたＵＩコンテンツオブジェクトに適用可能なマテリアルプロパティとして、環境の強さは、オブジェクトのサーフェスと接触する環境光の相対的量を決定し、３２ビットＡＲＧＢ値を使用して、環境色と透明度を指定することができる。
例示されている一実施形態では、環境の強さは０．０（環境光量０では、一様に黒の外観が与えられる）から１．０（オブジェクト上に一様に分散されている指定された色の最大の強さ）の範囲である。白い環境色を持つ環境の強さの効果により、オブジェクトの一般的明度の制御を可能とする。

拡散の強さは、オブジェクトのサーフェスに接触した後すべての方向に散乱する有向光の量を決定する。光自体は、１つまたは複数の指向性の光または立方体ライトマップ（ｃｕｂｉｃ ｌｉｇｈｔ ｍａｐ）のいずれにかによって与えられる。ＣＤＷＭ管理されたＵＩコンテンツオブジェクトに適用可能なマテリアルプロパティとして、拡散色は、乱反射した光の透明度がアルファ成分により指示される、色を指示する３２ビットＡＲＧＢ値により指定することができる。拡散の強度値は０．０（光が乱反射せず、オブジェクトに一様に黒い外観が与えられる）から１．０（すべての光が反射され、拡散色値に応じてオブジェクトに陰影付の外観が与えられる）までの範囲である。照明が当たったサーフェスは、環境と拡散の強度値の合計が１．０に近づくにつれてよりリアルにモデル化されているように見える。

鏡面の強さでは、オブジェクトのサーフェスから見る人に直接反射される光の量を制御し、鏡面色は、オブジェクトのＡＲＧＢ色として指定することができる。光源自体は、１つまたは複数の指向性の光または立方体のライトマップの形態とすることができる。ＣＤＷＭ管理されたＵＩコンテンツオブジェクトに適用可能なマテリアルプロパティとして鏡面の強さの値を大きくすることにより、鮮明なハイライトで光沢のあるサーフェスをモデル化することができるが、値を小さくした場合は、ハイライトがかすかであるか、または全くない、つや消しのサーフェスをモデル化することができる。色のアルファ成分により、鏡面ハイライトの透明度が決定される。

反射率（ｒｅｆｌｅｃｔｉｖｉｔｙ）も、鏡面反射率（ｓｐｅｃｕｌａｒｉｔｙ）のように、オブジェクトのサーフェスから見る人に向かって直接反射される光の量を決定する。反射が鏡面反射率と異なるのは、反射が光源だけでなく環境全体に適用されるという点である。ＣＤＷＭ管理されたＵＩコンテンツオブジェクトに適用可能なマテリアルプロパティとして反射率の値が０．０だと、サーフェスにおける環境の反射はなく、値が１．０だと、サーフェスにおける環境の反射は鏡のようになる。環境は、立方体環境マップとマウスカーソルとの組み合わせを使用してモデル化することができる。したがって、マウスカーソルだけでなく環境の静的特徴もウィンドウサーフェスから反射されるようにでき、ある程度反射の強さのスカラで制御される。

各オブジェクトの屈折率は、オブジェクトを通過する光の出射角を決定する。ｎ_１ｓｉｎθ_１＝ｎ_２ｓｉｎθ_２というスネルの法則を使用することができるが、ただし、ｎ_１およびｎ_２は、媒体１および２の屈折率、θ_１およびθ_２は、それぞれ、サーフェス法線に対する光の入射角と出射角である。したがって、媒体１が割り当てられた屈折率が１．０（屈折なし）のデスクトップ環境を表し、媒体２がウィンドウ基本オブジェクトの媒体であれば、屈折角はθ_ｏｂｊ＝ｓｉｎ^−１（ｓｉｎθ_ｅｎｖ／ｎ_ｏｂｊ）で求められる。シミュレートできるさまざまな媒体の知られている屈折率を以下の表１に示す。

屈折角が決定され／計算されると、これを使用して、他のマテリアルプロパティに関連するさらなる処理に続いてオブジェクトの可視サーフェス上に描画する適切なピクセルを背景から選択することができる。屈折のリアルタイムの描画を目的とする最適化では、フレネルの方法、つまり当業者に周知の方法を組み込むことができる。

ビジュアルスタイル（テーマ）を使用して、ＣＤＷＭのビジュアルおよび挙動ポリシーを定義することができる。ビジュアルスタイルとは、一般に、共通のユーザインターフェース要素に適用される手書きでデザインした精密なグラフィックスおよび挙動属性を指定するユーザ選択可能なテーマを指す。アプリケーションのオプションによりこれらの属性の一部をオーバーライドすることができるが、他の属性は、ユーザインターフェースの整合性のためにシステムにより選択的に強制される。ビジュアル属性は、フレーム領域（基本コンテンツ）、非クライアントボタン、およびその他のアプリケーション独立の要素などの共通ウィンドウコンテンツの外観を含む。挙動属性は、ウィンドウおよびデスクトップ遷移アニメーションを含み、このとき、ウィンドウは、マウス（例えば、素早く動く（ｓｎａｐ）、接着して伸ばす（ｇｌｕｅ ａｎｄ ｓｔｒｅｔｃｈ）、および制約（ｃｏｎｓｔｒａｉｎｔ））、およびその他のアプリケーション独立の挙動で対話的に移動またはサイズ変更される。ビジュアルおよび挙動ポリシーは、そのポリシーをソフトウェア描画パイプライン全体に分散させるのではなく、ＣＤＷＭ内に一括して配置することができるため、エンドユーザのエクスペリエンスがより整合性のあるものとなり、開発環境が簡素化される。

本発明の例示されている一実施形態によれば、ビジュアルスタイルの既定の（またはカスタムの）テクスチャは、各ピクセルが修正されたものに基づくアルファレベルおよび／またはビットマップを含むことができる。例えば、当技術分野で知られているように、アルファレベルを使用して透明度レベルを修正することができる。さらに、テクスチャは、クライアントおよび／または非クライアント領域、あるいはクライアントおよび／または非クライアント領域の一部のピクセルシェーディングに使用するビットマップを含むことができる。例えば、例示されている一実施形態では、このビットマップは、すりガラスの外観を与えることができる。図５は、すりガラスフレーム５０３で描画されたウィンドウ５０１を例示しており、ウィンドウフレーム５０３の背後のコンテンツからどのピクセルを表示するべきかを決定する際にガラスをシミュレートするため屈折率を指定することができる。グラフィックス描画エンジンの高度なテクスチャ機能、照明、および３Ｄ機能を活用し、適切なビットマップを使用することにより、ＣＤＷＭは、３Ｄデスクトップ環境内のオプション指定された仮想光源からの光を反射するが、クライアントコンテンツが見えにくくならないように不透明のクライアントコンテンツ領域を有する、すりガラスの外観を有するフレーム５０３でウィンドウ５０１を合成することができる。

デスクトップ描画モデル（無効化対合成（ｉｎｖａｌｉｄａｔｉｏｎ ｖｅｒｓｕｓ ｃｏｍｐｏｓｉｔｉｎｇ））は、それぞれ、アプリケーションプログラムのウィンドウがデスクトップ上に適切に保持されるようにアプリケーションプログラムと対話するための固有のスキーマを持つ。例えば、無効化モデルでは、デスクトップ描画は、ウィンドウの「クリッピング領域」の管理および連続更新に依存する。クリッピングは、描画をウィンドウの該当する領域に制限するプロセスである。一方のウィンドウが他方のウィンドウで一部隠されると、クリッピング領域はその隠された領域の反転に対応する。下にあるウィンドウでそのコンテンツが描画される場合、描画メッセージに対する応答であろうと、要求に基づかない方法であろうと、無効化モデルＤＷＭでは、そのクリッピング領域が出力に適用され、描画が上に載るウィンドウ内で必ず発生しないようにする。上に載るウィンドウが移動した場合、または下にあるウィンドウがＺオーダの最上位に来た場合、下にあるウィンドウのクリッピング領域は、それに応じてＤＷＭにより調整された後、描画メッセージをウィンドウに送り、新しく公開されたコンテンツを更新する。

そのため無効化モデルＤＷＭおよび合成モデルＤＷＭは、デスクトップの描画のために異なる情報に依存する。例えば、無効化モデルでは、ＤＷＭはそれぞれのウィンドウのサーフェス全体のコピーをデスクトップ上に格納しないため、ＤＷＭはサイズ変更および再描画の間コンテンツをリフレッシュするためにアプリケーションと通信しなければならない。同様に、アプリケーションでは、ＤＷＭによりそうするよう要求されない限りそのコンテンツをリフレッシュする必要がないことを当てにしている（もちろん、コンテンツがユーザ入力の結果として更新されない場合）。アプリケーションが自コンテンツを独立して更新する必要がある場合、アプリケーションは自ウィンドウの一部を無効化するようＤＷＭに依頼し、ＤＷＭから無効領域に対応する描画要求を受け取ることを当てにしている。合成デスクトップの場合、各ウィンドウを全部描画するのに十分な情報が、ＣＤＷＭにより保持されるため、ＣＤＷＭは、上述のようなイベントについてウィンドウ描画メッセージを送信する必要はない。言い換えると、このことは、無効化ステップを未然に防ぎ、つまり、アプリケーションは、単に内部イベントの指示通りにそれ自身の全部または一部を再描画するだけでよい。

これらの基本的な相違点のため、それぞれのＤＷＭおよび／またはＣＤＷＭは固有のＡＰＩセットを有し、これにより、アプリケーションプログラムは、ウィンドウコンテンツが必ず最新に維持されるようにするためにＤＷＭと通信することを期待される。結果として、無効化モデルＤＷＭとともに使用するように元々プログラムされているアプリケーション、つまり、そのコンテンツを描画する描画メッセージに依存するアプリケーションは、必ずしも、合成モデルＣＤＷＭと連携しない。そこで、図４を参照すると、ＣＤＷＭは、無効化モデルＤＷＭで使用するために最初に開発されたアプリケーションをサポートすることができる。これらのアプリケーションは、本明細書ではレガシアプリケーションと呼び、後方互換性サポートは、本明細書ではレガシサポートと呼ぶことができる。レガシＡＰＩは、レガシアプリケーションとの互換性を持つ無効化モデルＤＷＭを使用したオペレーティングシステムの旧バージョンとともに使用するためのＡＰＩを指す。レガシＡＰＩ １９２ｂ（図１Ｂ）では、アプリケーションは無効化モデルＤＷＭ（レガシＤＷＭ）１９２ａと通信することができる。レガシＤＷＭでは、別々のレガシＡＰＩ要素を使用して、アプリケーションの代わりにＣＤＷＭへのさまざまなレガシ通知を処理し、関連する状態情報をＣＤＷＭに転送し、入力およびフォーカスの決定についてレガシ座標空間とＣＤＷＭ座標空間との間の変換を行うことができる。レガシＤＷＭは、後述のように、ＣＤＷＭにデータをリダイレクトするように修正することができる。

図４は、本発明の例示されている一態様によるウィンドウ合成方法の一部を示す図である。ステップ４０１〜４０９は、ソース描画サーフェス（またはサーフェスを生成するために要求される命令があれば集合（ｓｅｔ））が、レガシウィンドウマネージャ１９２ａから取得されるレガシアプリケーションウィンドウと関連付けられたコンテンツの初期描画を表している（図１Ｂ）。ステップ４１１〜４１９は、合成を意識したアプリケーションプログラムにより作成されたウィンドウコンテンツの描画を例示している。

ステップ４０１において、アプリケーションがそれのために設計された無効化モデルに従って、レガシアプリケーションがレガシＡＰＩ１９２ｂを呼び出してデスクトップ上にウィンドウ描画した結果として、ＣＤＷＭは、レガシウィンドウマネージャから１次ウィンドウコンテンツの初期更新通知を受け取る。例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｏｒｄ（登録商標）ＸＰは、レガシＡＰＩを呼び出し、その結果レガシＤＷＭ１９２ａが、ユーザにより入力されたテキストを描画することができる。ステップ４０３で、ＣＤＷＭは、テーママネージャからコンテンツの既定のメッシュを取り出す。ステップ４０５で、ＣＤＷＭは、レガシウィンドウマネージャからリダイレクトサーフェスを取り出す（または生成する）。このサーフェスは、コンテンツの拡散テクスチャとして使用することができる。ステップ４０７で、ＣＤＷＭは、レガシテクスチャの所望の領域のみが保持され、レガシウィンドウフレーム、枠、および／またはキャプションを含む領域が描画されないようにする。これを都合よく実行する方法として、所望の領域のみがメッシュのｘおよびｙ境界エクステントにマッピングされるように、メッシュのテクスチャマッピング座標を変換することによる方法がある。ステップ４０９で、ＣＷＤＭは、コンテンツに対する既定のマテリアルプロパティを取り出す。レガシコンテンツを描画するために必要なリソースおよびパラメータはすでに集められている。

ステップ４１１で、ＣＤＷＭは、ウィンドウに関連付けられたコンテンツオブジェクトの描画を必要とするアプリケーションプログラムから情報を受け取る。コンテンツには、オプションにより、カスタムメッシュ、カスタムテクスチャ、および／またはカスタムマテリアルプロパティが随伴する。カスタムメッシュは、アプリケーションプログラム側で既存のコンテンツオブジェクトに対し非標準形状であるのが望ましいとしている場合だけ、提供することができる。注目しているコンテンツオブジェクトがウィンドウ基本コンテンツの場合、カスタムメッシュは、ウィンドウの形状を再定義する。カスタムテクスチャおよび／またはカスタムマテリアルプロパティは、アプリケーションプログラム側で非標準の外観（つまり、アクティブテーマにより指定されているもの以外）をシステム定義コンテンツオブジェクトに与えることを望ましいとしている場合だけ提供することができる。注目しているコンテンツオブジェクトがウィンドウ基本コンテンツの場合、カスタムテクスチャおよび／またはマテリアルプロパティは、その形状を修正せずにウィンドウの外観を再定義する。より一般的には、アプリケーションは、ゼロからコンテンツオブジェクトを作成し、そのメッシュ（一組の定義済みシステムメッシュから選択することができる）、テクスチャ、およびマテリアルプロパティ（一組の定義済みシステムマテリアルプロパティから選択することができる）を作成時に指定する。

ステップ４１３で、ＣＤＷＭは、カスタムコンテンツメッシュが指定されたかどうかを判別し、指定されていない場合、テーママネージャから既定のメッシュを取り出す（ステップ４０３）。ステップ４１５で、ＣＤＷＭは、カスタムテクスチャが指定されたかどうかを判別し、指定されていない場合、テーママネージャから既定のテクスチャを取り出す。ステップ４１７で、ＣＤＷＭは、カスタムマテリアルプロパティがアプリケーションにより指定されたかどうかを判別し、指定されていない場合、テーママネージャから既定の一組のマテリアルプロパティを取り出す。カスタムコンテンツを描画するために必要なリソースおよびパラメータはすでに集められている。

ステップ４１９で、ＣＤＷＭは、ＵＣＥプログラミングインターフェースを介して描画命令ブロックを組み立ててコンテンツを描画するが、その際に、適切なメッシュ、テクスチャ、およびマテリアルプロパティを参照する。描画命令ブロックは、ＵＣＥによる実行のためキューに入れられる。命令ブロックは、ターゲットデバイスの保留リフレッシュ間隔の期限切れ後に、ＵＣＥ描画モデルにより実行される。

ＣＤＷＭおよびレガシＤＷＭが組み込まれているオペレーティングシステムは、レガシサポートを提供することにより、本質的に無効化ＤＷＭ（レガシＤＷＭ １９２ａ）または合成ＤＷＭ（ＣＤＷＭ １９０）を使用してデスクトップを描画する機能を有する。つまり、レガシサポートを提供するため合成モデルのほかに無効化モデルＤＷＭがオペレーティングシステムによりサポートされるということである。したがって、デスクトップ合成に要求される、プロセッサに負担のかかる計算を効率よく実行するのに必要なビデオハードウェアをもたないシステム（例えば、ビデオメモリが少ない、または３Ｄアクセラレーションハードウェアを備えていないシステム）では、ＣＤＷＭおよび／またはオペレーティングシステム側で、合成描画モードを使用するのか、レガシ描画モードを使用するのかをユーザが選択できるようにする。この選択は、自動的にまたは手動で行うことができる。例えば、ユーザによって選択されたアクティブ化されたビジュアルスタイル（テーマ）により定義された描画モードに従って、マニュアルユーザコントロールを介して選択することができる。この選択は、それと別に、またはそれに加えて、節電条件に基づくようにもできる。例えば、携帯型装置がＡＣ電源から切り離され、電池に切り替えられた場合、ビデオグラフィックス処理装置（ＧＰＵ）の活動状態が低く、消費電力が小さいため、オペレーティングシステムはレガシ描画モードを強制することができる。

上述の方法およびシステムを使用することにより、オペレーティングシステムは、高度な３Ｄグラフィックス機能を使用する物理的にモデル化されたグラフィカルユーザインターフェースを実現することができる。ウィンドウフレームは、少なくともある程度の透明性とその透明性の結果として見えるコンテンツの少なくともある程度のひずみを併せ持つシミュレートされたサーフェス外観を与えるすりガラスまたは他の何らかの複雑なマテリアルの外観だけでなく、その特性も獲得することができる。つまり、本発明では、ウィンドウフレームまたは枠をすりガラスのように見せるだけでなく、ＧＵＩ環境でコンテンツを反映し、仮想光源を示すスペクトルハイライトを含み、「すりガラス」の枠の背後のコンテンツがそれに応じて少し補正され、ビットマップが１つまたは複数のピクセルシェーダを介して適用され下にあるコンテンツの歪みをもたらすようにガラスに似た屈折率をシミュレートするという点ですりガラスに似た挙動をウィンドウフレームがする。

すりガラスまたは他のガラスに似た物理的にモデル化されたオブジェクトは、グラフィカルユーザインターフェースのユーザに多くの利点を提供する。例えば、ガラスの審美的外観は、ＧＵＩを強化し、ユーザに明るいオープンな感じを与えることによりエンドユーザにとって本発明のＧＵＩが他のオペレーティングシステムのＧＵＩよりも望ましいものとなるリッチなユーザエクスペリエンスを提供する。それと同時に、ガラスの真の特性またはそれに近い特性を持つ物理的にモデル化されたすりガラスは、機能的な利点も持つ。

すりガラスの外観を持たせると、マルチウィンドウ環境でユーザがウィンドウのレイヤの順序を理解するのに役立つ。シェーディング、反射、および鏡面ハイライトは、デスクトップ上の深さとレイヤのより強い感覚を引き起し、ユーザがデスクトップ上のさまざまなウィンドウのＺオーダを判別することを助ける。いくつかの知られているシステムでは、一様な透明性をウィンドウ全体に適用しているが、これだとユーザは注目しているウィンドウ内にどのようなコンテンツがあるのか、ウィンドウの背後にどのようなコンテンツがあるのかを容易に認識できないであろう。この一様なピクセル毎の透明性をＺオーダの関数として変化させることにより、問題を改善することが可能であるが、その方法は不自然であり直感的ではない。むしろ、本発明では、それぞれのデスティネーションピクセルを生成する過程で複数の囲んでいるソースピクセルをサンプリングする調節可能なぼかしアルゴリズムをピクセルシェーダに組み込み、このシェーダをウィンドウフレームを描画するプロセスで実行することにより、現実世界のすりガラスの材質の欠陥から生じる光散乱挙動をモデル化する。ユーザが背景と前景のコンテンツとを瞬時に区別できるようにするのは、背景のこの物理的にモデル化された歪みである。また、この効果は累積的なので、重なり合うすりガラスウィンドウフレームは、前景から背景へと徐々に歪んでゆく。したがって、ユーザはすりガラスウィンドウフレームの複数のレイヤの下にある背景コンテンツを直感的に区別することができる。

すりガラスは、より太い枠線を使用して、例えば、ユーザがウィンドウの移動またはサイズ変更を行うためにウィンドウの枠をマウスで掴み、しかも、（ガラスは透明または半透明であるため）ウィンドウの下にあるコンテンツを遮らないことを容易にすることにより、ＧＵＩを用いたユーザの対話操作を容易にする。さまざまなすりガラス効果を利用することにより、アクティブなウィンドウ状態と非アクティブなウィンドウ状態とをユーザが簡単に区別するようにできる。さらに、すりガラスにより、ユーザはいつでもより広い画面領域を見ることができ（すりガラスは半透明または透明なので）、デスクトップはガラスが表示画面上で邪魔にならない要素なのであまり散らかっているようには見えないため、ユーザは容易に画面上のコンテンツを読み、かつ／または見ることができる。

当業者であれば、図はすりガラスの特定の例を示しているが、本発明はそれらに限られないことは理解されるであろう。すりガラスの外観は、異なるビットマップおよび／または異なるピクセルシェーダを外観の描画に適用することにより容易に変えることができる。さらに、異なる環境変数を適用する（例えば、反射および鏡面ハイライトに影響を及ぼす、光源を別のものにする）か、またはガラスの仮想物理特性（例えば、屈折率、反射率など）を変えて、すりガラスの外観にも影響を及ぼす。本発明は、他のテクスチャおよび複合物、例えば、金属、プラスチック、紙、コットン、ならびにその他の天然および合成材料をシミュレートすることにも使用できることは理解されるであろう。

本発明は、本発明を実施するこの好ましい方法を含む特定の実施例に関して説明してきたが、当業者であれば、上述のシステムおよび技術のさまざまな変更形態および置換があることを理解されよう。そこで、本発明の精神および範囲は、添付の特許請求の範囲で規定されているとおり広い意味で解釈すべきである。

本発明の例示的な実施形態の１つまたは複数の態様に使用できる動作環境を示す図である。 合成デスクトッププラットフォームの例示的な実施形態におけるコンポーネント間の機能およびサービスの分配を示す図である。 本発明の例示的な態様による合成方法を示す図である。 本発明の例示的な態様によるウィンドウを示す図である。 本発明の例示的な態様によるウィンドウ合成方法の一部を示す図である。 本発明の例示的な態様により描画されるすりガラスフレーム付きのウィンドウを示す図である。 動的なウィンドウ構造をもつウィンドウを示す図である。 メッシュのサイズ変更の間に使用される領域を示す図である。

符号の説明

１２０ 処理装置
１２１ システムバス
１３０ システムメモリ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ その他のプログラムジュール
１３７ プログラムデータ
１４０ 固定の、不揮発性メモリインターフェース
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ その他のプログラムモジュール
１４７ プログラムデータ
１５０ 取り外し可能の、不揮発性メモリインターフェース
１６０ ユーザ入力インターフェース
１７０ ネットワークインターフェース
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ ワイドエリアネットワーク
１８０ リモートコンピュータ
１８２ リモートアプリケーションプログラム
１８３ ビデオアダプタ
１８４ モニタ
１８５ デジタイザ
１８７ 出力周辺インターフェース
１８８ プリンタ
１８９ スピーカ
１９０ 合成デスクトップウィンドウマネージャ
１９０ａ アプリケーションプログラミングインターフェース
１９０ｂ サブシステムプログラミングインターフェース
１９０ｃ ＵＩオブジェクトマネージャ
１９１ アプリケーションソフトウェア
１９２ レガシグラフィカルユーザインターフェースサブシステム
１９２ａ レガシウィンドウマネージャ
１９２ｂ レガシグラフィックスデバイスインターフェース
１９３ テーママネージャ
１９４ ユニバーサル合成エンジン（ＵＣＥ）
１９４ａ プログラミングインターフェース
１９４ｂ リソースマネージャ
１９４ｃ 要求キュー
１９４ｄ 描画モジュール
１９５ ３Ｄグラフィックスインターフェース（Ｄｉｒｅｃｔ３Ｄ、ＯｐｅｎＧＬなど）
１９６ ビデオドライバデバイスオブジェクト
１９７ 表示装置

Claims (34)

1. 表示装置に表示されるデスクトップ表現を描画するためのウィンドウを定義するデータ構造を格納するコンピュータ読み取り可能な媒体であって、
   前記ウィンドウの基本コンテンツオブジェクトの基本コンテンツオブジェクトプロパティを格納する第１のデータフィールドと、
   複数の個別の１次コンテンツオブジェクトのコンテンツオブジェクトプロパティを格納する第２のデータフィールドとを備えることを特徴とするコンピュータ読み取り可能な媒体。
2. 前記第１のデータフィールドは、基本ジオメトリを含む基本オブジェクトプロパティを格納するように細分されることを特徴とする請求項１に記載のコンピュータ読み取り可能な媒体。
3. 前記第１のデータフィールドは、基本コンテンツマージン、基本エクステント、および基本マテリアルを含む基本オブジェクトプロパティを格納するように細分されることを特徴とする請求項１に記載のコンピュータ読み取り可能な媒体。
4. 前記第１のデータフィールドは、さらに、メッシュを定義する複数の頂点を含む基本ジオメトリプロパティを格納するように細分されることを特徴とする請求項２に記載のコンピュータ読み取り可能な媒体。
5. 前記第１のデータフィールドは、さらに、環境色、拡散色、および鏡面色を含む基本マテリアルプロパティを格納するように細分されることを特徴とする請求項３に記載のコンピュータ読み取り可能な媒体。
6. 前記環境色、拡散色、および鏡面色はそれぞれＡＲＧＢ値として定義されることを特徴とする請求項５に記載のコンピュータ読み取り可能な媒体。
7. 前記第１のデータフィールドは、さらに、反射スカラおよび屈折率を含む基本マテリアルプロパティを格納するように細分されることを特徴とする請求項３に記載のコンピュータ読み取り可能な媒体。
8. 前記第１のデータフィールドは、さらに、拡散テクスチャおよびバンプテクスチャを含む基本マテリアルプロパティを格納するように細分されることを特徴とする請求項３に記載のコンピュータ読み取り可能な媒体。
9. 前記第２のデータフィールドは、さらに、それぞれの１次コンテンツオブジェクトに対するコンテンツジオメトリおよびコンテンツサーフェスを格納するように細分されることを特徴とする請求項１に記載のコンピュータ読み取り可能な媒体。
10. 前記第２のデータフィールドは、さらに、それぞれの１次コンテンツオブジェクトに対するＡＲＧＢテクスチャを含むコンテンツサーフェスプロパティを格納するように細分されることを特徴とする請求項９に記載のコンピュータ読み取り可能な媒体。
11. プロパティが格納される複数のウィンドウについて、基本オブジェクトのプロパティおよび１つまたは複数の１次コンテンツオブジェクトのプロパティを含むウィンドウプロパティを格納するメモリと、
    プロパティが格納される各ウィンドウのウィンドウプロパティに基づいてデスクトップを構成する合成デスクトップウィンドウマネージャのソフトウェアモジュールとを備え、
    プロパティが格納される前記複数のウィンドウのうちの１つについて、前記メモリは複数の１次コンテンツオブジェクトを格納することを特徴とするデータ処理システム。
12. 前記基本オブジェクトの前記プロパティは、基本ジオメトリを含むことを特徴とする請求項１１に記載のデータ処理システム。
13. 前記基本オブジェクトの前記プロパティは、基本コンテンツマージン、基本エクステント、および基本マテリアルを含むことを特徴とする請求項１１に記載のデータ処理システム。
14. 前記基本ジオメトリプロパティは、メッシュを定義する複数の頂点を含むことを特徴とする請求項１２に記載のデータ処理システム。
15. 前記基本マテリアルプロパティは、環境色、拡散色、および鏡面色を含むことを特徴とする請求項１３に記載のデータ処理システム。
16. 前記環境色、拡散色、および鏡面色はそれぞれ、少なくともＡＲＧＢ値により定義されることを特徴とする請求項１５に記載のデータ処理システム。
17. 前記基本マテリアルプロパティは、反射スカラおよび屈折率を含むことを特徴とする請求項１３に記載のデータ処理システム。
18. 前記基本マテリアルプロパティは、拡散テクスチャおよびバンプテクスチャを含むことを特徴とする請求項１３に記載のデータ処理システム。
19. 前記メモリは、少なくとも１つの１次コンテンツオブジェクトについて、コンテンツジオメトリおよびコンテンツサーフェスを格納することを特徴とする請求項１１に記載のデータ処理システム。
20. 前記コンテンツサーフェスは、ＡＲＧＢテクスチャを含むことを特徴とする請求項１９に記載のデータ処理システム。
21. オペレーティングシステムのシェルのグラフィカルユーザインターフェースでウィンドウを表示するためのコンピュータによって実施される方法であって、
    アプリケーションプログラムのインスタンスからウィンドウ情報を受け取ることと、
    基本オブジェクトおよび複数の個別の１次コンテンツオブジェクトを有するウィンドウを描画することとを備えることを特徴とする方法。
22. 描画することは、基本コンテンツマージン、基本エクステント、および基本マテリアルに基づくことを特徴とする請求項２１に記載の方法。
23. 描画することは、メッシュにより定義された基本ジオメトリに基づくことを特徴とする請求項２１に記載の方法。
24. 描画することは、環境色、拡散色、および鏡面色を含む基本マテリアルプロパティに基づくことを特徴とする請求項２２に記載の方法。
25. 前記環境色、拡散色、および鏡面色はそれぞれ、ＡＲＧＢ値として定義されることを特徴とする請求項２４に記載の方法。
26. 描画することは、反射スカラおよび屈折率を含む基本マテリアルプロパティに基づくことを特徴とする請求項２２に記載の方法。
27. 描画することは、拡散テクスチャおよびバンプテクスチャを含む基本マテリアルプロパティに基づくことを特徴とする請求項２１に記載の方法。
28. 描画することは、それぞれの１次コンテンツオブジェクトのコンテンツジオメトリおよびコンテンツサーフェスに基づくことを特徴とする請求項２１に記載の方法。
29. 描画することは、それぞれの１次コンテンツオブジェクトに対するＡＲＧＢテクスチャを含むコンテンツサーフェスプロパティに基づくことを特徴とする請求項２８に記載の方法。
30. 前記ウィンドウのサイズを変更するユーザ入力を受け取ることと、
    前記メッシュをメッシュ次元毎に３つの領域に分割することと、
    領域毎に、前記領域を前記ウィンドウの境界ボックスで囲む任意の次元のメッシュの頂点のオフセットを保持し、前記領域を前記ウィンドウの前記境界ボックスで囲まない任意の次元のメッシュの頂点を拡大縮小することとをさらに備えることを特徴とする請求項２３に記載の方法。
31. ２つの１次コンテンツオブジェクトを有する、一部メッシュにより定義されるウィンドウのサイズ変更を行うための方法であって、
    前記メッシュをメッシュ次元毎に３つの領域に分割することと、
    領域毎に、前記領域を前記ウィンドウの境界ボックスで囲む任意の次元のメッシュの頂点のオフセットを保持し、前記領域を前記ウィンドウの前記境界ボックスで囲まない任意の次元のメッシュの頂点を拡大縮小することとを含むことを特徴とする方法。
32. 前記領域は、等しいサイズであることを特徴とする請求項３１に記載の方法。
33. 前記領域は、等しいサイズでないことを特徴とする請求項３１に記載の方法。
34. 前記境界ボックスによって囲まれる前記領域は、拡大縮小すべきでないマテリアルを包含するのに必要なだけ小さいことを特徴とする請求項３３に記載の方法。
    

Images