<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 5, 2014 at 1:32 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, 30 Jan 2014 17:35:17 +0200<br>
Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>
<br>
</div><div class="">> Hi,<br>
><br>
> it's time for a take two on the Wayland presentation extension.<br>
><br>
><br>
>               1. Introduction<br>
><br>
> The v1 proposal is here:<br>
> <a href="http://lists.freedesktop.org/archives/wayland-devel/2013-October/011496.html" target="_blank">http://lists.freedesktop.org/archives/wayland-devel/2013-October/011496.html</a><br>
><br>
> In v2 the basic idea is the same: you can queue frames with a<br>
> target presentation time, and you can get accurate presentation<br>
> feedback. All the details are new, though. The re-design started<br>
> from the wish to handle resizing better, preferably without<br>
> clearing the buffer queue.<br>
</div>...<br>
<div class="">>   <interface name="presentation" version="1"><br>
</div><div class="">>     <request name="destroy" type="destructor"><br>
><br>
</div>>     <request name="feedback"><br>
>     <request name="queue"><br>
>     <request name="discard_queue"><br>
><br>
>     <event name="clock_id"><br>
<div class="">><br>
>   </interface><br>
><br>
>   <interface name="presentation_feedback" version="1"><br>
</div><div class="">>     <request name="destroy" type="destructor"><br>
><br>
</div>>     <event name="sync_output"><br>
>     <event name="presented"><br>
>     <event name="discarded"><br>
>   </interface><br>
<br>
Hi,<br>
<br>
another random thought; should we support queueing frames (buffers) in<br>
reverse chronological order?<br>
<br>
It's not really possible with the scheduling algorithm I wrote down in<br>
the spec. There is no timestamp associated with the currently showing<br>
content, which means that if you queue a frame with a target timestamp<br>
in the past, it will replace the current content, even if the current<br>
content was originally queued with a later target timestamp.<br>
<br>
I wonder if we could define, that the current content effectively has<br>
the timestamp of when it was presented, and all queued updates with<br>
an earlier target timestamp will be discarded.<br>
<br>
That should work, right?<br>
<br>
Now, is there a corner case... output update has been submitted to<br>
hardware but has not been presented yet, which means the content in<br>
flight has no timestamp determined yet... but we won't update the<br>
output again before the update in flight has completed, which gives the<br>
presented timestamp for the was-in-flight current content.<br>
<br>
If we do need the timestamp for content in flight, we could use the<br>
target timestamp it had when queued, or the timestamp the compositor is<br>
targeting. Since clients have a choice between queued and immediate<br>
updates, I guess using the compositor's target timestamp would be<br>
better defined.<br>
<br>
Opinions?<br></blockquote><div><br></div><div>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.<br>
<br>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?<br><br></div><div>--Jason Ekstrand<br></div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think I should fix it like that.<br>
<br>
Isn't queueing (writing into the audio scanout buffer) audio samples in<br>
reverse chronological order the proper method to update audio content<br>
on the fly with minimal umm... latency? Wonder if some video-like<br>
playback would benefit from a similar algorithm, which minimizes<br>
latency(?) or the difference to wall time at the cost of possibly<br>
skipping older new updates. Errm, to avoid shifting the content<br>
on the time axis. Or something.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Thanks,<br>
pq<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div></div>