Bug 477737

Summary:	KWIN includes window decorations in the size of new windows for SSD (xdg_toplevel)
Product:	[Plasma] kwin	Reporter:	Campbell Barton <ideasman42>
Component:	wayland-generic	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	kde, nate, vlad.zahorodnii, xaver.hugl
Priority:	NOR	Keywords:	wayland-only
Version First Reported In:	5.27.9
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Campbell Barton 2023-11-29 22:24:58 UTC

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

Comment 1 Vlad Zahorodnii 2023-11-30 19:50:15 UTC

> 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.

Comment 2 Vlad Zahorodnii 2023-11-30 19:59:24 UTC

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.

Comment 3 Campbell Barton 2023-12-01 03:15:54 UTC

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

Comment 4 Campbell Barton 2023-12-01 03:16:45 UTC

Closing as not a bug.