JP2015528145A - 仮想サーフェス割り当て - Google Patents

Abstract

仮想サーフェス技術について説明する。このような技術は、アップデートの初期化及びバッチングのサポート、アップデート及びルック・アサイド・リストの使用、ガターの使用、ブレンディング操作及びＢＬＴ操作、プッシュ・ダウン等のサーフェス最適化技術、並びに、列挙及びクランピング、メッシュ使用、及びオクルージョン管理技術を含む。

Description

多様なコンピューティング・デバイス構成が増加し続けている。従来のデスクトップ・パーソナル・コンピュータから携帯電話、ゲーム・コンソール、セットトップ・ボックス、タブレット・コンピュータ等に至るまで、これらの構成の各々から利用可能な機能は大いに変わり得る。

結果として、１つの構成向けに開発された従来のディスプレイ技術は、別の構成に対してあまり適していない場合がある。例えば、かなりのメモリ・リソースを有するデバイス向けに以前に利用されていたディスプレイ技術は、より少ないリソースしか有さないデバイスにとっては適していない場合がある。

仮想サーフェス（virtual surface）技術について説明する。このような技術は、アップデートの初期化及びバッチング（batching）のサポート、アップデート及びルック・アサイド・リスト（look aside list）の使用、ガター（gutter）の使用、ブレンディング（blending）操作及びＢＬＴ操作、プッシュ・ダウン（push down）等のサーフェス最適化技術、並びに、列挙（enumeration）及びクランピング（clumping）、メッシュ使用、及びオクルージョン管理技術（occlusion management technique）を含む。

この概要は、詳細な説明において以下でさらに説明されるコンセプトのうち選択したものを簡略化した形で紹介するために提供される。この概要は、特許請求される主題の主要な特徴又は必要不可欠な特徴を特定することを意図するものではないし、特許請求される主題の範囲を決定する際の助けとして使用されることを意図するものでもない。

添付の図面を参照して、詳細な説明が記載される。図面において、参照番号の一番左の数字は、その参照番号が最初に現れる図を特定する。説明中及び図面中の異なる例における同一の参照番号の使用は、類似の項目又は同一の項目を示し得る。
本明細書で説明する仮想サーフェス技術を実行するために動作可能な例示的な実装における環境の図。 仮想サーフェスがリサイズされる例示的な実装を示す図。 アプリケーションと仮想サーフェスの論理サーフェスとの間のインタラクションが示されている例示的な実装を示す図。 図１のコンポジション・システムをより詳細に示す例示的な実装を示す図。 仮想サーフェスを開始するコンポジション・システムの動作の例示的な実装を示す図。 アップデートのための、コンポジション・システムによるサーフェスの準備を示す例示的な実装を示す図。 図６のルック・アサイド・リストを用いたコンポジション・システムの動作の例示的な実装を示す図。 ガターを使用するコンポジション・システムの動作を示す例示的な実装を示す図。 コンポジション・システムによる有効な領域の管理を示す例示的な実装を示す図。 プッシュ・ダウン技術を用いてサーフェスを結合するコンポジション・システムの動作を示す例示的な実装を示す図。 有効な領域を新たなサーフェスに結合するコンポジション・システムの動作を示す例示的な実装を示す図。 メッシュを使用するコンポジション・システムの動作を示す例示的な実装を示す図。 オクルージョンに関するコンポジション・システムの動作を示す例示的な実装を示す図。 データをレンダリングするためにサーフェスにサイズが割り当てられる例示的な実装における手順を示すフロー図。 有効な領域がコンポジション・システムによりトラッキングされる例示的な実装における手順を示すフロー図。 サーフェスを管理するためにルック・アサイド・リストが使用される例示的な実装における手順を示すフロー図。 オクルージョンに基づいてサーフェスがリサイズされる例示的な実装における手順を示すフロー図。 １つのサーフェスから別のサーフェスへの有効な領域のプッシュ・ダウンを伴うコンパクション技術が説明される例示的な実装における手順を示すフロー図。 有効な領域を新たなサーフェスに結合することを伴うコンパクション技術が説明される例示的な実装における手順を示すフロー図。 ドライバへの呼び出しを行ってメッシュを用いてサーフェスをレンダリングするために、コンポジション・システムがメッシュを使用する例示的な実装における手順を示すフロー図。 本明細書で説明する技術の実施形態を実装するために、図１〜図２０を参照して説明される任意のタイプのコンピューティング・デバイスとして実装することができる例示的なデバイスの様々なコンポーネントを含む例示的なシステムを示す図。

概要
仮想サーフェスを使用して、ビジュアル（visual）をレンダリングするためにサーフェスを割り当てて管理することができる。例えば、仮想サーフェスを使用して、ビジュアルをレンダリングするためにハードウェアにより割り当てられ得るメモリよりも大きなウェブ・ページのレンダリングを管理する、大きなウェブ・ページや没入型アプリケーション（immersive application）を管理する等、ハードウェアの制限を克服することができる。

仮想サーフェス・コンポジション及びアップデート技術が、本明細書において説明される。１以上の実装において、レンダリングのためにサーフェスを管理する技術が説明される。これは、図４及び図５に関連してさらに説明されるアップデートの初期化及びバッチングをサポートする技術、図６及び図７に関連して説明されるアップデート及びルック・アサイド・リストの使用、図８に関連して説明されるガターの使用、図９に関連して説明されるブレンディング操作及びＢＬＴ操作、図１０に関連して説明されるプッシュ・ダウン等のサーフェス最適化技術、並びに、図１１に関連して説明される列挙及びクランピング、図１２に関連して説明されるメッシュ使用、及び図１３に関連して説明されるオクルージョン管理技術を含む。

以下の記載において、本明細書で説明する仮想サーフェス技術を実行するために動作可能な例示的な環境が最初に説明される。次いで、例示的な環境及び他の環境において動作可能な例示的な手順が説明される。さらに、例示的な環境は、例示的な手順のパフォーマンスに限定されるものではない。

例示的な環境
図１は、１以上の実施形態に従った動作環境を一般に１００で示している。環境１００は、１以上のプロセッサを含み得る処理システム１０４を有するコンピューティング・デバイス１０２、メモリ１０６として図示される例示的なコンピュータ読み取り可能な記憶媒体、オペレーティング・システム１０８、及び１以上のアプリケーション１１０を含む。コンピューティング・デバイス１０２は、限定ではなく例として、デスクトップ・コンピュータ、ポータブル・コンピュータ、携帯情報端末（ＰＤＡ）といったハンドヘルド・コンピュータ、携帯電話、タブレット・コンピュータ等の任意の適切なコンピューティング・デバイスとして具現化することができる。コンピューティング・デバイス１０２の異なる例が、図２１において示され以下で説明される。

コンピューティング・デバイス１０２は、処理システム１０４上で実行されるものとして示されメモリ１０６に記憶可能なオペレーティング・システム１０８を含む。コンピューティング・デバイス１０２は、メモリ１０６に記憶されるものとして示され処理システム１０４上で実行可能なアプリケーション１１０をさらに含む。オペレーティング・システム１０８は、アプリケーション１１０により使用される基本的なハードウェア・リソース及びソフトウェア・リソースを抽象化し得るコンピューティング・デバイス１０２の機能を表す。例えば、オペレーティング・システム１０８は、データがディスプレイ・デバイス１１２上にどのようにして表示されるかという機能を、この表示がどのようにして実現されるかをアプリケーション１１０が「知る」必要なく、抽象化し得る。コンピューティング・デバイス１０２の処理システム１０４及びメモリ１０６といったリソースやネットワーク・リソース等を抽象化するといった多様な他の例も意図されている。

コンピューティング・デバイス１０２はまた、コンポジション・システム１１４を含むものとして示されている。コンポジション・システム１１４は、オペレーティング・システム１０８の一部として示されているが、スタンドアロン・モジュールとして、別個のアプリケーションとして、コンピューティング・デバイス１０２自体のハードウェアの一部（例えば、ＳＯＣ又はＡＳＩＣ）として等、様々な形で実装されてよい。コンポジション・システム１１４は、ビジュアルをレンダリングするためにアプリケーション１１０により使用される１以上のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を介して機能を公開する等、ビジュアルをレンダリングするための多様な技術を使用することができる。

例えば、そのような１つの技術は、スワップ・チェーン（swap chain）と呼ばれるオブジェクトに基づくものであり、これは、ビットマップを表すバッファのアレイを利用することができる。例えば、そのバッファの１つを使用して、ディスプレイ・デバイス１１２上に一度にデータを表示することができ、したがって、そのバッファは、「オンスクリーン・バッファ」又は「フロント・バッファ」と呼ばれることがある。他のバッファも、オフスクリーンのラスタ化のためにアプリケーション１１０に利用可能となっており、したがって、他のバッファは、「オフスクリーン・バッファ」又は「バック・バッファ」と呼ばれることがある。

アプリケーション１１０は、様々な方法により、ディスプレイ・デバイス１１２上に表示されるものに変更を加えることができる。そのような最初の技術では、アプリケーション１１０は、ポインタを用いてオフスクリーン・バッファのうちの１つをオンスクリーン・バッファにしたりその逆を行ったりすること等により、バック・バッファのうちの１つを再描画して、内容を「フリップする（flip）」ことができる。

そのような第２の技術では、異なるサイズのバッファを利用することができる。例えば、コンポジション・システム１１４は、オンスクリーン・バッファとして、第１のバッファを利用することができる。コンポジション・システム１１４はまた、オフスクリーン・バッファとして、第１のバッファよりも小さな第２のバッファを利用することができる。したがって、コンテンツに対するアップデートがなされる場合、そのアップデートは、第２のバッファにラスタ化することができる。次いで、例えば、ｂｌｔを用いて、そのアップデートをオンスクリーン・バッファにコピーすることができる。このようにして、コンピューティング・デバイス１０２のリソースを節約することができる。

コンポジション・システム１１４はまた、仮想サーフェス技術をサポートするよう構成され得る。こうした技術を使用して、ビジュアルをレンダリングするために使用されるコンピューティング・デバイス１０２のリソースを低減させるために、アプリケーション１１０の開発者を支援することができる。これは、仮想サーフェス１１８の使用を含み得る。これにより、アプリケーション１１０が、ビジュアル・データのサーフェスをタイル（tile）に分割し、次いで、前もってそのタイルをレンダリングすることを可能にする。以下でさらに説明されるように、サーフェスを分割するためにタイルが使用されない（例えば、アプリケーション１１０がサイズを指定する）他の実装も意図されている。

仮想サーフェス１１８は、１以上の論理サーフェス１２０の集合として構成され得る。論理サーフェス１２０は、アプリケーション１１０により確認される個々のサーフェスを表し、１以上のビジュアルに関連付けることができる。例えば、論理サーフェス１２０は、固定サイズを有するタイルとして構成され得る。複数のタイルは、固定グリッド状に配列され得る。しかしながら、タイルが固定サイズで利用されない多様な他の例も意図されていることは明らかであろう。例えば、タイルのサイズは、ビジュアルをレンダリングしようとするアプリケーションにより指定することができ、したがって、この例におけるタイルのサイズは、アプリケーション自体により設定することができる。これは、以下の説明において、「チャンク（chunk）」とも呼ばれる。

仮想サーフェス１１８を使用して、テクスチャにより表される領域よりも大きな領域を表すことができる。例えば、アプリケーション１１０は、作成時に、仮想テクスチャのサイズを指定することができる。サイズは、仮想サーフェス１１８のための境界を定める。サーフェスは、１以上のビジュアルに関連付けることができる。１以上の実装において、仮想サーフェスが最初に初期化されるとき、仮想サーフェスは、実際の割り当てによりバックされない。すなわち、仮想サーフェス１１８は、初期化時に「ビットを保持せず」、例えば、割り当て時といった後の時点でビットを保持する。

以下の説明において、ビジュアルは、基本的コンポジション要素（basic composition element）を指すことがある。例えば、ビジュアルは、ビットマップと、コンポジション・システム１１４により処理するための関連コンポジショナル・メタデータとを含み得る。ビジュアルのビットマップは、（例えば、ビデオ等の動的コンテンツでは、）スワップ・チェーンに関連付けることができ、あるいは、（例えば、半動的コンテンツでは、）アトラス・サーフェス（atlas surface）に関連付けることができる。２つのプレゼンテーション・モデルが、コンポジション・システム１１４によりサポートされる単一のビジュアル・ツリーにおいて、サポートされ得る。

半動的コンテンツでは、アトラスは、ビジュアルのビットマップのための更新モデルとして機能することができ、集合的レイヤ（aggregate layer）を指し得る。集合的レイヤは、レンダリングされる複数のレイヤを含み得るが、単一のレイヤも意図されている。ビジュアル及びそのプロパティ操作（例えば、オフセット、トランスフォーム、エフェクト等）、並びにビジュアルのアトラスベースのビットマップを更新するメソッド（Ｂｅｇｉｎ Ｄｒａｗ、Ｓｕｓｐｅｎｄ Ｄｒａｗ、Ｒｅｓｕｍｅ Ｄｒａｗ、Ｅｎｄ Ｄｒａｗ）が、アプリケーション・プログラミング・インタフェース１１６を介して公開されるのに対し、アトラス・レイヤ・サイズ、タイル・サイズ、ビットマップ・アップデートのパッキング（packing）／コンパクション／管理は、アプリケーション１１０から隠すことができる。

スワップ・チェーンは、ポインタを変える等により、オンスクリーンに次々に「フリップ」し得る一連のバッファを指す。したがって、フリップ・モードは、スワップ・チェーン技術を使用してオフスクリーン・バッファをオンスクリーン・バッファにするモードである。オフスクリーン・バッファは、例えば、オフスクリーン・バッファとオンスクリーン・バッファとの間のスワッピング・ポイントを使用することにより、オンスクリーン・バッファにされる。しかしながら、ｂｌｔモードは、コンポジション・システム１１４のランタイムが、オフスクリーン・バッファからオンスクリーン・バッファへの「ｂｌｔ」（例えば、ビット・ブロック画像転送）を発する技術を指し、これを使用して、オンスクリーン・バッファを更新することができる。

前述したように、１以上の実装において、仮想サーフェス１１８が最初に初期化されるとき、仮想サーフェス１１８は、実際の割り当てによりバックされない。すなわち、仮想サーフェス１１８は、「ビットを保持しない」。アプリケーション１１０がサーフェスを更新するのを始めると、コンポジション・システム１１４は、タイル（すなわち、コンポジション・サーフェス・オブジェクト）の割り当てを実行することができる。アプリケーション１１０は、それぞれの操作に対するｂｅｇｉｎ ｄｒａｗ、ｓｕｓｐｅｎｄ ｄｒａｗ、ｒｅｓｕｍｅ ｄｒａｗ、及びｅｎｄ ｄｒａｗといったＡＰＩコール等の多様な操作を介して、仮想サーフェス１１８を更新することができる。マッピングは、コンポジション・システム１１４の内部アルゴリズムにより決定することができ、１以上の実装において、アプリケーション１１０に対して可視的とはならない。

さらに、コンポジション・システム１１４は、アプリケーション１１０が仮想サーフェス１１８をリサイズしてトリムすることを可能にするＡＰＩを介して、機能を公開し得る。例えば、リサイズ操作を使用して、仮想サーフェス１１８の境界を変えることができる。これは、新たなアップデート及び／又は割り当てが新たなサイズにより設定される境界内に含まれることを意味する。アプリケーション１１０はまた、コンポジション・システム１１４に、仮想サーフェス１１８の領域がもはや利用されておらず（例えば、有効でなく）、したがって、再利用することができることを通知するために、このメソッドを使用することができる。リサイズが領域の縮小をもたらす場合、アプリケーション１１０は、コンポジション・システム１１４による管理を介して、新たな境界の範囲外にある領域に対するアップデートをもはや行うことができない。

図２は、仮想サーフェスがリサイズされる例示的な実装２００を示している。図示された例において、第１の段階２０２及び第２の段階２０４を使用して、３×３の仮想サーフェスが２×２にリサイズされることを示す。第２の段階２０４におけるクロス・ハッチングを含む領域は、リサイズ操作の一部として破棄されるタイルを表す。前述したように、次いで、これらのタイルを記憶するために使用されるメモリ１０６は、コンポジション・システム１１４により、再利用することができる。リサイズの後、アプリケーション１１０は、再度仮想サーフェスをリサイズすることなく、破棄された領域（すなわち、クロス・ハッチングの領域）に対するアップデートをもはや行うことができない。

さらに、１以上の実装において、リサイズ操作は、操作のインジケーションの受信に応答して、コンポジション・システム１１４により開始することができる。例えば、コンポジション・システム１１４は、アプリケーションが「ｃｏｍｍｉｔ」を呼び出すのを待つことなく、インジケーションの受信時に、リサイズ・アップデートを実行することができる。例えば、アプリケーションは、「Ｒｅｓｉｚｅ（０，０）」、「Ｒｅｓｉｚｅ（ＩＮＴ＿ＭＡＸ，ＩＮＴ＿ＭＡＸ）」、及び「Ｃｏｍｍｉｔ（）」を呼び出すことができる。この例において、アプリケーション１１０は、第１のリサイズでコンテンツを破棄したので、第２のリサイズが、「Ｃｏｍｍｉｔ（）」の前に呼び出されたとしても、影響を与えない。このケースでは、表示のために何も利用可能でないので、ディスプレイ・デバイス１１２は、コンテンツを表示しない。

トリム操作を使用して、アプリケーション１１０によりリクエストされている仮想アトラスの領域をコンポジション・システム１１４に記述することができる。したがって、仮想サーフェス１１８の境界をリサイズすることなく、トリム操作を実行することができる。しかしながら、これは、どの論理サーフェスが現在割り当てられるのかをコンポジション・システム１１４に通知しない。論理サーフェスの例については、次の図に関連して説明する。

図３は、アプリケーションと仮想サーフェスの論理サーフェスとの間のインタラクションが示されている例示的な実装３００を示している。この例も、第１の段階３０２及び第２の段階３０４を使用することにより示されている。この例において、アプリケーションのビューポート（viewport）３０６が、第１の段階３０２及び第２の段階３０４の両方で示されている。したがって、第１の段階３０２において、アプリケーションは、ビューポート３０６に含まれる、（１５タイルを含む）仮想サーフェスの最初の６タイルをまずレンダリングする。これらのタイルがクロス・ハッチングにより示されている。

仮想サーフェスにより表されるページがスクロールされると、次に、アプリケーションは、第２の段階３０４に示されるように、最後の６タイルをレンダリングさせることができる。したがって、アプリケーション１１０は、最後の６タイルにより定められる領域が現在使用されており、このため、コンテンツの残りが現在使用されていないことを示すために、「ｔｒｉｍ」を呼び出すことができる。次いで、コンポジション・システム１１４は、元々最初の６タイルを表していた論理サーフェス５０６を再利用することを選択することができる。

コンポジション・システム１１４はまた、論理サーフェス（すなわち、物理サーフェス）及び仮想サーフェスを作成して削除するとともに、個々のサーフェスに対するアップデートを行うために、図１のＡＰＩ１１６を公開し得る。コンポジション・システム１１４は、更新可能な領域の範囲外に描画するときの無関係なビジュアルを避けるために、アプリケーション１１０により領域を更新させることができる。

初期化及びバッチング
図４は、図１のコンポジション・システム１１４をより詳細に示す例示的な実装４００を示している。今日のコンピューティングの世界において、ユーザは、しばしば、自分自身が大きなリッチ・コンテンツを閲覧し、その中をナビゲートしているのに気付くであろう。そのようなコンテンツの全体は、ディスプレイ・デバイスにより一度に表示されない。このような例は、複雑な動的ウェブ・ページ、写真のライブ・アイテム／グループの大きなリストを有する最新のアプリケーション・ビュー、音楽若しくは他のライブ・コンテンツ、又は大きなドキュメントを含む。

タッチ及び画像キャプチャベースの操作等のユーザ・インタフェースにより、ユーザは、スレート、電話、大型ＴＶ／プロジェクション等のユーザ・インタフェースの多数のディスプレイにわたり、迅速に、スクロール、パン、及びズームを行うことができる。多くのケースにおいて、コンテンツ全体を事前にレンダリングすること、及びコンテンツがアニメーション化し変化するときに最新の状態に保つことは、極めてコストがかかり、実際、デバイスのハードウェアによりサポートされないことさえあり得る。その代わりに、ユーザ操作によりコンテンツがビューポートに入る前に推測で先にコンテンツをレンダリングし、上述したように使用されたリソースを低減させるためにビューポートが動いたときにキャッシュからコンテンツを破棄する等、ビューポートに入ってくるコンテンツの一部をインテリジェントにレンダリングしキャッシュすることができる。

所望の応答性をユーザに提供するために、コンポジション及びレンダリングは、コンポジション・システム１１４により別個に実行することができる。これが、コンポジション・エンジン４０２、コントローラ４０４、及びレンダラ４０６をコンポジション・システム１１４に組み込むことにより示されている。１以上の実装において、コンポジション・システム１１４のこれらのコンポーネントは、非同期に実行され得る。このようにして、事前にレンダリングされたコンテンツは、ユーザ入力に応答するコントローラ４０４及びコンポジション・エンジン４０２により、パン／ズームを行うことができるのに対し、レンダラ４０６は、レンダリングを続ける。

前述したように、コンポジション・システム１１４は、１以上の仮想サーフェス１１８を使用することができる。仮想サーフェス１１８を使用することにより、すでにレンダリングされたコンテンツのキャッシング及びコンポジションが可能になる。レンダラ４０６による仮想サーフェス１１８上の領域のアップデート及びトリムは、推測的なレンダリング・ポリシに基づいて実行することができるのに対し、コントローラ４０４及びコンポジション・エンジン４０２は、仮想サーフェス１１８を変形するために使用される。この変形は、コンテンツをレンダリングしビューポート内に存在する仮想サーフェス１１８の領域に基づくユーザ・インタフェースに対するアップデートを生成するためのユーザ入力に基づいて実行することができる。コンポジション・エンジン４０２は、複数の仮想サーフェス１１８及び／又はビジュアルを一度に作成するよう構成され得る。

１以上の実装において、コンポジション・システム１１４は、コンポジションのためにフロント・バッファとして使用される固定サイズのタイル又は混合サイズのタイルとして、論理サーフェス１２０を使用するよう構成され得る。レンダラ４０６が、仮想サーフェス１１８の一部を更新することを望むとき、レンダラ４０６は、別個のアップデート・サーフェスにレンダリングすること、又は、タイル・サーフェスに直接レンダリングすることを実行することができる。別個のアップデート・サーフェスを用いる場合、描画を終えるときに、コンテンツが、アップデート・サーフェスからフロント・バッファにコピーされる。次いで、レンダラ４０６がタイルから有効なコンテンツをトリムするときに、タイルをリリースすることができる。

しかしながら、変化したコンテンツは、古いコンテンツを伴うスクリーン上に構成されるので、この実装は、構造的テアリング（structural tearing）をもたらす場合がある。さらに、タイル間又は仮想サーフェス上で更新される領域のチャンク間の継ぎ目が、ガター及びサンプリング（例えば、双線形）又はＴジャンクション（T-junction）のために、生成される場合があるとともに、ガター、複数のオーバラッピング・アップデート、及び複雑な有効領域を扱うために過度のＣＰＵ使用率及びＧＰＵ使用率を生じさせる場合がある。さらに、動的なコンテンツ変化又はユーザにより操作されるコンテンツのために、過度のメモリ使用率に直面する場合がある。タイル手法による固定／混合サイズのサーフェスでは、タイルの不使用部分のために、より大きなサイズのタイルほどメモリ浪費に直面し、より小さなタイルに対するレンダリング／処理アップデートと構成時におけるアップデートのレンダリングとのために、ＣＰＵ／ＧＰＵ浪費に直面し、別個のアップデート・バッファが使用される場合、アップデート・バッファからフロント・バッファへのＣＰＵ／ＧＰＵコピー・コストに直面し得る。したがって、コンポジション・システム１１４の実装において、多様な考慮事項の間でバランスが取られ得る。

これらの考慮事項は、ビューポートに収まらないリッチで且つ／又は動的なコンテンツを操作するときのユーザ・エクスペリエンス品質及びパフォーマンスに関する以下のテネット（tenet）のセットを含み得る。第１のそのようなテネットは、ビジュアル応答性（visual responsiveness）と呼ばれる。これは、仮想サーフェス１１８が、ユーザの「指の先端」及びユーザ操作において真のサーフェスのように感じるように構成され得ることを意味する。これは、知覚される遅延なく操作に応答しそのような操作をトラッキングするために、コンポジション・システム１１４の構成によりサポートされ得る。コントローラ４０４及びコンポジション・エンジン４０２と別々にレンダラ４０６を用いることで、堅牢な形でこのテネットをサポートすることができる。

第２のそのようなテネットは、ビジュアル統一性（visual coherence）に関する。この例において、サーフェスが操作され、サーフェス内の動的コンテンツ（例えば、アニメーション）が更新されるので、ディスプレイ・デバイス１１２上のコンテンツは、ユーザの熱中又は信頼を妨げるアーチファクトを示さない。例えば、継ぎ目、目に見えるテアリング、又は破損なく、コンテンツを表示することができる、ユーザ・インタフェースの一部が、付随すべき他の一部に後れを取ることがない、等である。

第３のテネットは、ビジュアル完全性（visual completeness）に関する。ユーザ・インタフェースが、視覚的に完全である場合、ユーザは、ディスプレイ・デバイス１１２の一部を覆うフィラー／プレースホルダ・パターン（例えば、チェッカーボード）をめったに見ない。そのようなパターンがある場合、このディスプレイは、比較的短い時間制限される。さらに、例えば、性能の低いデバイス上での複数のズーム・レベルにわたる終わりのないリッチ・コンテンツにおいて、保証されないかもしれないが、サーフェス・コンテンツ・アップデートは明らかに衰えない。例えば、レンダラ４０６が仮想サーフェス１１８を更新しコンポジション・エンジン４０２がそれを作成するのがより最適で効率的であるほど、追加的なビジュアル完全性を実現するために、レンダラ４０６は、先に推測でさらにレンダリングするためのより高い処理能力を有するようになる。

第４のテネットは、ライブ・サーフェスに関する。このテネットでは、アニメーション、ビデオ、及び他の動的コンテンツが、操作中休むことなく再生及び実行を続ける。レンダラ４０６がビジュアル完全性を実現しライブ・サーフェスを実現する処理能力を有する場合、これは実現され得る。これは、仮想サーフェス１１８の効率的な更新及び作成によりサポートされ得る。

コンポジション・システム１１４は、これらのテネットのバランスを取るよう構成され得る。このようにして、レンダラ４０６がビジュアル完全性及びライブ・サーフェスを確実にするための十分な処理能力を有するよう、仮想サーフェス・アップデートを管理して構成するためにビジュアル正確性（visual correctness）及びビジュアル統一性並びにビジュアル応答性をサポートする総合的な解決策が実行され得る。

図５は、仮想サーフェス１１８を開始するコンポジション・システム１１４の動作の例示的な実装５００を示している。この実装は、第１の段階５０２及び第２の段階５０４を使用することにより示されている。第１の段階５０２において、アプリケーション１１０は、ユーザ・インタフェースをレンダリングするために、サーフェスのサイズをリクエストする。これは、１以上のビジュアルに関連付けることができる。前述したように、仮想サーフェス１１８が、実際の割り当てによりバックされない、したがって、初期化時に「ビットを保持しない」ように、仮想サーフェス１１８が、まず初期化される（例えば、作成される）。

次いで、アプリケーション１１０は、レンダリングされるビジュアルを、仮想サーフェス１１８に指定することができる。したがって、コンポジション・エンジン４０２は、レンダラ４０６により仮想サーフェス１１８にレンダリングするために、図示される車等のこうしたビジュアルを構成することができる。これは、タイル、又は、割り当てのサイズがアプリケーションにより指定される「チャンク」を使用することにより実行され得る。

第２の段階５０４において、レンダラ４０６は、サーフェスの矩形領域等の仮想サーフェス１１８の領域を更新する命令を受信することができる。レンダラ４０６とコンポジション・エンジン４０２との間のインタフェースは、レンダラ４０６が、複数の仮想サーフェス１１８にわたる複数のアップデート５０６（例えば、トリム命令、ビジュアルに対する変更、ビジュアルの作成又は削除等）とともに、コンテンツとしてこうしたサーフェスを有することができるビジュアルに対するトランスフォーム・アップデートを実行できることである。アップデート５０６の例は、カーソルとして構成されるビジュアル、及びユーザが選択可能なボタンとして構成されるビジュアルを含む。

一実装において、複数のアップデート５０６がレンダラ４０６によりレンダリングされ得るよう、例えば、バッチとして更新され得るよう、「ｃｏｍｍｉｔ」操作が呼び出され得る。このようにして、コンポジション・システム１１４は、不完全なアップデートのレンダリングに対して保護することができる。これにより、レンダラ４０６は、ビジュアル統一性テネットによる、ディスプレイ・デバイス１１２により一貫した統一性のあるビジュアルを表示させることができる。

さらに、ユーザ入力を処理するコントローラ４０４は、レンダラ４０６を経ることなく、直接的にコンポジション・エンジン４０２に対して、ユーザ操作に基づいて、（例えば、パン又はズームのための）ビジュアルに対するトランスフォームを更新することができる。例えば、アニメーション又は動的コンテンツの他の状態変化を処理するために、且つ／又は、制限された処理リソースしか有さないシン・デバイス上で複雑なコンテンツをラスタ化するために、レンダラ４０６が比較的長い時間占められる場合であっても、この態様は、ビジュアル応答性を提供する。

仮想サーフェス１１８の実装は、レンダラ４０６がレンダリングすることができるサーフェス及びオフセットをレンダラ４０６に提供することを含む。次いで、コンポジション・エンジン４０２がピックアップし、レンダラ４０６に対してコミットされた完全なアップデートのバッチを処理しているときに、コンポジション・エンジン４０２によりこのサーフェスを「フリップする」ことができる。これを使用して、別のアップデート・サーフェスがレンダラ４０６によるアップデートのレンダリングのために使用された場合、そうでない場合に実行されるコピー操作を除外することができる。

また、このフリッピングにより、コンポジション・エンジン４０２が、（例えば、コミット操作を介した）単一のバッチにおいてレンダラ４０６により生成される複数のアップデートの各々が全体としてディスプレイ・デバイス１１２まで到達するのを確実にすることを可能にすることができる。したがって、コンポジション・システム１１４による部分的なアップデートの処理を回避することができる。

アップデート及びルック・アサイド・リスト
図６は、更新のための、コンポジション・システム１１４によるサーフェスの準備を示す例示的な実装６００を示している。コンポジション・システム１１４は、更新のためのサーフェスを準備するために、多種多様な技術を利用することができる。第１のケースでは、コンポジション・システム１１４は、アプリケーションからのアップデートを実行するために、領域を割り当てるリクエストを受信することができる。これが、図示された例において、第１の矩形６０２として示されている。

このリクエストに応答して、コンポジション・システム１１４は、リクエストされた領域よりも大きな領域を割り当てることができる。これが、リクエストされた第１の矩形６０２を含む第２の矩形６０４として示されている。したがって、わずかに異なるサイズのアップデートがその後に受信される場合、これにより、以前に割り当てられたサーフェスの再利用が可能となる。

例えば、コンポジション・システム１１４は、コンポジション・システム１１４により以前に割り当てられたサーフェス６０８のルック・アサイド・リスト６０６を保持することができる。これは、サーフェス６０８の再利用及びサーフェス６０８の「チャンク」のためにメモリを「蓄積する」ために、コンポジション・システム１１４により使用することができる。

例えば、これらのサーフェス６０８は、もはや使用されていないサーフェスのために、コンピューティング・デバイス１０２のメモリ１０６内に保持することができる。したがって、アップデートのためのサーフェスを提供する、コンポジション・システム１１４によるリクエストの受信時に、コンポジション・システム１１４は、そのリクエストに対応する以前に割り当てられたサーフェス６０８が、コンピューティング・デバイス１０２のメモリ１０６内で利用可能であるかを判定するために、ルック・アサイド・リスト６０６をまず調べることができる。利用可能なサーフェス６０８が存在する場合、コンポジション・システム１１４は、そのようなサーフェスを利用することができ、それにより、新たなサーフェスを割り当てないことで、システムの全体的な効率を向上させることができる。さらに、前述したように、リクエストされたよりも大きなサイズ（例えば、より多くのピクセルを有する）をサーフェスに割り当てることにより、こうしたサーフェス６０８がその後のアップデートに関連する可能性が増大し得る。

例えば、わずかに異なるサイズのアップデートが、ある時間期間の間受信される場合、これにより、例えば、次のアップデートがわずかに広い又は高い領域に対するものであるときには、以前に割り当てられたサーフェス６０８のより多くの再利用が可能となる。したがって、新たなサーフェスを割り当てることなく、コンポジション・システム１１４は、関連するサーフェスを見つけるために、以前に利用可能となったサーフェスのルック・アサイド・リスト６０６を利用することができる。サーフェスの一部のトリム及び他のアップデートも利用可能であることに留意すべきである。

これは、確認されたバッチ（confirmed batch）に基づく領域を通じてトラッキングされ得る。アップデートが、他の有効なコンテンツも有する既存のサーフェス６０８の利用可能な一部に収まる場合、そのサーフェスを再利用することができる。そのような各遷移（transition）はセットアップ・コストを招くので、これはまた、複数の異なるサーフェスからレンダリングすることを避けることにより、コンポジション側のコストを低減させる。ルック・アサイド・リスト６０６のサイズ（例えば、リスト及びコンピューティング・デバイス１０２のメモリ内に保持されるサーフェス６０８の数）は、過去のピーク使用又は多様な他のファクタに基づいて設定することができる。

図７は、図６のルック・アサイド・リスト６０６を用いたコンポジション・システム１１４の動作の例示的な実装７００を示している。この実装は、第１の段階７０２、第２の段階７０４、及び第３の段階７０６を用いて示されている。第１の段階７０２において、サーフェス７０８が、レンダラ４０６によるレンダリングのために割り当てられる。次いで、レンダラ４０６には、レンダリングを実行するために、サーフェス７０８の制御が与えられる。

このレンダリング中、アップデートを実行するために、第２の段階７０４において、別のサーフェス７１０を割り当てることができる。この例において、別のサーフェス７１０は、レンダラ４０６によりレンダリングされているサーフェス７０８と同一のディスプレイの領域内に含まれる。したがって、サーフェス７０８がレンダリングされている間に、サーフェス７１０を割り当てることができ、サーフェス７１０を満たす（例えば、描画する）ことができる。次いで、例えば、前述したコミット・コマンドに応答して、レンダリングのために、このサーフェス７１０をレンダラ４０６に渡すことができる。

第３の段階７０６において、ユーザ・インタフェースを更新するための別のアップデートが受信され得る。この例において、コンポジション・システム１１４は、図６のルック・アサイド・リスト６０６を使用することにより、アップデートが、以前に割り当てられたサーフェス、例えば、第１の段階７０２のサーフェス７０８を含むかを判定する。したがって、コンポジション・システム１１４は、アップデート７１２を含む、すでに割り当てられたサーフェス７０８を使用することができる。このようにして、新たなサーフェスを再割り当てすることなく、サーフェス７０８を使用することができ、それにより、コンピューティング・デバイス１０２のリソースを節約することができる。多様な他の例も意図されている。

ガター
図８は、ガターを使用するコンポジション・システム１１４の動作を示す例示的な実装８００を示している。ビジュアル正確性を維持する際の１つの問題点は、ガターを逃してしまうことに関する。例えば、スクロール等のため、仮想サーフェスが、サブピクセル・オフセットに配置又はスケーリングされ得る。したがって、ディスプレイ・デバイス１１２により表示されるピクセルの値は、例えば、双線形サンプリングを利用するために、隣接ピクセルに基づいて決定される。

しかしながら、アップデート８０２のエッジ８０４に配置されるアップデート８０２の隣接ピクセルは、間違った情報に基づく値を有する場合がある。例えば、アップデート８０２外の隣接ピクセルが、（例えば、他のアップデートからの）「ごみ」を含む場合、ラスタライザ（rasterizer）は、こうしたピクセルからサンプリングし得るので、それにより、良くない値を有するピクセルを生成する。これは、ディスプレイ・デバイス１１２により表示されるとき、継ぎ目のように見える場合がある。

これに対処する１つの方法は、アップデート８０２の新たに割り当てられたサーフェス内の隣接ピクセルに重なる別のタイル／クランプ（clump）・サーフェス８０６内に存在し得るエッジにおけるピクセルのロー又はカラムをコピーすることである。しかしながら、こうした追加的なコピーは、コンピューティング・デバイスのリソース、例えば、コンピューティング・デバイス１０２のＣＰＵリソース及びＧＰＵリソースの両方を処理するために、極めてコストがかかり得る。

したがって、１以上の実装において、アップデート８０２のエッジは、サーフェス・エッジとともにアラインされる。次いで、サーフェス外になる「隣接」ピクセルをサンプリングするときにラスタライザにサーフェス・エッジにおけるピクセルの値を使用させるクランピング操作を利用する。結果が視覚的に完全に正確ではなくとも、これを利用して、コストとビジュアル正確性との間の合理的なトレードオフを生成することができ、ユーザにとって、結果がかなり正確に見え得る。１以上の実装において、ガター自体は更新されない。

いくつかの例において、アップデート・エッジは、サーフェス・エッジとともにアラインさせることができない場合がある。これは、アップデートよりも大きなサーフェスの割り当てのためである。このような例において、同一のサーフェス上のアップデートのエッジにおけるピクセルのロー／カラムは、クランピング動作に対する類似の効果のために、隣接ピクセルにコピーすることができる。

同様に、トリムされ更新されるとき、１以上の実装において、ガターは、描画することができる新しいと考えられるピクセルとともには更新されない。というのは、ガターが、そのときの有効なピクセルとともに表示されていた以前の有効なピクセルを含むからである。これは、正確性と、ユーザが見たときにユーザにとって邪魔になる、一般的ケースにおける最小限の映像アーチファクトを生み出すパフォーマンスとの間のトレードオフをサポートする。

ブレンディング及びＢＬＴ
図９は、コンポジション・システム１１４による有効な領域の管理を示す例示的な実装９００を示している。前述したように、仮想サーフェス１１８は、アップデートのための有効な部分と有効でない部分とを含み得る。図示した仮想サーフェス１１８の例では、例えば、アップデートは、車ではなく、仮想サーフェス１１８内のカーソルを含み得る。したがって、カーソルを使用して、仮想サーフェス１１８の他の領域ではなく、有効である仮想サーフェス１１８の領域を定めることができる。この仮想サーフェス１１８及び他のサーフェスのこうした領域をトラッキングすることにより、コンポジション・システム１１４は、多様な最適化を利用することができる。

例えば、サーフェスから２つの部分にレンダリングされ、ブレンドされ、ＢＬＴされる（BLT’d）領域を分割する技術について説明する。この技術を使用して、アップデートが小さく仮想サーフェス上に結果として生じる有効な領域が比較的複雑である（例えば、多数の小さなソース・サーフェス（source surface）を有する複雑なメッシュをもたらす）例に対処することができる。

サーフェスが「予めマルチプライされている（pre multiplied）」又は透明である（且つ「不透明でなく」若しくはアルファ値を無視できるよう設定されている）場合、サーフェスが「ブレンドされる」。これを利用して、レンダラにより提供されるコンテンツが存在しない「クリアされた」且つ／又は完全に透明なピクセルを含むより大きな矩形形状をブレンドすることができる。いくつかのケースでは、これは、複雑な形状のパス／エッジの各々の外形を描く複雑なメッシュを用いて処理してラスタ化するよりも、より最適となる。

有効な領域が不透明なサーフェスに対して複雑であるときには、この手法は、ガターに対して使用することもできる。例えば、内部的な部分はＢＬＴされるが、エッジ周りのピクセルは、隣接ピクセルがクリアされるようにブレンドされる。したがって、ラスタライザがこうしたピクセルからサンプリングするとき、正確な値を実現することができる。１以上の実装において、この技術は、仮想サーフェス１１８のエッジに対して使用され、タイル・クランプと仮想サーフェスを構成するサーフェスとの間の内部的なエッジに対しては使用されない。

タイル・サイズにアラインされるクランプ・サーフェスが割り当てられることを確実にするとともに、そのタイルを保持していた以前のサーフェスからのコンテンツが新たなサーフェスに移動されることを確実にするために、ビットをコピーし、一部をクリアすることができる。１以上の実装において、これは、例えば、図７に示される中央におけるアップデート矩形等のレンダラ４０６により更新される部分については実行されない。サーフェスが不透明である場合、アップデート後、エッジ上のピクセルは、「ブレンディング」により、不透明になり得る、すなわち、こうしたピクセルのアルファ・チャネルにおいて、完全な不透明に到達する。

コピーすること、クリアすること、及び不透明にすることというタスクの各々は、非オーバラッピング矩形ストライプ（non-overlapping rectangular stripe）から成る「領域」を用いて実行され得る。領域は、交差してもよいし、ユニオン（union）を形成してもよいし、又は、取り去られてもよい。さらに、領域を構成する非オーバラッピング矩形ストライプは、列挙されてもよい。これにより、様々な矩形及び領域を単一の領域に効率的にまとめることが可能となり、結果として生じる矩形の最適なセットを効率的に抽出することが可能となる。例えば、Ｗｉｎ３２ ＨＲＧＮは、こうしたファシリティ（facility）を利用するために使用することができるＧＤＩ構造体である。各タイルについて個別に何をすべきか決定するのではなく、このような操作を使用して、例えば、クリア又はコピー等の操作が実行される、まとめられ最適化された矩形のセットを識別する。これを使用して、こうしたタスクを実行するために、ＣＰＵ及びＧＰＵ両方における著しい効率を実現することができ、これにより、タイル／アラインメント・サイズを、３２×３２又は１６×１６といった比較的小さな値に低減させることができる。これにより、前述したように、消費を低減させることができる。

レンダラ４０６からのトリム・リクエストは、有効な領域の複雑さに基づいて異なるように対処され得る。一般的ケースでは、タイル・クランプ／サーフェスの有効な領域は、トリム・リクエストに従って更新され得る。しかしながら、有効な領域が複雑であり、ＢＬＴ／ブレンド技術が利用されている場合、追加的な操作を実行することができる。例えば、有効な領域の一部が、不透明になるようにブレンドされ得る。というのは、このような部分は、現在領域のエッジに配置されているからである。これに対処する別の方法は、有効な領域が取り除かれるタイルのための新たなクランプを作成することである。しかしながら、タイルは、いくつかの残存する有効な部分を有し続ける場合がある。このようなタイルに対しては、残存する有効な部分を既存のサーフェスからコピーすることができ、不透明になったトリムされた部分をクリアすることができる。レンダラ４０６が、例えば、コミット操作のために、アップデートの完全なバッチをコミットするときに、このような新たなクランプは、コミットされ得る。この操作は、矩形ストライプの領域を用いて最適化され得るが、他の例も意図されている。

レンダラ４０６によりアップデートのセットをコミットするとき、トリム及び視覚的トランスフォーム（例えば、結果として生じるタイル・クランプ／サーフェスのセット及びそれらの有効な領域）が、コンポジション・エンジン４０２に伝達され得る。このようなサーフェス上でのラスタ化のための未処理のＣＰＵ／ＧＰＵワークが完全であることを確実にするためにコンポジション・エンジン４０２により使用することができるそれぞれのトークンを用いて、アップデートを伝達することができる。このとき、追加的な技術を利用して、効率をさらに向上させることができる。このような技術の例について、以下のセクション群で説明する。

プッシュ・ダウン
図１０は、プッシュ・ダウン技術を用いてサーフェスを結合するコンポジション・システム１１４の動作を示す例示的な実装１０００を示している。この例において、コンポジション・システム１１４は、ビジュアルを表示するために、サーフェス割り当て１００２を行った。これが、図において、ハッシュ・マークを用いたボックスとして示されている。次いで、別のサーフェス割り当て１００４が、アップデートを実行するために行われる。これが、ハッシュ・マークのボックスを用いて配置された白のボックスとして示されている。

コンポジション・システム１１４によりサーフェスの有効な領域をトラッキングすることにより、リソース利用を向上させるために、割り当てを結合することができる。例えば、複数のサーフェスからのレンダリングは、単一のサーフェスからレンダリングするよりもリソース集中型であり得る。

図示した例において、サーフェス割り当て１００４の有効な部分は、サーフェス割り当て１００２に「プッシュ・ダウンされる」。サーフェス割り当て１００４からの有効な領域が現在サーフェス割り当て１００２に含まれることを示すために、これが、破線のボックスを用いて示されている。プッシュ・ダウンの後、アップデートを含んでいたサーフェス割り当て１００４をリリースすることができ、それにより、コンピューティング・デバイス１０２のメモリ１０６の一部を自由にすることができる。したがって、この技術を使用して、新たなサーフェス割り当てを作成することなく、結合されたサーフェスの１つの割り当てを利用することにより、サーフェスを結合することができる。

例えば、いくつかの例において、コンポジション・システム１１４は、現在の又は以前のアップデートのバッチにおいて、重なり合う大きなアップデートに直面する場合がある。これは、比較的小さい有効な領域を含む複数のサーフェスの割り当てを引き起こす場合がある。結果として、コンポジション・システム１１４は、大きなサーフェスを割り当てる場合があるが、比較的小さい有効な領域は、このようなサーフェスがリリースされるのを妨げる場合がある。

しかしながら、第１のサーフェス（例えば、より新しいより小さなサーフェス）からの有効な領域を、第２のサーフェス（例えば、より古いより大きなサーフェス）に「プッシュ・ダウンする」ことにより、第１のサーフェスからの有効な領域を取り除くことができる。これは、第１のサーフェスのリリースを可能にし、それにより、メモリを自由にし、追加的なサーフェス割り当てを伴うことなく、コンポジション・システム１１４により管理されるサーフェス割り当ての量を低減させることができる。このようにして、レンダラ４０６には、より少ないサーフェスをレンダリングするタスクが与えられ、それにより、コンポジション・システム１１４の効率を向上させることができる。新たなサーフェス割り当てが行われる他の技術も意図されており、この技術の例について、以下のセクションで説明する。

列挙及びクランピング
図１１は、有効な領域を新たなサーフェスに結合するコンポジション・システム１１４の動作を示す例示的な実装１１００を示している。前述したように、コンポジション・システム１１４は、サーフェス割り当ての有効な領域をトラッキングするよう構成され得る。その例が、それぞれ有効な領域を有する１１０２（１）、１１０２（２）、及び１１０２（ｎ）として示されている。時間が経過するにつれ、有効な領域を含むサーフェスに対する有効な領域のサイズは、他のサーフェスからのアップデート等のために、減少し得る。したがって、コンポジション・システム１１４は、サーフェス割り当て１１０２（１）〜１１０２（ｎ）からの有効な領域を１以上の新たなサーフェス割り当て１１０４に結合するよう構成され得る。

例えば、コンポジション・システム１１４は、ソースとしてセットアップされ、ディスプレイ・デバイス１１２上のディスプレイを構成するためにレンダリングされる元となるサーフェスの数を低減することにより、サーフェス割り当て及びコンポジションに対処するよう構成され得る。これは、全体的な仮想サーフェスの有効な領域内の矩形の最適化されたセットを列挙することにより実行され得る。次いで、そのような各矩形に対して、クランプを作成することができる。これが多数の小さな矩形をもたらす場合、上述したブレンド／ＢＬＴ技術を使用することができる。このようにして、コンポジション・エンジン４０２により適切に構成される、クリアされたピクセルの領域を有するより大きな矩形が実現され得る。

例えば、コンポジション・エンジン４０２がアップデート・バッチを受信すると、コンポジション・エンジン４０２は、更新される、ディスプレイ・ツリーを構成する仮想サーフェス及びビジュアルの「汚れた（dirtied）」部分を最初に判定することができる。これは、例えば、元となるサーフェス又は「クランプ」が変化する場合であっても（例えば、プッシュ・ダウン又は再クランピング）、アップデートから汚れた領域を明示的に計算して伝達し、コンポジタ（compositor）にトリムすることを含むよう実行され得、同一のコンテンツの有効な領域が持ち越され得るので、新たな汚れた領域は生成されない。有効な領域を記述するこのような矩形は、アップデート／トリム操作により、明示的に伝達され得る。１以上の実装において、より少ない数のより大きな矩形をもたらしてセットアップする際及びより多数のより小さなレンダリング操作を実行する際の大きなオーバヘッドを招くことを避けるために、汚れた領域を低減させることができる。このようにするための１つの技術は、最大数の汚れた矩形を許容することである。新たな汚れた矩形同士が遭遇すると、これらの矩形は、リストに付加され得るか、あるいは、全体的な最小領域増加をもたらす矩形を用いてまとめられ得る（例えば、ユニオンを形成する）。

メッシュ
図１２は、メッシュを使用するコンポジション・システム１１４の動作を示す例示的な実装１２００を示している。メッシュ（例えば、ポイントのリスト）は、単一のｄｒａｗ呼び出しがＧＰＵのドライバに対してなされ得る複数のビジュアルを含み得る。このようにして、ドライバに対する多数のｄｒａｗ呼び出しを低減させることができ、それにより、各呼び出しに伴われるオーバヘッドを回避することができる。

コンポジション・エンジン４０２は、仮想サーフェス１１８のクランプ／サーフェスを構成するための多数のオプションを有する。例えば、コンポジション・エンジン４０２は、各クランプの有効な領域を認識しているので、コンポジション・エンジン４０２は、更新される汚れた領域に重なり合わないクランプをスキップすることにより開始することができる。仮想サーフェス１１８に含まれるビジュアルがピクセル・アラインされる場合、上述したガター技術を利用することなく、トランスレーション（translation）は変形する。これにより、クランプ内の各矩形に対して単純なＢＬＴ／ブレンドを使用することが可能となる。

こうした操作を１つずつ実行する代わりに、コンポジション・エンジン４０２は、矩形のセットから三角形メッシュを作成することができ、そのメッシュを用いてサーフェスをレンダリングさせることができる。例えば、有効な領域を有する矩形のセット１２０２が、コンポジション・システム１１４により調べられ得る。次いで、各矩形を２つの三角形に分割することにより、矩形のセットに対して、三角形メッシュ１２０４が生成され得る。しかしながら、矩形から、Ｔジャンクションが形成される場合もある。Ｔジャンクションは、例えば、浮動小数点又は丸め誤差のため、三角形メッシュ１２０４を継ぎ目とともにラスタ化させる場合がある。したがって、コンポジション・システム１１４は、代わりに、Ｔジャンクションを含まない、非オーバラッピング矩形の三角形メッシュ１２０６を形成するために、矩形のセットを処理することができる。

生成されたメッシュは、クランプの矩形が変化しない場合、コンポジション・フレームにわたってキャッシュさせることができ、再利用することができる。非ピクセル・アラインされた（non-pixel aligned）トランスフォームが存在するが、そのトランスフォームが単にトランスレーションを含む場合、コンポジション・エンジン４０２は、それでもメッシュを生成することができ、そのまま各クランプをレンダリングすることができる。しかしながら、より複雑なトランスフォームが存在する場合、コンポジション・エンジン４０２は、Ｔジャンクションを回避して継ぎ目のない正確なラスタ化を確実にするために、矩形のセットを処理することができる。

こうするために、各クランプは、それぞれの矩形のセットをコンポジション・システム１１４により管理されるメッシュ・ジェネレータ・オブジェクト（mesh generator object）に登録することができる。各座標が調べられるので、コンポジション・システム１１４のメッシュ・ジェネレータ機能は、すでに登録されているエッジ上に、１以上の追加的な頂点を付加することができる。エッジをそれぞれ登録することは、それ自体に付加されるその範囲において既存の頂点を有することでもある。結果は、追加的な頂点を有する、各クランプについての矩形のセットである。次いで、これらの矩形が、このような頂点を用いて非オーバラッピング三角形のセットに分割される。したがって、単純でないトランスフォームのケースでは、三角形メッシュ１２０６内に示される、これらの生成されたＴジャンクションのないメッシュを用いて、クランプをレンダリングすることができる。

オクルージョン
図１３は、オクルージョンに関するコンポジション・システム１１４の動作を示す例示的な実装１３００を示している。各クランプが、不透明な仮想サーフェスのために、そのサーフェスの一部及びＢＬＴの他の部分をブレンドする命令を有し得る場合であっても、コンポジション・システム１１４は、各クランプ上の有効で不透明な領域を認識している。

オクルージョンに関して、こうした領域は、仮想サーフェス全体にわたって蓄積することができ、オクルージョン検出のためにコンポジション・エンジン４０２により使用することができる。１以上の実装において、コンポジション・エンジン４０２は、ディスプレイ・デバイス１１２により表示するためにｚ次（z-order）においてユーザにより近い不透明なビジュアルにより隠される部分を識別するために、登録されたオクルージョン矩形を介して列挙することができる。

しかしながら、オクルージョン・パス（occlusion pass）を介して矩形を複雑な形状に分解することは、コストがかかり得る。領域を構成する非オーバラッピング矩形ストライプが、その領域全体により隠されるであろう矩形を完全に隠すことを確実にするために、コンポジション・システム１１４は、矩形コンテインメント技術（rectangular containment technique）及びインターセクション技術を利用することができる。

そのような技術の例が、図１３の例示的な実装１３００において示されている。例示的な実装１３００は、第１の段階１３０２及び第２の段階１３０４により示されている。第１の段階１３０２において、第１の矩形１３０６及び第２の矩形１３０８が、コンポジション・エンジン４０２により作成される。しかしながら、コンポジション・エンジン４０２は、第１の矩形１３０６の一部１３１０が、第２の矩形１３０８により隠されていることを判定することができる。

したがって、隠している矩形がエッジ全体を見えなくするので、その結果が低減された単一の矩形である場合、コンポジション・エンジン４０２は、チェックされた矩形を低減するよう構成され得る。この例が、第２の段階１３０４において示されている。第２の段階１３０４において、第１の矩形１３０６は、第２の矩形１３０８により隠される一部１３１０を含まないように低減される。したがって、第２の矩形１３０８のエッジを使用して、第１の矩形１３０６のための新たなエッジを定めることができ、それにより、コンピューティング・デバイス１０２のリソースを節約することができる。多様な他の例も意図されている。

例示的な手順
以下の記載は、前述したシステム及びデバイスを利用して実装することができる技術を説明する。各手順の態様は、ハードウェア、ファームウェア、若しくはソフトウェア、又はこれらの組合せにより実装することができる。この手順は、１以上のデバイスにより実装される動作を指定するブロックのセットとして示されるが、それぞれのブロックにより動作を実行するために示される順序に限定されるわけではない。以下の記載の一部において、図１の環境１００、及び図２〜図１３の例示的な実装を参照する。

図１４は、データをレンダリングするためにサーフェスにサイズが割り当てられる例示的な実装における手順１４００を示している。１以上のビジュアルをレンダリングするためにサーフェスを割り当てるリクエストであって、サーフェスのサイズを指定するリクエストが、コンポジション・システムにより受信される（ブロック１４０２）。例えば、リクエストは、「ビットをレンダリングする」ことを始めるアプリケーションから発生し得る。１以上の実装において、リクエストが受信されたときにサーフェスが「ビットを保持していなかった」ように、リクエストが受信されるが割り当てられなかったときに、サーフェスは、すでに初期化されている。

リクエストの受信に応答して、１以上のビジュアルをレンダリングするために、リクエストされたサイズよりも大きなサイズを有するサーフェスが、コンポジション・システムにより割り当てられる（ブロック１４０４）。前述したように、コンポジション・システム１１４は、もはや有効ではない割り当てられたサーフェスの再利用を促進するために「メモリを蓄積する」よう構成され得る。アプリケーションによりリクエストされたよりもサーフェスを大きくすることにより、コンポジション・システム１１４は、サーフェスが後に再利用される可能性を増大させることができる。

図１５は、有効な領域がコンポジション・システムによりトラッキングされる例示的な実装における手順１５００を示している。ディスプレイ・デバイスによる表示のために、ビジュアルを含むサーフェスが、コンポジション・システムにより管理される（ブロック１５０２）。例えば、サーフェスは、前述した仮想サーフェスとして構成することができる。

ディスプレイ・デバイスにより表示されるサーフェス内の有効な領域がトラッキングされる（ブロック１５０４）。例えば、サーフェスは、ディスプレイの一部を更新するよう最初は構成され得る。しかしながら、時間の経過とともに、他のサーフェスが、そのディスプレイのすでに更新された部分をさらに更新し得る。したがって、サーフェスの一部は、表示のために有効のまま残っているが、他の部分は有効ではない。コンポジション・システム１１４は、この有効性をトラッキングするよう構成され得る。これを使用して、オクルージョン管理、サーフェス・リサイズ、サーフェス・コンパクション等、この記載の他の場所で説明された多種多様な機能をサポートすることができる。

図１６は、サーフェスを管理するためにルック・アサイド・リストが使用される例示的な実装における手順１６００を示している。１以上のビジュアルをレンダリングするためにサーフェスを割り当てるリクエストが、コンポジション・システムにより受信される（ブロック１６０２）。前と同様、アプリケーション１１０は、コンポジション・システム１１４の１以上のＡＰＩ１１６を介した呼び出しとして、リクエストを行うことができる。

受信されたリクエストに対応し、コンピューティング・デバイスのディスプレイ・デバイスによる表示のために有効であるビジュアルを含まないサーフェスが、コンピューティング・デバイスのメモリ内に割り当てられたものとして利用可能であるかを判定するために、ルック・アサイド・リストが、コンポジション・システムにより調べられる（ブロック１６０４）。例えば、ルック・アサイド・リストは、例えば、後の受信されるアップデートのために、メモリ内に割り当てられているがもはや有効な部分を有していないサーフェスを参照することができる。

判定されるサーフェスが利用可能であるかの調査に応答して、判定されたサーフェスが、１以上のビジュアルのレンダリングのために利用可能となる（ブロック１６０６）。例えば、判定されたサーフェスには、前述したように、リクエストされたよりも大きなサイズが割り当てられており、したがって、判定されたサーフェスは、後のアップデートと関連し得る。多様な他の例も意図されている。

図１７は、オクルージョンに基づいてサーフェスがリサイズされる例示的な実装における手順１７００を示している。サーフェスの一部が、ディスプレイ・デバイスにより表示される別のサーフェスにより隠されるかの判定がなされる（ブロック１７０２）。例えば、コンポジション・エンジン４０２は、サーフェスの表示のためのｚ次を判定することができ、他のサーフェスの少なくとも一部がサーフェスの一部に重なってレンダリングされるかを判定することができる。

サーフェスから一部が取り除かれる（ブロック１７０４）。これは、他のサーフェスのエッジを使用して、低減されるサーフェスのエッジを定め、それにより、サーフェスの少なくとも１つの新たなエッジを定めることによって等、多様な方法により実行することができる。

取り除かれた一部を有するサーフェスが、他のサーフェスとともにレンダリングされる（ブロック１７０６）。このようにして、サーフェスから取り除かれる一部をレンダリングすることを回避することができ、それにより、コンピューティング・デバイス１０２のリソースを節約することができる。

図１８は、１つのサーフェスから別のサーフェスへの有効な領域のプッシュ・ダウンを伴うコンパクション技術が説明される例示的な実装における手順１８００を示している。１以上のビジュアルをレンダリングするために、使用可能な複数のサーフェスの有効な領域が、コンポジション・システムによりトラッキングされる（ブロック１８０２）。例えば、コンポジション・システム１１４は、サーフェスのどの部分がディスプレイ・デバイスにより表示され、サーフェスのどの部分がディスプレイ・デバイスにより表示されないかを判定することができる。

次いで、第１のサーフェスの第１の有効な領域が、第２のサーフェスの割り当て内に包含可能かの判定が、コンポジション・システムによりなされる（ブロック１８０４）。例えば、第１のサーフェスは、アップデートとして構成することができる。次いで、第１の有効な領域以外のアップデートの一部を無効にする後続のアップデートが実行され得る。

次いで、第２のサーフェスの一部として包含するために、第１の有効な領域がプッシュ・ダウンされる（ブロック１８０６）。これは、有効な領域のビットを第２のサーフェスにコピーすることを含み得る。コピーの後、次いで、第１のサーフェスをリリースすることができ、それにより、別個のサーフェスを維持する際のリソースを節約することができるとともに、より小さな数のサーフェスを使用することにより、レンダリング操作の効率を向上させることができる。したがって、この例において、新たなサーフェスは割り当てられず、それにより、割り当てを行い維持する際のコンピューティング・デバイス１０２のリソースを節約することができる。他の例も意図されており、そのうちの１つについて以下で説明する。

図１９は、有効な領域を新たなサーフェスに結合することを伴うコンパクション技術が説明される例示的な実装における手順１９００を示している。１以上のビジュアルをレンダリングするために、使用可能な複数のサーフェスの有効な領域が、コンポジション・システムによりトラッキングされる（ブロック１９０２）。前と同様、コンポジション・システム１１４は、複数のサーフェスのどの部分がディスプレイ・デバイスにより表示され、複数のサーフェスのどの部分がディスプレイ・デバイスにより表示されないかを判定することができる。

次いで、複数のサーフェスからの有効な領域を包含するために使用可能な新たなサーフェスのための割り当てが計算される（ブロック１９０４）。例えば、新たなサーフェスは、複数の有効な領域の包含のために境界を有する矩形として構成することができる。次いで、新たなサーフェスが、複数のサーフェスからの有効な領域を包含するために割り当てられ（ブロック１９０６）、次いで、有効な領域が、新たなサーフェスにコピーされ、それにより、コンポジション・システム１１４が元となるサーフェスを自由にすることを可能にする。コンポジション・システム１１４によるサーフェス・コンパクションの多様な他の例も意図されている。

図２０は、ドライバへの呼び出しを行ってメッシュを用いてサーフェスをレンダリングするために、コンポジション・システムがメッシュを使用する例示的な実装における手順２０００を示している。Ｔジャンクションを含まない矩形のセットからメッシュが形成される（ブロック２００２）。例えば、メッシュは、Ｔジャンクションと、したがって、前述したように、こうしたジャンクション（例えば、継ぎ目）をレンダリングする際に遭遇する複雑さとを避けるために形成される三角形のセットを記述するものとして形成することができる。ユーザ・インタフェース内にアップデートのための有効な領域を有する複数の矩形を記述するために使用することができるグラフィックス機能（例えば、ＧＰＵ）のドライバに対する単一の呼び出し等、メッシュを用いてサーフェスをレンダリングするために、ドライバへの呼び出しがなされる（ブロック２００４）。したがって、メッシュは、上記の対応するセクションにおいて説明したメッシュの三角形を形成するために使用される矩形の各々に対する呼び出しの使用を回避することに役立ち得る。

例示的なシステム及びデバイス
図２１は、本明細書で説明した様々な技術を実装することができる１以上のコンピューティング・システム及び／又はデバイスを表す例示的なコンピューティング・デバイス２１０２を含む例示的なシステムを、一般に２１００で示している。例えば、コンピューティング・デバイス２１０２は、サービス・プロバイダのサーバ、クライアントに関連付けられたデバイス（例えば、クライアント・デバイス）、オンチップ・システム、及び／又は任意の他の適切なコンピューティング・デバイス若しくはコンピューティング・システムとすることができる。コンピューティング・デバイス２１０２は、図１のコンポジション・システム１１４を含むものとして示されている。

図示された例示的なコンピューティング・デバイス２１０２は、処理システム２１０４、１以上のコンピュータ読み取り可能な媒体２１０６、及び１以上のＩ／Ｏインタフェース２１０８を含み、これらは、互いに通信可能に接続される。図示されてはいないが、コンピューティング・デバイス２１０２は、互いに様々なコンポーネントを接続するシステム・バス又は他のデータ・コマンド転送システムをさらに含んでもよい。システム・バスは、メモリ・バス若しくはメモリ・コントローラ、周辺バス、ユニバーサル・シリアル・バス、及び／又は多様なバス・アーキテクチャのいずれかを利用するプロセッサ・バス若しくはローカル・バス等の異なるバス・アーキテクチャの任意の１つ又はそれらの組合せを含むことができる。制御線及びデータ線等の多様な他の例も意図されている。

処理システム２１０４は、ハードウェアを用いて１以上の動作を実行する機能を表す。したがって、処理システム２１０４は、プロセッサ、機能ブロック等として構成され得るハードウェア要素２１１０を含むものとして示されている。これは、１以上の半導体を用いて形成される特定用途向け集積回路又は他の論理デバイスとしてのハードウェアの実装を含み得る。ハードウェア要素２１１０は、ハードウェア要素が形成される材料又はハードウェア要素において使用される処理機構により限定されるものではない。例えば、プロセッサは、１以上の半導体及び／又はトランジスタ（例えば、電子集積回路（ＩＣ））から構成されることがある。このようなコンテキストにおいて、プロセッサ実行可能な命令は、電子的に実行可能な命令であってよい。

コンピュータ読み取り可能な記憶媒体２１０６は、メモリ／ストレージ２１１２を含むものとして示されている。メモリ／ストレージ２１１２は、１以上のコンピュータ読み取り可能な媒体に関連付けられたメモリ／ストレージ能力を表す。メモリ／ストレージ・コンポーネント２１１２は、（ランダム・アクセス・メモリ（ＲＡＭ）等の）揮発性媒体及び／又は（読み取り専用メモリ（ＲＯＭ）、フラッシュ・メモリ、光ディスク、磁気ディスク等の）不揮発性媒体を含み得る。メモリ／ストレージ・コンポーネント２１１２は、固定媒体（例えば、ＲＡＭ、ＲＯＭ、固定ハード・ドライブ等）及び取り外し可能な媒体（例えば、フラッシュ・メモリ、取り外し可能なハード・ドライブ、光ディスク等）を含み得る。コンピュータ読み取り可能な媒体２１０６は、以下でさらに説明するような多様な他の形で構成され得る。

１以上の入力／出力インタフェース２１０８は、様々な入力／出力デバイスを用いて、ユーザがコマンド及び情報をコンピューティング・デバイス２１０２に入力することを可能にするとともに、情報をユーザ及び／又は他のコンポーネント若しくはデバイスに提示することを可能にする機能を表す。入力デバイスの例は、キーボード、カーソル制御デバイス（例えば、マウス）、マイクロフォン、スキャナ、タッチ機能（例えば、物理的接触を検出するよう構成されている静電容量式センサ又は他のセンサ）、カメラ（例えば、赤外周波数等の可視波長又は不可視波長を使用して、接触を伴わないジェスチャとして動きを認識することができる）等を含む。出力デバイスの例は、ディスプレイ・デバイス（例えば、モニタ又はプロジェクタ）、スピーカ、プリンタ、ネットワーク・カード、触覚応答デバイス等を含む。したがって、コンピューティング・デバイス２１０２は、ユーザ・インタラクションをサポートするために、以下でさらに説明するような多様な形で構成され得る。

ソフトウェア、ハードウェア要素、又はプログラム・モジュールの一般的コンテキストにおいて、様々な技術が、本明細書において説明され得る。一般に、そのようなモジュールは、特定のタスクを実行するか、あるいは、特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、エレメント、コンポーネント、データ構造等を含む。「モジュール」、「機能」、及び「コンポーネント」という用語は、本明細書で使用されるとき、一般に、ソフトウェア、ファームウェア、ハードウェア、又はそれらの組合せを表す。本明細書で説明した技術の特徴は、プラットフォームに依存しない、すなわち、こうした技術は、多様なプロセッサを有する多様な商用コンピューティング・プラットフォーム上で実装することができる。

説明したモジュール及び技術の実装は、何らかの形態のコンピュータ読み取り可能な媒体上に記憶することができ、あるいは、何らかの形態のコンピュータ読み取り可能な媒体にわたって伝送することができる。コンピュータ読み取り可能な媒体は、コンピューティング・デバイス２１０２によりアクセスされ得る多様な媒体を含み得る。限定ではなく例として、コンピュータ読み取り可能な媒体は、「コンピュータ読み取り可能な記憶媒体」及び「コンピュータ読み取り可能な信号媒体」を含み得る。

「コンピュータ読み取り可能な記憶媒体」は、単なる信号伝送、搬送波、又は信号自体ではなく、永続的な且つ／又は非トランジトリな情報の記憶を可能にする媒体及び／又はデバイスを指し得る。したがって、コンピュータ読み取り可能な記憶媒体は、非信号担持媒体を指す。コンピュータ読み取り可能な記憶媒体は、コンピュータ読み取り可能な命令、データ構造、プログラム・モジュール、論理エレメント／回路、又は他のデータ等の情報を記憶するのに適した方法又は技術により実装された、揮発性及び不揮発性、取り外し可能な及び取り外し不可能な媒体及び／又はストレージ・デバイス等のハードウェアを含む。コンピュータ読み取り可能な記憶媒体の例は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、若しくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、若しくは他の光ストレージ、ハード・ディスク、磁気カセット、磁気テープ、磁気ディスク・ストレージ、若しくは他の磁気ストレージ・デバイス、又は他のストレージ・デバイス、有体の媒体、又は所望の情報を記憶するのに適しておりコンピュータによりアクセスされ得る製品を含み得るが、これらに限定されるものではない。

「コンピュータ読み取り可能な信号媒体」は、例えばネットワークを介して、コンピューティング・デバイス２１０２のハードウェアに命令を伝送するよう構成されている信号担持媒体を指し得る。信号媒体は、一般的に、搬送波、データ信号、又は他の搬送機構等の変調されたデータ信号内に、コンピュータ読み取り可能な命令、データ構造、プログラム・モジュール、又は他のデータを具現化し得る。信号媒体はまた、任意の情報伝達媒体を含む。「変調されたデータ信号」という用語は、情報をその信号内で符号化するような方法で設定又は変更されたその特性の１以上を有する信号を意味する。例えば、通信媒体は、有線ネットワーク又は直接配線接続などの有線媒体、並びに、音響、ＲＦ、赤外線、及び他の無線媒体等の無線媒体を含むが、これらに限定されるものではない。

前述したように、ハードウェア要素２１１０及びコンピュータ読み取り可能な媒体２１０６は、１以上の命令を実行する等のために、本明細書で説明した少なくともいくつかの技術の態様を実装するいくつかの実施形態において使用することができるハードウェア形態で実装されたモジュール、プログラマブル・デバイス・ロジック、及び／又は固定デバイス・ロジックを表す。ハードウェアは、集積回路又はオンチップ・システムのコンポーネント、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、コンプレックス・プログラマブル論理デバイス（ＣＰＬＤ）、及び、シリコン又は他のハードウェアによる他の実装を含み得る。このコンテキストにおいて、ハードウェアは、命令により定められるプログラム・タスク及び／又はハードウェアにより具現化されるロジックを実行する処理デバイスとして機能することができるとともに、例えば、前述したコンピュータ読み取り可能な記憶媒体といった実行するための命令を記憶するために利用されるハードウェアとして機能することができる。

上記の組合せを使用して、本明細書で説明した様々な技術を実装することもできる。したがって、ソフトウェア、ハードウェア、又は実行可能なモジュールが、何らかの形態のコンピュータ読み取り可能な記憶媒体上に具現化される、且つ／又は１以上のハードウェア要素２１１０により具現化される１以上の命令及び／又はロジックとして実装され得る。コンピューティング・デバイス２１０２は、ソフトウェア・モジュール及び／又はハードウェア・モジュールに対応する特定の命令及び／又は機能を実装するよう構成され得る。したがって、ソフトウェアとしてコンピューティング・デバイス２１０２により実行可能なモジュールの実装は、例えば、コンピュータ読み取り可能な記憶媒体及び／又は処理システム２１０４のハードウェア要素２１１０を使用することにより、少なくとも一部はハードウェアを用いて実現され得る。命令及び／又は機能は、本明細書で説明した技術、モジュール、及び例を実装するために、１以上の製品（例えば、１以上のコンピューティング・デバイス２１０２及び／又は処理システム２１０４）により実行可能／動作可能であり得る。

図２１にさらに示されるように、例示的なシステム２１００は、パーソナル・コンピュータ（ＰＣ）、テレビジョン・デバイス、及び／又はモバイル・デバイス上でアプリケーションを実行するときに、シームレスなユーザ・エクスペリエンスのためのユビキタス環境を可能にする。サービス及びアプリケーションは、アプリケーションを使用している、ビデオ・ゲームをプレイしている、ビデオを観賞している間等に１つのデバイスから次のデバイスに移るとき、共通のユーザ・エクスペリエンスのために、３つの環境全てにおいて実質的に同様に動作する。

例示的なシステム２１００において、複数のデバイスが、中央コンピューティング・デバイスを介して相互接続される。中央コンピューティング・デバイスは、複数のデバイスに対してローカルにあってもよいし、あるいは、複数のデバイスからリモートに配置されてもよい。一実施形態において、中央コンピューティング・デバイスは、ネットワーク、インタネット、又は他のデータ通信リンクを介して複数のデバイスに接続されている１以上のサーバ・コンピュータのクラウドであってよい。

一実施形態において、この相互接続アーキテクチャにより、共通のシームレスなエクスペリエンスを複数のデバイスのユーザに提供するために、機能を複数のデバイスにわたって分散させることが可能となる。複数のデバイスの各々は、異なる物理的要件及び能力を有し得る。中央コンピューティング・デバイスは、プラットフォームを使用して、デバイス向けに調整されるとともにそれでも全てのデバイスに共通のエクスペリエンスをデバイスに提供することを可能にする。一実施形態において、ターゲット・デバイスのクラスが作成され、エクスペリエンスが、デバイスの全体的クラス向けに調整される。デバイスのクラスは、物理的特徴、使用のタイプ、又はデバイスの他の共通の特性により定められ得る。

様々な実装において、コンピューティング・デバイス２１０２は、コンピュータ２１１４、モバイル２１１６、及びテレビジョン２１１８向け等、多種多様な構成を想定し得る。これらの構成の各々は、一般に異なる構造及び能力を有し得るデバイスを含み、したがって、コンピューティング・デバイス２１０２は、異なるデバイス・クラスの１以上に従って構成され得る。例えば、コンピューティング・デバイス２１０２は、パーソナル・コンピュータ、デスクトップ・コンピュータ、マルチ・スクリーン・コンピュータ、ラップトップ・コンピュータ、ネット・ブック等を含むデバイスのコンピュータ２１１４・クラスとして実装され得る。

コンピューティング・デバイス２１０２はまた、携帯電話、ポータブル音楽プレイヤ、ポータブル・ゲーミング・デバイス、タブレット・コンピュータ、マルチ・スクリーン・コンピュータ等のモバイル・デバイスを含むデバイスのモバイル２１１６・クラスとしても実装され得る。コンピューティング・デバイス２１０２はまた、臨時の視聴環境におけるより大きなスクリーンを有するデバイス又はそのようなスクリーンに一般に接続されたデバイスを含むデバイスのテレビジョン２１１８・クラスとしても実装され得る。これらのデバイスは、テレビジョン、セットトップ・ボックス、ゲーミング・コンソール等を含む。

本明細書で説明した技術は、コンピューティング・デバイス２１０２のこれら様々な構成によりサポートされ得るものであり、本明細書で説明した技術の特定の例に限定されるものではない。この機能は、以下で説明するように、「クラウド」２１２０を介してプラットフォーム２１２２を用いる等、分散システムを使用することにより、全てが又は部分的に実装され得る。

クラウド２１２０は、リソース２１２４のためのプラットフォーム２１２２を含む、且つ／又はリソース２１２４のためのプラットフォーム２１２２を表す。プラットフォーム２１２２は、クラウド２１２０のハードウェア・リソース（例えば、サーバ）及びソフトウェア・リソースの基本的機能を抽象化する。リソース２１２４は、コンピューティング・デバイス２１０２からリモートにあるサーバ上でコンピュータ処理が実行されている間に使用することができるアプリケーション及び／又はデータを含み得る。リソース２１２４はまた、インタネット、及び／又は、セルラネットワーク若しくはＷｉ−Ｆｉ（登録商標）ネットワーク等の加入者ネットワークを介して提供されるサービスも含み得る。

プラットフォーム２１２２は、コンピューティング・デバイス２１０２を他のコンピューティング・デバイスに接続するためのリソース及び機能を抽象化し得る。プラットフォーム２１２２はまた、プラットフォーム２１２２を通じて実現されるリソース２１２４に対して出された要求に合わせて、対応するレベルの規模を提供するために、リソースの規模調整（scaling）を抽象化する働きもする。したがって、相互接続されたデバイスの実施形態において、本明細書で説明した機能の実装は、システム２１００全体を通じて分散させることができる。例えば、機能は、コンピューティング・デバイス２１０２上に部分的に実装されるとともに、クラウド２１２０の機能を抽象化するプラットフォーム２１２２を通じて実装され得る。

結論
本発明が、構造的特徴及び／又は方法論的動作に特有の言葉で説明されたが、添付の特許請求の範囲において定められる本発明は、説明した特定の特徴又は動作に必ずしも限定される必要がないことを理解すべきである。むしろ、特定の特徴及び動作は、特許請求された発明を実施するための例示的な形態として開示されたものである。

Claims (10)

1. コンピューティング・デバイスにより実施される方法であって、
   １以上のビジュアルをレンダリングするためにサーフェスを割り当てるリクエストを、コンポジション・システムにより受信するステップであって、前記リクエストは、前記サーフェスのサイズを指定する、受信するステップと、
   前記リクエストの前記受信に応答して、前記１以上のビジュアルをレンダリングするために、リクエストされた前記サイズよりも大きなサイズを有する前記サーフェスを、前記コンポジション・システムにより割り当てるステップと、
   を含む、方法。
2. 前記リクエストは、前記コンピューティング・デバイスにより実行される１以上のアプリケーションから、前記コンポジション・システムにより受信される、請求項１記載の方法。
3. 前記リクエストは、前記１以上のアプリケーションから、前記コンポジション・システムの１以上のアプリケーション・プログラミング・インタフェースを介して受信される、請求項２記載の方法。
4. 前記リクエストが受信されるとき、前記サーフェスは、前記コンポジション・システムにより初期化されるが、前記コンピューティング・デバイスのメモリ内には割り当てられない、請求項１記載の方法。
5. 前記サーフェスは、前記コンポジション・システムにより維持される仮想サーフェスであり、前記仮想サーフェスを作成し、更新し、削除する機能を含む、請求項１記載の方法。
6. 前記仮想サーフェスは、１以上のビジュアルを前記コンピューティング・デバイスのディスプレイ・デバイス上に表示するために、リクエストが受信される前に前記１以上のビジュアルをレンダリングする機能を含む、請求項５記載の方法。
7. 前記仮想サーフェスは、初期化されるときに、実際の割り当てにより、前記１以上のアプリケーションから、バックされない、請求項１記載の方法。
8. 少なくとも部分的にハードウェアを用いて実装された１以上のモジュールを備え、
   １以上のアプリケーションによりアクセスするための１以上のアプリケーション・プログラミング・インタフェースを公開して、１以上のビジュアルをレンダリングするために前記１以上のアプリケーションにより指定されるサイズを有する仮想サーフェスを割り当てるコンポジション・システムを実装するよう構成されたコンピューティング・デバイス。
9. 前記コンポジション・システムによる前記仮想サーフェスの前記割り当ては、前記１以上のアプリケーションによりリクエストされた前記サイズよりも大きなサイズを有するように実行される、請求項８記載のコンピューティング・デバイス。
10. 命令を記憶した１以上のコンピュータ読み取り可能な記憶媒体であって、コンピューティング・デバイスによる実行に応答して、前記命令は、前記コンピューティング・デバイスに、
    ディスプレイ・デバイスにより表示されるビジュアルを含むサーフェスを管理すること、及び前記ディスプレイ・デバイスにより表示される前記サーフェス内の有効な領域をトラッキングすることを含む１以上の動作を実行するコンポジション・システムを実装させる、１以上のコンピュータ読み取り可能な記憶媒体。

Images