[RFC v2] Wayland presentation extension (video protocol)

[Pekka Paalanen]

On Thu, 30 Jan 2014 17:35:17 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> Hi,
> 
> it's time for a take two on the Wayland presentation extension.
> 
> 
> 		1. Introduction
> 
> The v1 proposal is here:
> http://lists.freedesktop.org/archives/wayland-devel/2013-October/011496.html
> 
> In v2 the basic idea is the same: you can queue frames with a
> target presentation time, and you can get accurate presentation
> feedback. All the details are new, though. The re-design started
> from the wish to handle resizing better, preferably without
> clearing the buffer queue.
...
>   <interface name="presentation" version="1">
>     <request name="destroy" type="destructor">
> 
>     <request name="feedback">
>     <request name="queue">
>     <request name="discard_queue">
> 
>     <event name="clock_id">
> 
>   </interface>
> 
>   <interface name="presentation_feedback" version="1">
>     <request name="destroy" type="destructor">
> 
>     <event name="sync_output">
>     <event name="presented">
>     <event name="discarded">
>   </interface>

Hi,

another random thought; should we support queueing frames (buffers) in
reverse chronological order?

It's not really possible with the scheduling algorithm I wrote down in
the spec. There is no timestamp associated with the currently showing
content, which means that if you queue a frame with a target timestamp
in the past, it will replace the current content, even if the current
content was originally queued with a later target timestamp.

I wonder if we could define, that the current content effectively has
the timestamp of when it was presented, and all queued updates with
an earlier target timestamp will be discarded.

That should work, right?

Now, is there a corner case... output update has been submitted to
hardware but has not been presented yet, which means the content in
flight has no timestamp determined yet... but we won't update the
output again before the update in flight has completed, which gives the
presented timestamp for the was-in-flight current content.

If we do need the timestamp for content in flight, we could use the
target timestamp it had when queued, or the timestamp the compositor is
targeting. Since clients have a choice between queued and immediate
updates, I guess using the compositor's target timestamp would be
better defined.

Opinions?

I think I should fix it like that.

Isn't queueing (writing into the audio scanout buffer) audio samples in
reverse chronological order the proper method to update audio content
on the fly with minimal umm... latency? Wonder if some video-like
playback would benefit from a similar algorithm, which minimizes
latency(?) or the difference to wall time at the cost of possibly
skipping older new updates. Errm, to avoid shifting the content
on the time axis. Or something.


Thanks,
pq