Best practices for client side buffer management

[Guillermo Rodriguez Garcia]

Hi Brad,

El vie., 19 jun. 2020 a las 5:24, Brad Robinson
(<brobinson at toptensoftware.com>) escribió:
[...]
>
> Finally, the toolkit already maintains an off-screen buffer with the window's current contents rendered into it.  I'll probably replace that with a Wayland buffer, but wondering about partial updates.  eg: if the client only needs to redraw a part of the window what's the correct process to update just that part with Wayland.  Can I just update the existing buffer and prompt Wayland to just redraw that part?

I am facing a similar situation with a toolkit that maintains an
off-screen buffer with the current window contents, and will update
that buffer at arbitrary times, when the application needs to update
the UI.

You must consider the following:

Once you submit a buffer to Wayland you cannot touch it anymore until
the compositor releases it back (wl_buffer.release callback). From
Pekka's email:

> When you submit a buffer to a Wayland compositor, it gives the
> compositor permission to read the buffer at any time, as many times as
> it wants to, until it tells you with wl_buffer.release that it will not
> be looking at that buffer again. You must not write to a buffer that
> might be read by the compositor, as that can cause misrendering on
> screen (e.g. your repaint is shown unfinished).

This means you cannot simply use the same off-screen buffer that the
toolkit maintains, since the toolkit should not update the buffer once
it submits it to Wayland.

At some point I thought that I could have separate Wayland buffers and
copy damaged regions from the toolkit buffer to one of these Wayland
buffers before submitting it to the compositor.
The idea would be to copy the set of regions that were damaged since
the last update.

But just copying damaged regions is not enough either. From Pekka's email:

> Also, every buffer you submit must be fully drawn, also outside of the
> areas you mark as damage. The compositor may be reading more than just
> the damage you submit.

So this means that everytime the toolkit updates the off-screen
buffer, I may need to copy _the entire thing_ to a Wayland buffer and
submit it to the compositor... not very efficient I guess.

I have the feeling that Wayland is designed for a model where the
client renders the entire frame on demand (most of the examples I've
found so far work like this) and not for a model where the client is
updating a buffer asynchronously and you just want to tell the
compositor to update parts of the frame.

I would be very interested to learn about your solution to this problem.

Best,

Guillermo Rodriguez Garcia
guille.rodriguez at gmail.com