<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi,<br>
<br>
<br>
On 08/02/2014, Jason Ekstrand wrote :<br>
</div>
<blockquote
cite="mid:CAOFGe95Y+UJfph3rkuH2CofWa+ExMdy4r=3F6b66dgqcOBPUQg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<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">
<br>
For each surface with queued content updates and
matching main<br>
output, the compositor picks the update with the
highest<br>
timestamp no later than a half frame period after
the predicted<br>
presentation time. The intent is to pick the content
update<br>
whose target timestamp as rounded to the output
refresh period<br>
granularity matches the same display update as the
compositor is<br>
targeting, while not displaying any content update
more than a<br>
</blockquote>
<div><br>
</div>
<div>I'm not really following 100% here. It's not your
fault, this is just a terribly awkward sort of thing to
try and put into English. It sounds to me like the
following: If P0 is the time of the next present and P1 is
the time of the one after that, you look for the largest
thing less than the average of P1 and P2. Is this
correct? Why go for the average? The client is going to
have to adjust anyway.<br>
</div>
</div>
</div>
</div>
</blockquote>
If you target t, and P0 and P1 are possible pageflips time,<br>
if P0<t<(1/2)P0+(1/2)P1 then you take the pageflip at P0<br>
if (1/2)P0+(1/2)P1<t<P1 then you take the pageflip at P1<br>
That way the length of the intersection of the interval (t,t+time
between two pageflips) and 'time interval at which it is displayed'
is maximized.<br>
<br>
<blockquote
cite="mid:CAOFGe95Y+UJfph3rkuH2CofWa+ExMdy4r=3F6b66dgqcOBPUQg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
half frame period too early. If all the updates in
the queue are<br>
already late, the highest timestamp update is taken
regardless<br>
of how late it is. Once an update in a queue has
been chosen,<br>
all remaining updates with an earlier timestamp in
the queue are<br>
discarded.<br>
</blockquote>
<div><br>
</div>
<div>Ok, I think what you are saying works. Again, it's
difficult to parse but these things always are.<br>
</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">My one latent concern is that I still
don't think we're entirely handling the case that QtQuick
wants. What they want is to do their rendering a few frames
in advance in case of CPU/GPU jitter. Technically, this
extension handles this by the client simply doing a good job
of guessing presentation times on a one-per-frame baseis.
However, it doesn't allow for any damage tracking. In the
case of QtQuick they want a linear queue of buffers where no
buffer ever gets skipped. In this case, you could do damage
tracking by allowing it to accumulate from one frame to
another and you get all of the damage-tracking advantages that
you had before. I'm not sure how much this matters, but it
might be worth thinking about it.<br>
<br>
</div>
</div>
</blockquote>
If they really want to work that way, why not doing this queue
client side? It doesn't need to be done in the compositor.<br>
<br>
<blockquote
cite="mid:CAOFGe95Y+UJfph3rkuH2CofWa+ExMdy4r=3F6b66dgqcOBPUQg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">Hope that helps,<br>
</div>
<div class="gmail_extra">--Jason Ekstrand<br>
</div>
</div>
<br>
</blockquote>
Axel Davy<br>
</body>
</html>