当前位置 : 主页 > 网络安全 > 测试自动化 >

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

来源:互联网 收集:自由互联 发布时间:2021-06-22
我有一个 WPF窗口,其中包含一个花式图像,大约有200个控件(从按钮派生),所有这些都使用我的5个模板之一(路径,阴影效果等).同意,这是一个沉重的窗口.我可以忍受这一点. 我的问题来自调
我有一个 WPF窗口,其中包含一个花式图像,大约有200个控件(从按钮派生),所有这些都使用我的5个模板之一(路径,阴影效果等).同意,这是一个沉重的窗口.我可以忍受这一点.

我的问题来自调整窗口大小.最大化/恢复大约需要1-2秒,但手动拖动左下角会导致系统挂起约5-10秒.在那个延迟中,窗口是黑色的&包含部分剩余部分,直到显示最终结果.它看起来很业余,我不能忍受.

远程连接:使用远程帐户,我发现窗口调整大小总是需要1-2秒,但在拖动窗口边框时不会绘制“中间”阶段.结果像我期望的那样快活.

我的结论是:调整大小期间的重绘是瓶颈.

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

提前感谢任何想法……

@Seb: I’m beginning to think WPF is
not designed for interfaces that go
beyond 2-3 controls at a time

Visual Studio 2010和Expression Blend应该是很好的反例.虽然Visual Studio有时会冻结瓶颈,但绝对不是WPF渲染.

@Seb: The inevitable question is this : how
can I prevent redrawing the window
until the resize is finished?

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

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

要回答它,你应该看看你的代码.也许您在测量/排列算法中集中使用依赖属性?或者你可能选择了错误的面板(例如Grid比Canvas慢)?或许……我在这里停止猜测:).

顺便说一句,最好是在分析器下启动你的应用程序并证明瓶颈而不是假定它可能存在的位置.检查Eqatec Profiler它是免费但功能强大. VS 2010还提供了很好的分析功能,但它远非免费.你可能想检查WPF Performance Suite.

希望这可以帮助.

网友评论