I’m working on a CAD app that uses WPF 4.6.2 and Direct3D 11, they interop through a D3DImage. The app renders the 3D content very slow when the window is maximized on a 4K 3840x2160 display, I’m getting about 1 FPS. I thought “well, it’s too many pixels in the screen, that’s probably normal”.
However, if I resize the window so it’s no longer maximized but just a couple of pixels smaller than the maximized would be, 3D rendering works OK and I’m getting about 20 FPS. Same scene, same rendering settings, same everything, the only difference is fullscreen vs windowed.
My window uses custom chrome, i.e. <WindowChrome CornerRadius="0" GlassFrameThickness="0" UseAeroCaptionButtons="False" /> and custom title bar & system buttons. I’ve narrowed down the problem to that WindowChrome XAML thing.
I think the problem is native Win32 window is too large in this state, even larger than 4K, and needs to be clipped to the screen. Spy++ showed me the following rectangle for my maximized window: (-11,-11)-(3851,2111), 3862x2122 (Maximized)
Why does SystemCommands.MaximizeWindow() API do that to my window? Is there a way to make it respect my screen size and stop resizing my window larger than that?
Update: OK, as mentioned in comments, the maximized window size being larger than the screen is normal, and I confirm it’s still the case without custom chrome.
What is not normal however, is window client rectangle being larger than the screen.
In the error state that kills Direct3D performance, the client rectangle of that window is (-5,-6)-(3857,2166), 3862x2122.
In the good state (but with system provided chrome), the client rectangle is (11,45)-(3851,2111), 3840x2066.
I have not found a proper solution to the performance issue in WPF.
Instead, I implemented a workaround. Specifically, I added a Boolean preference that defaults to false. When enabled, this preference disables custom chrome and reverts to the OS-provided window title and system menu, which resolves the D3D11 rendering performance problem.
A combination of a 4K monitor and an older GPU is not very common, so the issue only affected a small percentage of our users. This workaround proved to be sufficient for our application.