렌더링 시간 및 성능 측면에서 패널은 어떤 순서로 가장 효율적입니까?

렌더링 시간 및 성능 측면에서 패널은 어떤 순서로 가장 효율적입니까?

---

하나 이상의 패널이 원하는 레이아웃에 적합 할 때가 여러 번 있지만 패널 유형에 따라 렌더링 시간에 차이가 있다는 것을 알고 있습니다.

예를 들어 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는 내용을 렌더링 할 때 측정 및 정렬이라는 두 가지 패스를 만듭니다. 각 패널은이 두 패스 각각에 대해 서로 다른 성능 특성을 갖습니다.

측정 패스의 성능은 정렬을 사용하여 스트레칭을 수용 할 수있는 기능 (또는의 경우 자동 Grid)과 스트레칭 또는 자동 크기 조정 된 자식 수에 따라 패널의 성능에 가장 큰 영향을받습니다 . 배열 패스의 성능은 다른 어린이의 레이아웃 위치와 어린이 수의 상호 작용이 복잡하기 때문에 영향을받습니다.

때로는 주어진 패널이 필요한 레이아웃에 쉽게 적합하지 않습니다. 사용 가능한 공간의 특정 백분율에 각 항목을 배치하기 위해 임의의 수의 항목이 필요한 컨트롤을 만들었습니다. 기본 컨트롤 중 어느 것도이 작업을 수행하지 않습니다. (부모의 실제 크기에 바인딩하여)이를 수행하면 끔찍한 성능이 발생합니다. 캔버스를 기반으로 레이아웃 패널을 만들었으며 최소한의 작업으로 원하는 결과를 얻었습니다 (캔버스의 소스를 복사하고 약 20 줄을 수정했습니다).

사용 가능한 패널 :

• 캔버스

  캔버스 영역을 기준으로 좌표로 자식 요소를 명시 적으로 배치 할 수있는 영역을 정의합니다.

  캔버스는 각 항목에 정적으로 위치가 지정되므로 정렬 패스에 대한 모든 패널의 성능이 가장 우수합니다. 이 패널에는 스트레칭 개념이 없기 때문에 측정 패스도 뛰어난 성능을 발휘합니다. 각 어린이는 단순히 기본 크기를 사용합니다.

• DockPanel

  자식 요소를 서로에 대해 가로 또는 세로로 배열 할 수있는 영역을 정의합니다.

  Dockpanel에는 이전에 추가 한 항목과 비교하여 항목을 하나씩 추가하는 매우 간단한 레이아웃 구성표가 있습니다. 기본적으로 높이 또는 너비는 항목의 기본 크기 (각각 위 / 아래 대 왼쪽 / 오른쪽 기준)에 의해 결정되며 다른 방향은 Dock너비 또는 높이가 정의되지 않은 경우 속성에 의해 결정됩니다 . 중간에서 빠른 측정 단계 및 중간에서 빠른 배열 단계.

• 그리드

  열과 행으로 구성된 유연한 그리드 영역을 정의합니다.

  비례 크기 조정 또는 자동 크기 조정을 사용하는 경우 가장 성능 집약적 인 패널이 될 수 있습니다. 자식 항목 크기 계산은 항목의 기본 크기와 격자로 지정된 레이아웃의 복잡한 조합 일 수 있습니다. 레이아웃은 모든 패널 중에서 가장 복잡합니다. 측정 단계의 경우 중간에서 중간 성능, 정렬 단계의 경우 중간에서 느린 성능.

• StackPanel

  자식 요소를 가로 또는 세로 방향으로 정렬 할 수있는 단일 선으로 정렬합니다.

  StackPanel은 방향과 반대 방향으로 기본 또는 상대 크기를 사용하고 방향 방향으로 기본 크기를 사용하여 자식을 측정합니다 (정렬은이 방향으로 아무것도 수행하지 않습니다). 이것은이 분야에서 중간 단계의 수행자입니다. 배열 패스는 단순히 항목을 순서대로 배치하는 것입니다. 이 패스에서 아마도 두 번째로 좋은 성능 일 것입니다. 측정 단계의 중간 성능 및 레이아웃 단계의 빠른 성능

• 가상화 패널

  자식 데이터 수집을 가상화하는 패널 요소에 대한 프레임 워크를 제공합니다. 이것은 추상 클래스입니다.

  A base class for implementing your own virtualizing panel. Only loads visible items to prevent unneeded use of memory and processor. MUCH more performant for sets of items. Probably slightly less performant for items that fit on the screen due to the bounds checking. The SDK only provides one subclass of this, the VirtualizingStackPanel.

• WrapPanel

  Positions child elements in sequential position from left to right, breaking content to the next line at the edge of the containing box. Subsequent ordering occurs sequentially from top to bottom or right to left, depending on the value of the Orientation property.

  The measure pass is a somewhat complex pass where the largest item for a particular row determines the height of the row and then each item on that row either uses its native height (if it has one) or the height of the row. The layout pass is simple, putting each item one after the other on a row and then continuing onto the next row when there is not enough room for the next item. Medium performance measure pass. Medium to fast performance for the arrangement pass.

References:

Use the Most Efficient Panel where Possible

The complexity of the layout process is directly based on the layout behavior of the Panel-derived elements you use. For example, a Grid or StackPanel control provides much more functionality than a Canvas control. The price for this greater increase in functionality is a greater increase in performance costs. However, if you do not require the functionality that a Grid control provides, you should use the less costly alternatives, such as a Canvas or a custom panel.

From Optimizing Performance: Layout and Design

The layout system completes two passes for each member of the Children collection, a measure pass and an arrange pass. Each child Panel provides its own MeasureOverride and ArrangeOverride methods to achieve its own specific layout behavior.

During the measure pass, each member of the Children collection is evaluated. The process begins with a call to the Measure method. This method is called within the implementation of the parent Panel element, and does not have to be called explicitly for layout to occur.

First, native size properties of the UIElement are evaluated, such as Clip and Visibility. This generates a value named constraintSize that is passed to MeasureCore.

Secondly, framework properties defined on FrameworkElement are processed, which affects the value of constraintSize. These properties generally describe the sizing characteristics of the underlying UIElement, such as its Height, Width, Margin, and Style. Each of these properties can change the space that is necessary to display the element. MeasureOverride is then called with constraintSize as a parameter.

Note There is a difference between the properties of Height and Width and ActualHeight and ActualWidth. For example, the ActualHeight property is a calculated value based on other height inputs and the layout system. The value is set by the layout system itself, based on an actual rendering pass, and may therefore lag slightly behind the set value of properties, such as Height, that are the basis of the input change. Because ActualHeight is a calculated value, you should be aware that there could be multiple or incremental reported changes to it as a result of various operations by the layout system. The layout system may be calculating required measure space for child elements, constraints by the parent element, and so on. The ultimate goal of the measure pass is for the child to determine its DesiredSize, which occurs during the MeasureCore call. The DesiredSize value is stored by Measure for use during the content arrange pass.

The arrange pass begins with a call to the Arrange method. During the arrange pass, the parent Panel element generates a rectangle that represents the bounds of the child. This value is passed to the ArrangeCore method for processing.

The ArrangeCore method evaluates the DesiredSize of the child and evaluates any additional margins that may affect the rendered size of the element. ArrangeCore generates an arrangeSize, which is passed to the ArrangeOverride method of the Panel as a parameter. ArrangeOverride generates the finalSize of the child. Finally, the ArrangeCore method does a final evaluation of offset properties, such as margin and alignment, and puts the child within its layout slot. The child does not have to (and frequently does not) fill the entire allocated space. Control is then returned to the parent Panel and the layout process is complete.

From Measuring and Arranging Children

---

Maybe this will help you.

Not only for panels but also for every application you want to make in WPF.

It concludes WPF drawing & measuring performance.

It also has a drawing test application, results, and conclusions information for different operating systems that you want to target.

---

The panels you mention are Layout panels so a brief overview of the layout system suggests that it's likely not going to be just a simple list of the most efficient panel but how you use the panels that have the largest effect on efficiency and performance.

LayoutSystem_Overview :

At its simplest, layout is a recursive system that leads to an element being sized, positioned, and drawn. More specifically, layout describes the process of measuring and arranging the members of a Panel element's Children collection. Layout is an intensive process. The larger the Children collection, the greater the number of calculations that must be made. Complexity can also be introduced based on the layout behavior defined by the Panel element that owns the collection. A relatively simple Panel, such as Canvas, can have significantly better performance than a more complex Panel, such as Grid.

Each time that a child UIElement changes its position, it has the potential to trigger a new pass by the layout system. Therefore, it is important to understand the events that can invoke the layout system, as unnecessary invocation can lead to poor application performance. The following describes the process that occurs when the layout system is invoked.

1. A child UIElement begins the layout process by first having its core properties measured.

2. Sizing properties defined on FrameworkElement are evaluated, such as Width, Height, and Margin.

3. Panel-specific logic is applied, such as Dock direction or stacking Orientation.

4. Content is arranged after all children have been measured.

5. The Children collection is drawn on the screen.

6. The process is invoked again if additional Children are added to the collection, a LayoutTransform is applied, or the UpdateLayout method is called.

See LayoutSystem_Measure_Arrange for more information on the measuring and arranging of children

LayoutSystem_Performance :

Layout is a recursive process. Each child element in a Children collection gets processed during each invocation of the layout system. As a result, triggering the layout system should be avoided when it is not necessary. The following considerations can help you achieve better performance.

Be aware of which property value changes will force a recursive update by the layout system.

Dependency properties whose values can cause the layout system to be initialized are marked with public flags. AffectsMeasure and AffectsArrange provide useful clues as to which property value changes will force a recursive update by the layout system. In general, any property that can affect the size of an element's bounding box should have a AffectsMeasure flag set to true. For more information, see Dependency Properties Overview.

When possible, use a RenderTransform instead of a LayoutTransform.

A LayoutTransform can be a very useful way to affect the content of a user interface (UI). However, if the effect of the transform does not have to impact the position of other elements, it is best to use a RenderTransform instead, because RenderTransform does not invoke the layout system. LayoutTransform applies its transformation and forces a recursive layout update to account for the new position of the affected element.

Avoid unnecessary calls to UpdateLayout.

The UpdateLayout method forces a recursive layout update, and is frequently not necessary. Unless you are sure that a full update is required, rely on the layout system to call this method for you.

When working with a large Children collection, consider using a VirtualizingStackPanel instead of a regular StackPanel.

By virtualizing the child collection, the VirtualizingStackPanel only keeps objects in memory that are currently within the parent's ViewPort. As a result, performance is substantially improved in most scenarios.

Optimizing Performance: Layout and Design: This article goes into detail on how to build the tree efficiently and gives a simple list of panels based on their complexity

Canvas (least complext = more efficient and better performance)

Grid

Other Panels (more complex = less efficient and worse performance)

Other performance considerations to pay attention to: Ways to improve WPF UI rendering speed

1. Cache everything. Brushes, Colors, Geometries, Formatted Texts, Glyphs. (For example we have two classes: RenderTools and TextCache. Rendering process of each unit addresses to shared instance of both classes. So if two charts have the same text, its preparation is executed just once.)
2. Freeze Freezable, if you are planning to use it for a long time. Especially geometries. Complex unfreezed geometries execute HitTest extremely slow.
3. Choose the fastest ways of rendering of each primitive. For example, there is about 6 ways of text rendering, but the fastest is DrawingContext.DrawGlyphs.
4. Enable Container Recycling. Virtualization brings a lot of performance improvements, but the containers will be disposed and re created, this is the default. But you can gain more performance by recycle containers by setting VirtualizingStackPanel.VirtualizationMode="Recycling"
5. From here: There is no practical limit to the amount of nesting that your application can support, however, it is generally best to limit your application to only use those panels that are actually necessary for your desired layout. In many cases, a Grid element can be used instead of nested panels due to its flexibility as a layout container. This can increase performance in your application by keeping unnecessary elements out of the tree.

참고URL : https://stackoverflow.com/questions/9946811/in-what-order-are-panels-the-most-efficient-in-terms-of-render-time-and-performa