surface: Unmap subsurface views, not surface, on parent destroy

Per the wl_subsurface spec:
      A sub-surface becomes mapped, when a non-NULL wl_buffer is applied
      and the parent surface is mapped. The order of which one happens
      first is irrelevant. A sub-surface is hidden if the parent becomes
      hidden, or if a NULL wl_buffer is applied. These rules apply
      recursively through the tree of surfaces.
      [...]
      If the parent wl_surface object is destroyed, the sub-surface is
      unmapped.

The terminology is kind of loose. My reading of this is that we should
'unmap' (hide from display, remove from input/focus consideration, etc)
a subsurface immediately when a parent is destroyed.

However, if the child surface is then paired with another parent which
is itself mapped, then the child surface should immediately be mapped,
because it has a non-NULL buffer already applied, and the parent surface
is mapped.

By marking the surface as 'unmapped' on parent destroy, we were removing
it from the scene graph, but also I think breaking the rules on mapping
by requiring another commit when it was reassociated with another,
already mapped, surface.

Removing the explicit surface unmap leaves the surface in the 'mapped'
state, but without any views, which I believe has the intended effect.

Signed-off-by: Daniel Stone <daniels@collabora.com>
This commit is contained in:
Daniel Stone 2023-06-22 16:06:05 +01:00
parent 3d9aecc846
commit 17af1c4d20

View File

@ -5087,9 +5087,6 @@ subsurface_handle_parent_destroy(struct wl_listener *listener, void *data)
assert(data == sub->parent);
assert(sub->surface != sub->parent);
if (weston_surface_is_mapped(sub->surface))
weston_surface_unmap(sub->surface);
weston_subsurface_unlink_parent(sub);
}