8

I have a problem with wpf. The problem is my window, which uses some auto and * columns in a Grid, it is opening very slow. I've used the Visual Studio debugger to investigate what the trouble is, and found it in the layout section. The message is:

Changes were made to XAML visual tree that required the size and/or position of all affected elements to be computed.

Here is a screenshot of the debugger:

Debug Information

What is the best way to detect the exact problem with the layout? Or are there some general rules I could follow?

Thank you very much, I did not experience this behaviour with wpf before, even with large usercontrols / windows...

EDIT I don't use any animation of transformation to rotate controls. In general it is a very flat window. As an additional information, scrolling through GridViews in the window is also very slow.

causa prima
  • 1,502
  • 1
  • 14
  • 24
BendEg
  • 20,098
  • 17
  • 57
  • 131
  • Do you use expensive `LayoutTransform` animations instead of `RenderTranform`? – Sinatr Oct 01 '15 at 14:06
  • Thank you for your comment. I only use WPF default behaviour and did not specify `LayoutTransform` or `RenderTranform.` – BendEg Oct 01 '15 at 14:10
  • What exactly happens at the moment layout starts taking so much time? Do you use non-virtualized containers (and begin filling them)? Do you add thousands of controls to some `Grid`? See [this](http://stackoverflow.com/q/9946811/1997232) question, it should be helpful. – Sinatr Oct 01 '15 at 14:14
  • Not thousends, maybe between 50 and 70. Not more. I will read the article, seems to be very informatic. – BendEg Oct 01 '15 at 14:18
  • So you are adding ~60 controls when it happens. Adding where? How? It could be complicated templates or adding each item triggering layout pass for container (or even whole window). In either case consider to providing related xaml and code. Another thing I could think of is relative bindings of control margins, etc., whenever adding one control will cause a chain reaction. – Sinatr Oct 01 '15 at 14:25
  • The UI does not use `Trigger`. It is build from 8 `UserControl`s which are added programatically. The 8 `UserControl`s than contains the other controls. But no advanced styling, merging binding or some thing like that. Event replacing auto to some fixed value does not help. – BendEg Oct 01 '15 at 14:32
  • Would have to see under the hood to diagnose this one. Could be any number of things that just a basic description won't help much to identify. – Chris W. Oct 01 '15 at 15:32
  • We can't diagnose the cause just by looking at the symptoms. Post some code to detail your implementation. – Glen Thomas Oct 01 '15 at 17:00
  • 3
    There's a trial-and-error approach. Loading a blank window to get the baseline and then slowly add you controls into the window one by one to see the difference. Setting a fix number to your height and width on your grid is also a nice thing to try on. Eventually, you'll be able to get your answer on what caused the problem – cscmh99 Oct 01 '15 at 17:07
  • 1
    @BendEg I've experience problems if I hook up my * incorrectly, replace them with fixed sizes for the time being and see if that helps you isolate your issue. – patrick Jul 20 '16 at 21:24

2 Answers2

2

Off the top of my head (and re-iterating a few of the comments):

  • Are you using nested IsSharedSizeScope? This can cause cascading layout updates.
  • Have you turned off virtualization and have many items in the grid? This can cause slow and studdering performance.
  • Try to isolate the issue by removing stuff until it works (or removing a lot and adding things back until the issue starts to reappear)
  • Post your code here so we help you better
Andreas Zita
  • 7,232
  • 6
  • 54
  • 115
1

I had the same issue. The reason was accidentally switched OFF virtualization in ListView in XAML file. Probably copy/paste from web. Changing from false to true made the magic.

VirtualizingPanel.IsVirtualizing="True"
Milan Švec
  • 1,675
  • 17
  • 21