WPF性能.错误的脏矩形计算 [英] WPF Performance. Wrong dirty rect calculation

问题描述

我目前正在处理与WPF富客户端LOB应用程序中的性能问题有关的客户分配.

I currently work in a customer assignment related to performance problems in a WPF rich client LOB application.

问题是该应用程序运行非常缓慢/缓慢.尤其是数据表的处理(滚动，排序，选择)非常慢，并且使应用程序无法使用.

The problem is that the application runs very slow/sluggish. Especially data table handling (scrolling, sorting, selection) is extremely slow and leaves the application unusable.

我分析了包含几个文本框，组合框和标签的单个选项卡被打开并闲置(等待用户输入)时的系统状态.

I analyzed the system state when a single tab containing a few textboxes, comboboxes and labels is opened and left idle (waiting for user input).

这些是我的发现:

• 所有渲染都是在GPU上计算的
• 没有诸如动画，位图效果，透明度等性能高的功能.
• 选项卡处于空闲状态时(焦点区域的文本框中仅光标闪烁，选项卡的其余部分为静态，甚至不包含任何数据)，GPU的运行速度高达90％
• 选项卡失去焦点时，GPU会降为0
• GPU百分比与窗口大小直接相关.一个小窗口可将其降低到百分之几，全屏可将其提高到近100％
• WPF穿孔器告诉我WPF会计算整个选项卡的脏区，而不是仅闪烁的光标
• WPF Perforator在闲置选项卡上报告的脏矩形更新速率大于20/sec，它们与GPU使用率直接相关

我的结论:在开发过程中，为了使WPF适应整个系统的后端驱动体系结构，引入了许多自定义代码(布局，事件处理等).我的猜测是，由于某些自定义代码，WPF的脏乱的矩形"机制已被破坏.这会导致过多的绘图活动，从而导致很高的GPU使用率.这些不必要的活动导致了上述问题.

My conclusion: During development a lot of custom code (layout, event handling, etc..) has been introduced in order to fit WPF to the backend-driven architecture of the system as a whole. My guess is that due to some of the custom code the dirty-rect-mechanism of WPF has been broken. This leads to too much drawing activity and thus very high GPU usage. These innecessary activities lead to the problems described above.

现在，我正在寻找开始调查的任何建议.或换句话说:为了破坏WPF脏矩形更新算法，开发人员可能犯的典型错误是什么.任何输入都将受到高度赞赏.

Now I am looking for any advice where I should start my investigation. Or in other words: What are typical mistakes that a developer can make in order to break the WPF dirty-rect update algorithm. Any input is highly appreciated.

非常感谢和问候！

Manuel

推荐答案

感谢您的输入.让我澄清一下后端驱动:UI是高度动态的.来自后端的消息定义了ui的结构和要显示的数据.因此，对于选项卡的结构，我们没有任何xaml，只有c#.

Thanks for the input. Let me clarify backend-driven: The UI is highly dynamic. A message from the backend defines the structure of the ui and the data to be displayed. Therefore, we do not have any xaml for the structure of the tabs, only c#.

与此同时，我可以解决问题.我使用了Snoop，并在监视GPU使用情况时逐个折叠每个元素.我发现其中一个边界上有一个非常小的像素阴影效果(DropShadowEffect).删除效果后，GPU从80％下降到1％.WPF在UI的小部分上绘制了正确的脏矩形.问题已解决，案件已结案.

In the meantime, I could solve the problem. I used Snoop and collapsed every element one by one while monitoring GPU usage. I found out that there was a very tiny pixelshader effect (DropShadowEffect) on one of the borders. As soon as I removed the effect, the GPU dropped from 80% to 1%. WPF drew correct dirty rectangles over small portions of the UI. Problem solved, case closed.

对我来说似乎很有趣的事情:1.这种微小的影响对GPU的使用产生了巨大的影响.2.破坏了脏矩形计算.3.因为它不是BitmapEffect而是PixelshaderEffect，所以我无法通过在Perforator中禁用BitmapEffects来揭示它.

Things that seem interesting to me: 1. The tremendous impact that this small effect has on the GPU usage. 2. That it breaks the dirty-rect calculation. 3. Since it was not a BitmapEffect but a PixelshaderEffect I could not reveal it by disabling BitmapEffects in Perforator.

谢谢！MM

这篇关于WPF性能.错误的脏矩形计算的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！