CODEWITHSUNDEEP
wpfperformanceuser-interfacexamllayout
heltonbiker
heltonbiker

Reputation: 27595

Is excessive nesting of WPF layout panels (e.g. Grid) computationally expensive?

folks

I have heard from a coworker that I - as a designer using Microsoft Expression Blend - should avoid using excessive nesting of panel elements, because they are computationally expensive.

For example, I tend to create the mainwindow with header and custom statusbar with grid, and then take the top panel and put a grid inside it, and if I have a message inside a rectangle on the already gridded top panel I create yet another grid, etc.

As a very layout-oriented disigner (who wants to use every screen most efficiently whatever the screen dimensions are) I know this is the best way to do it considering absolute control and flexibility, which prevent the window to resize in "unpredictable" ways ;oP

BUT... ...this friend of mine said that, if you have, say, five grids nested inside one another, if you pass the mouse over them, you generate five mouse events, which is costly.

Also, if you have too many calculations due to the too many containers asking for children sizes before the actual rendering, it can also be costly.

I had some previous experience with PyGtk, and I must say I used A LOT o layout panels for all my scripts, and even the resizing of windows never seemed to me to be specially costly, except when I had some complex canvas drawing needed to be recalculated.

Does anyone have any experience or know anything about it?

Thanks a lot for reading

Upvotes: 15

Views: 3466

Answers (2)

brunnerh
brunnerh

Reputation: 184682

Wouldn't worry about it that much, i for one did not have problems with it so far. Apply some common sense, what panels are needed in which case? Do you really need yet another panel to achieve your goal or not?

The MSDN article on this issue might be of interest since it explains a few things which are not straightforward: Optimizing Performance: Layout and Design

Upvotes: 4

Drew Marsh
Drew Marsh

Reputation: 33379

There's no straight-forward answer to this, but obviously the more elements you have participating in layout, the longer the measure and arrange phases are going to take for the window. Depending on which features of which Panel types you use it could be more or less costly, but for sure the more you use the more overhead there will be during the layout calculations. You can learn more about how the layout system works by reading that entire MSDN article.

In the end this is something that, unless you've gone crazy, will not often be an issue. To find out if it is causing problems for your app I suggest using the WPF Performance Suite to do some performance testing.

Upvotes: 7

Related Questions