c# - Graphics.DrawImage 对于更大的图像是否太慢？

Question

我目前正在开发一款游戏，我希望有一个带有背景图像的主菜单。

但是，我找到了方法 Graphics.DrawImage()真的很慢。我做了一些测量。让我们假设 MenuBackground 是我的资源图像，分辨率为 800 x 1200 像素。我会将它绘制到另一个 800 x 1200 位图上(我首先将所有内容渲染到缓冲区位图，然后缩放它，最后将其绘制到屏幕上 - 这就是我处理多个玩家分辨率的可能性的方式。但它不应该影响无论如何，请参阅下一段)。

所以我测量了以下代码:

Stopwatch SW = new Stopwatch();
SW.Start();

// First let's render background image into original-sized bitmap:

OriginalRenderGraphics.DrawImage(Properties.Resources.MenuBackground,
   new Rectangle(0, 0, Globals.OriginalScreenWidth, Globals.OriginalScreenHeight));

SW.Stop();
System.Windows.Forms.MessageBox.Show(SW.ElapsedMilliseconds + " milliseconds");

结果令我惊讶 - Stopwatch测量 40 - 50 milliseconds 之间的东西.并且因为背景图像不是唯一要绘制的东西，所以整个菜单需要大约 100 毫秒才能显示，这意味着可观察到的滞后。

我试图将它绘制到由 Paint 事件给出的 Graphics 对象，但结果是 30 - 40 milliseconds ——变化不大。

那么，这是否意味着 Graphics.DrawImage()不能用于绘制更大的图像？如果是这样，我应该怎样做才能提高游戏的性能？

Answer 1

是的，它太慢了。

几年前我在开发 Paint.NET 时遇到了这个问题(实际上从一开始就遇到了这个问题，这很令人沮丧!)。渲染性能很糟糕，因为它总是与位图的大小成正比，而不是它被告知要重绘的区域的大小。也就是说，帧率随着位图大小的增加而下降，而在实现 OnPaint() 和调用 Graphics.DrawImage() 时，帧率永远不会随着无效/重绘区域的大小下降而上升。一个小的位图，比如 800x600，总是可以正常工作，但较大的图像(例如 2400x1800)非常慢。 (无论如何，对于上一段，您可以假设没有发生任何额外的事情，例如使用一些昂贵的双三次滤波器进行缩放，这会对性能产生不利影响。)

可以强制 WinForms 使用 GDI 而不是 GDI+ 甚至避免创建 Graphics幕后的对象，此时您可以在其上放置另一个渲染工具包(例如 Direct2D)。然而，这并不简单。我在 Paint.NET 中执行此操作，您可以通过在名为 GdiPaintControl 的类上使用诸如 Reflector 之类的东西来查看需要什么。在 SystemLayer DLL 中，但对于您正在做的事情，我认为这是最后的手段。

但是，您使用的位图大小 (800x1200) 在 GDI+ 中应该仍然可以正常工作，而不必求助于高级互操作，除非您的目标是低至 300MHz Pentium II。以下是一些可能会有所帮助的提示:

如果您在对 Graphics.DrawImage() 的调用中使用不透明位图(无 alpha/透明度) ，特别是如果它是一个带有 alpha channel 的 32 位位图(但你知道它是不透明的，或者你不在乎)，然后设置 Graphics.CompositingMode至 CompositingMode.SourceCopy调用前 DrawImage() (一定要设置回原来的值，否则普通的绘图图元会很难看)。这跳过了很多额外的每像素混合数学。

确保Graphics.InterpolationMode未设置为类似 InterpolationMode.HighQualityBicubic .使用 NearestNeighbor将是最快的，尽管如果有任何拉伸(stretch)，它可能看起来不太好(除非它正好拉伸(stretch)了 2 倍、3 倍、4 倍等)Bilinear通常是一个很好的妥协。除了 NearestNeighbor，你不应该使用任何东西如果位图大小与您要绘制的区域相匹配，以像素为单位。

永远画进Graphics在 OnPaint() 中给您的对象.

始终在 OnPaint 中进行绘图.如需重绘区域，请调用Invalidate() .如果您需要立即进行绘图，请调用 Update()后 Invalidate() .这是一种合理的方法，因为 WM_PAINT 消息(导致调用 OnPaint())是“低优先级”消息。窗口管理器的任何其他处理都将首先完成，因此您最终可能会出现大量跳帧和卡顿现象。

使用 System.Windows.Forms.Timer因为帧率/滴答计时器不能很好地工作。这些是使用 Win32 的 SetTimer 实现的。并导致 WM_TIMER 消息，然后导致 Timer.Tick事件正在引发，而 WM_TIMER 是另一个低优先级消息，仅在消息队列为空时发送。你最好使用 System.Threading.Timer然后使用 Control.Invoke() (以确保您在正确的线程上!)并调用 Control.Update() .

一般情况下，不要使用 Control.CreateGraphics() . (“总是使用 OnPaint()”和“总是使用 Graphics 给你的 OnPaint()”的推论)

我建议不要使用 Paint 事件处理程序。相反，实现 OnPaint()在您正在编写的类(class)中，它应该派生自 Control .从另一个类派生，例如PictureBox或 UserControl , 要么不会为您增加任何值(value)，要么会增加额外的开销。 (顺便说一句 PictureBox 经常被误解。你可能几乎永远不想使用它。)

希望有帮助。