Clarify how surfaces which extend beyond the geomtry bounds of an xdg_surface should be rendered.

The problem:

There is some disagreement on how subsurfaces which extend beyond the bounds of the window geometry of an xdg_surface (in particulare an xdg_toplevel surface). See https://gitlab.gnome.org/GNOME/gtk/-/issues/1097. Specifically, Gtk3 assumes that subsurfaces that extend beyond the window geometry should still be rendered (assuming they are still on screen) and uses this for popovers, whereas in sway, the developers believe any surfaces should be clipped to the window geometry (and things like popovers should use xdg_popup). This is less of an issue in Gtk4, since xdg_popup is used more thoroughly there. However, existing applications may use subsurfaces this way (such as any applications that continue to use Gtk3), and this disagreement may lead to subsurfaces being used in this way in the future, which will not work as expected in sway or other compositors that clip to the window geometry.

The fact that intelligent people from different projects interpret the same documentation in such a contradictory way suggests that the documentation is not sufficiently clear.

Therefore, I propose that the documentation clarify how compositors should handle surfaces which extend beyond the window geometry, and what assumptions clients can make about this behavior.

Relavent documentation:

description of wl_subsurface:

A sub-surface's size and position are not limited to that of the parent. Particularly, a sub-surface is not automatically clipped to its parent's area.

description of xdg_surface.set_window_geometry:

The window geometry of a surface is its "visible bounds" from the user's perspective. Client-side decorations often have invisible portions like drop-shadows which should be ignored for the purposes of aligning, placing and constraining windows.

If never set, the value is the full bounds of the surface, including any subsurfaces. This updates dynamically on every commit. This unset is meant for extremely simple clients.

description of xdg_toplevel.configure (event):

The width and height arguments specify a hint to the window about how its surface should be resized in window geometry coordinates. See set_window_geometry.

Possible clarifications:

In the following by "window geometry", I mean the window geometry as determined by the compositor, which may come from the client, or may be determined by the tiling layout (and communicated to the client via a configure event).

1. The compositor MUST (or SHOULD?) clip surfaces to the window geometry, the client SHOULD NOT render outside the geometry.
2. The compositor MAY clip surfaces to the window geometry, the client SHOULD NOT render outside the geometry.
3. The compositor MUST NOT clip surfaces to the window geometry for a focused surface or it's subsurfaces. Clients may render outside the geometry, and assume that such rendering will be visible, provided the region is on-screen and the surface or it's ancestor is focused.
4. The compositor MUST NOT clip surfaces to the window geometry for any surface. This is quite problematic for tiling compositors.
5. The compositor should clip surfaces if the window is tiled, but not if it is floating. This would make it difficult for the client to know if it can rely on subsurfaces to be rendered as expected, and in practice wouldn't be any better for client than simply always clipping.