У якому порядку панелі є найбільш ефективними з точки зору часу візуалізації та продуктивності?

Є багато разів, коли для макета, який я хочу, підійде більше, ніж одна панель, однак я знаю, що для різних типів панелей є різниця у часі візуалізації.

Наприклад, MSDN стверджує, що

Порівняно простий Panel, такий як Canvas, може мати значно кращі показники, ніж складніший Panel, наприклад Grid.

Отже, з точки зору часу візуалізації та продуктивності, в якому порядку панелі WPF є найбільш ефективними?

Панелі WPF:

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

Я досить впевнений, що я десь в Інтернеті побачив список цього, але зараз не можу його знайти.

Ідеальна відповідь, яку я шукаю, надав би мені список панелей у тому порядку, який вони зробили б швидше. Я розумію, що кількість дітей є важливим фактором ефективності роботи панелей, тому для цього питання припустимо, що для кожної групи є лише пара Label/ TextBoxпара.

Крім того, я хотів би перелік винятків, таких як конкретні панелі, які працюють краще, ніж інші, на основі певних умов.

Оновлення

Підсумовуючи на основі прийнятої відповіді нижче, продуктивність панелі базується на кількості та компонуванні дочірніх елементів, однак загалом список від найшвидшого до найповільнішого:

• Canvas
• StackPanel
• WrapPanel
• DockPanel
• Grid

Крім того, a VirtualizingPanel/ VirtualizingStackPanelзавжди слід використовувати, якщо є багато елементів, які не завжди вміщуються на екрані.

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

Я думаю, що більш коротко і зрозуміло описати характеристики продуктивності кожної панелі, ніж спробувати дати абсолютне порівняльне порівняння продуктивності.

WPF робить два пропуски при візуалізації вмісту: Виміряти та Впорядкувати. Кожна панель має різні характеристики продуктивності для кожного з цих двох проходів.

На ефективність проходу вимірювання найбільше впливає здатність панелі розміщувати розтягування за допомогою вирівнювання (або Авто в разі Grid), а потім кількість дітей, які розтягуються або мають розмір авто. На ефективність переходу «Впорядкувати» впливає складність взаємодії між розташуванням макетів різних дітей, а потім, звичайно, кількістю дітей.

Часом дані панелі не легко піддаються необхідній компоновці. Я створив елемент управління, який потребував довільної кількості елементів, щоб кожен розміщувався у певному відсотку наявного простору. Жоден із елементів за замовчуванням не робить цього. Спроба змусити їх зробити це (через прив’язку до фактичного розміру батьків) призводить до жахливої ​​продуктивності. Я створив панель макета на основі Canvas, яка досягла бажаного результату за мінімальної роботи (я скопіював джерело для полотна і змінив близько 20 рядків).

Доступні панелі:

• Полотно

  Визначає область, в межах якої ви можете чітко розташувати дочірні елементи за координатами відносно області Canvas.

  Полотно має найкращі показники з усіх панелей для оформлення проходу, оскільки кожному елементу статично призначено місце розташування. Прохідний показник також має чудові показники, оскільки в цій панелі немає концепції розтягування; кожна дитина просто використовує свій рідний розмір.

• DockPanel

  Визначає область, в межах якої можна розташувати дочірні елементи або по горизонталі, або по вертикалі, відносно один одного.

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

• Сітка

  Визначає гнучку область сітки, яка складається з стовпців і рядків.

  Це може бути найефективніша панель, якщо використовується пропорційне розмір або автоматичне розмір. Обчислення розміру дочірнього предмета може бути складною комбінацією нативного розміру елемента та макета, визначеного сіткою. Макет - це також найскладніший з усіх панелей. Повільна до середньої продуктивності для проходу вимірювання та повільна до середньої продуктивності для проходу вимірювання.

• StackPanel

  Впорядковує дочірні елементи в єдину лінію, яка може бути орієнтована горизонтально або вертикально.

  StackPanel вимірює своїх дітей, використовуючи або рідне, або відносне розмір у протилежному напрямку від орієнтації та нативного розміру у напрямку його орієнтації (вирівнювання нічого не робить у цьому напрямку). Це робить її виконавцем середнього рівня в цій галузі. Пропуск домовленості - це просто, просто викладаючи елементи по порядку. Мабуть, друга найкраща вистава для цього проходу. Середня продуктивність для проходу вимірювання та швидка продуктивність для проходу макета.

• VirtualizingPanel

  Забезпечує основу для елементів панелі, які віртуалізують збір даних їхніх дітей. Це абстрактний клас.

  Базовий клас для реалізації вашої власної панелі віртуалізації. Завантажує лише видимі елементи, щоб запобігти непотрібному використанню пам'яті та процесора. МНОГО ефективніше для наборів предметів. Можливо, трохи менш ефективні для предметів, які поміщаються на екрані через перевірку меж. SDK надає лише один підклас цього, the VirtualizingStackPanel.

• WrapPanel

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

  Пропуск міри - це дещо складний прохід, де найбільший елемент для певного рядка визначає висоту рядка, а потім кожен елемент у цьому рядку або використовує свою власну висоту (якщо вона має), або висоту рядка. Пропуск макета простий, розміщуючи кожен елемент один за одним на ряду, а потім продовжуючи переходити до наступного ряду, коли для наступного елемента не вистачає місця. Пропуск середньої продуктивності. Середня швидкість та швидкість роботи для оформлення.

Список літератури:

Використовуйте найефективнішу панель, де це можливо

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

Від оптимізації продуктивності: макет та дизайн

Система компонування доповнює два пропуски для кожного учасника дитячої колекції, мірний пропуск та упорядкований пропуск. Кожна дочірня панель пропонує свої власні методи MeasureOverride та ArrangeOverride для досягнення власної поведінки у компонуванні.

Під час проходження заходів оцінюється кожен член колекції «Діти». Процес починається з виклику методу «Міра». Цей метод викликається в рамках реалізації батьківського елемента Panel, і його не потрібно явно викликати, щоб відбулася компонування.

Спочатку оцінюються властивості UIElement нативного розміру, такі як Clip та Visibility. Це генерує значення з назвою constraintSize, яке передається MeasureCore.

По-друге, властивості фрейму, визначені на FrameworkElement, обробляються, що впливає на значення constraintSize. Ці властивості, як правило, описують характеристики розмірів базового UIElement, такі як його Висота, Ширина, Поля та Стиль. Кожна з цих властивостей може змінити простір, необхідний для відображення елемента. Потім MeasureOverride викликається constraintSize як параметр.

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

Упорядкувати пропуск починається з виклику методу Arrange. Під час організації пропуску батьківський елемент панелі генерує прямокутник, який представляє межі дитини. Це значення передається методу ArrangeCore для обробки.

Метод ArrangeCore оцінює бажаний розмір дитини та оцінює будь-які додаткові поля, які можуть впливати на розмір відображеного елемента. ArrangeCore генерує аранжувальний розмір, який передається методу ArrangeOverride панелі як параметр. ArrangeOverride генерує остаточний розмір дитини. Нарешті, метод ArrangeCore робить остаточну оцінку властивостей зміщення, таких як маржа та вирівнювання, і вводить дитину в її слот для макета. Дитині не потрібно (а часто і не) заповнювати весь виділений простір. Потім контроль повертається на батьківську панель, і процес компонування завершено.

Від вимірювання та упорядкування дітей

Можливо, це вам допоможе.

Не тільки для панелей, але і для кожної програми, яку ви хочете зробити в WPF.

Він завершує креслення та вимірювання продуктивності WPF.

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

Панелі, про які ви згадуєте, - це панелі "Макет", тому короткий огляд системи компонування говорить про те, що, швидше за все, це буде не просто простий список найефективніших панелей, а те, як ви використовуєте панелі, які мають найбільший вплив на ефективність та ефективність.

LayoutSystem_Overview :

Найпростіше, компонування - це рекурсивна система, яка призводить до розміру, розміщення та малювання елемента. Більш конкретно, макет описує процес вимірювання та упорядкування членів дитячої колекції елемента «Панель». Макет - це інтенсивний процес. Чим більша колекція «Діти», тим більша кількість обчислень, які необхідно зробити. Складність також може бути введена на основі поведінки макета, визначеного елементом Panel, який належить колекції. Порівняно простий панель, такий як Canvas, може мати значно кращі показники роботи, ніж складніші панелі, такі як Grid.

Кожен раз, коли дочірнє UIElement змінює своє положення, воно має потенціал викликати новий пропуск у системі компонування. Тому важливо зрозуміти події, які можуть викликати систему компонування, оскільки непотрібне виклик може призвести до низької продуктивності програми. Далі описується процес, що виникає при виклику системи компонування.

1. Дочірнє UIElement починає процес компонування, спочатку вимірюючи його основні властивості.

2. Оцінюються властивості розмірів, визначені FrameworkElement, такі як ширина, висота та межа.

3. Застосовується специфічна для панелі логіка, наприклад, напрямок доки або орієнтація укладання.

4. Вміст влаштовується після того, як всі діти оцінюються.

5. На екрані малюється дитяча колекція.

6. Процес знову викликається, якщо в колекцію додаються додаткові діти, застосовується LayoutTransform або викликається метод UpdateLayout.

Див. LayoutSystem_Measure_Arrange для отримання додаткової інформації про вимірювання та облаштування дітей

LayoutSystem_Performance :

Макет - це рекурсивний процес. Кожен дочірній елемент колекції для дітей обробляється під час кожного виклику системи компонування. Як результат, слід уникати запуску системи компонування, коли це не потрібно. Наступні міркування можуть допомогти вам досягти кращих показників.

Будьте в курсі, які зміни вартості властивості змусять рекурсивне оновлення системою компонування.

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

Коли це можливо, використовуйте RenderTransform замість LayoutTransform.

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

Уникайте зайвих дзвінків до UpdateLayout.

Метод UpdateLayout примушує рекурсивне оновлення макета, і це часто не потрібно. Якщо ви впевнені, що потрібне повне оновлення, покладайтеся на систему компонування, щоб викликати цей метод для вас.

Працюючи з великою дитячою колекцією, подумайте про використання VirtualizingStackPanel замість звичайного StackPanel.

Віртуалізуючи дочірню колекцію, VirtualizingStackPanel зберігає лише об'єкти в пам'яті, які зараз перебувають у батьківському ViewPort. Як результат, ефективність роботи значно покращується у більшості сценаріїв.

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

Полотно (найменше комплексно = більш ефективна та краща ефективність)

Сітка

Інші панелі (складніші = менш ефективні та гірші показники)

Інші міркування щодо ефективності, на які слід звернути увагу: Шляхи покращення швидкості надання інтерфейсу WPF UI

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