В каком порядке панели наиболее эффективны с точки зрения времени и производительности?

Ответ 1

Я думаю, что более кратко и понятно описать характеристики производительности каждой панели, чем пытаться дать абсолютное относительное сравнение производительности.

WPF делает два прохода при рендеринге контента: Measure и Arrange. Каждая панель имеет разные рабочие характеристики для каждого из этих двух проходов.

На эффективность прохода меры больше всего влияет способность панели приспосабливаться к растяжению с использованием выравниваний (или "Авто" в случае Grid), а затем количество растягиваемых или автоматически измеряемых дочерних элементов. На производительность прохода Arrange влияет сложность взаимодействия между расположением макета разных дочерних элементов и, конечно, количеством дочерних элементов.

Иногда данные панели не легко поддаются нужной компоновке. Я создал элемент управления, для которого требовалось произвольное количество элементов, каждый из которых должен располагаться в определенном проценте доступного пространства. Ни один из элементов управления по умолчанию не делает этого. Попытка заставить их сделать это (посредством привязки к фактическому размеру родителя) приводит к ужасной производительности. Я создал панель макета на основе Canvas, которая достигла желаемого результата с минимальными затратами (я скопировал исходный текст для холста и изменил около 20 строк).

Доступные панели:

• холст

  Определяет область, в которой вы можете явно расположить дочерние элементы по координатам относительно области Canvas.

  Холст имеет наилучшую производительность среди всех панелей для прохода аранжировки, поскольку каждому элементу статически назначается место. Проход измерения также имеет отличные характеристики, поскольку в этой панели нет концепции растяжения; каждый ребенок просто использует свой родной размер.

• DockPanel

  Определяет область, в которой вы можете расположить дочерние элементы по горизонтали или по вертикали относительно друг друга.

  Dockpanel имеет очень простую схему компоновки, в которой элементы добавляются один за другим относительно предыдущего добавленного элемента. По умолчанию высота или ширина определяется собственным размером элемента (на основе сверху/снизу и слева/справа соответственно), а другое направление определяется свойством Dock если ширина или высота не определены. Пропуск от среднего до быстрого и проход от среднего до быстрого.

• сетка

  Определяет гибкую область сетки, которая состоит из столбцов и строк.

  Это может быть панель с наибольшей производительностью, если используется пропорциональный или автоматический размер. Расчет размера дочернего элемента может представлять собой сложную комбинацию собственного размера элемента и макета, заданного сеткой. Компоновка также является самой сложной из всех панелей. Производительность от медленной до средней для прохода меры и производительность от медленной до средней для прохода схемы.

• StackPanel

  Объединяет дочерние элементы в одну строку, которая может быть ориентирована горизонтально или вертикально.

  StackPanel измеряет свои дочерние элементы, используя собственные или относительные размеры в противоположном направлении от своей ориентации и собственные размеры в направлении своей ориентации (выравнивание ничего не делает в этом направлении). Это делает его исполнителем среднего уровня в этой области. Порядок Аранжировки - это просто, просто выкладывая предметы по порядку. Вероятно, второе лучшее выступление для этого прохода. Средняя производительность для прохода измерения и высокая производительность для прохода макета.

• VirtualizingPanel

  Предоставляет платформу для элементов Panel, которые виртуализируют их дочерний сбор данных. Это абстрактный класс.

  Базовый класс для реализации вашей собственной панели виртуализации. Загружает только видимые элементы, чтобы предотвратить ненужное использование памяти и процессора. НАМНОГО более производительный для наборов предметов. Вероятно, немного менее производительный для элементов, которые помещаются на экране из-за проверки границ. SDK предоставляет только один подкласс этого, VirtualizingStackPanel.

• WrapPanel

  Позиционирует дочерние элементы в последовательном положении слева направо, разбивая содержимое на следующую строку на краю вмещающего блока. Последующее упорядочение происходит последовательно сверху вниз или справа налево, в зависимости от значения свойства Orientation.

  Проход меры представляет собой довольно сложный проход, в котором самый большой элемент для конкретной строки определяет высоту строки, а затем каждый элемент в этой строке либо использует свою собственную высоту (если она есть), либо высоту строки. Этап макета прост: размещение каждого элемента один за другим в ряду, а затем переход к следующему ряду, когда для следующего элемента недостаточно места. Мера средней производительности пройти. Средняя и высокая производительность для прохода аранжировки.

Рекомендации:

Используйте наиболее эффективную панель, где это возможно

Сложность процесса макета напрямую зависит от поведения макета используемых вами производных от Panel элементов. Например, элемент управления Grid или StackPanel предоставляет гораздо больше функциональных возможностей, чем элемент управления Canvas. Ценой такого увеличения функциональности является увеличение затрат на производительность. Однако если вам не требуются функции, предоставляемые элементом управления Grid, следует использовать менее дорогостоящие альтернативы, например Canvas или пользовательскую панель.

От оптимизации производительности: макет и дизайн

Система макетов выполняет два прохода для каждого члена коллекции Children, проход для измерения и проход для аранжировки. Каждая дочерняя панель имеет свои собственные методы MeasureOverride и ArrangeOverride для достижения своего собственного поведения макета.

Во время прохождения мероприятия оценивается каждый член коллекции Children. Процесс начинается с вызова метода Measure. Этот метод вызывается в реализации родительского элемента Panel, и его не нужно явно вызывать для создания макета.

Сначала оцениваются свойства собственного размера UIElement, такие как Clip и Visibility. Это создает значение с именем constraintSize, которое передается в MeasureCore.

Во-вторых, обрабатываются свойства платформы, определенные в FrameworkElement, что влияет на значение constraintSize. Эти свойства обычно описывают характеристики размеров базового элемента UIElement, такие как его высота, ширина, поля и стиль. Каждое из этих свойств может изменить пространство, необходимое для отображения элемента. MeasureOverride затем вызывается с constraintSize в качестве параметра.

Примечание. Существуют различия между свойствами высоты и ширины, а также ActualHeight и ActualWidth. Например, свойство ActualHeight является вычисленным значением, основанным на других параметрах высоты и системе макетов. Значение задается самой системой макетов на основе фактического прохода рендеринга и поэтому может немного отставать от заданного значения свойств, таких как Высота, которые являются основой изменения ввода. Поскольку ActualHeight является вычисляемым значением, вы должны знать, что в него могут быть внесены множественные или инкрементные изменения в результате различных операций системы макетов. Система макета может вычислять требуемое пространство мер для дочерних элементов, ограничения родительским элементом и так далее. Конечная цель прохода меры - дать ребенку возможность определить его DesiredSize, который происходит во время вызова MeasureCore. Значение DesiredSize сохраняется Measure для использования во время прохода упорядочения контента.

Проход аранжировки начинается с вызова метода аранжировки. Во время прохода аранжировки родительский элемент Panel создает прямоугольник, представляющий границы дочернего элемента. Это значение передается в метод ArrangeCore для обработки.

Метод ArrangeCore оценивает DesiredSize дочернего элемента и оценивает любые дополнительные поля, которые могут повлиять на размер элемента, который отображается. ArrangeCore генерируетrangeSize, который передается методу ArrangeOverride Panel в качестве параметра. ArrangeOverride генерирует finalSize дочернего элемента. Наконец, метод ArrangeCore выполняет окончательную оценку свойств смещения, таких как поля и выравнивание, и помещает дочерний элемент в свой слот макета. Ребенок не должен (и часто не) заполняет все выделенное пространство. Затем элемент управления возвращается в родительскую панель, и процесс верстки завершен.

Из измерения и аранжировки детей

Ответ 2

Может быть, это поможет вам.

Не только для панелей, но и для любого приложения, которое вы хотите сделать в WPF.

Он завершает WPF рисунок и измерения производительности.

Он также содержит приложение для тестирования чертежей, результаты и выводы для различных операционных систем, на которые вы хотите ориентироваться.

Ответ 3

Панели, которые вы упоминаете, это панели макета, поэтому краткий обзор системы компоновки предполагает, что это скорее всего не просто список наиболее эффективной панели, а то, как вы используете панели, которые оказывают наибольшее влияние на эффективность и производительность.

LayoutSystem_Overview:

В своем простейшем, макет - это рекурсивная система, которая приводит к тому, что элемент будет подгоняться, позиционироваться и рисоваться. Более конкретно, в макете описывается процесс измерения и организации элементов коллекции "Элемент группы элементов". Макет - это интенсивный процесс. Чем больше коллекция "Дети", тем больше количество вычислений, которые должны быть сделаны. Сложность также может быть введена на основе поведения макета, определенного элементом Panel, который владеет коллекцией. Сравнительно простая панель, например Canvas, может иметь значительно лучшую производительность, чем более сложная панель, например Grid.

Каждый раз, когда дочерний UIElement меняет свое положение, он может инициировать новый проход системой макета. Поэтому важно понимать события, которые могут вызвать систему компоновки, поскольку ненужный вызов может привести к плохой производительности приложения. Ниже описывается процесс, который возникает при вызове системы макета.

1. Ребенок UIElement начинает процесс компоновки, сначала измеряя его основные свойства.

2. Оцениваются свойства калибровки, определенные в FrameworkElement, такие как ширина, высота и маржа.

3. Используется панель-специфическая логика, такая как ориентация док-станции или ориентация укладки.

4. Содержимое упорядочивается после измерения всех детей.

5. Коллекция "Дети" рисуется на экране.

6. Этот процесс вызывается снова, если к коллекции добавляются дополнительные дети, применяется LayoutTransform или вызывается метод UpdateLayout.

Подробнее о измерении и организации детей см. LayoutSystem_Measure_Arrange

LayoutSystem_Performance:

Макет - это рекурсивный процесс. Каждый дочерний элемент в коллекции Children обрабатывается во время каждого вызова системы макета. В результате при запуске системы компоновки следует избегать, когда это не требуется. Следующие соображения могут помочь вам достичь лучшей производительности.

Имейте в виду, какие изменения значений свойств заставят рекурсивное обновление системой компоновки.

Свойства зависимостей, значения которых могут привести к инициализации системы макета, отмечены общедоступными флагами. AffectsMeasure и AffectsArrange предоставляют полезные подсказки относительно того, какие изменения стоимости свойств заставят рекурсивное обновление системой макета. В общем случае любое свойство, которое может влиять на размер ограничивающей рамки элемента, должно иметь флаг AffectsMeasure, установленный в true. Дополнительные сведения см. В разделе Обзор свойств зависимостей.

По возможности используйте RenderTransform вместо LayoutTransform.

LayoutTransform может быть очень полезным способом повлиять на содержимое пользовательского интерфейса (UI). Однако, если эффект преобразования не должен влиять на положение других элементов, лучше использовать RenderTransform вместо этого, поскольку RenderTransform не вызывает систему компоновки. LayoutTransform применяет его преобразование и заставляет рекурсивное обновление макета учитывать новую позицию затронутого элемента.

Избегайте ненужных вызовов UpdateLayout.

Метод UpdateLayout заставляет рекурсивное обновление макета и часто не требуется. Если вы не уверены, что требуется полное обновление, полагайтесь на систему макета, чтобы вызвать этот метод для вас.

При работе с большой дочерней коллекцией, используйте вместо Virtual StackPanel VirtualizationStackPanel.

Виртуализируя дочернюю коллекцию, VirtualizingStackPanel сохраняет только объекты в памяти, которые в настоящее время находятся в родительском ViewPort. В результате в большинстве сценариев производительность существенно улучшается.

Оптимизация производительности: макет и дизайн: В этой статье подробно рассказывается о том, как эффективно строить дерево и дает простой список панелей на основе их сложности.

Холст (наименьшее дополнение = более эффективная и лучшая производительность)

Сетка

Другие панели (более сложные = менее эффективная и худшая производительность)

Другие соображения производительности, на которые следует обратить внимание: Способы улучшения скорости отображения пользовательского интерфейса WPF

• Загрузите все. Кисти, Цвета, Геометрия, Отформатированные Тексты, Символы. (Например, у нас есть два класса: RenderTools и TextCache. Процесс рендеринга каждого элемента адресуется к общему экземпляру обоих классов. Поэтому, если две диаграммы имеют один и тот же текст, его подготовка выполняется только один раз.)
• Freeze Freezable, если вы планируете использовать его в течение длительного времени. Особенно геометрия. Сложные незамерзающие геометрии выполняют HitTest чрезвычайно медленно.
• Выберите самые быстрые способы рендеринга каждого примитива. Например, существует около 6 способов рендеринга текста, но самым быстрым является DrawingContext.DrawGlyphs.
• Включить переработку контейнеров. Виртуализация приносит много улучшений производительности, но контейнеры будут удалены и созданы повторно, это значение по умолчанию. Но вы можете получить больше производительности за счет контейнеров с переработкой, установив VirtualizingStackPanel.VirtualizationMode = "Утилизация"
• Из здесь: практического ограничения на количество вложений, которое может поддерживать ваше приложение, не существует, однако, как правило, лучше всего ограничить ваше приложение использует только те панели, которые действительно необходимы для вашего желаемого макета. Во многих случаях элемент Grid можно использовать вместо вложенных панелей из-за его гибкости в качестве контейнера компоновки. Это может повысить производительность вашего приложения, оставив ненужные элементы из дерева.