Logical error with new windows under WAYLAND & server-side decorations, where the surface size is used to create a new window that includes the window decorations. This means creating a surface 500x500 then using XDG top-level to assign server side decorations will create a 500x500 window, shrinking the applications surface (e.g. 480x494) in the `configure` callback. Since there is no way to access the decoration size there is no way to create a window with a predictable surface size. This was reported to Blender, which stores & restores the size of the file-selector. This results in the window shrinking each time it's displayed, see: https://projects.blender.org/blender/blender/issues/113059 Video: https://projects.blender.org/attachments/d781be36-c778-452b-8115-f96310d46329 ---- STEPS TO REPRODUCE 1. Open Blender [versions `3.6.x`, `4.0`, `4.0.1`]. 2. Press Ctrl-O (the file selector will display). 3. Move the cursor over the window and press Escape (closing the file selector). 4. Repeat steps 2 & 3. OBSERVED RESULT The window shrinks each time. EXPECTED RESULT The `xdg_toplevel_listener::configure` callback should not include window decorations in the `width` & `height` arguments. Instead, the existing surface size should be used unless there is a reason to constrain them (window size exceeds monitor size for e.g.). SOFTWARE/OS VERSIONS Windows: NA macOS: NA Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.27.9 Qt Version: 6.6.0
> This means creating a surface 500x500 then using XDG top-level to assign server side decorations will create a 500x500 window Does blender request a server side decoration **after** attaching a 500x500 buffer to the surface? > existing surface size should be used unless there is a reason to constrain them (window size exceeds monitor size for e.g.). What window geometry size the compositor puts in configure events is subject to compositor policies. Apps cannot make assumptions about it.
If blender initializes xdg-toplevels as follows -> wl_compositor.create_surface -> xdg_wm_base.get_xdg_surface -> xdg_surface.get_toplevel -> xdg_decoration_manager_v1.get_toplevel_decoration -> xdg_toplevel_decoration_v1.set_mode -> wl_surface.commit wait for the configure event -> wl_surface.attach(500x500) -> wl_surface.commit then the toplevel won't shrink. If the server side decoration is requested **after** the surface has been mapped, what happens next is up to the compositor. In case of kwin, it tries to maintain same frame geometry, so the space for window borders will be subtracted from the surface size. If blender indeed initializes like that, we recommend to request a server side decoration **before** the first wl_surface commit. It's going to fix this issue and it's going to ensure that there's no any flickering caused by server side decoration being missing for one frame.
This works, thanks for the hint... while I'm not sure if this is following the XDG spec, postponing attaching the sized buffer helps to avoid flickering. Committed fix: https://projects.blender.org/blender/blender/commit/e6c200e94ccc16839bcccee39be84dde9dce3993
Closing as not a bug.