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

[Alexandre Janniaux]

Hi,

On Mon, Feb 22, 2021 at 01:05:08PM +0100, Steve Lhomme wrote:
> 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.

It's still much more than not having to wait at all.

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

It's easy to see that it's more time than previously since controls
are unresponsive. Dividing the time by two would still be too much
in most cases from this basis since it is not related to the time
it actually takes.


Regards,
--
Alexandre Janniaux
Videolabs