Concerning the child. accel design proposed, I am not sure if I find it less complex, but rather differently complex. !6107 centralizes the complexity in the `wayland_surface` update logic, but then other parts of the code can just use it without caring about most of the details. This MR has simpler parts, but then spreads out the complexity, since other parts need to care about `wayland_surface` vs `wayland_client_surface` etc. I am sure this perception about complexity is affected by my mind being used to the other design, though, and there are certainly benefits to this MR (e.g., avoiding an intermediate `wl_surface` when doing child accel. rendering).
Fwiw, the rationale behind keeping client surfaces better separated from window surfaces, is that I believe it will make it easier to move move more code into win32u. Right now the driver responsibility is fairly large, and they can manage and organize their surfaces pretty much the way they like. I think it makes it however difficult to factor things together between drivers. Other drivers have this same window vs client surface model, I think it's good to keep it the same.
What I ambition then, is to move as much of the "client surface" (GL/VK) code as possible to win32u. This is already almost the case for Vulkan, a bit less for GL. Then, win32u would also be in charge of managing these client surfaces the way it likes, compositing them or sharing them with other processes in a common way.
For the "window surface", I would like to find a way to split it a bit more than it is currently. We could have pure windowing on one side, which would be only about positioning/organizing window frames. And the GDI drawing logic on another side. Ideally the latter would be using the same primitives as the "client surface" code, and use similar surfaces that could be presented directly or fed into our compositor, to be later presented onto the window frames we have set up.
It's actually quite similar to the wayland protocol BTW, with surfaces and buffers, but would be done in win32u, with our primitives, and for all the drivers.