我注意到在我正在开发的 MFC 应用程序中，当拖动滚动条以平滑地向下滚动文档时，当包含一段文本的 block 出现在屏幕上时，帧率会下降到不稳定的水平，但当它出现在屏幕上时，帧率会非常平滑离屏。调查性能，我发现单个 CDC::DrawText 调用负责文本段落。这是在优化的发布版本中。
我使用 QueryPerformanceCounter 对 DrawText 调用进行了高分辨率测量，只是，如下所示:
QueryPerformanceCounter(...);
pDC->DrawText(some_cstring, some_crect, DT_WORDBREAK);
QueryPerformanceCounter(...);
文本是 unicode，lorem-ipsum 样式填充符，865 个字符长，并在给定矩形和字体的情况下环绕 7 位行(Segoe UI，lfHeight = -12，a标准正文文本大小)。根据我的测量，单独 调用平均耗时 7.5 毫秒，奇数峰值为 21 毫秒。 (请注意，要跟上 60Hz 的显示器，您需要大约 16 毫秒的时间来渲染每个更新。)
我尝试进行一些更改以提高性能:
- 删除
DT_WORDBREAK可将性能提高到大约 1 毫秒(大约快 7 倍)，但如果只有一行文本出现在屏幕上，并且只有 7 行多于断字，在我看来，这似乎表明瓶颈在别处。 - 我在透明模式下绘制文本 (
SetBkMode(TRANSPARENT))。所以我尝试了带有纯色背景填充的不透明模式。没有改善。 - 我认为 ClearType 渲染可能是罪魁祸首。我将字体
lfQuality从CLEARTYPE_QUALITY更改为NONANTIALIASED_QUALITY。它看起来像垃圾，棱角分明，没有任何改进。 - 根据评论建议，我使用的是 CMemDC，但我摆脱了它并进行了直接绘图。它像疯了一样闪烁，没有改善。
这是在配备 Intel Core 2 Duo P8400 @ 2.26 GHz 和 4 GB RAM 的 Windows 7 64 位笔记本电脑上运行的 - 我认为它不算是一个慢速系统。
每次绘制时我都会调用 DrawText()，这显然会影响如此慢的函数的性能，尤其是当其中几个文本 block 同时可见时。这足以让体验变得迟钝。然而，Firefox 可以用更多文本在 ClearType 中呈现像这样的页面，并且似乎处理得很好。我究竟做错了什么？如何解决实际 DrawText 调用性能不佳的问题？
最佳答案
在每次刷新时绘制文本是一种浪费。使用双缓冲，即绘制一个离屏位图，然后将其位 block 传输到屏幕上。然后，为了滚动，只需根据需要向上或向下或向侧面复制大部分位图，然后仅绘制无效区域(在将结果 block 传送到屏幕之前)。
如果结果还是太慢，请将绘制的文本也保存在屏幕外位图中，并用 blit 代替绘制。
干杯，
关于c++ - DrawText 在 Win7 x64 上的性能不佳，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4280783/