On Wed, Feb 5, 2014 at 1:32 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Thu, 30 Jan 2014 17:35:17 +0200 > Pekka Paalanen <ppaala...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel