title: Is excessive nesting of WPF layout panels (e.g. Grid) computationally expensive?
body: <p>folks</p>
  
  <p>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. </p>
  
  <p>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.</p>
  
  <p>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</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Does anyone have any experience or know anything about it?</p>
  
  <p>Thanks a lot for reading</p>