I have been working for quite a while on a simple graphics engine in C++ using Direct3d 11. I have decided to try and build a GUI just for fun, and after reading some on WPF, I really got fond of it. Thing is, i'm not sure if what I want to do is even possible.
What I would like to do is to load my engine DLL in a WPF application, and use the DX device inside a portion of the WPF window. Basically, what I want to do is similar to a map editor( where the main window has a bunch of controls and a child window that contains the render area - the device ), but instead of converting my engine to XNA, I'd like to use the already working C++ code with WPF. Is that possible?
Also, I have tried just for practice to create a window with Win32 and attach the device to it. It was a simple matter of just assigning the window HWND to the device upon device creation. I assume its the same with a WPF window, or am I wrong? Thank's for reading :)
Edit: Forgot to mention that I'm a complete novice with C#, but I do know you can import a C++ DLL and use its functions, I'm just no sure about the device - wpf window interaction.
WPF supports embedding D3D surfaces.
Start here http://msdn.microsoft.com/en-us/library/system.windows.interop.d3dimage.aspx
WPF mainly works with managed code. Managed code means most of the things are taken care by garbage collector. And as I can see from your post You want to integrate C++ dll which is unmanaged code. It is not so simple using C++ library in WPF but not impossible. C# provides many other aspects to handle these kind of scenarios.
You will have to take a look about Interoperability and unmanaged code.
Have a look on below link:
Sample Project
For the WPF/D3D11 interop, have a look at WPFDXInterop that was written by a Microsoft engineer. This allows you to have a D3D render target inside a WPF window, with proper interaction. There's a sample project at the link.
Related
I would like to render a WPF window into my own buffer and add that to my render loop, render into my own scene, manipulate it, etc.
Is there a built-in way to capture a WPF window's underlying DirectX buffer/swapchain?
Possible but not easy.
There is two great articles I found when trying to achieve this both by Jeremiah Morrill.
A Critical Deep Dive into the WPF Rendering System
How to get access to WPF’s internal Direct3D guts
Jeremiah uses a Dynamic Link Library (DLL) written in C++ which hooks DirectX functions and exports initialise function in which C# calls.
This still does not stop you using Easyhook and doing it in C# instead of Jeremiahs way.
When doing this myself this was my flow:
Hook DirectX 9/10/11 (EndScene, Present)..
Callback in .NET domain
and marshal buffer data using PInvoke
Manipulate buffer return
manipulated buffer back to C++ library
Display the final image buffer to
screen i.e WPF...
My experience: there is a compromise on speed but I believe with optimisation could be viable solution.
Another Solution
You could EAT hook D3D11CreateDeviceAndSwapChain which is an export from d3d11.dll. This won't work since WPF uses DirectX 9 under the hood.
Update:
After reversing WPF over the weekend I found unmanaged wpfgfx.dll which contains milcore which is a wrapper around DirectX 9 still to this date. You can see this in the below diagram of WPF Architecture.
Inside the module wpfgfx.dll it contains MILCore DirectX wrapper. More about WPF Architecture
I have written a DX11 renderer using c++. I am now looking for a way to implement an Editor/GUI for it.
Since im pretty used to Windows Forms and WPF C# Applications im thinking about putting my renderer inside a dll, load the dll from a c# application and use it to draw into a defined section of the form. Does this even work with a window handle passed by a managed c# appication and how is the performance if it does?
From my understanding, since the actual communication with the DX11 API would still be directly in c++ and the c# part would only tell the dll what to do the performance loss should be almost nothing. Or is this generally a bad idea and implementing the GUI directly in c++ using a library or D2D is the better approach.
In WPF you can use D3DImage which is just like a simple Image in your xaml. The general principle is as follows:
Allocate a Direct3D 9 texture, this will be your rendering target.
Hand it over to the D3DImage.SetBackBuffer.
Put your rendering code inside CompositionTarget.Rendering event handler.
RenderStuffToTexture();
d3dImage.Lock();
d3dImage.AddDirtyRect(new Int32Rect()
{
X = 0,
Y = 0,
Height = d3dImage.PixelHeight,
Width = d3dImage.PixelWidth
});
d3dImage.Unlock();
Since you are using Direct3D 11, you have to use DXGI surface sharing to share the D3D9 textute with D3D11. There are 2 examples I know of that illustrate how to do just that. Microsoft D3D11Image and D3DImageEx (my personal preference, can be found in multiple places online).
Regarding performance, once you use WPF you no longer doing the presentation yourself. You literally write a small render-to-texture logic inside a WPF D3D9-based renderer. So not everything can be controlled including presentation time. From my personal experience, you can definitly render simple scenes at a nice framerate. For a really graphics intensive app and strict FPS requirements I would use a more lightweight (and less intrusive) UI solution.
Note that you can also use WinformHost control to get a HWND and render to it. This has a serious disadvantage if you want to overlay UI controls over the rendered frame - AFAIK you simply can't.
We have Delphi code that displays data capture and edit forms, and would like to integrate that into a WPP app. Changes can be made to the Delphi code, to communicate with a C# service that enables communication between the two apps.
Something that has been mentioned is, at a low level, changing the parent window of a Delphi window from another Delphi window (maybe even the main app window) to another window, a WPF or WinForms window. How feasible is this? How can it be done?
I am also pondering somehow using the WPF Remote Desktop control, but connecting to a remote desktop server on the same machine somewhere. Once again, how feasible, and how?
I'm embedding wpf windows into my delphi app. Yes, it's the opposite way, but maybe you get inspired. I build some COM-Objects on both sides - c# and delphi, which are used for exchanging events/functions etc. To embed the windows i use HWndSource Class.
If you want to embed a Delphi window into WPF, you can use the HWndHost Class.
There is a good C-sample which can nearly direct translated to Delphi in MSDN. See Walkthrough: Hosting a Win32 Control in WPF
Also a good starting point is this article "WPF and Win32 Interoperation".
I've never done it myself, but I've heard of RemObjects' Hydra framework, they do exactly what you want.
Check this out:
http://www.remobjects.com/hydra/
and an example on their wiki:
http://wiki.remobjects.com/wiki/Delphi_WPF_Sample_(Delphi)
Hydra itself will be a host application that can host both - WPF (managed) and Delphi (unmanaged) modules.
WPF Remote Desktop control is a bad idea in my view, users won't be happy with such experience.
I want to create a simple 3D editor program, and I don't like C++ windows programming. But I don't want to mess with managed code when using OpenGL, either. So, it is possible to create in native C++ a control which will host the OpenGL 3D drawing surface, with no other controls, and also with an interface (methods and properties), and use it as a control in a WinForms, or even better, WPF application?
It is also possible to use managed C++. I created a simple OpenGL control for WinForms which suits your requirements. You can find more info about it here.
Does it have to be OpenGL? Consider using XNA which would let you use C# and DirectX. Otherwise I suggest you find a C# wrapper for OpenGL. There are two wrappers listed here http://www.opengl.org/resources/bindings/.
I dont really understand your intention. You said that you hate C++ programming, you dont want to mess with managed code when using OpenGL, you want opengl windows with no ui control but you want winform or wpf as you ui.
If you hate programming c++, you have to use managed code.
If you dont want to mess with managed code when using OpenGL, you have to use c++ programming.
if you want to create in native C++ a control which will host the OpenGL 3D drawing surface, with no other controls(which i assume UI controls), why consider winform or wpf?
Dont use WPF to create 3d heavy applications. wpf was meant as a ui. you will find a lot of limitation along the way. There is also limitation in hosting(WPF), which makes it useless to use opengl with wpf.
I think the best bet would be XNA or http://www.opentk.com/(if you must use OpenGL). Tao Framework is obsolete and is not worth the effort.
I suggest you look at Ogre 3D ( http://www.ogre3d.org ). This cross-platform C++ library covers Open GL as well as DirectX. It has been successfully embedded in Qt, MFC and even has .NET representation. I highly suggest you take a look at it.
All you have to do is create a wrapper in c++ that exposes functions in c#
Windows API
So i know that the WinForms touches on the Windows API a little, but frankly its horrible. ESPECIALLY with the layered windows and flickering. So i was wondering if anyone has wrote partial, or full wrappers for the Windows API.Im particularly interested in the Layered Window aspect, but really any part of the API is a good place to start.
Update: I found the Windows API Code Pack here: http://code.msdn.microsoft.com/WindowsAPICodePack but it seems that it doesnt wrap Layered Windows? Am i correct in assuming this?
Native API (Windows)
Ive heard a little bit about the Native API, but im not quite sure what it is for? what features does it provide? would it be a good idea to look into?
Summary (Questions in a nutshell)
Does anyone know of an existing (partial or full) wrapper of the Windows API?
If the answer is no to question one, where would be a good resource to learn about it myself, and potentially write my own?
An explanation of the Native API? What does it do? Can I use it to make applications better? Can I even USE it at all?
An answer to any of those is highly appreciated :) thanks
You could start at PInvoke.NET.
The LayeredWindows actually work better in WinForms than windows.
The native windows controls don't even have the alpha channel support of the WinForms analogues, so native windows flicker, and require massive amounts of subclassing to override the painting to use alpha compatible routines.
You would be better off going to WPF. The windows team has not treated the native control's well at all, going so far as to remove support for a style (WS_EX_COMPOSITED) if aero glass is enabled which, given the way that windows controls paint, effectivly made it impossible for any application to paint flicker free if it uses child window's as controls.
WPF "draws" windows controls, but does not use discrete (native) child windows to represent individual controls. This gives it control over when and how its window surface is rendered.
The Windows API is huge. There is a ton of stuff in it. Windows Forms is a wrapper of parts of it. WPF is a wrapper of parts of it. Parts of the Base Class Libraries (eg System.IO.*) are wrappers of parts of it. The Code Pack is a wrapper specifically of things that were new in Vista and Windows 7 and not in Windows Forms or WPF.
Have you looked into WPF? Combined with P/Invoke of specific API functions, it might take you a long way towards where you want to be.