Bug with multiple monitors - in mode duplicated displays

[ChroChro]

I was just playing with the GLWpfControl - testing for multiple monitors. Works well with extended monitors - one can drag from display to display. Switching monitor off is no problem.
It crashes, however, in the following scenario (my preferred configuration): Normally I work at FullHD - seeing on both the notebook monitor and external monitor the same stuff (displays are duplicated). When I close the lid of computer - the main monitor shows 4K. It was working fine with GLControl but not with GLWpfControl - yet.
The GLWpfControl.Example in such a case (no matter whether we close the lid or open it) freezes on some lock in PreRender function.
My application (when lid is closed or opened) crashes instead - on some Interop: Message=UCEERR_RENDERTHREADFAILURE (0x88980406).
I guess should be easy to reproduce for anyone.
Seems when the context is given - it is not able to change automatically to match the other monitor settings? But I only speculate here...

[marcotod1410]

I'm fully able to reproduce this issue.
In my case, the example raises UCEERR_RENDERTHREADFAILURE error when the monitors are in duplicated mode and I close the lid of my laptop.

[varon]

Thanks guys, Hopefully #30 will address this.

[marcotod1410]

I'm currently digging into it. It seems a D3D9 related problem, as I'm able to reproduce the same issue in a separate project that does not have the GLWpfControl (it has only D3D9 and WPF, no OpenGL context).

Basically when the lid is closed, the D3D9 object and device go in some "faulted" state that I'm not able to detect atm. Then WPF is trying to render the surface created previously but it fails with the error previously mentioned.

The PR you mentioned has some infrastructure to recover from a failed D3D9 context, so as soon as I'm finding the root cause of the issue, I'll integrate the patch in that PR.

[marcotod1410]

Update:
I've managed to find the root cause. Basically when the lid is closed, for some reason the D3D9 context is not able to find the adapter related to the monitor that is showing the control (GetAdapterMonitor() call returns null, even with a new valid monitor handle).

The existent D3D9 device looks good (strangely). In fact, CheckDeviceState() returns S_PRESENT_MODE_CHANGED, that is a perfectly valid state. However, after the closing of the lid, using any resource related to that device will lead to a crash. As stated in D3D docs, when the state is S_PRESENT_MODE_CHANGED, I should Reset() the device. Calling it was basically a no-op, as the control will keep crashing even if new surfaces were created after the reset.

The solution was detecting this situation just before the render. If so, it clears everything (D3D9 context, devices and framebuffers), while aborting the current frame. The rendering will resume when there will be a new context with a new valid associated monitor handle.

I'm aware that this is not a perfect solution, but this is my best guess. I've had no luck in looking to the net.

[NogginBops]

Resolving this issue will have to be moved to 4.3.0

[NogginBops]

This is likely related to #30. Will look at this when I look at #30 for 4.3.1.

[NogginBops]

#30 is moved to 4.3.3 so this will likely be fixed in 4.3.3.

[NogginBops]

Didn't get to the multi-monitor/multi-gpu issues this version. But hopefully next version we can fix this.