Commit 2933d3b0 authored by Simon Ser's avatar Simon Ser
Browse files

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's avatarSimon Ser <contact@emersion.fr>
Closes: wayland/wayland#185
parent f452e412
Pipeline #326494 passed with stages
in 1 minute and 43 seconds
......@@ -1434,9 +1434,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.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment