我们有一个旧的（Win32）和新的（WPF）版本的我们的印迹软件，交易商目前正在并行运行。但是，运行WPF应用程序通常会严重降低Win32应用程序的重绘速度。
在WPF应用程序未运行（或最小化）的情况下，Win32应用程序中的绘制速率流畅且快速。随着WPF应用程序打开，Win32应用程序的UI绘制速率明显减慢。运行WPF应用程序似乎触发了一些从Win32应用程序中获取的资源（两者都是图形繁重的） - 导致它看起来变慢。
CPU和内存不会接近饱和，所以它似乎与那些无关。降低分辨率和/或减少要显示的显示器数量（因此降低显卡内存使用量和带宽负载）没有明显差异，因此它似乎也不是图形硬件性能问题。
可以解释原因的一个假设如下：
在幕后，我们知道WPF和Win32应用程序都将图形信息输出到Windows“消息泵”，这基本上是绘制到屏幕的内容的指令队列。好像当WPF应用程序没有运行时，Win32可以完全自由地访问它，并且屏幕更新也很流畅。在它旁边运行WPF应用程序会在此队列上添加其他消息，因此Win32应用程序必须更难以竞争访问它（为了进行每个屏幕元素更新），因此“堵塞泵”会产生我们看到的效果。
如果是上述情况，是否有人可以推荐管理/控制窗口消息泵的方法以防止这种情况发生？
闪烁是资源不足时通常会获得的类型，您可以在其中看到单个元素（表单，标签）闪烁并逐渐绘制到屏幕上。
如果有人有任何建议/想法，请告诉我们。
答案 0 :(得分：3)
每个进程都有自己的消息泵 - 这不是共享的。
如果您没有看到高CPU利用率，那么WPF正在使用硬件渲染，因此它可能是GPU饱和度。你能获得有关GPU利用率的信息吗？
以下文章详细介绍了获取GPU利用率的方法：
答案 1 :(得分：3)
好的，我认为我们找到了原因并解决了问题。简而言之，硬件和软件加速窗口效果不佳。全面使用软件渲染可修复以前运行硬件加速窗口时出现的故障。由于我们的旧版Win32应用程序即将退役，这是一个可行的措施 - 我们可以在删除旧版应用程序时简单地切换硬件加速。
以下注释：
似乎这个问题是由于同时运行传统的软件加速2D应用程序（X）和3D硬件加速的WPF（Y）引起的，并且是图形驱动程序问题。
强制Y在WPF软件加速模式下运行也会导致滚动性能几乎没有下降（因为瓶颈仍然是网格的内部布局代码）。
然而，它所做的是摆脱X中的慢速绘图问题，因为Y现在作为软件加速的2D应用程序运行，就像交易者机器上的所有其他Windows应用程序一样。这就解释了为什么Y以外的应用程序没有导致速度减慢 - 似乎软件和硬件加速的图形应用程序在同时运行时效果不佳。
这是有道理的 - 例如，当我玩硬件加速游戏时，我看到过类似的情况（在硬件/软件加速模式之间切换到游戏时，桌面重绘速度非常慢）。
值得庆幸的是，我们可以关闭硬件渲染，而不会对性能产生太大影响。一旦X退役，我们就可以重新开启硬件加速，以获得它在Y中提供的微小优势（支持更平滑的动画和更大的填充渐变使用而不会减慢速度等）。