[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
http://www.remlab.net/
More information about the vlc-devel
mailing list