我即将开始一个新项目。有些决定是我无法控制的：其中一些是使用 WPF 和 OpenGL。
但是，我已将 OpenGL 选项缩小到两个：OpenTK 或 SharpGL。SharpGL 有一个 WPF 控件，而 OpenTK 只有一个 Windows 窗体控件，这使得我必须将它嵌入到 Windows 窗体主机中：-/ 虽然我不介意空域限制，但我确实希望有不错的性能，因为我正在构建一个实时应用程序。不是游戏，但仍然是实时的。
在 Windows 窗体主机上使用 OpenTK 与使用带有“纯”WPF 控件的 SharpGL 相比，我的程序会对性能造成多大影响？
说到性能，我其实只能给你一个答案：自己做一个基准测试！但是，当您要求进行详尽的猜测时：
SharpGl需要的间接步骤更少，因为它将 Windows 窗体主机控件作为“中间”blitting 目标。不过，对此持保留态度，我既没有查看源代码，也没有自己测试过。
但实际上：性能应该非常相似。归根结底，计算繁重的操作可能是渲染本身，这是由 OpenGL 完成的。Blitting 完成的结果应该只需要一小部分时间。所以我希望，无论你如何决定，这些选项都不会真正影响你的表现。
为了论证：让我们假设渲染本身（OpenGL 部分）需要 16 毫秒，所以我们的理论性能约为 60 FPS。框架 A 增加了 1 毫秒的开销，框架 B 增加了 4 毫秒的开销。即使在开销上有这么大的差异，框架 a 的渲染速度约为 58 FPS，而框架 B 的渲染速度约为 50 FPS。因此，在这两种情况下，应用程序都应该保持可用。
但令我困惑的是你对这方面有多少疑惑。最后，您正在使用 OpenGL 进行工作，如果事情变糟，简单地切换底层实现应该不会太麻烦？界面对我来说似乎并没有太大的不同。
我会说使用 OpenTK，或者如果您使用 SharpGL 更舒服，那么在 Winforms 模式下使用它并将其嵌入到 WPF 应用程序中。
原因是 OpenGL 驱动程序知道如何使用随每个 winforms 控件提供的窗口句柄。在 WPF 应用程序中，只有一个窗口句柄，即主窗口之一。您可以尝试使用它，但我认为它会带来太多问题。
如果您不希望将事物直接渲染到屏幕上，并且您考虑使用 PixelBufferObject 或 RenderBufferObject，那么您可能会在 WPF 模式下使用 SharpGL（它渲染到 RenderBufferObject，然后将生成的缓冲区放在图像，可能使用 WritableBitmap 左右），或者您可以自己做同样的事情。