Является ли чрезмерная вложенность панелей макета WPF (например, Grid) вычислительно дорогостоящей?

Я слышал от коллеги, что я - как дизайнер, использующий Microsoft Expression Blend - должен избегать чрезмерного вложения элементов панели, потому что они являются дорогостоящими.

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

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

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

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

У меня был предыдущий опыт работы с PyGtk, и я должен сказать, что я использовал A LOT o макеты для всех своих скриптов, и даже изменение размера окон никогда не казалось мне особенно дорогостоящим, за исключением случаев, когда у меня был сложный холст-рисунок необходимо пересчитать.

Есть ли у кого-нибудь опыт или что-то знать об этом?

Ответы

Ответ 1

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

В конце концов, это то, что, если вы не сошли с ума, часто не будет проблемой. Чтобы узнать, вызывает ли это проблемы для вашего приложения, я предлагаю использовать WPF Performance Suite для выполнения некоторых тестов производительности.

Ответ 2

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

Статья MSDN по этой проблеме может представлять интерес, поскольку она объясняет некоторые вещи, которые не являются простыми: Оптимизация производительности: макет и дизайн