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 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