I am using Opengl to render the scene in Engine. And the application with UI controls are developed using WPF (xaml c#).
I have given up the FBO and pBuffer rendering for two reasons:
Some of our end user systems do not support this.
It takes quite some time to get the buffer and set it to the WPF panel’s background. Getting window’s handle and rendering on it directly is much much faster.
I have tried swapping the part of buffer after getting the window’s handle. Have tried the Windows form host and have passed the handle rendering the scene there. Have looked at some sources from Open TK.
Rendering works fine in all these cases. But when there are controls placed on top of the viewing area, I experience several problems.
In case of windows form host i dont get any mouse event (Have tried placing a transparent layer on top it - failed)
In all three cases, the engine paints on the entire viewarea, causing the conrols to disappear. We have to refresh the controls - which causes some gray-out effect. As the controls are transparent, some part of the window is affected while refreshing it.
Can anyone help me out in resolving this problem.
Thank you.
To get a window handle you’ll need to use a forms host container to embed a user control or some such, but from a graphics API standpoint that’s about the only real distinction from plain old winforms or win32 for that matter.
Or 3) provide an invisible WPF overlay over the WinFormsHost and attach your WPF controls to that.
As far as I know, this should work fine as long as the WPF controls are not transparent.
I have played with instantiating an OpenGL context directly on a WPF window but this will not (indeed cannot) work reliably across configurations. Actually, it might be possible to hack WPF into submission by disabling hardware acceleration, but I don’t think that’s an acceptable approach.
@ Stephen : I guess even the third option comes under the airspace restriction as pointed out by Chris. Not sure if you were referring to the visibility / transparency. Anyways tried both the options. It dint work out.
My point was that trying to use OpenGL just increases the development effort, without added value.
WPF is windows only, so you loose already the portability beneficts of OpenGL.
If you decide to use OpenGL just because you don’t want to touch DirectX, you are only increasing your development effort without gaining much benefict.
Because there are so many ways to tackle this confusion and on so many levels, can’t we just roast some chestnuts and sip a hot nog toddy instead?
Incidentally, skimming over the new Direct2D API it appears that mixing the 2D & 3D stuff is going to require new BGRA back buffer formats, region locking mechanisms and syncing primitives to allow any of this seamless interplay to take place at all - and that’s just for DX.
Render your own in-window GUIs in-house and be done with it?
There you go. You can host opengl in Wpf special using bitmapped brushes. In fact it is much easier to do directx and wpf interop. Consider it if you are building your project from scratch!
I feel like some people here are saying things that aren’t tested. I host an OpenGL Engine in a Winform app which is an editor for my game engine, the game engine itself is hosted in the winform.
All i need is an hwnd, and then you have to forward the messages by replacing the WNDPROC function callback.
Requirements don’t mean a thing, if the guy wants OpenGL in WPF then fine.
I am attempting to move my winform in a winformshost in WPF and nab the HWND, but i am new to WPF (aka newb) and dont see anything in the window haha. I’m still plugging away at it.
I don’t think nabbing the HWND of the WinFormsHost will work. What I’d suggest is to create a custom WinForms UserControl and use the HWND of that. Then, you can host the custom control into your WindowsFormsHost.Child property.
Here is an example that does exactly that using OpenTK.GLControl and here is the source for OpenTK itself (check OpenTK.sln -> OpenTK.GLControl project).
The downside is that you cannot host WPF elements on top of a WindowsFormsHost control. There are workarounds, but these won’t be necessary unless you find this limitation to be an issue in practice.
and I must add that the menus show up fine over the openGL window. and i didnt even do anything about it. So there is a way to render stuff over it, granted it uses the same thing as the pop-out menuitem
