On Mon Aug 21 23:42:20 2023 +0000, Zebediah Figura wrote:
I'm finding this comment a bit difficult to understand, sorry. The problem—what's making the test fail—is just that it tries to resize our window, right? I.e. for the purposes of the test, it doesn't matter that it's also to the wrong size? This doesn't really seem like it's "dodging" the issue, either. The whole point of 37daa3573 is to test that WM_SIZE isn't sent, and here, it is. I suppose we can detect fvwm2 by checking that it's resizing to the wrong size, but it does kind of cripple the test. Why does changing mode twice make a difference?
In the current test WM_SIZE(*) gets sent twice below the d3d level - once when d3d resizes the window, and this message is filtered by d3d. The test tests that this is not supposed to be delivered.
The second one is when fvwm assumes that the fullscreen window isn't fullscreen and resizes it. At this point d3d is long done changing the window size, stopped filtering, and WM_SIZE gets delivered.
By changing the second mode switch to switch back to the original size fvwm never thinks it needs to change the window size because after d3d is done changing modes and resizing the window both the screen mode and window size match what fvwm knows about the screen size. Thus the first (ultimately filtered) WM_SIZE is generated by user32 when wined3d switches windows, and there is never an incorrect second one sent.
(*) It is actually WM_WINDOWPOSCHANGING + WM_WINDOWPOSCHANGED, the WM_SIZE is just the response of DefWindowProc to WM_WINDOWPOSCHANGED.