[解決済み] レンダリング時間やパフォーマンスの面で最も効率的なパネルはどのような順番になりますか？

質問

複数のパネルがレイアウトに適している場合が多々ありますが、パネルの種類によってレンダリング時間に差があることは知っています。

たとえば MSDN には次のように書かれています。

比較的単純な Panel のような Canvas のように、より複雑なものよりも より複雑な Panel のような Grid .

では、レンダリング時間とパフォーマンスの観点から、WPF パネルはどのような順序で最も効率的なのでしょうか。

WPF パネルです。

• Canvas
• DockPanel
• Grid
• UniformGrid
• StackPanel
• WrapPanel
• VirtualizingPanel / VirtualizingStackPanel

ネットのどこかでこのリストを見たのは確かなのですが、今は見つかりません。

私が探している理想的な答えは、最も速くレンダリングされる順番でパネルのリストを提供してくれることです。私は、子の数がパネルの効率に大きな影響を与えることを理解しているので、この質問のために、各パネルにのみ Label / TextBox のペアです。

さらに、特定の条件に基づいて他のパネルよりも優れたパフォーマンスを発揮する特定のパネルなど、例外のリストが欲しいです。

更新

を元にまとめると 回答 に基づいて要約すると、パネルのパフォーマンスは子アイテムの数とレイアウトに基づいていますが、一般的に最も速いから最も遅いまでのリストは次のとおりです。

• Canvas
• StackPanel
• WrapPanel
• DockPanel
• Grid

さらに VirtualizingPanel / VirtualizingStackPanel は、常に画面に収まらない多くの項目がある場合に使用されるべきです。

を読むことを強くお勧めします。 受諾回答 を読むことを強くお勧めします。

どのように解決するのですか？

絶対的な相対性能比較をしようとするよりも、各パネルの性能特性を説明する方が簡潔でわかりやすいと思います。

WPF はコンテンツをレンダリングするときに 2 つのパスを作成します。Measure と Arrange です。 各パネルは、この 2 つのパスのそれぞれについて異なるパフォーマンス特性を持っています。

測定パスのパフォーマンスは、アラインメントを使用してストレッチに対応するパネルの能力によって最も影響を受けます (または Grid を使用してストレッチに対応する能力、および次にストレッチまたは自動サイズ設定される子の数によって影響を受けます。 アレンジ パスのパフォーマンスは、異なる子のレイアウト位置と、もちろん子の数の間の相互作用の複雑さによって影響を受けます。

時には、与えられたパネルが必要なレイアウトに容易に適合しないことがあります。 私は、任意の数のアイテムをそれぞれ利用可能なスペースの特定の割合で配置する必要があるコントロールを作成しました。 デフォルトのコントロールは、どれもこれを行いません。 親の実際のサイズにバインドして）これをさせようとすると、ひどいパフォーマンスになります。 私はキャンバスに基づいてレイアウト パネルを作成し、最小限の作業で希望する結果を達成しました (キャンバスのソースをコピーし、そのうちの約 20 行を変更しました)。

利用可能なパネル。

• キャンバス

  子要素を明示的に配置できる領域を定義します。 子要素を明示的に配置できる領域を定義します。

  Canvas は、各アイテムに静的に場所が割り当てられるため、アレンジ パスのすべてのパネルの中で最高のパフォーマンスを持っています。 各子要素は単にそのネイティブ サイズを使用するため、このパネルにはストレッチの概念がないため、measure パスも優れたパフォーマンスを持っています。

• DockPanel

  子要素を水平または垂直に並べることができる領域を定義します。 子要素を相対的に水平または垂直に配置できる領域を定義します。

  Dockpanel は、アイテムが追加された前のアイテムに関連して一つずつ追加される、非常にシンプルなレイアウトスキームを持っています。 デフォルトでは、高さまたは幅はアイテムのネイティブサイズによって決定され (それぞれ Top/Bottom と Left/Right に基づく)、その他の方向は Dock プロパティによって決定されます。 中速から高速のメジャーパスと中速から高速のアレンジメントパス。

• グリッド

  列と行で構成される柔軟なグリッド領域を定義します。

  プロポーショナル・サイジングまたはオート・サイジングが使用される場合、これは最もパフォーマンス集中型のパネルになる可能性があります。 子アイテムのサイズの計算は、アイテムのネイティブ サイズとグリッドによって指定されたレイアウトの複雑な組み合わせになることがあります。 また、レイアウトはすべてのパネルの中で最も複雑です。 メジャー パスでは低速から中速のパフォーマンス、アレンジメント パスでは低速から中速のパフォーマンスとなります。

• スタックパネル

  子要素を一列に並べます。 子要素を一本の線に並べ、水平または垂直に方向付けることができます。

  StackPanel は、その向きから反対方向にネイティブ サイズまたは相対サイズ、およびその向きの方向にネイティブ サイズのいずれかを使用してその子を測定します (アライメントはこの方向には何も行いません)。 このため、この分野では中堅のパフォーマーになります。 アレンジメントパスは、シンプルに、アイテムを順番に並べていくだけです。 このパスの性能としては、おそらく2番手。 メジャー パスは中程度のパフォーマンス、レイアウト パスは高速なパフォーマンスです。

• 仮想化パネル

  子データコレクションを仮想化するPanel要素のためのフレームワークを提供します。これは抽象クラスです。

  独自の仮想化パネルを実装するための基底クラスです。 メモリとプロセッサの不要な使用を防ぐために、可視のアイテムのみをロードします。 アイテムのセットに対して非常に高いパフォーマンスを発揮します。 おそらく、境界チェックのため、画面に収まるアイテムのパフォーマンスはわずかに低くなります。 SDKは、このサブクラスを1つだけ提供します。 VirtualizingStackPanel .

• ラップパネル

  子要素を左から右へ順番に配置し、コンテンツを含むボックスの端で次の行に分割します。後続の順序は順次発生します。 の値に応じて、上から下へ、または右から左へと順次発生します。 Orientationプロパティの値によって異なります。

  メジャー パスはやや複雑なパスで、特定の行の最大のアイテムが行の高さを決定し、その行の各アイテムは固有の高さ (それがある場合) または行の高さを使用します。 レイアウトパスは単純で、各アイテムを行に次々と配置し、次のアイテムを配置するスペースがない場合は次の行に進みます。 中程度の性能の対策パス 配置パスのパフォーマンスは中～高速です。

リファレンスです。

可能な限り最も効率的なパネルを使用する

レイアウト処理の複雑さは、使用する Panel 派生要素のレイアウト動作に直接基づいています。 の動作に直接基づいています。たとえば、Grid または StackPanel コントロールは Canvas コントロールよりもはるかに多くの機能を提供します。この機能性の増加の代償として パフォーマンス・コストの増加です。しかし、Grid コントロールが提供する機能を必要としない場合 グリッド・コントロールが提供する機能を必要としない場合は、Canvasコントロールなど キャンバスやカスタムパネルなど、より安価な代替手段を使用する必要があります。

から パフォーマンスを最適化する。レイアウトとデザイン

レイアウトシステムは、Children コレクションの各メンバーに対して、メジャーパスとアレンジパスの 2 つのパスを実行します。各子パネル は、独自の MeasureOverride と ArrangeOverride メソッドを提供し、独自のレイアウト動作を実現します。 メソッドを提供し、独自のレイアウト動作を実現します。

メジャーパスの間、Children コレクションの各メンバーが評価されます。 の各メンバーが評価されます。この処理は、Measure メソッドの呼び出しから始まります。この メソッドは、親である Panel 要素の実装内で呼び出され、レイアウトが発生するために明示的に呼び出される必要はありません。 が発生します。

まず、UIElementのネイティブサイズのプロパティが評価されます。 ClipおよびVisibilityなどです。これにより、constraintSize という名前の値が生成され という値が生成され、MeasureCore に渡されます。

次に、FrameworkElement で定義されたフレームワークのプロパティが処理されます。 処理され、それは constraintSize の値に影響を与えます。これらのプロパティは は、一般に、基礎となる UIE 要素のサイズ特性を記述します。 UIElementの高さ、幅、マージン、スタイルなどのサイズ特性を記述します。これらの各 これらのプロパティは、要素を表示するために必要なスペースを変更することができます。 要素を表示するために必要なスペースを変更できます。MeasureOverride は、constraintSize をパラメータとして呼び出されます。 をパラメータとして呼び出されます。

注意 高さと幅のプロパティとActualHeightとActualWidthの間には違いがあります。 とActualHeight、ActualWidthのプロパティには違いがあります。例えば、ActualHeight プロパティは、他の高さ入力やレイアウトシステムに基づく計算値です。 レイアウトシステムに基づいて計算された値です。この値は、レイアウト・システム自体によって設定され、実際のレンダリング・パスに基づきます。 実際のレンダリングパスに基づき、レイアウトシステム自体によって設定されるため、Height などのプロパティの設定値より若干遅れる場合があります。 高さなどのプロパティの設定値より若干遅れることがあります。 の設定値より若干遅れることがある。ActualHeightは計算値であるため、以下の点に注意する必要があります。 様々な操作の結果、複数の、またはインクリメンタルな変更が報告される可能性があることに注意してください。 レイアウトシステムによるさまざまな操作の結果、ActualHeightに複数の、または増分的な変更が報告される可能性があることに注意してください。レイアウトシステムは レイアウトシステムは、子要素に必要な寸法スペース、親要素による制約、および 要素、親要素による制約など、必要な測定スペースを計算している可能性があります。最終的な メジャー・パスの最終的な目標は、子要素がそのサイズを決定することです。 これは、MeasureCore 呼び出し時に発生します。DesiredSize の値は、コンテンツのアレンジメント・パスで使用するために Measure によって保存されます。

arrange パスは、Arrange メソッドの呼び出しから始まります。アレンジ パスでは アレンジ パスでは、親である Panel 要素が子の境界を表す矩形を生成します。 を生成します。この値は ArrangeCore メソッドに渡され、処理されます。

ArrangeCore メソッドは、子の DesiredSize を評価し、子のレンダリングサイズに影響を与える可能性のある追加の余白を評価します。 要素のレンダリングサイズに影響を与える可能性のある追加の余白を評価します。 を評価します。ArrangeCore は arrangeSize を生成し、これを パラメータとして Panel の ArrangeOverride メソッドに渡されます。 ArrangeOverride は子要素の finalSize を生成します。最後に 最後に、ArrangeCore メソッドは、マージンやアライメントなどのオフセット プロパティの最終評価を行い の最終評価を行い、子プロセスをそのレイアウトスロット内に配置します。 子プロセスは、割り当てられたスペース全体を埋める必要はありません（多くの場合、そうではありません）。 を埋める必要はありません（多くの場合、割り当てられたスペース全体を埋めることはありません）。その後、制御が親パネルに戻され、レイアウト処理が完了します。 レイアウト処理が完了します。

から 子供の計測と配置