Hmm okay, but does it need to be done before vkQueuePresent? Regarding wayland_surface_ensure_contents, could we just for instance ensure the surface has contents when it is resized / made visible in wayland_WindowPosChanged?
Here are some concerns:
* If we unconditionally call `wayland_surface_ensure_contents` on resize/visibility, in most cases we will get another flush once the application actually draws, and end up with double commit, which is both inefficient and can cause flicker (since the first commit will be empty). * If we try to avoid the double commit, by detecting that the surface has old contents, but then the window surface is never flushed, we will get stuck with the old, incorrectly sized buffer (the committed buffer size matters for configuration reasons).
In essence, in WindowPosChanged we don't have all the information to properly decide whether we want to "ensure contents", and doing it unconditionally has some cost. The current approach avoids these problems by only performing the "ensure contents" commit in the few cases it is absolutely needed (i.e., when we want to show the GL/Vulkan subsurface contents and won't be able to otherwise).
With wayland_surface_reconfigure, it looks awkward that the client drawing is driving the window surface size, I think it should be done separately and client drawing should not involve any windowing logic but simply return errors if the size doesn't match.
This seems awkward because the Wayland surface model is different: surfaces have no independent inherent size, it's the buffer size (+transformations) that determines the "surface size", which makes drawing and sizing interlinked.
In Wayland's model ack-ing a new state and providing new contents (buffer + transformations) for that state should ideally happen in the same commit to get a glitch-free experience and also to prevent the compositor from disconnecting us.
If we unconditionally ack a state (let's say maximized) in the window management code (i.e., WindowPosChanged), and we have current contents with incompatible size attached (i.e., > max size) the compositor will disconnects us. If we don't ack the state in order to avoid the disconnect, then we will have to ack it somewhere else, and the only option is when we get new contents.
The wp_viewport protocol and xdg geometry do provide a sort of an escape hatch, by allowing us to fake the effective "surface size", but that means that contents and size will (at least transiently) disagree and lead to visual glitches/stretches etc.
Note that all of the alternatives I described are options I have previously considered (and tried in various experiments) and in the end decided against, due to concerns about complexity/edge-cases, efficiency, glitchiness and generally going against the grain of the Wayland model/expectations. These options are certainly available to us to explore again if we are absolutely determined to move away from the current approach, but I am not convinced it's currently worth going down this path.