ext-image-capture-copy-v1 needs frame submission deadline event

If the compositor is rendering at 60 fps, but the client wants 30 fps, and the client just blindly captures at a 30 Hz interval, there will be aliasing effects and the client's frame pacing will be off. However, if the client can predict when the next refresh time, it can carefully time its requests to happen right before refresh to avoid this.

Maybe this "figure" clarifies the problem for some:

Server: |  |  |  |  |
Client:    |     |

The lines can get nudged either direction, which would introduce hickups in the stream.

I thought that we had already solved this, but it appears that I made some premature assumptions. Currently, a client that is actively throttling capture has no good way of learning the compositor's refresh rate, so it properly schedule its frame submissions.

There are at least 2 approaches available to solve this:

• Adding an event or an argument to an existing event that tells the client the projected next refresh time.
• Telling the client the refresh rate of the image source.

I like the first one better because it's more in line with how things are done elsewhere in both DRM and Wayland. It should also play nice with VRR.

In any case, I think that this needs to be added before releasing the protocol.