レイアウトマネージャ

专利摘要:
ユーザインタフェースエレメントに対するレイアウトアップデート（更新）を管理するための種々のテクノロジおよび手法が開示されている。ユーザインタフェースエレメントのダーティステートが、ユーザインタフェースエレメントの複数のノードをもつツリーにおいてトラッキング（追跡）される。このダーティステートはノードのダーティサブツリーを特定することを可能にする。ルートノードはダーティサブツリーの各々について特定される。ツリーの影響を受けた部分は、ダーティサブツリーの各々について特定されたルートノードからスタートしてアップデートされる。アップデートプロセスの一部として、先祖ノードに対する変更が検出され、その変更はレイアウトプロセスをより効率化するために使用される。例えば、変更された祖先のいずれかの子孫ノードで現在実行されているレイアウトプロセスがあれば、そのレイアウトプロセスが放棄され、変更された祖先で再開される。ツリーの影響を受けた部分をアップデートしたあと、アップデートされたユーザインタフェースエレメントが出力デバイス上でレンダリングされる。
公开号:JP2011507056A
申请号:JP2010535009
申请日:2008-11-14
公开日:2011-03-03
发明作者:エス．パリク スジョー；ピー．レリア デイビッド
申请人:マイクロソフト コーポレーション；
IPC主号:G06T11-20

专利说明:

[0001] 現代のコンピュータオペレーティングシステムは、モニタまたはプリンタなどの出力デバイスからグラフィカルユーザインタフェースエレメントを提示し、管理する能力をもっている。あるグラフィカルユーザインタフェースエレメントがアプリケーション内で作成されるとき、そのアイテムは出力デバイス上でレンダリングするのに適したサイズにされ、配置されている。同様に、既存のグラフィカルユーザインタフェースエレメントがアプリケーション内で修正または削除されるとき、または新しいユーザインタフェースエレメントが追加されるとき、出力デバイスはその変更を正しく反映していなければならない。既存のコンピュータオペレーティングシステムは、デバイスドライバを利用して特定の出力デバイスと通信することにより、特定の出力デバイスからグラフィカル出力をレンダリングする煩雑な細事からソフトウェア開発者を解放している。既存のコンピュータオペレーティングシステムは、アプリケーションプログラミングインタフェース（Application Programming Interface：ＡＰＩ）を将来のソフトウェア開発者に公表することによってこれを達成している。]
[0002] 一般的に、ＡＰＩは、ソフトウェア開発者が利用することが可能で、いずれかの特定デバイスにとって必要であるローレベル（低水準）の命令に依存しないハイレベル（高水準）のファンクションコール（関数呼び出し）が集まったものである。プラットフォームまたはオペレーティングシステムは、デバイスドライバの援助を得て、ハイレベルのＡＰＩコールからローレベルのデバイス固有コールへの必要な変換を実行しているのが代表的である。]
[0003] それにもかかわらず、ソフトウェア開発者は、自分のアプリケーションのグラフィカルユーザインタフェースエレメントが、いずれかの特定の出力デバイス上でどのように物理的に表示されまたはレンダリングされるかを実現することに係わりをもつことを望まないとしても、その開発者は、これらのエレメントがどのように論理的にレイアウトされ、管理されるかには関心を持つことがある。例えば、ソフトウェア開発者が、そのメニューの表示またはアイコンの配置を特定の方法で行なうグラフィカルユーザインタフェースを開発したいこともあれば、その開発者が、シングルドキュメントの中の複数のグラフィカルユーザインタフェースエレメントを特定の方法で配置し、表示するアプリケーションを開発したいこともある。ツールの中には、グラフィカルレイアウトを管理するある種の能力をソフトウェア開発者に与えているものがあるが、このような能力は複雑または非効率的であることが多い。]
課題を解決するための手段

[0004] ユーザインタフェースエレメントに対するレイアウトアップデート（更新）を管理するためのテクノロジおよび手法が開示されている。ユーザインタフェースエレメントのダーティステート(dirty state)がユーザインタフェースエレメントのツリーの中でトラッキング（追跡）される。ツリーは、ユーザインタフェースエレメントの複数のノードを含み、このダーティステートは、ノードのダーティサブツリーを特定することを可能にしている。ルートノードはダーティサブツリーの各々について特定される。ツリーの影響を受けた部分(affected portions)は、ダーティサブツリーの各々について特定されたルートノードから始まってアップデートされる。このツリーの影響を受けた部分をアップデートしたあと、アップデートされたユーザインタフェースエレメントが出力デバイス上でレンダリングされる。]
[0005] ある実施形態では、祖先(ancestor)ノードに対する変更が検出され、その変更はレイアウトプロセスをより効率化するために使用される。レイアウトプロセスは指定したデバイスから開始される。指定したノードのいずれかの祖先が変更されたか否かの判断が行なわれる。指定したノードの少なくとも１つの変更された祖先が特定されたときは、その変更された祖先のいずれかの子孫(descendant)のノードで現在実行中のレイアウトプロセスがあれば、そのレイアウトプロセスが放棄され、このレイアウトプロセスが変更された祖先で再開される。]
[0006] 別の実施形態では、指定したノードについてレイアウトステータスを無効化することができる。指定したノードがすでにダーティであるか否かの判断が行なわれる。指定したノードがまだダーティでなければ、指定したノードはダーティとしてマークされ、指定したノードが現在レイアウト（測定または配置）されている少なくとも１つのノードの祖先であるか否かの判断が行なわれる。指定したノードが現在レイアウトされている少なくとも１つのノードの祖先であれば、指定したノードから現在レイアウト（測定または配置）されているノードまでの直接経路上のすべてのノードはダーティ祖先を有しているが、指定したノードを含んでいないとしてマークされる。]
[0007] この概要は、以下の「詳細説明」に詳しく記載されている概念を選んで簡単に紹介したものである。この要約説明は請求項に記載の主題のキーとなる特徴または必須の特徴を特定するものでも、請求項に記載の主題の範囲を判断する際の一助として使用されるものでもない。]
図面の簡単な説明

[0008] ある実施形態のコンピュータシステムを示す概略図である。
図１のコンピュータシステム上で動作するある実施形態のレイアウトマネージャアプリケーションを示す概略図である。
ノードの２つの異なるダーティサブツリーを有している例示のノードのツリーを示す概略図である。
祖先変更のステータスを使用してレイアウトプロセスをより効率化する際に係わりのあるステージを例示するある実施形態のプロセスフロー図である。
無駄な作業を避けるようにノードのサイズが変更されたとき親をダーティとしてマークする際に係わりのあるステージを例示するある実施形態のプロセスフロー図である。
ノードのダーティサブツリーを処理することによってレンダリング直前にレイアウトをアップデートする際に係わりのあるステージを例示するある実施形態のプロセスフロー図である。
指定したノードでレイアウトプロセスを実行する際に係わりのあるステージを例示するある実施形態のプロセスフロー図である。
レイアウトプロセスを無効化する際に係わりのあるステージを例示するある実施形態のプロセスフロー図である。] 図１
実施例

[0009] 本明細書におけるテクノロジと手法は、出力デバイス上でユーザインタフェースエレメントのサイズと位置のアップデートを調整するレイアウトマネージャアプリケーション(layout manager application)として一般的コンテキストの中で説明されていることがあるが、これらのテクノロジと手法は上記のほかに、他の目的にも役立っている。ある実施形態では、本明細書に記載のテクノロジの１つまたは２つ以上は、ＭＩＣＲＯＳＯＦＴ（登録商標）Ｓｉｌｖｅｒｌｉｇｈｔなどのプラットフォーム内の特徴としても、ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）などのオペレーティングシステム内の特徴としても、または出力デバイス上でユーザインタフェースエレメントに対するアップデートを調整することを担当する他のタイプのプログラムまたはサービスからの特徴としても実現することができる。]
[0010] ある実施形態では、ユーザインタフェースエレメントのサイズと位置のアップデートを調整し、そのアップデートを出力デバイス上でレンダリングするのを可能にするレイアウトマネージャが提供されている。本明細書の中で使用されている「ユーザインタフェースエレメント(user interface element)」という用語は、リストボックス、コンボボックス(combo box)、ツリー構造、ラジオボタン、カレンダ、ウィンドウ、フォーム、パネル、およびこれらを組み合わせたもの、などのすべてのユーザインタフェースオブジェクトを含むものを意味している。ユーザインタフェースオブジェクトの新しい実施形態は絶えず作成されており、これらの開示例には、まだ特別に名前が付けられていないユーザインタフェースエレメントも含まれている。ユーザインタフェースエレメントは、ノードのツリーに編成され、そのステータスがトラッキングされ、アップデートされることを可能にしている。本明細書の中で用いられている「ツリー(tree)」という用語は、ユーザインタフェースエレメント間の関係を特定することを可能にする階層または他の構造で表現された複数のユーザインタフェースエレメントを含むものを意味している。本明細書の中で用いられている「ノード(node)」という用語は、複数のユーザインタフェースエレメントのツリー内の個別的ユーザインタフェースエレメントを含むものを意味している。]
[0011] ユーザインタフェースエレメントに影響を与える所与のプログラム実行（run）の一部として、レイアウトマネージャはノードのツリーを使用して、ユーザインタフェースエレメントに対するこれらの変更をトラッキングする。例えば、ツリー内のあるノードについて１つまたは２つ以上のステータスインジケータは、ユーザインタフェースエレメントの１つまたは２つ以上の細部が変更されたことを確認するようにアップデートすることができる。一例として（この例に限定されない）、ユーザインタフェース上の特定のテキストボックスに収められているテキストのフォントサイズを変更するコードを実行することがある。ある実施形態では、変更されたノードでダーティインジケータがマークされ、そのノードには、ユーザインタフェースが次回に再レンダリングされるときにアップデートする必要がある１つまたは２つ以上の変更された細部を有しているとのフラグが付けられる。これらのステータスインジケータはレイアウトマネージャによってトラッキングされ、そのあと、出力デバイスから表示された所与のプログラムに対するユーザインタフェースエレメントについて、どのアップデートをレンダリングする必要があるかを判断するために使用される。]
[0012] 例えば、ステータスインジケータは、ユーザインタフェースに対するアップデートを再レンダリングする前にレイアウトマネージャによってコールされるレイアウトプロセスによって使用することができる。本明細書の中で用いられている「レイアウトプロセス」という用語は、ユーザインタフェースエレメントのサイズを決め、位置決めするプロセスを含むものを意味している。本明細書の中で用いられている「レイアウトされた(laid out)」という用語は、それまでにあるユーザインタフェースエレメントに影響を与えた変更を反映するためにそのユーザインタフェースエレメントのサイズが決められ、位置決めされたことを含むものと意味している。レイアウトマネージャは、測定プロセスおよび/または配置プロセスを含むことができる。「測定プロセス」は、ある特定のユーザインタフェースエレメントをどれだけ大きくすることが望ましいかを推定するプロセスである。測定プロセスの間、ノードは、その子のすべてが要求するサイズを判断することによって、あるいはそのノードに子がなければ、そのノード自身が要求するサイズによって、そのノードが要求するサイズを判断する。ノードの子を測定するとき（子がある場合）、そのノードにはサイズの制約があり、これは、ノードがまだ測定していない子に割り振るために親が残しておいたサイズであるのが代表的である。このサイズ制限は、一方または両方のディメンションにおいて無制限のこともある。ある実施形態では、ノードに子があるか否かに関係なく、高さ、最小高さ、最大高さ、幅、最大幅および最小幅といった他の制約は、これらが指定されていれば、使用されることもある。「配置プロセス」は、位置およびその位置に表示されるために子ノードに割り振られたサイズを親エレメントが子ノードに知らせる場合のプロセスである。これは、測定プロセスで要求したことをノードが示したサイズより小であることも、大であることも、等しいこともある。ノードは、それに応じて自身でスクリーン上の位置とサイズを決める。ストレッチモード、水平位置合わせ(horizontal alignment)および垂直位置合わせ(vertical alignment)、といったプロパティは、その指定があれば、ノードの位置および/またはサイズを判断するために使用されることもある。]
[0013] 図４乃至図８により詳しく記載されているいくつかの実施形態では、祖先ノードで行なわれた変更のステータスは、レイアウトプロセス（例えば、測定プロセスおよび/または配置プロセス）の実行をより効率化するために使用される。本明細書の中で用いられている「祖先ノード(ancestor node)」という用語は、指定したノードまでの上向きのリニアチェインに含まれるいずれかの先行ノード(predecessor node)を含むものを意味している。本明細書の中で用いられている「親ノード(parent node)」という用語は、指定したノードの近隣親ノード（例：父）を含むものを意味している。ある任意のノードについてレイアウトプロセス（測定プロセスおよび/または配置プロセス）を実行しているとき、レイアウトマネージャは、いずれかの祖先ノードが変更されたかどうかを判断する。いずれかの祖先ノードが変更されていれば、変更された祖先の下位にある子孫ノード（例：子ノード）についてプロセス中のレイアウト（測定および/または配置）があれば、そのレイアウトが放棄され、レイアウトプロセス（測定または配置している）が変更された祖先で再開される。指定したノードに対するいずれかの祖先ノードが変更されていなければ、レイアウトプロセス（測定および/または配置している）は、子孫ノードの経路を下っていくことにより継続する。ある実施形態では、祖先に対する変更が行なわれたことを認識することにより、無駄な作業は、子孫レベルではなく、祖先レベルで変更を処理することによって回避することができる。さもなければ、祖先ノードに対してアップデートがそのあとで処理されたとき期限切れになる可能性のある、子孫ノードに対する変更を処理するのにこの作業が消費されていた可能性がある。以下では、これらの手法の一部について詳しく説明する。] 図４ 図８
[0014] 図１に示すように、システムの１つまたは２つ以上の部分を実現するために使用される例示のコンピュータシステムは、コンピューティングデバイス１００のようなコンピューティングデバイスを含んでいる。その最も基本的な構成では、コンピューティングデバイス１００は、少なくとも１つの処理ユニット１０２とメモリ１０４を装備しているのが代表的である。コンピューティングデバイスの正確な構成とタイプに応じて、メモリは揮発性（ＲＡＭなど）であることも、不揮発性（ＲＯＭ、フラッシュメモリなど）であることも、これら２つを任意に組み合わせたものであることもある。この最も基本的な構成は図１に破線１０６で示している。] 図１
[0015] さらに、デバイス１００は追加の特徴/機能を備えていることもある。例えば、デバイス１００は追加ストレージ（取り外し可能および/または取り外し不能）を装備していることもあり、その中には、磁気または光ディスクまたはテープが含まれるが、これらに限定されない。このような追加ストレージは、図１に取り外し可能ストレージ１０８および取り外し不能ストレージ１１０で示されている。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータなどの情報をストアするための任意の方法またはテクノロジで実現された揮発性および不揮発性の取り外し可能および取り外し不能媒体を含んでいる。メモリ１０４、取り外し可能ストレージ１０８および取り外し不能ストレージ１１０は、いずれもコンピュータ記憶媒体の例である。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリテクノロジ、ＣＤ−ＲＯＭ、ＤＶＤまたは他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、または必要な情報をストアするために使用可能で、デバイス１００によってアクセス可能である任意の他の媒体を含んでいるが、これらに限定されない。このようなコンピュータ記憶媒体は、いずれもデバイス１００の一部になっていることがある。] 図１
[0016] コンピューティングデバイス１００は、コンピュータデバイス１００が他のコンピュータ／アプリケーション１１５と通信することを可能にする１つまたは２つ以上の通信コネクションを含んでいる。デバイス１００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの入力デバイス１１２を装備していることもある。ディスプレイ、スピーカ、プリンタなどの出力デバイス１１１が含まれていることもある。これらのデバイスはこの分野で周知であるので、ここで詳しく説明することは省略する。ある実施形態では、コンピューティングデバイス１００はレイアウトマネージャアプリケーション２００を含んでいる。レイアウトマネージャアプリケーション２００は図２に詳しく記載されている。] 図２
[0017] 図１に引き続き図２を参照して説明すると、図２はコンピューティングデバイス１００上で動作するレイアウトマネージャアプリケーション２００を示している。レイアウトマネージャアプリケーション２００は、コンピューティングデバイス１００上に置かれているアプリケーションプログラムの１つである。なお、当然に理解されるように、レイアウトマネージャアプリケーション２００は、代替的にまたは付加的に、１つまたは２つ以上のコンピュータ上のコンピュータ実行可能命令としておよび／または図１に示すものと異なるバージョンで具現化することができる。代替的にまたは付加的に、レイアウトマネージャアプリケーション２００の１つまたは２つ以上の部分は、他のコンピュータおよび／またはアプリケーション１１５上のシステムメモリの一部にすることも、コンピュータソフトウェア分野で見られるような他の変形にすることも可能である。] 図１ 図２
[0018] レイアウトマネージャアプリケーション２００はプログラムロジック２０４を含み、これは、本明細書に記載した手法の一部またはすべての実行を担当している。プログラムロジック２０４は、ユーザインタフェースエレメントのサイズと位置のアップデート（更新）を調整するためのロジック２０６（これは図３を参照して以下に説明されている）、エレメントのツリー内のユーザインタフェースエレメントのダーティステートをトラッキング（追跡）するためのロッジ２０８（これは図４乃至図７を参照して以下に説明されている）、エレメントのツリーの影響を受けた部分をアップデートするためのロジック２１０（これは図６を参照して以下に説明されている）、ツリー内のノードで特殊なステートを使用してダーティサブツリーのルートを見つけ、アップデート期間中の無駄な再計算を回避するためのロジック２１２（これは図４乃至図７を参照して以下に説明されている）、およびレイアウトマネージャアプリケーション２００を動作させるための他のロジック２２０を含んでいる。] 図３ 図４ 図６ 図７
[0019] 図３は、２つの異なるノードのダーティサブツリーを有する例示のノードのツリーを示す概略図である。本明細書の中で用いられている「サブツリー」の用語は、ツリー内のより小さなノードのサブセット、別の言い方をすると、ツリー内のツリーを含むものと意味している。本明細書の中で用いられている「ダーティサブツリー」という用語は、ダーティとしてマークされた祖先と子孫の１つまたは２つ以上の連続ノードであって、ダーティでない親ノードをもつノードを１つだけ含むものを意味している。この定義をもっと分かり易くする例をいくつか示すことにする。図３に示す例では、２つのダーティサブツリーが存在する。第一のサブツリーはｃａｎｖａｓ１を含んでいる。ｃａｎｖａｓ１が第一のサブツリーの唯一のメンバであるのは、同じくダーティである近隣の祖先または子孫がそこにないからである。第二のサブツリーにはｃａｎｖａｓ３とＲ４がある。ｃａｎｖａｓ３とＲ４は祖先／子孫の関係があり、連続的であり、ｃａｎｖａｓ３は同じくダーティである近隣の祖先をもたないサブツリーの唯一のメンバである。図６のような、以降の図の一部の説明の中では、ダーティサブツリーという概念を使用することにする。] 図３ 図６
[0020] 図１乃至図３に引き続いて図４乃至図８を参照して説明すると、レイアウトマネージャアプリケーション２００の１つまたは２つ以上の実施形態を実現するためのステージがより詳しく説明されている。いくつかの実施形態では、図４乃至図８のプロセスは、少なくともその一部がコンピューティングデバイス１００のオペレーティングロジックの中で実現されている。図４乃至図５には、祖先変更を使用してレイアウトプロセスをより効率化するハイレベルの例がいくつか示されている。図６乃至図８には、これらの広義概念を例示の実施形態に適用するためのいくつかの手法が詳しく記載されている。] 図１ 図３ 図４ 図５ 図６ 図８
[0021] 次に、図４を参照して説明すると、図４は、祖先変更のステータスを使用してレイアウトプロセス（測定または配置など）をより効率化する際に係わりのあるステージのある実施形態を示すプロセスフロー図である。所与のノードに対してレイアウトプロセスがコールされる（ステージ２４２）。レイアウトマネージャアプリケーション２００は、その所与のノードに対するいずれかの祖先ノードが変更されたかどうかを判断する（ステージ２４４）。いずれかの祖先が変更されていれば（判定ポイント２４６）、変更された祖先の下位にある子孫ノードに対してプロセス中のレイアウトが放棄され（ステージ２４８）、レイアウトプロセスが変更された祖先で再開される（ステージ２４９）。変更された祖先がなければ（判定ポイント）、レイアウトプロセスは子孫の経路を下って行くことにより継続する（ステージ２５０）。] 図４
[0022] 次に、図５を参照して説明すると、図５は、無駄な作業を避けるためにノードのサイズが変更されたとき親ノードをダーティとしてマークする際に係わりのあるステージのある実施形態を示すプロセスフロー図である。指定したノードに対してレイアウトプロセスがスタートされる（ステージ２７２）。そのノードのサイズが変更されていれば（判定ポイント２７４）、指定したノードの親ノードでダーティインジケータがマークされ（ステージ２７８）、現行レイアウトプロセスが放棄され（ステージ２７８）、そのレイアウトプロセスが親ノードで実行される（ステージ２８０）。これについては、他の図に詳しく説明されている。そのノードのサイズが変更されていなければ（判定ポイント２７４）、レイアウトプロセスはそのノードの次の兄弟(sibling)から継続される（ステージ２８２）。] 図５
[0023] 図６は、ダーティサブツリーの処理によってレンダリング直前にレイアウトをアップデートする際に係わりのあるステージのある実施形態を示すプロセスフロー図である。アップデートレイアウトプロセスをスタートすると、レイアウトマネージャ２００は、ウィンドウサイズが変更されたかどうか、またはツリー内のどこかで、エレメントが測定される必要があるかどうか（例えば、測定がダーティである）を判断する（判定ポイント３２２）。ウィンドウは、全スクリーン、スクリーン内のウィンドウ、ブラウザページのエリアなどのように、ユーザインタフェースエレメントとしてそこに表示されるスクリーンのエリアを含むことができる。これらの条件のいずれかが真であれば、ダーティサブツリーのルートノードが測定され（ステージ３２４）、そのあと評価が反復的に再び実行される（各ノードの子を処理するために）。これらの条件のいずれもが真でなければ（判定ポイント３２２）、レイアウトマネージャ２００はツリー内のどこかで、エレメントが配置される必要があるかどうか（例えば、配置がダーティである）を判断する（判定ポイント３２６）。そうであれば、ルートノードが配置され（ステージ３２８）、プロセスがループして判定ポイント３２２まで戻る。] 図６
[0024] ツリー内のどこかで配置がダーティでなければ（判定ポイント３２６）、キュー（待ち行列）に置かれたサイズ変更イベントがファイヤされ（ステージ３３０）、エレメントがそのサイズを変更したことに応答してアプリケーションがオプションのカスタムコードを実行するのを可能にしてから、エレメントがその新サイズで表示される。ツリーがダーティであれば（判定ポイント３３２）、プロセスはループして判定ポイント３２２まで戻る。ツリーがダーティでなければ（判定ポイント３３２）、レイアウトアップデートイベントがファイヤされ（ステージ３３４）、レイアウトアップデートオペレーションが完了したことに応答してアプリケーションがカスタムコードを実行するのを可能にしてから、アップデートしたエレメントのいずれかがその新サイズおよび／または位置で表示される。ツリーがダーティであれば（判定ポイント３３６）、プロセスはループして判定ポイント３２２まで戻る。ツリーがダーティでなければ（判定ポイント３３６）、プロセスは終了する（ステージ３３８）。]
[0025] 次に、図７を参照して説明すると、図７は、指定したノードでレイアウトプロセスを実行する際に係わりのあるいくつかの詳細ステージのある実施形態を示すプロセスフロー図である。指定したノード自体がダーティでなければ（判定ポイント３５２）、レイアウトマネージャ２００は、指定したノードがダーティ子孫を有しているかどうかを確かめるチェックを行い（判定ポイント３５８）、すぐあとに記載されているようにそのダーティ子孫の経路に対する処理を続ける。指定したノード自体がダーティであれば（判定ポイント３５２）、レイアウトプロセスが指定したノードで実行される（ステージ３５４）。祖先ノードがダーティとしてマークされたときは（判定ポイント３５６）、レイアウトプロセスは指定したノードに対して放棄される（ステージ３５７）。] 図７
[0026] 指定したノードでレイアウトを実行したあと祖先ノードがダーティとしてマークされていなければ、レイアウトマネージャ２００は指定したノードがダーティ子孫を有しているかどうかを判断する（判定ポイント３５８）。また、レイアウトマネージャは、指定したノード自身が判定ポイント３５２でダーティと分からなかった場合、指定したノードがダーティ子孫を有しているかどうかを判断する。どちらの場合も、指定したノードがダーティ子孫を有していなければ（判定ポイント３５８）、レイアウトプロセスは終了する（ステージ３６２）。指定したノードがダーティ子孫を有していなければ（判定ポイント３５８）、次の子がリトリーブされ（ステージ３６０）、レイアウトされる（ステージ３６４）。その子をレイアウトしたあと、レイアウトマネージャ２００は、祖先がダーティとしてマークされていたかどうかを判断する（判定ポイント３６６）。そうであれば（判定ポイント３６６）、レイアウトプロセスは放棄される（ステージ３５７）。祖先がダーティとしてマークされていなければ（判定ポイント３６６）、レイアウトマネージャ２００は、そのノード自身がダーティであるかどうかを判断する（判定ポイント３６７）。そのノード自身がダーティであれば（判定ポイント３６７）、レイアウトプロセスはそのノードに対して実行され（ステージ３５４）、レイアウトプロセスに続く他のステージが前述したように実行される。そのノード自体がダーディでなければ（判定ポイント３６７）、追加の子がある場合に次の子が処理される（ステージ３６８）。追加の子がなければ（判定ポイント３６８）、プロセスはループしてダーティサブツリー内の現在の親の次の兄弟ノードの処理まで戻る（ステージ３５２）。]
[0027] ある実施形態では、６つの異なるインジケータが各ノードで維持され、上述した判定のいくつかを行い、アップデートをいかに効率的に処理するかを判断する。６つの例示インジケータを示すと、以下の通りである。
・IsMearureDirtyビット：測定ではノードをダーティとしてマークする
・IsOnPathToMeasureDirtyビット：測定ではダーティ子孫を有しているとしてノードをマークする
・IsArrangeDirtyビット：配置ではノードをダーティとしてマークする
・IsOnPathtoArrangeDirtyビット：配置ではダーティ祖先を有しているとしてノードをマークする
・IsAnsestorDirtyビット：ダーティ祖先を有しているとしてノードをマークする
・IsOnStackビット：そのレイアウト（測定または配置）が進行中であるとマークする]
[0028] 他の実施形態では、より少ないまたは追加のインジケータが使用できる。これらのインジケータは例示の目的で以下のコードサンプルの中で使用されている。このサンプルは、図６と図７に記載のレイアウトプロセスを実行するためにいくつかの例示コードをウォークスルーしている。] 図６ 図７
[0029] LavoutManager ;;UpdateLavout擬似コード
While (true)
{
If (ディスプレイエリアサイズが変更された、またはルートmeasureDirtyまたはonPathToMeasureDirtyフラグがセットされた)
{
pRoot->Measure(ディスプレイエリアサイズ);
}
Else if (ルートはarrangeDirtyまたはonPathToArrangeDirtyフラグがセットされている)
{
pRoot->Arrange(ディスプレイエリアレクタングル);
}
Else
{
If (ファイヤする必要のあるSizeChangedイベントがある)
SizeChangedイベントをファイヤする
If (ルートは測定または配置を要求していない（上記参照）)
LayoutUpdatedイベントをファイヤする
}
Else
Break; Whileループ終了
}]
[0030] CUIElement;;Measure擬似コード

CUIElement::Measure(availableSize)
{
IsOnMeasureStack = true;
IsAncestorDirty = false;

while (true)
{
if (IsMeasureDirty || availableSizeが変更されている)
{
Measurelnternal(availableSize);
If (IsAncestorDirty || IsLayoutSuspended)
Break;
IsOnMeasureDirtyPath = false;
}
Else if (IsOnMeasureDirtyPath)
{
IsOnMeasureDirtyPath = false;
Foreach (子の中の子)
{
If (child->IsMeasureDirty || child-> IsOnMeasureDirtyPath)
{
child->Measure(child-> PreviousConstraint);
}
If (IsAncestorDirty)
{
IsOnMeasureDirtyPath = true; goto Cleanup;
}
If (IsMeasureDirty)
{
Break; // foreachループ終了
}
}
}
Else
Break; // whileループ終了
}
Cleanup:
IsOnMeasureStack = true;
}]
[0031] CUIElement;; Arrange擬似コード

CUIElement: : Arrange(finalRect)
{
IsOnArrangeStack = true;
IsAncestorDirty = false;

while (true)
{
if (いずれかのノードが測定を要求している)
break; // whileループ終了
if (IsArrangeDirty || finalReacが変更されている)
{
ArrangeInternal(availableSize) ;
If (IsAncestorDirty || IsLayoutSuspended)
Break;
IsOnArrangeDirtyPath = false;
}
Else if (IsOnArrangeDirtyPath)
{
IsOnArrangeDirtyPath = false;
Foreach (子の中の子)
{
if (いずれかのエレメントが測定を要求している)
break; // foreachループ終了
if (child->IsArrangeDirty 11 child->IsOnArrangeDirtyPath)
{
child-> Arrange(GetArrangeRect());
}
if (IsAncestorDirty)
{
IsOnArrangeDirtyPath = true;
Break; // foreachループ終了
}
}
}
Else
Break; // // whileループ終了
}
Cleanup:
IsOnArrangeStack = true;
}]
[0032] UpdateLayoutプロシージャで上述したように、測定プロセスは、ディスプレイエリアのサイズが変更されていた場合、またはルートはIsMeasureDirtyまたはonPathToMeasureDirtyフラグが真にセットされている（自身がダーティであるか、ダーティ子孫を有している）場合にコールされる。そうでなければ、ルートはIsArrangeDirtyまたはIsOnPathToArrangeDirtyフラグがセットされている場合、配置プロセスがコールされる。]
[0033] 次に、例示のコードサンプルに示す測定プロセスと配置プロセスとが必要に応じてノードのツリーの中を繰り返しループして、このコードサンプル（および図７）に記載された種々の基準の評価に応じて、祖先では上方に、子孫では下方に測定または配置するかを判断する。] 図７
[0034] 図８は、レイアウトプロセスを無効化する際に係わりがあるステージのある実施形態を示すプロセスフロー図である。指定したノードがすでにダーティであれば（判定ポイント３９２）、レイアウトプロセス無効化は終了する（ステージ３９４）。指定したノードがまだダーティでなければ（判定ポイント３９２）、指定したノードはダーティであるとしてマークされる（ステージ３９６）。指定したノードが現在レイアウトされているノードの祖先であれば（判定ポイント３９８）、このノードから現在レイアウトされているノードまでの直接経路上のすべてのノードはダーティ祖先を有しているとしてマークされる（ステージ４００）。このノードが現在レイアウトされているノードの祖先でなければ（判定ポイント３９８）、レイアウトプロセス無効化は終了する（ステージ４０２）。] 図８
[0035] 以下に示すいくつかの例示ソースコードは、図８のプロセスをより詳細に例示したものである。図示の例では、InvalidateMeasureプロセスは指定したノードがすでにスタック上にあるかどうか（つまり、測定されているかどうか）を確かめるチェックを行い、そうであれば、InvalidateMeasureプロセスは終了する。指定したノードはダーティとしてマークされ、そのあと祖先ノードはダーティであるとしてマークされる。] 図８
[0036] UIElement::InvalidateMeasure()
{
// すでに測定中であればダーティでない
If (CurrentOnStack == this)
{ Return;
}
// 自身をダーティとしてマークする
IsDirty = true;
// すべての祖先上のbreadcrumbsをマークする
Ancestor = this. Parent;
While (Ancestor !=NULL && Ancestor.OnPathToDirty == false)
{
Ancestor.OnPathToDirty = true;
Ancestor = Ancestor.Parent;
}
// いま、スタック上にいれば、ダーティ祖先を有するとして
// スタック上の現在から我々まで（しかし、我々を含まない）をマークする
If (IsOnStack)
{
Child = CurrentOnStack;
While (Child ! = NULL && Child ! = this)
{
Child.AncestoryDirty = true;
Child = Child.Parent;
}
}
}]
[0037] これらのコード例（このコード例に限定されない）は、これらの手法のいくつかを詳しく例示する目的で示されたものにすぎない。コンピュータソフトウェア分野の精通者ならば理解されるように、本明細書に記載の手法の一部またはすべてを実装するためにソースコードを書くことができる方法は他にも多数存在する。]
[0038] 構成上の特徴および／または方法上のアクトに特有の表現で主題を説明してきたが、当然に理解されるように、請求項に定義した主題は、必ずしも上述した特定の特徴またはアクトに限定されない。むしろ、上述した特定の特徴またはアクトは、請求項を実現する形態例として開示されたものである。本明細書に記載されている実施形態の精神の範囲内に属する、および／または請求項による等価技術、変更および改良はすべて保護の対象となるものである。]
[0039] 例えば、コンピュータソフトウェア分野の通常知識を有するものならば認識されるように、本明細書に説明した例は、これらの例に示したものよりも少ないオプションや追加のオプションまたは特徴を含むように１つまたは２つ以上のコンピュータ上で異なる編成にすることが可能である。]

权利要求:

請求項1
コンピュータ実行可能命令を収めたコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、ユーザインタフェースエレメントのツリーにおいてユーザインタフェースエレメントのダーティステートをトラッキングし、前記ツリーは複数のノードを含み、前記ダーティステートは前記ノードの１つまたは２つ以上のダーティサブツリーを特定できるように操作可能であるステップ（２０８）と、ダーティサブツリーの各々についてルートノードを特定するステップ（２１２）と、ツリーの影響を受けた部分を、ダーティツリーの各々について特定されたルートノードから始まってアップデートするステップ（２１０）と、を含むステップをコンピュータに実行させることを特徴とするコンピュータ可読媒体。
請求項2
前記ダーティサブツリーの各々についてルートノードを特定するステップ（２１２）は、ダーティステートおよびツリー内のノードに関連する追加ステートを分析することによって容易化されていることを特徴とする請求項１に記載のコンピュータ可読媒体。
請求項3
前記追加ステートは、ノードのうち選択されたノードがダーティ子孫ノードを有しているか否かを指定する（３５８）インジケータを含んでいることを特徴とする請求項２に記載のコンピュータ可読媒体。
請求項4
前記追加ステートは、ノードのうち選択されたノードがダーティ祖先ノードを有しているか否かを指定する（３５６）インジケータを含んでいることを特徴とする請求項２に記載のコンピュータ可読媒体。
請求項5
追加ノードは、ノードのうち選択されたノードが現在レイアウトされているか否かを指定する（３９８）インジケータを含んでいることを特徴とする請求項２に記載のコンピュータ可読媒体。
請求項6
ダーティステートは、ノードのうち選択されたノードがダーティであるか否かを指定する（３５２）インジケータを含んでいることを特徴とする請求項１のコンピュータ可読媒体。
請求項7
ユーザインタフェースエレメントのツリーの影響を受けた部分をアップデートしたあとユーザインタフェースエレメントを出力デバイス上でレンダリングするステップ（２１０）を含むステップをコンピュータに実行させるためのコンピュータ実行可能命令を、さらに収めていることを特徴とする請求項１に記載のコンピュータ可読媒体。
請求項8
前記アップデートするステップ（２１２）は、ダーティサブツリーの各々について特定されたルートノードからスタートし、親ノードで行なわれたアップデートに起因して、そのあとでオーバライトされるアップデートがダーティサブツリー内の子ノードで実行されないようにすることを特徴とする請求項１に記載のコンピュータ可読媒体。
請求項9
祖先ノード変更のステータスを使用してレイアウトプロセスをより効率化するための方法であって、指定したノードからレイアウトプロセスをスタートするステップ（２４２）と、指定したノードのいずれかの祖先が変更されたかどうかを判断するステップ（２４４）と、指定したノードの少なくとも１つの変更された祖先が特定されたとき、前記変更された祖先のいずれかの子孫ノードで現在実行されているレイアウトプロセスがあれば、そのレイアウトプロセスを放棄し（２４８）、前記変更された祖先でレイアウトプロセスを再開する（２４９）ステップとを含むことを特徴とする方法。
請求項10
指定したノードの少なくとも１つの変更された祖先が特定されないときは、指定したノードの子孫ノードの経路を下っていくことによりレイアウトプロセスを継続するステップ（２５０）をさらに含むことを特徴とする請求項９に記載の方法。
請求項11
指定したノードの少なくとも１つの祖先は、指定したノードの望みのサイズが変更されたために変更され、指定したノードの親ノードはそのあとダーティであるとしてマークされる（３２０）ことを特徴とする請求項１０に記載の方法。
請求項12
指定したノードのいずいれかの祖先が変更されたかどうかの判断を容易にするために複数のインジケータが使用される（３２０）ことを特徴とする請求項９に記載の方法。
請求項13
複数のインジケータの少なくとも１つは、特定のノードがダーティであるか否かを指定している（３５２）ことを特徴とする請求項１２に記載の方法。
請求項14
複数のインジケータの少なくとも１つは、特定のノードがダーティ子孫を有しているか否かを指定している（３５８）ことを特徴とする請求項１２に記載の方法。
請求項15
複数のインジケータの少なくとも１つは、特定のノードにダーティ祖先があるか否かを指定している（３５６）ことを特徴とする請求項１２に記載の方法。
請求項16
前記複数のインジケータの少なくとも１つは、特定のノードが現在レイアウトされているか否かを指定している（３９８）ことを特徴とする請求項１２に記載の方法。
請求項17
指定したノードの少なくとも１つの変更された祖先が特定され、変更された祖先で行なわれたアップデートに起因して、そのあとでオーバライトされる可能性のあるアッップデートは変更された祖先のいずれかの子孫ノードで実行されないように、レイアウトプロセスが放棄される（２７８）ことを特徴とする請求項９に記載の方法。
請求項18
指定したノードに対するレイアウトプロセスを無効化する方法であって、指定したノードがすでにダーティであるかどうかを判断するステップ（３９２）と、指定したノードがまだダーティでないときは、指定したノードをダーティとしてマークし（３９６）、前記指定したノードが現在レイアウトされている少なくとも１つのノードの祖先であるかどうかを判断するステップ（３９８）と、指定したノードが現在レイアウトされている少なくとも１つのノードの祖先であるときは（３９８）、指定したノードから現在レイアウトされているノードまでの直接経路上のすべてのノードはダーティ祖先を有しているが、指定したノードを含んでいないとしてマークするステップ（４００）とを含むことを特徴とする方法。
請求項19
指定したノードがすでにダーティであるときは、無効化レイアウトプロセスを終了するステップ（３９４）をさらに含むことを特徴とする請求項１８に記載の方法。
請求項20
指定したノードは、レイアウトされているノードのスタックに指定したノードが含まれているためにすでにダーティであると判断される（３９２）ことを特徴とする請求項１９に記載の方法。