Why do you get terrible performance? I vaguely recall reading that doing this ties the input queues together, so that all (input?) messages get dispatched to both processes, which then both need to have their message loops respond in a timely fashion. Is that it?
Anyway, I believe the Microsoft Management Console (MMC) actually does this. The content windows (at least in some cases) belong to a different process than the surrounding UI.
Also, WebView2 (the new Chromium-based Edge webview) runs out-of-process, but maybe it does some things in the embedding process to improve performance?
Microsoft Management Console loads DLLs into the process, it does not use a separate process for the snap-in. (Just checked this in a debugger)
As for why there would be bad performance for putting a window into another process's window, I can only speculate. It takes something like 10000+ CPU cycles for Windows to finish switching to a different thread or process. If this is happening for every message that is handled by both the parent and the child window, that would be a lot of overhead.
I haven't checked if the Out-of-process webview is the EXE that owns the window or not.
Hmm, maybe the MMC child windows were owned by a different thread (which would also involve a separate message loop and a context switch) but not a different process? I distinctly remember finding some windows in there that were not owned by the main thread, but I don't have my notes accessible at the moment.
Anyway, I believe the Microsoft Management Console (MMC) actually does this. The content windows (at least in some cases) belong to a different process than the surrounding UI.
Also, WebView2 (the new Chromium-based Edge webview) runs out-of-process, but maybe it does some things in the embedding process to improve performance?