我即将开始一个新项目。有些决定是我无法控制的：使用WPF和OpenGL是其中的一些。
但是，我已经将OpenGL选项范围缩小到两个：Opentk或SharpGl。SharpGl具有WPF控件，而Opentk仅具有Windows表单控件，这使得我必须将其嵌入Windows表单主机： -/尽管我不介意空域限制，但我确实希望有体面的性能，因为我正在建立实时应用程序。不是游戏，而是实时的。
我的程序将在Windows表单主机上使用Opentk的程序会受到多少次命中，而使用"纯" WPF控制的SharpGl？
在性能方面，我实际上只能给您一个答案：自己做一个基准！但是，当您要求一个精心的猜测时：
SharpGl 应该需要更少的间接步骤，因为它将Windows构成主机控制作为"中间"的漏油目标。不过，用一粒盐去吃这个，我既没有看源也不对其进行测试。
，但实际上说：性能应该非常相似。归根结底，计算重型操作可能是由OpenGL完成的渲染本身。命中最终结果只能花费一小部分时间。因此，我希望您决定，这些选择都不会真正损害您的表现。
为了论证：让我们假设渲染本身（OpenGL部分）需要16毫秒，因此我们的理论性能约为60 fps。框架A添加了1 ms的开销，框架B的开销为4 ms。即使在开销中有很大的差异，框架A也将以约58 fps和框架B的呈现约50 fps。因此，在这两种情况下，该应用程序都应保持可用。
但是让我感到困惑的是，您对这一方面有多想。最后，您正在与OpenGL一起工作，如果事情不好，可以简单地切换基础实现，这不应该太麻烦了吗？接口对我来说似乎没有太大不同。
我会说与Opentk一起去，或者如果您更舒适地使用SharpGl，然后将其与Winforms模式一起使用并将其嵌入WPF应用程序中。
原因是OpenGL驱动程序知道如何使用窗口句柄，并提供每个Winforms控件。在WPF应用程序中，只有一个窗口句柄，一个主窗口之一。您可能会尝试使用它，但我认为它会带来太多问题。
如果您不希望事情直接渲染到屏幕上，并且您想使用的是使用PixelBufferObject或RenderBufferObject，那么您可能会在WPF模式下使用SharpGl（它渲染到RenderBuffErObject）图像中的缓冲区，可能使用Writable bitmap左右），或者您可以自己做同样的事情。