4 ms·

Another awesome aspect of X11: Xembed. Since it's "windows all the way down" you can have apps (rather than the window manager or root window) be the parent of

Another awesome aspect of X11: Xembed. Since it's "windows all the way down" you can have apps (rather than the window manager or root window) be the parent of other app windows. Two nifty examples of this: * https://tools.suckless.org/tabbed/ https://tools.suckless.org/tabbed/ * https://surf.suckless.org/ https://surf.suckless.org/

odiroot 3y ago
AFAIK this is how audio plugins are embedding themselves in DAWs on Linux. No idea how that's gonna work on Wayland.
Dwedit 3y ago
Win32 does allow you to change a top-level window into a child window of another process. You just get terrible performance if you actually attempt to do this. For a more practical way to simulate a top-level window being a child window of another program, you make the top-level window Borderless, and perform all the necessary window management to maintain position, dimensions, and Z-order.
- ptx 3y ago
  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?
  - Dwedit 3y ago
    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.
    - ptx 3y ago
      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.

odiroot 3y ago

AFAIK this is how audio plugins are embedding themselves in DAWs on Linux. No idea how that's gonna work on Wayland.

Dwedit 3y ago

Win32 does allow you to change a top-level window into a child window of another process. You just get terrible performance if you actually attempt to do this. For a more practical way to simulate a top-level window being a child window of another program, you make the top-level window Borderless, and perform all the necessary window management to maintain position, dimensions, and Z-order.

ptx 3y ago
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?
- Dwedit 3y ago
  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.
  - ptx 3y ago
    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.