Dmitry Timoshkov wrote:
Hello,
this patch makes all the recently added ShowWindow tests pass in Wine, and is aimed to fix the bug #4960.
Although this patch creates a regression for popup windows created with WS_MAXIMIZED style set and calling ShowWindow( SW_SHOWMAXIMIZE ) right after that (Windows still calls SetWindowPos in that case, but Wine doesn't anymore - the tests show that SetWindowPos should not be called for child windows if their state already matches the ShowWindow command) but top level windows already behave slightly differently in Wine since they are WM driven, and adding window state change (min/max/restore) through a WM will make them behave even more differently.
Changelog: Make all the recently added ShowWindow tests pass in Wine.
This introduced a regression with WoW: The game starts fine, but as soon as I switch workspace the window disappears (isn't visible in the workspace switcher anymore), and when I switch back the game runs at 3-5fps.. dead slow. When I press ATL-TAB the game minimizes correctly (and the underlying gnome-terminal receives focus), but pressing ALT_TAB again doesn't make the game full-screen, the game appears as a 32x32pixel window in the top left corner of the screen. and from now on ALT-TAB toggles between these two modes, eg. invisible and 32x32pixel window. To bring the game to the foreground, I need to 'maximize' it using ALT-TAB, switch to another workspace and then back again. This however doesn't make the game run at fullspeed, it still runs slowly. I'm using E17 as the window manager, but I'll test it under metacity, too.
tom
"Tomas Carnecky" tom@dbservice.com wrote:
This introduced a regression with WoW: The game starts fine, but as soon as I switch workspace the window disappears (isn't visible in the workspace switcher anymore), and when I switch back the game runs at 3-5fps.. dead slow. When I press ATL-TAB the game minimizes correctly (and the underlying gnome-terminal receives focus), but pressing ALT_TAB again doesn't make the game full-screen, the game appears as a 32x32pixel window in the top left corner of the screen. and from now on ALT-TAB toggles between these two modes, eg. invisible and 32x32pixel window. To bring the game to the foreground, I need to 'maximize' it using ALT-TAB, switch to another workspace and then back again. This however doesn't make the game run at fullspeed, it still runs slowly. I'm using E17 as the window manager, but I'll test it under metacity, too.
If you could minimize the failure to a small test case that would help a lot.
Dmitry Timoshkov wrote:
If you could minimize the failure to a small test case that would help a lot.
Unfortunately, I have neither Windows nor the required knowledge to write windows applications :(
I did two logs when switching workspace (winpos-*) and two when minimizing (minimize-*), always one with your patch and one without.
Workspace switching: I started the game, changed the workspace and then the log starts: change workspace to the one where the game is running and back. Minimizing: I started the game, minimized it and then the log starts: maximize it and minimize it.
Note that the output differs significantly, for example, when min/maximizing with your patch, I didn't see any X11DRV_Expose messages in the log, without, there were heaps of these messages. Can that be the cause for the slow game? And in the winpos logs, without your patch, I see X11DRV_Expose when I switched to the workspace where the game was running, with your patch, the messages came when I was switching back.
The four logs are attached.
tom
Tomas Carnecky wrote:
Minimizing: I started the game, minimized it and then the log starts: maximize it and minimize it.
I'm sorry, this is the wrong description. ALT-TAB switches the active window, like under Windows, it does not minimize!
Even without your patch I can see the slowdown when I 'Iconify' the window (ALT + right mouse button brings up a context menu where I can select such actions). However, I can make the game run normal again by pressing ALT-TAB a few times.
tom
"Tomas Carnecky" tom@dbservice.com wrote:
I did two logs when switching workspace (winpos-*) and two when minimizing (minimize-*), always one with your patch and one without.
Workspace switching: I started the game, changed the workspace and then the log starts: change workspace to the one where the game is running and back. Minimizing: I started the game, minimized it and then the log starts: maximize it and minimize it.
Could you try to identify which piece of the patch caused the regression?
Dmitry Timoshkov wrote:
Could you try to identify which piece of the patch caused the regression?
It wasn't that hard after all.. ;)
The problem seems to be the SWP_NOACTIVATE that is now added to 'swp' in case of SW_MINIMIZE. Before your patch, SW_MINIMIZE has it's own 'case' section, now it falls through and in 'case SW_SHOWMINNOACTIVE' SWP_NOACTIVATE is added.
maybe change it to:
case SW_SHOWMINNOACTIVE: swp |= SWP_NOACTIVATE | SWP_NOZORDER; case SW_MINIMIZE: swp &= ~SWP_NOACTIVATE;
but I'm not sure if this is the right solution.
tom
"Tomas Carnecky" tom@dbservice.com wrote:
The problem seems to be the SWP_NOACTIVATE that is now added to 'swp' in case of SW_MINIMIZE. Before your patch, SW_MINIMIZE has it's own 'case' section, now it falls through and in 'case SW_SHOWMINNOACTIVE' SWP_NOACTIVATE is added.
Many thanks for the investigation. Does the attached patch fix the regression?
Dmitry Timoshkov wrote:
"Tomas Carnecky" tom@dbservice.com wrote:
The problem seems to be the SWP_NOACTIVATE that is now added to 'swp' in case of SW_MINIMIZE. Before your patch, SW_MINIMIZE has it's own 'case' section, now it falls through and in 'case SW_SHOWMINNOACTIVE' SWP_NOACTIVATE is added.
Many thanks for the investigation. Does the attached patch fix the regression?
Yes, this patch fixes it :)
tom
-
Dmitry Timoshkov -
Tomas Carnecky