[RFC v2] Wayland presentation extension (video protocol)
axel.davy at ens.fr
Sat Feb 8 14:14:40 PST 2014
On 08/02/2014, Axel Davy wrote :
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel