On Tue Aug 13 09:30:31 2024 +0000, Alexandros Frantzis wrote:
This was used in https://gitlab.winehq.org/wine/wine/-/merge_requests/6107/diffs?commit_id=ab... In short, the client area subsurface that contains the accelerated content will obscure any GDI rendering of child windows (which by default end up on the parent window_surface behind the GL/VK subsurface). Using a separate window_surface (and wayland_surface) allows us to place the child window contents above the GL/VK subsurface. I came across this scenario while testing your `wglchild` example program. Without this fix (or some other solution) the decoration of the child window is obscured.
Yeah, then this the same thing is happening with other drivers and they implement their own offscreen rendering / manual compositing for this case (although it's not widely implemented).
Historically child windows were used in winex11 for non-accelerated rendering, however it caused many issues as Win32 events and child window compositing is quite different from what the host may be doing.
Implementing the child window composition ourselves avoids the impedance mismatch, although we then need to handle the accelerated / non-accelerated composition case. In general this is not very well supported, and you probably don't need to care much about it for winewayland.