Vulkan Control?

[define-private-public]

I see in the upcoming 0.10 release an OpenGL control is included. To future proof Avalonia better, I think it would be wise to include a sort of Vulkan Control as well. There are projects out there such as Silk.NET which provide cross platform Vulkan bindings (have yet to try them out for myself).

Other widget toolkits such as Qt have already added Vulkan capability. And I'm sure that more are to follow.

[kekekeks]

OpenGLControlBase works on top of generic OpenGL-textrure-as-Bitmap API, which is essentially our D3DImage counterpart.

So Vulkan-drawn surfaces can be presented by either wrapping a DXGI-shared handle (win32), VK_KHX_external_memory extension (Linux) or IOSurface (OSX/iOS).

Wiring those up is an application-specific task that is outside of the scope of the project, but I'll try to provide some examples of doing that after 0.10 release.

[chances]

Note, the VK_KH*_external_memory extension has been promoted to a KHR.

[llfab]

We have finalized a Vulkan integration into WPF using DXGI similar to Microsofts sample implementation WPFDXInterop. Hence, we integrated our Vulkan 3D renderer with DX11 and made interoperability work with WPF DX9 creating our own subclass VulkanImage with D3DImage as its base class.

It works "functionally" very nicely. We also integrated the VulkanImage into a custom WPF FrameworkElement such that you can instantiate the entire thing via XAML.

We did a similar thing with OpenGL / Vulkan to make that work in Avalonia. This was a little more direct as you do not also have the breakage between the different DX versions.

However, both OpenGL / Vulkan integration and DirectX / Vulkan Integration have the following drawbacks:

• Latency: compared to a very native implementation using a swap chain to render to a hwnd using Windows.Forms and FormsHost for WPF integration, you can see quite some latency. We are displaying mostly still 3D scenes, so this is not so much a problem. For more demanding environments this seems almost a NoGo.
• Compatibility: both for OpenGL / Vulkan and DirectX / Vulkan we had to used vk extensions (OpenGL extensions) for sharing textures. This seems very demanding regarding GPU and driver capability. Though, it does work on most (even older) Nvidia environments and on most up to date Intel SoC GPU's, we found more incompatibilites than we would be happy with.
• Cross-platform: we found that you need different code routes on Windows than on Linux. Something that is not so nice to maintain.

Therefore, I would encurage a Vulkan backend for Avalonia to overcome above issues. Maybe that is also an option to overcome the Avalonia rendering "indirection" using EGL/Angle (as WGL seems not a good option on Windows). However, I admit that Vulkan compatibility is not as common as OpenGL, hence, fully replacing the OpenGL Skia backend would not be smart.