RDP holds buffers too long

https://gist.github.com/d3x0r/c86197d9567f604e35e407482f7c4eaa (can be downloaded as a zip) self contained example.

There is a 'mk.sh' which can be used to compile the sources.

vidlib.wayland.c includes local.h xdg-shell-client-protocol.h and xdg-shell-protocol.c are just what my last build process built; they should be built appropriately for your version.

When this program is run with a native hardware backend, buffers are released more expediently. https://gist.github.com/d3x0r/c86197d9567f604e35e407482f7c4eaa#file-test-native-success-log-L145 this is released before 'Frame 2' which is 0 allocated a frame, and drew, and committed, 1 allocated a frame and drew and committed, and then 0 is available before 2, which is just a double buffering.

When this program is run using RDP (I'm specifically using MSTSC on windows 10 to connect to a WSL2 which is running a Arch system on the WSL2 kernel, Weston version 10.0.0, running on localhost, but to a WSL virtual adapter at some 172.17 address) I have to maintain up to 5 backing - and I don't see a benefit for 'pentuple' buffering. In this specific operation order the buffer is released before the 3rd frame, which means I only technically need 3 frames; but if the first buffer is committed without damage, then it's not released until before the 4th frame. https://gist.github.com/d3x0r/c86197d9567f604e35e407482f7c4eaa#file-test-log-L138

My issue is - that I need more than 2 backing buffers for any backend :) I contend that RDP could release the buffers more readily; and that in certain sequences it can be even worse.

During the startup of this there are several commit() operations, but then, surfaces and buffers aren't the only things that need to be committed; and when connecting the shell, I do a commit; and maybe there's a order of operations because I create a surface with a buffer before attaching it to the shell; and the shell interface is created after the first surface.

But really the first commit for that surface after the shell shouldn't even be damaged, it's just a new buffer, and the application would have drawn the entire buffer anyway; (in the test program there's a skip commit if frame 0, which forces a damage to happen, but without that, RDP driver holds on to one more frame before release... )

And then my handy logic for tracking the damaged surface updates within the double buffering you're already making me use, no longer work to just copy the damaged areas forward for one frame when I have to use 5.... and I've noticed this makes RDP applications generally more 'flickery'.