使用大量控件调整窗口大小时，WPF的性能问题

Question

我有一个WPF窗口，其中包含一个花哨的图像，大约有200个控件(来自按钮)，所有这些控件都使用我的5个模板之一(路径、阴影效果等)。同意，这是一扇很重的画窗。我能忍受这一切。

我的问题是调整窗口的大小。最大化/恢复大约需要1-2秒，但是手动拖动左下角会导致系统挂起大约5-10秒。在这个延迟中，窗口是黑色的&包含部分剩菜，直到最后的结果显示出来。它看上去很业余，我无法忍受。

远程连接:使用远程帐户，我发现调整窗口大小总是需要1-2秒，但在拖动窗口边框时不会绘制“中间”阶段。结果和我预料的一样快。

我的结论是:在调整尺寸过程中的调整是瓶颈。

不可避免的问题是:在调整大小之前，如何防止重新绘制窗口？

谢谢你的任何想法..。

Answer 1

@Seb:我开始认为WPF不是为一次超过2-3控件的接口设计的。

Visual 2010和表达式的混合应该是好的反例。虽然Visual有时会冻结，但WPF呈现中肯定没有瓶颈。

@Seb:不可避免的问题是:在调整大小之前，如何防止重新绘制窗口？

只需在调整大小/最大化之前将窗口的内容可见性设置为Visibility.Collapsed，然后使其可见。虽然我觉得你问错了问题。这是正确的

如何使我的控件测量/安排得非常快？

要回答这个问题，你应该看看你的代码。也许您在度量/排列算法中大量使用了依赖属性？或者您选择了错误的面板(例如，Grid比画布慢)？或者也许..。我不再在这里猜测:)。

顺便说一句，最好是在分析器下启动你的应用程序，证明它的瓶颈，而不是假设它可能在哪里。检查Eqatec剖面仪，它是免费的，但足够强大。VS 2010还提供了不错的剖析功能，尽管它远不是免费的。您可能需要检查WPF性能套房。

希望这能有所帮助。

Answer 2

告诉我这是怎么回事..。我假设您的根视觉项是伸展到水平和垂直，以填补您的窗口的自动高度/宽度。去掉汽车高度/宽度。在app启动时，设置根元素的大小。有一个FrameworkElements有一个大小变化事件。在您的Application.Current.MainWindow上注册这个(可能是一个错误，这是来自内存)。每当发生此事件时，请以较小的间隔启动计时器。如果在计时器运行时得到另一个调整大小，则忽略它并重置计时器。一旦计时器触发，您现在就知道了用户想要的新大小，并且他们(至少在短时间内)停止了调整窗口的大小。

希望这能帮上忙！