Best practices for client side buffer management

[Brad Robinson]

Hi All,

I'm fairly new to Wayland and Linux GUI programming in general, but doing
some experiments to figure out how to integrate it into my custom UI
toolkit library and have a couple of questions about client side buffer
management.

Firstly, this is how I'm allocating the backing memory for client side
buffer pools.  This is C# p-invoking to libc, and basically it's using
mkstemp() to get a temp file, ftruncate() to set its length, mmap() to map
it and then unlink() once mapped so temp files aren't left behind.  Any
issues with this approach?

            // Get temp file
            var sb = new
StringBuilder(System.IO.Path.Join(System.IO.Path.GetTempPath(),
"mmXXXXXX"));
            int fd = mkstemp(sb);
            ftruncate(fd, (ulong)capacity);

            // Map it
            var addr = mmap(IntPtr.Zero, (ulong)capacity, Prot.Read |
Prot.Write, Map.Shared, fd, 0);

            // Unlink it (so temp files not left behind)
            unlink(sb.ToString());

Secondly I'm wondering about practical strategies for managing client side
buffers.  The toolkit in question basically needs arbitrarily sized buffers
to render whatever size the window happens to be.  Seems like to use a
buffer pool for this would require some sort of heap manager to manage
what's in each pool.  I'm wondering if there's any recommendations or best
practices for how to deal with this.  eg: create one big pool and
explicitly manage what's in there as a heap, use lots of little pools with
one buffer in each, a combination of both, something else?

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?

Any advice appreciated...

Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200619/10cbbf64/attachment.htm>