We Keep Coding

Using a DirectX c++ DLL in a C# WPF or Windows Forms Application

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.

UWP support for opengl

guys.
I have a opengl library written in c++. I know that I can use Angle but because of this I will need to code in C++ my whole app. Is there a way to use c++ opengl in UWP and still use C# as a main language?

Is there a way to use c++ opengl in UWP and still use C# as a main language?
ANGLE is currently the only way to get the OpenGL API to run in UWP. For more details please reference this thread.
You can write your own via interop if you want to use ANGLE from c#. You can also write your low level OpenGL stuff in C++ and wrapper it. Then invoke it by C# in your logic level.
Fortunately, people who have the same requirements as you created an issue on the GitHub a few days ago, and got samples from #mattleibow. #mattleibow shared his code in this thread. For more details, please reference OpenGL surface from SwapChainPanel declared in XAML in C#.
Additionally, ANGLE is actually for translating OpenGL ES to DirectX. So I recommend you to use Win2D instead. Win2D is a new, immediate mode 2D drawing framework for XAML applications on Windows 8.1 and Windows 10. It is built on the high performance foundation of DirectX, but is designed to provide the convenience and ease of use expected by C# and .NET developers. More details you can reference this video.

I realize it's been a long time since you posed this question, but I needed to do this also, so put together a small C# project that shows how to use ANGLE from C#. It includes minimal bindings to GL from C# (since OpenTK does not yet target UWP), and a part of the template application from ANGLE itself, which has all the SwapChainPanel, etc, setup. You can check it out here.

I had this issue, so I created my own library.
You could use my new library (https://github.com/hamarb123/hamarb123.SharpGLES) which runs OpenGL ES on UWP (and .NET Framework), it even has a GLESSwapChainPanel class for ease of use.

Can SDL run inside a WinRT application alongside other XAML controls?

I have found that SurfaceImageSource can be used to create an 'island of DirectX' (i.e. DirectX inside WinRT alongside other XAML controls). Considering that SDL has recently been ported to WinRT, can I create an SDL game (not fullscreen) which can have other XAML controls at it's side ?
There doesn't seem to be adequate documentation yet on WinRT. Also, if it's not possible with SDL can I achieve this (a simple arcade-style game) with some other graphics library/game engine ?

XAML support for SDL/WinRT is planned, but not yet implemented beyond a barely-functional (and largely non-functional), proof-of-concept phase. Much of the work on SDL/WinRT has, so far, been geared towards getting non-XAML/Direct3D apps running well.
Initial support for XAML will, to note, probably be geared around SwapChainPanel and/or SwapChainBackgroundPanel, as the APIs for these map a bit more closely to SDL's own APIs. (At least, these are my own plans, development-wise.)

Music spectrum visualization with better effects/graphics

I'm creating a music player in C# / WPF.
With the BASS audio engine, I can create simple spectrums like this:
But I'm looking to create nicer looking ones like those seen in YouTube videos created in After Effects.
Are there any DirectX, OpenGL or other engines that can produce similar effects that I can use in my application?

Well, first, your question isn't the best (fit wise) to SO, since it's not about a problem you have with code.
Having said that, WPF supports OpenGL, as you can see
Using OpenGL in a WPF Application
Creating OpenGL Windows in WPF
And also DirectX (although 9 it seems)
Walkthrough: Hosting Direct3D9 Content in WPF
So, yes, you can choose your engine :)

Integrating Silverlight 4 webcam functions into WPF

After toying a little with the new Silverlight 4 camera features, and being really disappointed that these were not included in WPF, I looked at the Silverlight assemblies and found that they more or less delegate all work to agcore.dll.
Do you think it is a good idea to package agcore.dll with my WPF application, and copy/paste or rewrite all classes concerning cameras to WPF, to get these nice features there?

That particular approach isn't likely to work, unfortunately. There's a lot more to getting C# code to work with Silverlight than just referencing the appropriate DLL. Silverlight is actually a completely different implementation of the CLR, so you can't just call into agcore.dll from a WPF app and have it run.
If you need Silverlight features in your app, I can think of two ways to get them: (1) you could conceivably host a completely separate instance of Silverlight inside a browser control in your WPF app, though communication with that Silverlight instance becomes complicated (though not impossible); or (2) you could write your entire app in Silverlight OOB (Out-of-browser)/trusted mode.

You can try VideoCaptureElement in my WPF MediaKit. It will show a webcam in WPF. It does have a different API than the Silverlight webcam API, but it should have just as many features.