I will move all resolution dependent code out of video renderer to guilib. The setting "pause during change of refresh rate" will disappear because it is silly having player continue playback during this time. Instead VideoPlayer will hook into windowing to OnDeviceLost and OnDeviceReset events of the IDispResource interface. Windowing has to know when a switch starts and when it is completed.
Are we sure that the display is really ready to show content already when the OnDeviceReset is fired. Or might it be that the resolution and stuff like that is set but the display isn't showing pixels yet? Not sure if it is an HDMI standard when we get the OnDeviceReset callback.
Beside that sounds like a good idea
(2015-09-18, 10:57)Memphiz Wrote: [ -> ]Are we sure that the display is really ready to show content already when the OnDeviceReset is fired.
If those Events are used correctly, yes. I will rename them to OnDisplayLost/OnDisplayReset in order to reflect better what they are supposed to do. Applications also get events from the windowing system when they need to redraw.
Are you really sure of that?
My projector for example has a (very annoying) ~5s blackout when switching refresh rate. It's incredible that the designers of such expensive hardware consider that acceptable, but it's not uncommon from what I understand.
Even if it does signal that condition over HDMI, I'm doubtful that would survive every possible signal chain of switches, splitters, AVRs and video processors all the way back to Kodi.
Some type of adjustable delay needs to be present. OnDisplayLost/OnDisplayReset only tell when the display has been lost or gained in the OS, NOT when it is actually stable and usable. I have some HDTVs/Monitors that switch quick, some can take as long as 10 seconds to quit twitching and become stable yet the OS thinks everything is fine.
thats what i was after - i just didn't formulate it right
I rely on 8 seconds worth of pausing refresh rate. Without it, the automated 3D switching time it takes my Samsung panel to get in the correct mode will lose the commands and never end up in the correct mode. It is picky and it is slow.
(2015-09-19, 13:45)MrMC Wrote: [ -> ]Some type of adjustable delay needs to be present. OnDisplayLost/OnDisplayReset only tell when the display has been lost or gained in the OS, NOT when it is actually stable and usable. I have some HDTVs/Monitors that switch quick, some can take as long as 10 seconds to quit twitching and become stable yet the OS thinks everything is fine.
If the delay is bound to the monitor, we should move it there. Then users can configure different delays for different monitors/projectors. Windowing needs to delay the OnDisplayReset event depending on the monitor connected.
current status:
https://github.com/FernetMenta/xbmc/comm...f117ea1d49
VideoPlayer listens to OnLostDisplay/OnResetDisplay events and acts accordingly. Delay after changing refresh rate is moved to videoscreen. Windowing implementations can delay the reset event if desired.