commit-start-time protocol

Let's say that a frame is latched at time T and the compositor wants the client to perform a commit for the presentation following T. The compositor wants the client to calculate the content update as late as possible for the lowest latency.

For this, the compositor must know how long it takes

1. the client to perform all required wayland requests
2. the commit to become applicable.

If this duration is delta, then the compositor will want to notify the client that is should start working on that content update at time T - delta - epsilon.

Some compositors use frame requests for this. I have not checked this, but I assume they use the time when the last frame request was dispatched before the wl_surface.commit as the start time. This is use of frame requests is not backed by the protocol and there are desktop-style applications where this would lead to calculated frame times that are orders of magnitude longer than the actual frame time. Similarly, if the client uses mailbox presentation but uses frame requests to pace animations, frame requests will have nothing to do with frame times.

This could be solved by creating a new wl_surface extension with a single request wp_commit_start_time.start_time(time_ns: u64) which indicates when the client started working on the content update.

I don't know yet how this would be used in applications using a WSI. The WSI might set the start time to the time the swapchain image was acquired but some applications might manage swapchain images outside the WSI. It probably would not be worse than the current way using frame requests.