<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<blockquote
cite="mid:CAAMvbhHEXV13UF1H8xsb3mgZ-qtQP6ZF+VQW5FtZzC_Ks9EsBg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Plus of course the same for the next buffer, so you know
e.g. how long<br>
a buffer was on screen etc.<br>
<br>
How does that sound?<br>
<br>
</blockquote>
<div>So, the information you propose, with timestamps, gives
us timestamps from events in the past.<br>
</div>
<div>Is there any way to deterministically ensure that a
particular frame is displayed at a particular scanout that
we would decide on in advance.<br>
</div>
<div>The problem is, if I timestamp a frame for time X and
the scan out actually happens as time X - 1 microsecond, I
really wanted not to miss that scanout.<br>
</div>
<div>It would be easier to be able to specify a particular
scanout.<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
Hi James, I understand your question, but pinopointing a particular
scanout makes less sense, as Pekka said, in the case where monitor
refresh rate can change without notice.<br>
I guess in that case, you'd probably miss your "expected" scanout
and present the buffer on the next vsync, but remember, you can't
know in advance when that scanout is going to happen.<br>
<br>
So just to summarize what we've got so far : <br>
<br>
- pre-submission timing (queueing buffers with expected
presentation times)<br>
- presentation callbacks (that's currently done by another team
at Collabora)<br>
- Output refresh rate change/adaptation notification back to
clients (we'll be working on that soon)<br>
<br>
and, as Pekka said, I'm kinda in favor of keeping "higher-level
info", like latency predictors for any higher-lever library API on
top of what we're doing now.<br>
What do you think ?<br>
<br>
<blockquote
cite="mid:CAAMvbhHEXV13UF1H8xsb3mgZ-qtQP6ZF+VQW5FtZzC_Ks9EsBg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
</div>
> So, I would propose the following.<br>
> 1) sequence number the frames at the display rate.<br>
> 2) provide an api for the application to predict the time
of each frame<br>
> number in the sequence. I.e The next 5 frames will
display at time<br>
> X1,X2,X3,X4,X5. Also provide a way to determine the
"frame submited to<br>
> frame displayed" latency. So the user application knows
how many frames in<br>
> advance it needs to do the submit.<br>
> 3) provide an api for the application to ensure that a
frame it submits<br>
> will get displayed at display rate sequence number X.<br>
> 4) If frame X has already past, only display it if there
are now newer<br>
> frames in the quene, otherwise drop it.</div>
</div>
</blockquote>
<br>
About that point #4 here, I've already started to work on the
implementation bits, and I was thinking about doing it like this :<br>
<br>
See, at time T=100, for example, if there's this in the queue : <br>
<br>
buffer1,T=75<br>
buffer2,T=99<br>
buffer3,T=110<br>
<br>
The compositor will drop buffer1 and present buffer2 right away
since buffer2 it's the most recent "past" buffers... <br>
<br>
And looking at your suggestion #4, if we're having this at time
T=112 : <br>
<br>
buffer3,T=110<br>
<br>
I don't see why we should drop buffer3 instead of displaying it (we
have no newer frames in the queue... but we definitely want to
display something, right ?)<br>
Any clarifications here could be very enlightning..<br>
<br>
Cheers :)<br>
</body>
</html>