并行运行 WPF/Win32 应用程序的性能问题？答案

【问题标题】：Performance issues running WPF/Win32 Applications Side by Side?并行运行 WPF/Win32 应用程序的性能问题？
【发布时间】：2011-06-06 14:04:45
【问题描述】：

我们的记事本软件有旧版 (Win32) 和新版 (WPF)，交易者目前正在同时运行它们。但是，运行 WPF 应用程序通常会严重减慢 Win32 应用程序的重绘速度。

在 WPF 应用程序不运行（或最小化）的情况下，Win32 应用程序中的绘制速率是流畅且快速的。随着 WPF 应用程序在其旁边打开，Win32 应用程序的 UI 绘制速度明显减慢。运行 WPF 应用程序似乎会触发使用一些从 Win32 应用程序中带走的资源（两者都需要大量图形）——这似乎会导致速度变慢。

CPU 和内存还没有接近饱和，所以它似乎与这些无关。降低分辨率和/或减少要显示的显示器数量（从而减少视频卡内存使用和带宽负载）没有明显差异，因此这似乎也不是图形硬件性能问题。

一个可以解释原因的假设如下：

在底层，我们知道 WPF 和 Win32 应用程序都将图形信息输出到 Windows“消息泵”，该“消息泵”基本上是一个关于在屏幕上绘制什么的指令队列。似乎当 WPF 应用程序没有运行时，Win32 可以完全不受限制地访问它并且屏幕更新是流畅的。与它一起运行 WPF 应用程序会在此队列上放置额外的消息，因此 Win32 应用程序必须更努力地争夺对它的访问权（以便进行每个屏幕元素更新），因此“堵塞泵”会产生我们看到的效果。

如果是上述情况，谁能推荐管理/控制窗口消息泵的方法以防止这种情况发生？

闪烁是资源不足时通常会出现的类型，您可以看到单个元素（表单、标签）闪烁并逐渐在屏幕上绘制。

如果有人有任何建议/想法，请告诉我们。

【问题讨论】：

标签： wpf windows performance winapi

【解决方案1】：

每个进程都有自己的消息泵 - 这不是共享的。

如果您没有看到高 CPU 利用率，则 WPF 正在使用硬件渲染，因此可能是 GPU 饱和。您能获得有关 GPU 利用率的信息吗？

以下帖子详细介绍了获取 GPU 利用率的方法：

Programmatically fetch GPU utilization

【讨论】：

谢谢，我们正在调查此事。
虽然这不是直接的解决方案，但这会引导我们走上正确的道路（更仔细地查看硬件/软件渲染），因此接受这个作为答案。谢谢！
@Gaurav 我认为它会在那个区域附近 - 很高兴能提供帮助。 :)

【解决方案2】：

好的，我想我们已经找到原因并解决了。简而言之，硬件和软件加速的窗口玩得不好。全面使用软件渲染修复了以前在运行硬件加速窗口时出现的故障。由于我们的旧版 Win32 应用程序即将停用，因此这是一个可行的折衷方案 - 当我们放弃旧版应用程序时，我们可以简单地重新打开硬件加速。

以下注意事项：

这个问题似乎是由同时运行传统的软件加速 2D 应用程序 (X) 和 3D 硬件加速 WPF one (Y) 引起的，并且是图形驱动程序问题。

强制 Y 在 WPF 软件加速模式下运行也几乎不会降低滚动性能（因为瓶颈仍然是网格的内部布局代码）。

但是，它的作用是消除 X 中的缓慢绘图问题，因为 Y 现在作为软件加速的 2D 应用程序运行，就像交易者机器上的所有其他 Windows 应用程序一样。这解释了为什么除了 Y 之外没有应用程序导致速度变慢 - 似乎软件和硬件加速的图形应用程序在同时运行时表现不佳。

这是有道理的 - 例如，当我玩硬件加速游戏时，我看到过类似的情况（在硬件/软件加速模式之间切换游戏时，桌面重绘非常缓慢）。

谢天谢地，我们可以关闭硬件渲染，而不会对性能产生太大影响。一旦 X 退役，我们可以重新打开硬件加速，以获得它在 Y 中提供的微小好处（支持更平滑的动画和更多地使用填充渐变而不减慢等）。

【讨论】：