Bugzilla

Well, we'd have to know what to use the timing information they provide for. Generally, it's there to allow you to do: `next_present = cur_present + (cur_present - past_present)`, and then e.g. prepare the video frame that should be shown at the next present time to match an audio track.

Examples for ways we could use it:

1. Provide some mechanism to query next estimated presentation time if the frame deadline is met, based on recorded presentation times.
2. Extend the VsyncSource to keep track of presentation events, and set the vsync event time to the last recorded presentation time, but still fire on frame callbacks.
3. Run the VsyncSource off presentation events. The timing related to frame callbacks is compositor and configuration specific. On Weston, it would result in about half the render time available in the default configuration on a 60Hz monitor.

The last two would require the vsync consumers to keep track of the presentation times themselves to perform the calculation, and would replace the current bogus timestamp on Wayland.

It might be interesting to see what Chromium does here in their Ozone Wayland implementation. It is closer to the "FrameSource" model, but uses both frame callbacks and presentation feedback.

Well, we'd have to know what to use the timing information they provide for. Generally, it's there to allow you to do: `next_present = cur_present + (cur_present - past_present)`, and then e.g. prepare the video frame that should be shown at the next present time to match an audio track.

Examples for ways we could use it:

1. Provide some mechanism to query next estimated presentation time if the frame deadline is met, based on recorded presentation times.
2. Extend the VsyncSource to keep track of presentation events, and set the vsync event time to the last recorded presentation time, but still fire on frame callbacks.
3. Run the VsyncSource off presentation events. The timing related to frame callbacks is compositor and configuration specific. On Weston, it would result in about half the render time available in the default configuration on a 60Hz monitor.

The last two would require the vsync consumers to keep track of the presentation times themselves to perform the calculation (and would replace the current bogus timestamp on Wayland), and would do no good if the vsync event time isn't used for anything.

It might be interesting to see what Chromium does here in their Ozone Wayland implementation. It is closer to the "FrameSource" model, but uses both frame callbacks and presentation feedback.