OpenTK、SharpGL 和 WPF

OpenTK, SharpGL and WPF

提问by Gilad

I am about to begin a new project. Some decisions are out of my control: Using WPF and OpenGL are some of them.

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

However, I have narrowed down my OpenGL options to two: Either OpenTK or SharpGL. SharpGL has a WPF control, while OpenTK only has a Windows Forms control, which makes it that I have to embed it in a Windows Forms Host :-/ While I don't mind the airspace restrictions, I do wish to have decent performance, since I am building a real time application. Not a game, but still, real time.

但是，我已将我的 OpenGL 选项缩小到两个：OpenTK 或 SharpGL。SharpGL 有一个 WPF 控件，而 OpenTK 只有一个 Windows 窗体控件，这使得我必须将它嵌入到 Windows 窗体主机中：-/ 虽然我不介意空域限制，但我确实希望有不错的性能，因为我正在构建一个实时应用程序。不是游戏，但仍然是实时的。

How much of a performance hit would my program take for using OpenTK over a Windows Forms Host, vs using SharpGL with a "pure" WPF control?

与使用带有“纯”WPF 控件的 SharpGL 相比，我的程序在 Windows 窗体主机上使用 OpenTK 对性能的影响有多大？

采纳答案by Marcus Riemer

When it comes to performance, I can actually only give you a single answer: Do a benchmark yourself! But as you are asking for an elaborate guess:

说到性能，我其实只能给你一个答案：自己做一个基准测试！但是，当您要求进行详细的猜测时：

SharpGl shouldrequire an indirection step less, as it leaves out the Windows Forms host control as an "intermediate" blitting target. Take this with a grain of salt though, I have neither looked at the source nor tested it myself.

SharpGl应该不需要一个间接步骤，因为它将 Windows 窗体主机控件排除在一个“中间”位块传输目标之外。尽管如此，我也没有看过源代码，也没有亲自测试过。

But practically speaking: The performance should be very similar. At the end of the day the computational heavy operations will probably be the rendering itself, which is done by OpenGL. Blitting the finished result should only take a fraction of that time. So I hope that, however you decide, none of these options would really hurt your performance.

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

For the sake of the argument: Lets assume the rendering itself (the OpenGL part) takes 16 ms, so we would have a theoretical perfomance of about 60 FPS. Framework A adds an overhead of 1 ms, Framework B an overhead of 4 ms. Even with this quite gross difference in the overhead, Framework a would render at ~ 58 FPS and Framework B at ~ 50 FPS. So in both cases, the application should remain usable.

为了论证：让我们假设渲染本身（OpenGL 部分）需要 16 毫秒，因此我们的理论性能约为 60 FPS。框架 A 增加了 1 毫秒的开销，框架 B 增加了 4 毫秒的开销。即使在开销上存在这种相当大的差异，框架 a 的渲染速度也会达到约 58 FPS，而框架 B 的渲染速度会达到约 50 FPS。因此，在这两种情况下，应用程序都应该保持可用。

But what puzzles me is how much you are wondering about this aspect. In the end you are doing work with OpenGL and it shouldn't be too much of a hassle to simply switch the underlying implementation in case things go bad? The interfaces don't seem too different to me.

但让我感到困惑的是你对这方面有多少想知道。最后，您正在使用 OpenGL，如果事情变糟，简单地切换底层实现应该不会太麻烦？界面对我来说似乎没有太大的不同。

回答by Itai Bar-Haim

I would say go with OpenTK, or if it's more comfortable for you to use SharpGL, then go with it in Winforms mode and embed it inside a WPF application.

我会说使用 OpenTK，或者如果您使用 SharpGL 更舒服，那么在 Winforms 模式下使用它并将其嵌入到 WPF 应用程序中。

The reason is that the OpenGL driver knows how to work with a window handle, provided with every winforms control. In a WPF application there is only one window handle, the one of the main window. You may try to use it, but I think it will pose too many problems.

原因是 OpenGL 驱动程序知道如何使用每个 winforms 控件提供的窗口句柄。在 WPF 应用程序中，只有一个窗口句柄，即主窗口之一。您可以尝试使用它，但我认为它会带来太多问题。

If you don't want things to get rendered directly to screen, and you think of using a PixelBufferObject or a RenderBufferObject, than you will probably be okay with SharpGL in WPF mode (it renders to a RenderBufferObject, than places the resulting buffer in an image, probably using a WritableBitmap or so), or you can do the same thing yourself.

如果您不希望将事物直接渲染到屏幕上，并且您考虑使用 PixelBufferObject 或 RenderBufferObject，那么在 WPF 模式下使用 SharpGL 可能没问题（它渲染到 RenderBufferObject，而不是将结果缓冲区放在图像，可能使用 WritableBitmap 左右），或者您可以自己做同样的事情。