Best practices for client side buffer management

[Brad Robinson]

Hi Carsten,


> i assume GetTempPath() will be looking at /tmp ... and /tmp may not be a
> ramdisk. it may be a real disk... in which case your buffers may be getting
> written to an actual disk. don't use /tmp.
>

That's kind of what was in the back of my head when I decided to post this,
but being new to Linux dev thought it might have been a silly question and
wasn't sure how to express it.  Going to switch to memfd_create for now.


> resizes of windows are less common (in general) than rendering to them.
> here
> i'd go for a scheme of N buffers in a ring per window. so you have buffers
> A,
> B, C and you first render to A then display it, then next frame B, then C,
> then
> A, then B, then C. You could get away without C. as the buffers retain
> their
> state you can take advantage of this and only partially render part of a
> buffer for updates "since 1 or 2 frames ago" (depending if you do double or
> triple buffering). as its predictable ABCABCABC you can just keep a
> "Sliding
> window of the update regions of the past N frames" and merge those into the
> "current amount to update" but always store per-frame update rectangle
> regions
> before this merge-at-render-time. 3 buffers allows you to be rendering a
> 3rd
> buffer while 1 buffer is queued to be displayed and one is still being
> displayed. if you find you need a 4th buffer, perhaps just overdraw the
> 3rd on
> you just did and "update it" ... or just block or don't update yet as you
> are
> getting too far ahead of the compositor.
>
> > 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?
>
> no. never do that. always have more than 1 and update a buffer that is not
> being displayed or queued to be displayed. the above sliding window allows
> your
> partial rendering to work as you can depend on previous content still being
> there where you left it from N frames ago.
>
>
OK thanks - that's pointing me in the right direction.  I have questions
about all this, but I don't want to waste your time until I've had time to
dig into it myself first.

(I'm a bit slow with all this because it's an evening side project and I'm
doing it in C# and trying to get the protocol bindings and libc pinvoke
functions all wired up at the same time as figuring out how it all works).

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