Introduce wlr_buffer

[emersion]

This PR introduces wlr_buffer, as discussed in #1046 (comment).

wlr_buffers are ref-counted and hold a texture. When they are destroyed, the wl_buffer is released and the texture is destroyed.

A compositor can reference the buffer when it needs to:

struct wlr_buffer *buffer = wlr_buffer_ref(surface->buffer);

// Use buffer->texture (can be NULL if client destroys the buffer)

wlr_buffer_unref(buffer);

@ammen99 Can you provide some feedback? Would this approach work for you?

• We probably want to get rid of wlr_surface.texture
• Listen for renderer destroy

Fixes #1046

[ammen99]

can be NULL if client destroys the buffer
I'm not sure about how buffers work in wayland, but is this going to happen for buffers that are uploaded as textures (like wl_shm)?

Otherwise this approach seems good to me.

[emersion]

I'm not sure about how buffers work in wayland, but is this going to happen for buffers that are uploaded as textures (like wl_shm)?

For wl_shm, wlr_buffer.resource will be NULL if the client destroys the buffer, but wlr_buffer.texture won't be NULL because we copied the data when uploading to the GPU (so even if the client destroys its copy, we're still able to read our own copy).

For wl_drm and dma-buf, the texture is shared with the client, so if the client destroys it early (before we send the release event) we loose access to the data. In general, this should not happen. This may happen when a client exits for instance (if you still have a reference to the wlr_buffer when the client terminates).

Additional note: if you reference a wlr_buffer backed by wl_shm and don't release it before the next commit, we'll have no choice but to re-upload the whole texture (wlr_buffers that are not released are immutable). I'm trying to think of a way to do it that would allow you to keep two buffers around and upload damage from the last 2 frames, but this will probably require more work in wlr_surface (maybe by allowing users to override the apply damage function, or require users to manage their wlr_buffers themselves).

[ammen99]

@emersion, fair enough, I'd also be interested in a way to be able to check whether the texture will survive (e.g wl_shm) or it can be destroyed at any time (dma-buf), because for some reason I might decide I really need the texture so I'd want to copy it manually if it is necessary.

[emersion]

I'd also be interested in a way to be able to check whether the texture will survive (e.g wl_shm) or it can be destroyed at any time (dma-buf)

That's easy, just check wlr_buffer.released. If the buffer is not released, then then client can destroy the texture.

[ghost]

wlr_buffer_ref should return a wlr_buffer *, since that's what API users will do - ref, create a new wlr_buffer struct and copy the contents of the original wlr_buffer.

[emersion]

Good idea. I don't get the last part though:

create a new wlr_buffer struct and copy the contents of the original wlr_buffer.

This would duplicate the ref counter?

[emersion]

Ping @ascent12

[ddevault]

Thanks!