Clarify behavior of client-side buffer storage destruction before wl_buffer.release
After !141 (merged), the spec says on this matter:
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.
This wording seems to me to allow (or I am misunderstanding the concepts of buffer storage not being re-used or mutated?) for one-shot buffer commit scenarios at points other than client process termination (which is used only as an example):
- client: attach wl_buffer A to wl_surface S
- client: commit wl_surface S
- client: destroy wl_buffer A and backing buffer storage (e.g., SHM memory).
- compositor: wl_surface S is presented with wl_buffer A contents until the next attach/commit
Some clients (e.g, Wine Wayland) currently use this one-shot feature, misbehaving under, e.g., Weston which doesn't fully support this (see weston#604). If this not a supported scenario, perhaps we can update the spec wording to further clarify this?