[RFC v2] Wayland presentation extension (video protocol)

[Axel Davy]

On 08/02/2014, Axel Davy wrote :
> 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.
>
Well it isn't really the reason why this is choosen (else one might say 
it would be better to maximize with (t-T/2,t+T/2) with T the time 
between two pageflips.).
The reason is more that you want to minimize the time at when the 
pageflip happens and t, so the real presentation time and t doesn't 
differ more than T/2.

Axel Davy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140208/8118c5fa/attachment.html>