D3D fullscreen not working upon re-entering it a second time about mpc-hc HOT 44 CLOSED

I submitted the same issue a while ago:

D3D Fullscreen Exclusive playback issue #27

There does not appear to be any way to resolve it as far as I know.

from mpc-hc.

I have confirmed that the problem started after the migration to the Windows 8.1 SDK. Microsoft has integrated the DirectX SDK into the Windows SDK. They also changed something that broke it.

It is probably fixable. But I don't use D3D myself so it is very low priority. Other people should help to fix issues like this one.

from mpc-hc.

I didn't write the rendering code, so I am not familiar with it. If you know how to fix it, then please make a patch or give more details.

from mpc-hc.

This problem also happens with software decoding. It is not related to DXVA. Same code also worked with older DirectX SDK.

from mpc-hc.

@clsid2 @ValZapod

New test build: https://mega.nz/#!1EoG2I7L!b0mb60rznghTQaYlPU_z7HlTpiJ4wHKOws7L6W6LvgE

I think this one actually addresses the real issue, if it works.

from mpc-hc.

Works good!

The exclusive mode dark seekbar channel color is still wrong. But that is unrelated to this issue.

from mpc-hc.

Just a quick FYI: Tested release 1.9.0 with the "D3D exclusive not working anymore when transitioning to fullscreen a second time" fix included, but it does not solve the issue I described in my initial bug report: D3D Fullscreen Exclusive playback issue. Enabling Windows 8 Compatibility mode does fix the issue using release 1.9.0, but MPC-HC 1.7.13 still works fine without enabling any compatibility mode at all...

I retract my previous comment (above) regarding the "D3D exclusive not working anymore [...]" issue not being solved in release 1.9.0, because it DOES WORK!

The first few times I tested the new release the issue was still present, but I did a complete cleanup of all traces from previous MPC-HC installations and put the new release in a freshly created folder, and this resulted in the issue being fixed. I'll test some more to make sure it is as stable as 1.7.13, but so far it is looking good!

Thank you all for taking the time to solve this annoying and not easily reproducible issue.

from mpc-hc.

@clsid2

To document what I found to fix this, PresentEx was returning value 0x08760878. This is not a very well documented value, because if you try to find it, it is not in a header file by that name (you have to know how to decipher d3d return codes, which means it is = MAKE_D3DSTATUS(0x0878)).

Further, it is not mentioned as a possible return code for PresentEx, but only as a return code CheckDeviceState. And the documentation states you should only call CheckDeviceState if you receive a fail code;

We recommend not to call CheckDeviceState every frame. Instead, call CheckDeviceState only if the IDirect3DDevice9Ex::PresentEx method returns a failure code.

Yet, a fail code is defined as a negative, which this value is not. So the system continues on, presenting, but the code has a meaning. Once you find what code it is, it starts to make sense:

https://docs.microsoft.com/en-us/windows/win32/direct3d9/device-state-return-codes
S_PRESENT_OCCLUDED

The presentation area is occluded. Occlusion means that the presentation window is minimized or another device entered the fullscreen mode on the same monitor as the presentation window and the presentation window is completely on that monitor. Occlusion will not occur if the client area is covered by another Window.
Occluded applications can continue rendering and all calls will succeed, but the occluded presentation window will not be updated. Preferably the application should stop rendering to the presentation window using the device and keep calling CheckDeviceState until S_OK or S_PRESENT_MODE_CHANGED returns.

Which is exactly what we were seeing. The system continued, MPC-HC did not report any issues (perhaps it should check for S_OK rather than a non-failure code), but nothing showed up on the screen.

The meaning of the code led me to believe the original fullscreen lock was never released after the first device creation, leading the subsequent creation to be unable to take the lock and thus was "occluded" by the original, non-existent device window.

The instructions for using d3d devices seem to suggest that the application should keep using ResetEx() until it fails, and then release the pointer to the device, and create a new one. But the MPC code (when doing a "reset device" call) would only reset the d3d device if the same window were reused (note this would never happen during a fullscreen switch, as the fullscreen window and the windowed view are different objects)--otherwise it would discard the pointers, and recreate new ones. This seemingly worked until the 8.1 SDK. Perhaps the 8.1 SDK started honoring S_PRESENT_OCCLUDED, or perhaps it stopped releasing the lock when the pointer was released.

All my patch does is include the state of the fullscreen changing in the list of conditions for resetting, rather than recreating the device. This means there won't be another device holding the fullscreen lock, since it is the same device.

Probably, the code could be rewritten to always reset, and recreate only when resetting fails. But I wanted to keep the patch minimal.

from mpc-hc.

I could not even repro this issue in Win 10 using 1.8.6. At first I thought I may have fixed it when I fixed this:

#141

But I can't even make it fail on older builds. Maybe Win10 fixed it (I am on 1909 or 18363.535).

from mpc-hc.

I can still reproduce on Windows 7.

When entering fullscreen the second time, I still see the windowed player and the desktop behind that, but the mouse clicks are captured as if things are rendered in full screen. For example I can click on the bottom area of the screen (where seekbar would be in fullscreen) to seek to a different position, and I actually see the seekbar move in the windowed player.

Also happens with your testbuild. So VS2019 doesn't solve it.

from mpc-hc.

I have a PC with both Win10 and Win7 so I should be able to reliably compare that at some point. Debug layers may also give some insights on that.

from mpc-hc.

Good to know. The original bug was on Win10 (at least in this thread). So I wonder why I can't repro it. Maybe video card manufacturer? I have AMD.

from mpc-hc.

Good to know. The original bug was on Win10 (at least in this thread). So I wonder why I can't repro it. Maybe video card manufacturer? I have AMD.

Could be vendor yes, could also be Win10 version, could be fullscreen optimizations, could be monitor setup (single vs multiple monitors).

from mpc-hc.

I got it now. The other thread indicates you have to disable the "full screen optimizations" in win10:

from mpc-hc.

Then that implies MPC-HC is having trouble getting back to exclusive fullscreen - since AFAIK fullscreen optimizations turn exclusive fullscreen into borderless with a flip mode presentation.

from mpc-hc.

I can also reproduce with W10 1909 in VirtualBox. Works ok with Win 7/8 compatibility mode. Disable fullscreen optimizations will make it fail already on the first transition to fullscreen.

from mpc-hc.

Same here, second time fails.

from mpc-hc.

@ValZapod @CookiePLMonster

Try this build: https://mega.nz/#!dVo1Da7C!-EGS3XZttAjrF3ijKkHjieKsVfm0aFAIEk9k-u61GTI

from mpc-hc.

@adipose Yes, this one is indeed

Works ok with Win 7/8 compatibility mode.

But fullscreen optem. do not metter.

I couldn't understand this post.

from mpc-hc.

Still broken for me on Win7 and Win10 VM.

from mpc-hc.

Thanks for testing it. I can repro it again, but not on my dev machine. Strange...

from mpc-hc.

@ValZapod

Here's another test build for you to test.

https://mega.nz/#!NQpxiAZY!8Oo6eh-0UX5qIOEjLO7CwCgwuRBj7V3LcmBDJb4fcUM

from mpc-hc.

@ValZapod
Test with different filenames. K-Lite uses a non-standard filename on systems with Optimus (Intel + NVIDIA) to bypass the NVIDIA application profile for MPC which by default uses the integrated Intel GPU.
Windows compatibility settings are also specific the the location of the .exe so check that you aren't using different settings.

from mpc-hc.

But you do have Intel CPU with integrated GPU? Try with different filename anyway as there is no functional difference in that other build.

@adipose, that last testbuild still has the issue.

from mpc-hc.

Are you testing with Sync Renderer?

from mpc-hc.

Here's what I've been testing with, and which now works in full screen, but didn't before. Send your screenshots as well so I can compare, if they are different, please!

from mpc-hc.

64 bit test build (both versions had the same behavior, for me). 32 bit is more universal, builds faster, and is a smaller file, is why I usually only provide 32 bit test builds.

https://mega.nz/#!RVw2maYJ!Om5ITVzxSs6imtEwBV4XxlaKML8AAvod4iM4A6rSrZQ

from mpc-hc.

I just tested windows 7 64 bit and it doesn't work (it fails the first try of full screen). But on Win10 1909 it is working, even on subsequent tries.

from mpc-hc.

It seems to me we have two separate issues:

1. Win7 cannot enter fullscreen.
2. Win10 fails on second attempt at fullscreen (whitesnakeftw).

@whitesnakeftw, can you test the latest test build for your issue?

Is anyone getting the 2nd issue above with the test build? I can no longer repro it after my patch.

from mpc-hc.

Apologies, I may have inadvertently snuck a fix for EVR into the 64-bit build. Here are new builds for 32 & 64, with fix for both Sync and EVR.

https://mega.nz/#!Rc40nABT!BQfKiFhTx7k5cJsSOix2dUms1YCLIdzELr-Mf0rdbsg
https://mega.nz/#!RVw2maYJ!Om5ITVzxSs6imtEwBV4XxlaKML8AAvod4iM4A6rSrZQ

from mpc-hc.

Still doesn't work for me on Win7 (NVIDIA) and Win10 VM. Also tried on a laptop with 1909 and Intel GPU and there 1.8.8.40 already works fine.

When entering and exiting fullscreen the first time (which works) I see the screen flash/refresh (mode switch). The second time it doesn't do anything and fullscreen isn't working.

from mpc-hc.

I have the required DirectX files. They are also included in MPC-HC installer.

from mpc-hc.

@clsid2 I cannot get it working in Windows 7 VM. But I wonder if it's a VMWare issue, rather than mpc-hc?

Also, in Win10 to see the issue on second load, you must check this box:

from mpc-hc.

@adipose No, in windows 10 VM there is no issue. But you need to install directx.

Windows 7/VMware, then?

from mpc-hc.

Point is, if windows 7 VM fails, what does it mean? Does Windows 7 bare metal work ok? If regression is just for Win7 VMWare, it seems acceptable to me.

from mpc-hc.

I use Win7 as main OS. The Win10 VM is in VirtualBox. The graphics functionality of VirtualBox driver depends a bit on the host OS, so maybe that is why it is also failing in the VM for me.

D3D exclusive is not really important. It has more downsides than benefits. I doubt many people use it.

from mpc-hc.

Try k-lite mpc. If it fails in win 7 then f*** it. If not we need to ask them what they did. I suppose they have some (many) out of tree patches because well, the binaries are very different and I do not think it is because you use VS 2019 and they use VS 2017...

It fails.

I'm using VMWare Workstation 15 on host OS Win10 1909.

I think the main bug here has been fixed.

from mpc-hc.

And if people still have issues with it, then the answer is simple: don't use exclusive mode. Even madVR has disabled it by default because it gave issues.

from mpc-hc.

@clsid2 @ValZapod

I may have found a better solution that works in windows 7 as well.

Test build:

The issue seems to be some sort of timing problem, where changing the window resets the device via a message posted to the main window. This happens before the final positioning of the fullscreen window (but the reset could in theory happen after). A theory might be that something in DX or Win7 or both has made that timing fail. I put a reset after the movewindow command, and it seems to solve Win10 and Win7's issues.

I don't know if this is the best solution, but I haven't noticed any regressions, and it leaves the render codes alone.

from mpc-hc.

Works on Win7 now. I see the double screen update only on the first transition. Perhaps the first reset can be removed?

Unrelated, but in dark theme the exclusive mode seekbar channel has same color as the background.

from mpc-hc.

@ValZapod @clsid2

Try this build. I could not observe the double reset, here.

from mpc-hc.

Yes, seems to work good now.

from mpc-hc.

After more testing, it sometimes works and sometimes it does not.

from mpc-hc.

Awesome. Fix for the colors added to the PR, too.

That seekbar is ugly--probably could be replaced with the modern one with a little effort. But for now I'll wait for someone to complain.

from mpc-hc.