Discussion on how to integrate vsg and C# WinForm.

[XMatrixXiang]

A long time ago, I wrote a Demo for the integration of OSG and MFC. At that time, the approach was to transmit the handle of the MFC window to OSG, and then open a separate thread in OSG for rendering. Now I plan to try the integration of vsg and C# winform. If I pass the handle of C# window to vsg and then let vsg render in an independent thread alone, I don't know if this method is feasible.

[robertosfield]

I don't know anything about C# or winform as I'm not a Windows dev, so will have to defer to the Windows users in the community provide specif guidance.

As general note, the VSG, a bit like OSG, provides support for passing in the native Window handle via vsg::WindowTraits to the window creation so that the VSG just creates the required Vulkan surface, instance and logical device etc. I expect this will be the most straight forward means of integration.

The vsgQt project uses this approach, getting the native window handle from the Qt window and the uses the VSG to create the Vulkan integration.

[AnyOldName3]

You could either set up the WindowTraits with the native HWND and use the provided Win32_Window class, which would work fine as long as MFC/WinForms aren't expecting to handle any of the events that Win32_Window wants to handle, or you could make your own vsg::Window subclass like vsgQt does, but either way, you'll create a surface by passing vkCreateWin32SurfaceKHR a HWND. If you make your own subclass, you might want to avoid calling ValidateRect in response to WM_PAINT (so Windows knows you'll want to repaint as soon as you can), and then use WM_PAINT to trigger drawing and presenting a frame, but you can also copy the frame-loop-driven approach in regular VSG and don't even have to present from the same thread as owns the HWND, you'll just need to make sure you do call ValidateRect in response to WM_PAINT, or PeekMessage will always have a new message and you'll never be able to run the rest of your frame loop.