[RFC v2] Wayland presentation extension (video protocol)

[Jason Ekstrand]

On Wed, Feb 5, 2014 at 1:32 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> 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 agree.  The current frame (or frame for the currently pending flip)
should be treated as if it has a timestamp of its expected next
presentation time.  I'm still not completely understanding the algorithm
for presenting stuff correctly, but it should be possible for the client to
sneak a frame in for the next present.

I need some time at my chalkboard to try and get my head wrapped around all
this.  Maybe it would be good if you made a couple of little timeline
pictures to go with it?

--Jason Ekstrand


> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140208/34715c98/attachment-0001.html>