[vlc-devel] Display update/restart

[Steve Lhomme]

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.

> We have other displays that have limitations on input chroma and/or picture
> size. You cannot assume that a display will handle the change. Simple as that.

If you read my first email I said this very clearly:
"So we have to handle the restart/recreate no matter what."

> 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.

In push the decoder might push all it can and wait until a picture is 
released/used by the video output. I don't think there's a particular 
buffering issue. Once the display is opened the video output should drop 
whatever is too late. As explained elsewhere there is a buffer size 
issue if the decoder creates a new pool at every picture it outputs 
because of a tiny format change. Again that's a huge waste of resources 
when there's a small change.