summaryrefslogtreecommitdiff
path: root/protocol
diff options
context:
space:
mode:
authorSimon Ser <contact@emersion.fr>2021-05-26 12:07:17 +0200
committerSimon Ser <contact@emersion.fr>2021-06-11 14:05:27 +0000
commit3e897faa29d13bef6f9af31d4f2e89a526e60f4c (patch)
tree93e1d89eb6f99d4b9d80761d1f93e993b0380a8b /protocol
parentba0c63dee86cf94272c7763d711695fe3af0f210 (diff)
downloadwayland-3e897faa29d13bef6f9af31d4f2e89a526e60f4c.tar.gz
protocol: allow immediate wl_buffer.destroy if not re-used
Allow wl_buffer objects to be destroyed without having to wait for wl_buffer.release if the underlying storage isn't going to be re-used. The main motivation for this is to avoid glitches when a client is torn down. When a client disconnects, all of its objects are destroyed in arbitrary order. However some compositors will still need to access the destroyed buffer's underlying storage afterwards, e.g. for visual effects (fade-out) or for atomic layout updates (wait for other clients to commit a new buffer before hiding the buffer). It's still incorrect for clients to destroy a wl_buffer and mutate the underlying storage without waiting for wl_buffer.release. Signed-off-by: Simon Ser <contact@emersion.fr> Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/185
Diffstat (limited to 'protocol')
-rw-r--r--protocol/wayland.xml9
1 files changed, 6 insertions, 3 deletions
diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index acb85fd..ef65714 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1435,9 +1435,12 @@
from the same backing storage or use wp_linux_buffer_release.
Destroying the wl_buffer after wl_buffer.release does not change
- the surface contents. However, if the client destroys the
- wl_buffer before receiving the wl_buffer.release event, the surface
- contents become undefined immediately.
+ the surface contents. Destroying the wl_buffer before wl_buffer.release
+ is allowed as long as the underlying buffer storage isn't re-used (this
+ can happen e.g. on client process termination). However, if the client
+ destroys the wl_buffer before receiving the wl_buffer.release event and
+ mutates the underlying buffer storage, the surface contents become
+ undefined immediately.
If wl_surface.attach is sent with a NULL wl_buffer, the
following wl_surface.commit will remove the surface content.