Skip to content

Draft: alternative present-timing protocol

Sebastian Wick requested to merge swick/wayland-protocols:present-timing-mr into main

This is another attempt at making presentations work well. The previous one by @afrantzis sits at !45 which is modeled after the WIP VK_EXT_present_timing Vulkan extension. The extension in its current form however results in stutter and high latency for cases where the buffer readiness deadline is earlier than the presentation (IOW in composited cases).

This protocol explicitly communicates the refresh cycle including the buffer readiness deadline, the presentation time and the time the presentation becomes visible.

It also takes a lesson from the surface suspension protocol !99 (closed) and explicitly communicates the lack of a refresh cycle.

The ideal and optional presentation times were removed because they are redundant with the refresh cycle known.

It allows presentation hints to be set with the first user being a tearing hint to let applications opt into tearing content updates (effectively pulling in !65 (merged)).

It makes the presentation-time protocol redundant. Instead of splitting feedback between the two protocol I've chosen to pull in all the information available from presentation-time.

VRR mode is accounted for. There is two cases, the first one is when the VRR mode is controlled by another entity and the surface just has to adapt to the variable refresh cycle which works without any VRR specific information. The second case is when the surface is controlling the VRR by setting the target present time and the refresh becomes a range which again is explicitly communicated.

There is a few issues with the protocol that I know of right now:

  • the refresh cycle information is sent continuously which might fill up the the socket queue pretty fast (thanks @daenzer)
  • there actually is two deadlines: the commit deadline and the buffer readiness deadline. it's unclear to me if it makes sense to communicate both (thanks @daenzer)
  • displays without a refresh cycle are not handled at all
  • it's not clear to me if controlling VRR should be opt-in like tearing or if applications will always handle it well
  • we might want to make some guarantees regarding buffer releases and swapchain size because this will impact timing as well

All feedback welcome, especially about the refresh cycle idea.

Merge request reports