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
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel