问题描述
我目前正在处理与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性能.错误的脏矩形计算的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！