ext_image_copy_capture_session_v1 cannot capture resizing toplevels

This goes back to something I mentioned in the protocol MR: The protocol requires the compositor to reject incorrectly sized buffers. This becomes problematic during toplevel resize operations. If the user resizes the toplevel above a certain speed, it becomes increasingly unlikely for clients to be able to capture any frames. This correlates with the display refresh rate: The lower the refresh rate, the slower the user has to resize for captures to work.

First consider my proprietary protocol used in my screencapture portal implementation:

proprietary

You can see that the the resize operation is captured smoothly. There is a small amount of jank: If the toplevel is smaller than buffer, the excess is filled with the desktop's background color. If the toplevel is larger, some parts of the bottom and right edges are clipped. You can see this most easily by looking at cursor position.

Now ext_image_copy_capture_session_v1:

original-copy

You can see that very few frames are captured successfully. This was recorded on a 60hz display. I tried various combinations of techniques:

• Debouncing resize events to reduce client re alocations.
• Destroying frames eagerly in the client or waiting for the failure event.

But they all lead to similar outcomes. There might be ways to improve this without protocol changes but I have not found them.

Lastly, ext_image_copy_capture_session_v1 but with the buffer-size-match requirement removed:

modified-copy

Here, I used the same behavior as in my proprietary protocol except that I fill excess space with black instead of the desktop's background color.

I believe that this is a huge improvement for most users. However, to make it even better, the compositor needs a way to tell the client about the actual size of the captured frame so that the client can crop or pad the buffer.