В каком порядке панели наиболее эффективны с точки зрения времени рендеринга и производительности? - PullRequest
116 голосов
/ 30 марта 2012

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

Например, MSDN утверждает, что

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

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

Панели WPF:

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

Я почти уверен, что видел этот список где-то в Интернете, но сейчас не могу его найти.

Идеальный ответ, который я ищу, - предоставить мне список панелей в том порядке, в котором они будут отображаться быстрее всего. Я понимаю, что количество дочерних элементов является важным фактором в том, насколько эффективны панели, поэтому ради этого вопроса предположим, что каждая панель имеет только пару Label / TextBox.

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

Обновление

Подводя итог на основании принятого ответа ниже, производительность панели основана на количестве и расположении дочерних элементов, однако в целом список от самого быстрого до самого медленного:

  • Canvas
  • StackPanel
  • WrapPanel
  • DockPanel
  • Grid

Кроме того, всегда следует использовать VirtualizingPanel / VirtualizingStackPanel, если на экране много предметов, которые не всегда умещаются.

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

Ответы [ 3 ]

118 голосов
/ 03 апреля 2012

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

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

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

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

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

  • Canvas

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

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

  • DockPanel

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

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

  • Сетка

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

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

  • StackPanel

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

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

  • VirtualizingPanel

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

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

  • WrapPanel

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

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

Ссылка:

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

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

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

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

Во время прохождения мероприятия каждый член коллекции «Дети» оценены. Процесс начинается с вызова метода Measure. это метод вызывается в рамках реализации родительской панели элемент, и не должен вызываться явно для макета происходят.

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

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

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

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

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

С Измерение и расположение дочерних элементов

11 голосов
/ 07 апреля 2012

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

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

В нем приводятся результаты рисования и измерения WPF.

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

7 голосов
/ 03 апреля 2012

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

LayoutSystem_Overview :

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

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

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

2. Оцениваются свойства размеров, определенные в FrameworkElement, такие как Width, Height и Margin.

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 вызывает рекурсивное обновление макета и часто не требуется. Если вы не уверены, что требуется полное обновление, положитесь на систему макетов, чтобы вызвать этот метод для вас.

При работе с большой коллекцией Children рассмотрите возможность использования VirtualizingStackPanel вместо обычной StackPanel.

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

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

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

Сетка

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

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

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