我即将开始一个新项目。有些决定是我无法控制的：其中一些是使用WPF和OpenGL。

但是，我将OpenGL选项的范围缩小到了两个：OpenTK或SharpGL。 SharpGL具有WPF控件，而OpenTK仅具有Windows Forms控件，这使得我不得不将其嵌入Windows Forms Host中：-/
尽管我不介意领空限制，但我确实希望有不错的性能，因为我正在构建一个实时应用程序。不是游戏，而是实时。

与通过"纯" WPF控件使用SharpGL相比，在Windows Forms Host上使用OpenTK会给我的程序带来多少性能影响？

关于性能，我实际上只能给您一个答案：自己做一个基准！但是，当您要进行详细的猜测时：

SharpGl应该需要更少的间接步骤，因为它将Windows Forms宿主控件作为"中间"提示目标遗漏了。不过，带着一粒salt把它拿走，我既没有看过来源，也没有亲自测试过。

但实际上：性能应该非常相似。归根结底，计算量大的操作可能是渲染本身，这是由OpenGL完成的。刮光完成的结果只需要那一小部分时间。因此，我希望，无论您决定如何，这些选项都不会真正损害您的性能。

为论证：假设渲染本身(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左右)，或者您也可以自己做同样的事情。