[RFC v2] Wayland presentation extension (video protocol)

[Axel Davy]

Hi,


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

>           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
>           discarded.
>
>
> 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
>
Axel Davy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140208/64031ba6/attachment.html>