May 28, 2024
3:32 p.m.
On Fri Mar 29 14:02:40 2024 +0000, Alexandros Frantzis wrote: > > 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. But the OpenGL/Vulkan surface is not the window surface, and I don't see why GL/VK drawing should have anything to do with their parent window surface, except passively reacting to its size changes. You can create a GL/VK surface on a message or an invisible window, with no window surface, or a child window which would ultimately use its ancestor toplevel surface as a support. Assuming we have some logic in win32u, do you think it could work if we ensure that the toplevel window surface is flushed before presenting (ie: calling `surface->funcs->flush` -> `wayland_window_surface_flush`)? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5418#note_66482