有谁知道有任何可靠的（并且希望是广泛的）书籍/网站讨论 GDI+ 性能（超出显而易见的范围）？
例如，我最近遇到这个出色的实验 http://www.gamedev.net/community/forums/topic.asp?topic_id=467752。我最近也注意到Graphics.FillPath()比Graphics.DrawPath()。我很想知道我还缺少哪些其他重要信息。
善意，
大卫
嗯。如果您需要绘制路径的轮廓，那么知道 FillPath 比 DrawPath 更快并没有什么好处！
优化 GDI+ 的最佳方法与优化任何其他代码完全相同：首先，不要优化它。反而：
- 首先编写它，让它简单地工作，然后确定它是否真的太慢。
- Then examine your "algorithm":
- 简化你正在绘制的内容（减少你正在绘制的东西的数量），它会变得更快（并且在大多数情况下，由于减少了混乱，看起来会更好）。
- 您是否每次都绘制整个显示，或者是否使用剪辑矩形来避免绘制不需要更新的图像部分？
- 检查你如何画东西。您是否为每次重画创建和销毁资源（例如画笔和钢笔）？将它们缓存在成员变量中。您是否多次过度绘制同一像素？ （例如，绘制背景，然后在顶部绘制位图，然后在其顶部绘制一个矩形 - 也许您可以避免其中一些重绘）。当只用 10 条线段看起来就足够好的时候，您是否使用 100 条多边形线段来绘制一条曲线？当窗口滚动时，您是否让操作系统移动现有图像，以便您只需要重新绘制新暴露的条带，还是浪费时间重新绘制整个窗口？
- 您是否正在使用变换或是否在代码中进行冗长的定位计算？
- 检查所有循环并确保从其中移出尽可能多的代码 - 预先计算在循环中使用的值等。确保循环尽可能以 CPU 缓存友好的方向/方式迭代数据。
- 重绘期间您正在处理的数据中是否有任何内容？也许其中一些可以预先计算或以更渲染优化的形式组织。例如使用不同类型的列表会更快地枚举数据吗？您是否正在处理 1000 个数据项以找到需要绘制的 10 个数据项？
- 你能用不同的方法获得相同的外观吗？例如您可以通过黑白交替绘制 64 个方格来绘制棋盘。先绘制 32 个黑色方块，然后绘制 32 个白色方块可能会更快，这样就可以避免矩形之间的状态变化。但实际上您可以使用白色背景清晰、4 个黑色矩形和 4 个 XOR 矩形（8 个矩形而不是 64 => 更快的算法）来绘制它。
- 图像中是否有不经常变化的部分？尝试将它们缓存在屏幕外位图中，以最大程度地减少每次重绘所需“重建”的数量。请记住，您仍然可以渲染离屏位图，然后在其上分层图形基元，因此您可能会发现比您意识到的更多的“静态”图像区域。
- 您正在渲染位图图像吗？尝试将它们转换为屏幕的像素格式并以“本机”形式缓存它们，而不是让 GDI+ 在每次绘制它们时都进行转换。
- 如果您愿意以较低质量换取更快渲染速度，请调低质量设置
完成所有这些操作后，您就可以开始寻找有关优化渲染的书籍。当然，如果还是太慢的话。运行分析器以找出渲染的哪些部分最慢。
在您认为可能会有所收获的地方，尝试不同的渲染方式（例如，Graphics.Clear() 可能比用 FillRectangle() 填充背景快得多），或不同的渲染顺序（绘制所有的东西）首先绘制一种颜色，以防状态更改花费您的时间 - 对于现代显卡，批处理操作通常非常重要。绘制多个多边形的单个调用通常比进行多个单多边形调用更快，因此您可以将所有多边形累积到延迟渲染缓冲区，然后在渲染过程结束时将它们全部提交？）
之后，您可能需要考虑使用 GDI 或 DirectX 来更接近硬件。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
