12

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

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.

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?

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
Gilad
  • 343
  • 1
  • 3
  • 13
  • I've tested WinForms + DX versus WPF + DX through D3DImage interop. DX + Winforms is much faster. There is a performance hit when using WPF D3DImage because of some needed copying to integrate it into its rendering engine. I would imagine the same would apply for OpenGL – Alan Nov 13 '12 at 08:41
  • The use of a 'Windows Forms Host' is a bad solution IMHO. You can't embed it as a normal control, because it doesn't support overdraw. – Jeroen van Langen Jan 11 '18 at 08:28

2 Answers2

5

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 should require 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.

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.

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.

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.

Marcus Riemer
  • 7,244
  • 8
  • 51
  • 76
  • I doubt the hit is small: WPF benefits from hardware acceleration, winforms doesn't. – Louis Kottmann Nov 12 '12 at 09:45
  • 5
    I think you are missing my point: The main work is done in OpenGL, which should be hardware accelerated. To "bridge" from the OpenGL output, the "resulting" image is simply blitted over various surfaces. And these blitting operations should only take a fraction of the time needed for rendering. Oh, and WPFs hardware acceleration doesn't buy much here. I don't think there is a possibility to access the OpenGL image from WPF, so a "software" copy has to be made anyway. – Marcus Riemer Nov 12 '12 at 09:56
  • You make wayyyyy too many assumptions for your answer to have any credit. – Louis Kottmann Nov 12 '12 at 10:03
  • 3
    Well, thats anything I can do when people ask vague perfomance related questions, the "real" answer is the first paragraph. The rest is just personal experience, feel free to prove me wrong ;) – Marcus Riemer Nov 12 '12 at 10:09
  • 1
    There's also the matter of interface. OpenTK uses its own enums and structs, while SharpGL allows for emulated low-level OpenGL calls. Because of that, SharpGL is very easy to port to other devices, while OpenTK will be a more of a hassle. – Gilad Nov 25 '12 at 08:30
4

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.

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.

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.

Itai Bar-Haim
  • 1,686
  • 16
  • 40