[d3d9] Send WM_ACTIVATEAPP messsage on WM_SIZE. #2383
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The issue is Rocksmith 2014 Edition (221680) displays white screen on starup (can be worked around by tweaking screen size in app's ini file).
After creating fullscreen d3d9 device and starting some drawing the app calls MoveWindow() with a window size slightly bigger than the monitor size display mode it selected. It gets that size from AdjustWindowRect() called with window's style (including caption etc) although the exact size doesn't matter. I don't have a clue what the app is trying to achieve this way but as far as my debugging and unit testing on Windows goes this doesn't affect anything on Windows and thus probably a good thing to do.
We have two issues here. First, fshack currently doesn't scale windows which have non-fullscreen window sizes (and the window technically stops being fullscreen after such an adjustment). That is probably good thing to solve in the fshack (and the issue as described - empty window - is not there with. e. g., gamescope), but in this paricular case this is not the core problem and the window size / scaling would be still a bit off.
I sent a test to Wine testsuite showing that such an adjustment made to d3d9 fullscreen window is getting reset back to the monitor size after pumping the message loop: https://source.winehq.org/patches/data/220941. Albeit it does it on Windows just once before, e. g., swapchain reset (changing the size again will leave it changed) that is enough to fix the game.
I don't have a full prepared test for what is actually happening behind this observed behaviour but I dumped window messages pumped by flush_event() and found out that each time WM_SIZE is sent to the focus window the WM_ACTIVATEAPP gets posted there. WM_ACTIVATEAPP is already processed by both wind3d and dxvk in somewhat similar way and, in particular, restores the size of the window. My patch does exactly this: posts WM_ACTIVATEAPP on WM_SIZE. I separately tested that:
Then, this alone doesn't explain why this size reset works only one time on Windows, it works each time with my patch. My guess is that WM_ACTIVATEAPP processing remembers the active state on Windows and spares SetWindowPos if sent again. Sending WM_ACTIVATEAPP to the window prior to even device creation is enough to stop size restoration observed in test (altough WM_ACTIVATEAPP is still sent on each resize). However, this looks like a different change affecting the existing WM_ACTIVATEAPP processing and this is not needed for the present issue (that works either way).