Add CreateSurfaceFromHwnd to Windows.UI.Composition

[zhuman]

A major barrier I would have to using WinUI right now is the inability to host a child HWND - or even better, bring back the IDCompositionDeviceDesktop::CreateSurfaceFromHwnd as a new function in Windows.UI.Composition to host layered child windows. Bringing CreateSurfaceFromHwnd into the new API would solve so many issues with hosting third-party plug-ins, the "airspace problem", and enable people to integrate old UI technologies seamlessly with composition blends and animation. As an example, every audio application that supports third-party VST controls needs to be able to host HWNDs in some way, as this is the interop mechanism provided by the standard.

Right now the closest I could come would be to host WinUI in another framework - the reverse. This has its own issues, particularly around performing layout/arrangement of the WinUI parts with the HWND. It also makes it impossible to use WinUI "around" child HWNDs since you can only have one island today, and even with multiple islands things would get really unwieldy.

Please consider CreateSurfaceFromHwnd! (I know it's actually internally used heavily by the Windows shell with Windows.UI.Composition, so this is a request to make it public!)

Originally posted by @zhuman in #719 (comment)

[ranjeshj]

@jeffstall as FYI

[mfkl]

Yes, we are interested in this for proper LibVLC support as well.

[selastingeorge]

Looks like this might not be happening any soon so it's better to use DWM private API's to achieve it. Windows.UI.Composition Thumbnail

[HO-COOH]

2024 now and I am still waiting for this to happen.
How Arc browser is able to seemingly achieve this is still a myth. (This pop up is not a window, so if they host the chrome window as the normal child-window way, it will block the pop up)