<div dir="ltr"><div dir="ltr">Hi Carsten,<div><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
i assume GetTempPath() will be looking at /tmp ... and /tmp may not be a<br>
ramdisk. it may be a real disk... in which case your buffers may be getting<br>
written to an actual disk. don't use /tmp.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
resizes of windows are less common (in general) than rendering to them. here<br>
i'd go for a scheme of N buffers in a ring per window. so you have buffers A,<br>
B, C and you first render to A then display it, then next frame B, then C, then<br>
A, then B, then C. You could get away without C. as the buffers retain their<br>
state you can take advantage of this and only partially render part of a<br>
buffer for updates "since 1 or 2 frames ago" (depending if you do double or<br>
triple buffering). as its predictable ABCABCABC you can just keep a "Sliding<br>
window of the update regions of the past N frames" and merge those into the<br>
"current amount to update" but always store per-frame update rectangle regions<br>
before this merge-at-render-time. 3 buffers allows you to be rendering a 3rd<br>
buffer while 1 buffer is queued to be displayed and one is still being<br>
displayed. if you find you need a 4th buffer, perhaps just overdraw the 3rd on<br>
you just did and "update it" ... or just block or don't update yet as you are<br>
getting too far ahead of the compositor.<br>
<br>
> Finally, the toolkit already maintains an off-screen buffer with the<br>
> window's current contents rendered into it.  I'll probably replace that<br>
> with a Wayland buffer, but wondering about partial updates.  eg: if the<br>
> client only needs to redraw a part of the window what's the correct process<br>
> to update just that part with Wayland.  Can I just update the existing<br>
> buffer and prompt Wayland to just redraw that part?<br>
<br>
no. never do that. always have more than 1 and update a buffer that is not<br>
being displayed or queued to be displayed. the above sliding window allows your<br>
partial rendering to work as you can depend on previous content still being<br>
there where you left it from N frames ago.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>(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).</div><div><br></div><div>Brad</div><div><br></div></div></div>