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

Rémi Denis-Courmont remi at remlab.net
Fri Feb 19 15:06:22 UTC 2021

Le perjantaina 19. helmikuuta 2021, 15.12.49 EET Steve Lhomme a écrit :
> In an ideal world we would never wait between prepare and display, they
> would have predictable time and we could estimate exactly when we must
> do the prepare to be on-time for the display.

That's not ideal either. prepare() should rather be called at the earliest 
option, which is to say whence the picture has been filtered and converted. 
Estimations should only be used for display() if at all.

This is really a design flaw in the the interface exposed by the "vout display" 
capability. For a start, it should be possible not to display a picture that 
has been prepared. Eventually it should also be possible to prepare multiple 
pictures ahead. And ultimately, it should maybe be possible to display the 
same picture multiple times, though that last point is much less useful now 
that compositing is pervasive.

We already talked about that problem at the last vout workshop two years ago.

> That would also leave all that time to the vout control loop to process
> more mouse events that might occur before we start the displaying.

Unfortunately, it is not that easy. Once the display lock is released, the 
display might reset (especially the dumb ones like X11 and GDI), and 
invalidate the prepared picture. With the current interface, we cannot unlock 
the display between prepare() and display().

Without question, we should allow it. It's not just mouse events, but all 
interactions with the windowing system. In particular, we should forcefully 
redraw the last picture immediately  whenever the display "damaged" (in the 
windowing system sense).

But again, the current vout display capability has no such provisions.

Rémi Denis-Courmont

More information about the vlc-devel mailing list