tl; dr要素に子を追加する場合 - theParent.UpdateLayout();を呼び出すと、子のレイアウトが更新されますか？UpdateLayoutはすべての子要素も更新しますか？
長いバージョン
私はその子のプロパティに関するいくつかの情報を取得する要素にUpdateLayoutを呼び出す必要があります。
theParent.Children.Add(child);
theParent.UpdateLayout();
私のテストで見る限り、要素の子供の子供も更新されているようです。つまり、UpdateLayoutは再帰的です。しかし、文書をチェックするUIElement.UpdateLayout私はそれが期待していることは言及していません。さらに、ドキュメントでは、必要な場合を除いて、この方法を使用しないようにしているため、ここでのテストは方法ではないと心配しています。結論として、UpdateLayoutが再帰的であることが保証されていますか？
レイアウトシステムは本質的に再帰的です。ボタンの内容に応じて自動的にサイズを変更するには、子要素（通常はTextBlockラベル）を最初に測定する必要があります。これらの子要素の子も測定する必要があります。
新しいUIElementを作成すると、そのレイアウトは最初は無効になります（つまり「ダーティ」）。これは、要素が「次のレイアウトサイクル中にレイアウトする必要がある」とマークされていることを意味します。レイアウトシステムは、最適化（レイアウトは複雑なビジュアルツリーの場合は特に高価です）とマークされていない要素をスキップします。
子要素をパネルに追加すると、パネルのサイズや位置が子によって影響を受けるため、パネル自体が無効になります（StackPanelとGridではtrueですが、Canvasではそうではありません）。
レイアウト操作がバッチ処理されていることを理解することが重要です。レイアウトパスは高価なオペレーションであるため、要素への更新がそれ以上発生しなくなるまで遅延させるのが最適です。 ListViewに100個のアイテムを追加した場合、毎回100回のレイアウト更新を実行するのではなく、100個のアイテムがリストに追加された後、ある時点で1回の更新だけを実行するとします。
とにかく、UpdateLayoutを呼び出すとすぐにレイアウト遅延レイアウトがパスするまで待つ代わりに、UpdateLayoutが呼び出された要素をルートとするサブツリー内の無効化された要素。
これは、ドキュメントがUpdateLayoutは基本的に順番にInvalidateMeasureとInvalidateArrangeを呼び出すことと同じです
を言うことは興味深いです。
しかし、実際に無効にされた要素の即時更新を強制するのではなく、実際に要素のレイアウトを無効にしないように見えます。彼らはここでは "基本的に"非常に緩やかに使用しています。