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

절대적인 상대 성능 비교를 제공하는 것보다 각 패널의 성능 특성을 설명하는 것이 더 간결하고 이해 가능하다고 생각합니다.

WPF는 내용을 렌더링 할 때 측정 및 정렬이라는 두 가지 패스를 만듭니다. 각 패널은이 두 패스 각각에 대해 서로 다른 성능 특성을 갖습니다.

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

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

사용 가능한 패널 :

• 캔버스

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

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

• DockPanel

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

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

• 그리드

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

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

• StackPanel

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

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

• 가상화 패널

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

  자체 가상화 패널을 구현하기위한 기본 클래스입니다. 메모리와 프로세서의 불필요한 사용을 방지하기 위해 보이는 항목 만로드합니다. 아이템 세트의 성능이 훨씬 뛰어납니다. 경계 확인으로 인해 화면에 맞는 항목의 성능이 약간 떨어질 수 있습니다. SDK는이 하위 클래스 중 하나만 제공합니다 VirtualizingStackPanel.

• 랩 패널

  하위 요소를 왼쪽에서 오른쪽으로 순차적으로 배치하여 내용을 포함하는 상자 가장자리의 다음 줄로 나눕니다. 이후의 순서는 방향 속성 값에 따라 위에서 아래로 또는 오른쪽에서 왼쪽으로 순차적으로 발생합니다.

  측정 단계는 특정 행의 가장 큰 항목이 행의 높이를 결정한 다음 해당 행의 각 항목이 기본 높이 (있는 경우) 또는 행의 높이를 사용하는 다소 복잡한 패스입니다. 레이아웃 패스는 간단하여 각 항목을 하나씩 차례로 배치 한 다음 다음 항목을위한 공간이 충분하지 않으면 다음 행으로 계속 진행합니다. 중간 성능 측정 단계. 어레인지먼트 패스의 중간에서 빠른 성능.

참고 문헌 :

가능하면 가장 효율적인 패널을 사용하십시오

레이아웃 프로세스의 복잡성은 사용하는 패널 파생 요소의 레이아웃 동작을 직접 기반으로합니다. 예를 들어 Grid 또는 StackPanel 컨트롤은 Canvas 컨트롤보다 훨씬 더 많은 기능을 제공합니다. 이러한 기능 향상의 가격은 성능 비용의 증가입니다. 그러나 Grid 컨트롤이 제공하는 기능이 필요하지 않은 경우 Canvas 또는 사용자 정의 패널과 같이 비용이 저렴한 대안을 사용해야합니다.

에서 레이아웃 및 디자인 : 성능 최적화

레이아웃 시스템은 Children 컬렉션의 각 멤버에 대해 두 개의 패스, 소절 패스 및 어레인지 패스를 완료합니다. 각 하위 패널은 고유 한 레이아웃 동작을 달성하기 위해 자체 MeasureOverride 및 ArrangeOverride 메소드를 제공합니다.

측정 단계 동안 Children 컬렉션의 각 구성원이 평가됩니다. 프로세스는 Measure 메서드를 호출하는 것으로 시작합니다. 이 메서드는 부모 Panel 요소의 구현 내에서 호출되며 레이아웃이 발생하기 위해 명시 적으로 호출 할 필요는 없습니다.

먼저 UIElement의 기본 크기 속성 (예 : Clip 및 Visibility)이 평가됩니다. 그러면 MeasureCore로 전달되는 constraintSize라는 값이 생성됩니다.

둘째, FrameworkElement에 정의 된 프레임 워크 속성이 처리되어 constraintSize의 값에 영향을줍니다. 이러한 속성은 일반적으로 높이, 너비, 여백 및 스타일과 같은 기본 UIElement의 크기 특성을 설명합니다. 이러한 각 속성은 요소를 표시하는 데 필요한 공간을 변경할 수 있습니다. 그런 다음 constraintSize를 매개 변수로 사용하여 MeasureOverride가 호출됩니다.

참고 Height 및 Width 속성과 ActualHeight 및 ActualWidth 속성에는 차이가 있습니다. 예를 들어 ActualHeight 속성은 다른 높이 입력 및 레이아웃 시스템을 기반으로 계산 된 값입니다. 이 값은 실제 렌더링 패스를 기준으로 레이아웃 시스템 자체에 의해 설정되므로 입력 변경의 기초가되는 Height와 같은 속성의 설정 값보다 약간 뒤처 질 수 있습니다. ActualHeight는 계산 된 값이므로 레이아웃 시스템에 의한 다양한 작업의 결과로 여러 변경 또는 증분보고 된 변경 사항이있을 수 있습니다. 레이아웃 시스템은 자식 요소에 필요한 측정 공간, 부모 요소에 의한 제약 조건 등을 계산할 수 있습니다. 측정 단계의 궁극적 인 목표는 아동이 DesiredSize를 결정하는 것입니다. 이는 MeasureCore 호출 중에 발생합니다. DesiredSize 값은 콘텐츠 정렬 단계에서 사용하기 위해 Measure에 의해 저장됩니다.

정렬 단계는 Arrange 메서드를 호출하는 것으로 시작합니다. 정렬 단계 동안 부모 패널 요소는 자식의 경계를 나타내는 사각형을 생성합니다. 이 값은 처리를 위해 ArrangeCore 메소드로 전달됩니다.

ArrangeCore 메서드는 자식의 DesiredSize를 평가하고 요소의 렌더링 된 크기에 영향을 줄 수있는 추가 여백을 평가합니다. ArrangeCore는 배열의 ArrangeOverride 메소드에 매개 변수로 전달되는 배열 크기를 생성합니다. ArrangeOverride는 자식의 finalSize를 생성합니다. 마지막으로 ArrangeCore 메서드는 여백 및 정렬과 같은 오프셋 속성을 최종 평가하고 자식을 레이아웃 슬롯에 배치합니다. 자식은 할당 된 전체 공간을 채울 필요가 없으며 자주하지 않습니다. 그런 다음 컨트롤이 부모 패널로 돌아가고 레이아웃 프로세스가 완료됩니다.

에서 어린이를 측정 및 정렬

답변