Skip to content

Draft: staging: add refresh cycle protocol

Sebastian Wick requested to merge swick/wayland-protocols:refresh-cycle into main

Figuring out when to start producing new frames and when those frames become visible with the current framework is impossible:

The frame callback mechanism is not suitable because

  • can occur at arbitrary times in the refresh cycle
  • can be moved around in response to client timings to try to minimze latency
  • can not be send at all

The presentation time mechanism is not suitable because

  • it is only send in response to a commit and not for every refresh cycle
  • it is send some time after the latching event

Using the frame callback mechanism together with presentation time also doesn't work reliably. The variable nature of the frame callback might increase the number of refresh cycles to present arbitrarily. Any increase or decrease in the work a client does might result in missing the latching deadline and increase the number of refresh cycles to present. There is no indication this happened and no measurement can be taken to prevent it.

This protocol tries to solve those issues by explicitly communicating the refresh cycles, the latching event, fixed and variable refresh rates and the absence of refresh cycles.

It also allows improvements to the Vulkan WSI such as a proper implementation of VK_KHR_present_wait, partial implementation of VK_EXT_present_timing and suspending swapchains (!99 (closed)).

The throttle hint and the VRR parts are not thought out very well.

The implementation in compositors should be rather easy because all information should already exist in some form.

Merge request reports