在 C# WinForms 中，每当在这里或那里制作小游戏时，我都会编写一个快速类，它是 System.Windows.Forms.Panel 的子类，并在构造函数中将 DoubleBuffered 设置为 true。然后您可以覆盖 OnPaint 方法来显示游戏元素。我已经这样做了 2 或 3 年了，但我真的很想拥抱 WPF 和 XAML，我真的很喜欢它用于常规应用程序布局。在 WPF 中这样做有什么等价物？
最佳答案
不是您寻求的答案，而是:您不应该将 WPF 用于游戏。坚持使用 Forms(它不会被 MS 抛弃，因为 WPF 没有取代 Forms)或者如果您想进入下一个级别，请尝试 XNA。
更新:昨天我回答的很快，因为我很着急而且因为我也是为了做游戏而研究WPF，所以我没有'我不想在没有正确答案的情况下离开 OP。
这是交易:
WPF 的目标是简化丰富的 UI 开发。首先，MS 理解 Forms 的编码方式混合了行为和表示。这对应用程序设计和可维护性来说都是不好的。此外，在 Forms 中，所有内容都必须进行编码；图书馆本身对用户的作用很小。例如，如果您想要一个具有不同外观的按钮，则必须覆盖其 Draw 方法，然后以某种方式绘制代表它的任何图形。
使用 WPF，行为 与表示 是分开的。例如，什么是按钮？在 Windows 中，我们知道它是一个带有圆角的框，但环顾四周……您的鼠标滚动也是一个按钮，尽管它看起来与 Windows 默认按钮完全不同。作为一个按钮意味着具有特定的行为(主要是点击)，而不是看起来像一个盒子。使用 WPF，这非常简单。您定义一个按钮，然后使用图像或文本等将其呈现给用户。
当然，所有这些都是有代价的；例如，WPF 比 Forms 慢。游戏需要快速，尽量不要浪费资源。在游戏中，每个行为都倾向于被编码(当然不是 UI)，每个演示都是定制的(2D 图形或 3D 对象)，因此您无论如何都必须进行大量编码。因此，您正在使用一项昂贵的技术，但却放弃了它的大部分优势。
但我不是专家。你可以查看this博客，其中一名前 Microsoft 员工尝试将 WPF 用于游戏近两年。他总结道:
You've probably noticed that the blog hasn't been updated in a while. WPF performance just doesn't seem to be there for serious games, and I've thrown in the towel and will work on games using XNA. I just don't think it's worth fighting the WPF framework...
从那里我得出了大部分结论。
关于C# WPF OnPaint 方法替代？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3340213/