[vlc-devel] [PATCH v2] video_output: wait half the extra time we have without getting the display_lock

Steve Lhomme robux4 at ycbcr.xyz
Mon Feb 22 12:05:08 UTC 2021


On 2021-02-22 11:59, Rémi Denis-Courmont wrote:
> Le maanantaina 22. helmikuuta 2021, 9.47.25 EET Steve Lhomme a écrit :
>> Since f1bf7ce5b4480a3d38d54c7ae1d1564f0670d83f we start the rendering much
>> earlier than before, so we have more time to do things if necessary.
>>
>> The problem is that for almost all the duration of the call display_lock is
>> held. So it's blocking all other UI related events from being handled. Even
>> if we are going to spend most of the time waiting until we can do the
>> display.
>>
>> This patch waits a bit before locking the display_lock when we estimate we
>> will have so extra time before doing the display/swap.
> 
> We can't block the UI for that long. If you hold the lock for two long, you
> will first make the UI unresponsive, and then eventually kill the connection to
> the display server and end the whole process.

Yes, this is what I'm trying to solve.

> So eventually, we have to release the lock between prepare and display. Which
> means we have to change the interface whether you like it or not.

Not necessarily. You can make the time between the prepare and the 
display virtually 0. This is IMO a better (and more responsive) solution 
that doesn't change anything in the display modules. That's what the 
deadline and prepare duration estimate are supposed to do. Except on 
Windows it just doesn't seem to do what it's supposed to.

> Halving the wait time is not proper even as a work-around. We should not wait
> longer than we used to (which was arguably too long but grand father clause
> apply).

You can't tell this is more or less than before without knowing what the 
time was before. And it's not half of a frame duration but half of the 
"extra time left". It can vary a lot between frames, to the point there 
is 0 extra time, even though there's plenty of time to render the picture.

So it's not going to disturb the rendering time/precision much. But it 
seems sufficient to fix the UI lagness.


More information about the vlc-devel mailing list