[vlc-devel] Display update/restart

[Rémi Denis-Courmont]

Le mardi 17 novembre 2020, 08:46:20 EET Steve Lhomme a écrit :
> On 2020-11-16 18:58, Rémi Denis-Courmont wrote:
> > Le lundi 16 novembre 2020, 18:01:29 EET Steve Lhomme a écrit :
> >> The issue is not the glitch. It's how long it's going to take to unload
> >> a display module and reload it, for a tiny change that would take almost
> >> no time to handle directly.
> > 
> > That's if you assume that only D3D and GL are used.
> 
> No. A format change would allow any display to reject/switch to the new
> format. It doesn't matter who implements it. GDI or VDPAU would reject
> it and we do the change the hard way.

I already explained in the previous thread why that won't work with the 
current probing scheme.

It's not even only about rejecting the second format. Even thoug a module with 
higher priority rejected the first format, it might accept the second format. 
Bottom line, you always have to reiterate the modue list at every format 
change.

Or then we need to switch to a model where all displays accept every formats, 
as I did for the audio outputs long ago. That also implies that checking the 
window type (Open) is separate from checking the format (Start), otherwise 
there will be duplicate format handling code and bugs (similar to display size 
change bugs we've had in the past).

> > If your display is slow to (un)load, you have a problem anyway, as it will
> > break buffering and piss users off as it is.
> 
> This is new to 4.0 and the push model. In 3.0 it didn't matter because
> the decoder would have to wait for the new display to get its buffers.
> So it could take however long it wanted.

The problem is not new in terms of pissing off the user. And I have the awfully 
slow NVIDIA-GL, so I know firsthand what I'm talking about :( As for buffering, 
I think it depends on the scenario whether it was already a problem in 3.0 or 
not. It's not plain new, and it wouldn't be plainly fixed with format change.

-- 
Rémi Denis-Courmont