[RFC v2] Wayland presentation extension (video protocol)
axel.davy at ens.fr
Sat Feb 8 13:59:25 PST 2014
On 08/02/2014, Jason Ekstrand wrote :
> For each surface with queued content updates and matching main
> output, the compositor picks the update with the highest
> timestamp no later than a half frame period after the predicted
> presentation time. The intent is to pick the content update
> whose target timestamp as rounded to the output refresh period
> granularity matches the same display update as the compositor is
> targeting, while not displaying any content update more than a
> 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.
If you target t, and P0 and P1 are possible pageflips time,
if P0<t<(1/2)P0+(1/2)P1 then you take the pageflip at P0
if (1/2)P0+(1/2)P1<t<P1 then you take the pageflip at P1
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
> half frame period too early. If all the updates in the queue are
> already late, the highest timestamp update is taken regardless
> of how late it is. Once an update in a queue has been chosen,
> all remaining updates with an earlier timestamp in the queue are
> Ok, I think what you are saying works. Again, it's difficult to parse
> but these things always are.
> 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.
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.
> Hope that helps,
> --Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel