On 11/01/2022 16:27, Stefan Dösinger wrote:
Am 11.01.2022 um 16:19 schrieb Gabriel Ivăncescu gabrielopcode@gmail.com:
I'm not sure if that will work, unless you have something in mind. As you can see, each version is different. In fact, d3d8 is the only one that cares about "foreground thread" in this respect. d3d9ex cares only about the focus_window being in the foreground, so you can say it's a more strict subset of this.
You are probably right, and I don't care enough where Windows implements whatever behavior. If focus can be stolen on Windows so be it, we care about getting the applications working on Wine :-) .
However, there's d3d9 (normal one) and dxgi which don't care at all about what's in foreground / active / thread, and always do change to topmost, so from what I can see, how are we supposed to implement this outside d3d* (or wined3d) and have d3d9/dxgi still work? Won't this affect them as well? How can it make an exception for d3d9/dxgi?
Yeah, good point
And frankly, dxgi is way more important than d3d8—frankly, I didn't even want to fix the d3d8 behavior, just wanted to add some tests to show that it is different than ddraw—so the ddraw regression can be fixed (starting with patch 4).
Agreed. I don't particularly care about d3d8/9/dxgi unless we have an application that needs a particular behavior.
Musing 2: Is it the foreground thread that matters or that the foreground thread belongs to the current process?
Ah, I had missed that, but not sure how important it is to test, it would complicate the test a bit since it would require spawning a new thread and some synchronization...
You could test it by creating a window on a separate thread and making it foreground. But it is kinda moot, see below.
I experimented with your tests a bit on Windows and looked at the d3d8 and ddraw tests. On my Win10 box (up to date Win1021H2) the win_skip("topmost set when inactive due to inconsistent behavior, skipping related tests...\n"); line always triggers, so I can't read much into the test. I'll dust off my Windows 7 laptop and test there later. Either way, I'd say ignore d3d8/9/dxgi for now and focus on fixing the ddraw regression.
Re ddraw:
ret = SetForegroundWindow(window2); ok(ret, "Failed to set foreground window.\n"); hr = IDirectDraw_SetCooperativeLevel(ddraw, window, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN); ok(SUCCEEDED(hr), "SetCooperativeLevel failed, hr %#x.\n", hr); tmp = GetWindowLongA(window, GWL_STYLE); expected_style = style | WS_VISIBLE; todo_wine ok(tmp == expected_style, "Expected window style %#x, got %#x.\n", expected_style, tmp); tmp = GetWindowLongA(window, GWL_EXSTYLE); todo_wine ok(tmp == exstyle, "Expected window extended style %#x, got %#x.\n", exstyle, tmp);This part - making "window2" foreground, then setting up ddraw on "window", and WS_EX_TOPMOST is *not* set - nicely shows that ddraw cares about the foreground window, not foreground thread or process.
However, immediately afterwards
GetWindowRect(window, &r); ok(EqualRect(&r, &fullscreen_rect), "Expected %s, got %s.\n", wine_dbgstr_rect(&fullscreen_rect), wine_dbgstr_rect(&r));This test is not as helpful as it looks because the window already has the fullscreen size from previous tests (afaiu; I am on Mac now and realized that I didn't explicitly test it). What I did test was add
- SetWindowPos(window, NULL, 0, 0, 50, 50, SWP_NOZORDER | SWP_NOACTIVATE);
- GetWindowRect(window, &r);
- ok(!EqualRect(&r, &fullscreen_rect), "Window resize failed? got %s.\n",
wine_dbgstr_rect(&r));Before the SetForegroundWindow() calls to give the window a different size. Even in cases where WS_EX_TOPMOST is not added by native ddraw, it does resize the window to the fullscreen size. I am not yet certain what to make of it - it isn't my understanding of "no windows changes", but it might just be in line with what ddraw's hooks on top of wined3d's hooks already do.
wrt the window size—I thought exiting fullscreen resized the window back to its original size? Granted that's not tested because I thought it was redundant. But yes, more or less I wanted to test the fact that the window does get fullscreen, just not topmost.
As for "no window changes", I think this is intentional. wined3d's "no window changes" flag does the same thing: it only applies to visibility changes and topmost, not size, which is similar among different APIs so it must be something common on what Microsoft considers here "window changes" I guess.