mirror of
https://gitlab.freedesktop.org/wayland/wayland.git
synced 2025-11-01 22:58:40 -04:00
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
This commit is contained in:
parent
ba0c63dee8
commit
3e897faa29
1 changed files with 6 additions and 3 deletions
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue