Windows resizing in Windows 11
jeffreyzhang92 opened this issue · comments
Hello,
I have used this applications for months and it has been great. I switched to Windows 11 recently, and for the most part it has still been great. However, it seems that there are always several windows which always get resized so they are very very large.
I have 3 monitors: one portrait 1440p, one landscape 4k, one landscape 1440p in that order left to right. The issue seems to be most prominent with windows which were originally on the middle monitor.
Is there any way to fix this? Thanks!
Sounds similar to #276
This kind of bug is hard to debug & fix if it can not be reproduced consistently.
This doesn't seem to be the same issue.
An example of what the issue looks like:
Red is the limits of monitor 1, green is the limits of monitor 2, and blue is the limits of monitor 3. MS word is stretching from the middle of the second monitor to the middle of the third monitor.
This is what it looks like when I hover over windows explorer. The white space designates space that the window takes up but is not actually a part of any particular monitor.
Please run PersistentWindows5.51_patch289.zip with -debug_process "WINWORD" command option, which saves Word window location history to event log.
Once the Word window issue is reproduced, follow the instruction of the last section of PW home page to report back
Does this work?
The event log shows Word window is restored to (1130, 425) with size 1752x1559 on 6:46:01 PM (striding between 2nd and 3rd monitor), using position data captured before 2/6/2024 9:12:07 AM, which is however missing from resizing.txt. It could be that the issue is caused by bad capture. Without complete capture/restore log, I could not tell
Capture 1 is from when i started the patched PW with the debug process. I turned the computer on and off a few times to see if anything would happen (nothing did).
Capture 2 is from the morning after, when Word didn't encounter the resizing issue but other applications such as Zoom and Steam did encounter the issue, I didn't move Word at this point.
The oddness happened in capture 2,
while user does not perceive location change of Word window after PW auto restore, Windows OS (or MS Word) suddenly forgot the middle monitor has 150% scale factor, and silently changed the coordinate of Word window as if the middle monitor has 100% scale factor, thus triggered PW to capture wrong data.
Information 2/6/2024 9:11:58 AM Application 9990
PersistentWindows: Captured 9540.002b15b8 WINWORD at (1130, 425) of size 1752 x 1559 PROJECT NARRATIVE.docx - Word
Information 2/6/2024 9:11:57 AM Application 9990
PersistentWindows: Captured 9540.002b15b8 WINWORD at (753, 283) of size 1168 x 1039 PROJECT NARRATIVE.docx - Word
while PW correctly restored the 150% scale data at 9:11:24 AM (30 seconds before the oddness happened)
Information 2/6/2024 9:11:24 AM Application 9990
PersistentWindows: Restore finished in pass 5 with 11 windows recovered for display setting Display_LocM1440xM407_Res1440x2560__Display_Loc0x0_Res2560x1440__Display_Loc3840x274_Res2560x1440
Information 2/6/2024 9:11:24 AM Application 9990
PersistentWindows: MoveWindow(WINWORD [753x283]-[1168x1039]) - True
This issue is most likely caused by Windows 11, or interaction between Word and Windows11
I figured it had something to do with the resolution. A lot of the time the text in a window is really small after all the reshuffling, I jiggle it a little and the text size goes back to normal.
Is there any settings I can change to help with this? Or is this something out of scope?
I made a speculative fix to disable related DPI awareness function call for Windows 11.
Please try
PersistentWindows5.51_patch289.zip
It seems to be worse. I did not start it on debug mode so I don't have the logs but I'll do that tonight.
Try
PersistentWindows5.51_patch289_2.zip
The new patch attempt to avoid capture position change due to sudden DPI change by the Word window itself.
If the issue still exist, try run PW with new command option -dpi_sensitive_call=0
I don't have Win11 test platform with the same display setting, all these fixes are speculative, thanks for testing.
Just created win11 branch to remove the dpi awareness code, the new win11 patch is in 5.51 release page,
https://github.com/kangyu-california/PersistentWindows/files/14227995/PersistentWindows5.51_win11_patch.zip
The base run didn't work, trying it now with dpi_sensitive_call=0. If this still doesn't work I'll do the debug process.
It also doesn't work, also there seem to have been a lot of windows on my portrait monitor that shrank.
I'll do a debug process tonight. Should I try with or without dpi_sensitive_call=0?
@jeffreyzhang92 my theory is that some app window does not like to be repositioned by PW built with dpi awareness config enabled, no matter whether the dpi command switch is off or not. My develop env setup is too simple to reproduce this issue. thanks for helping, really appreciate.
This was with dpi_sensitive_call=0
Again it took 2-3 monitor reboots until the weirdness popped up.
Thanks for the help with this too!
@jeffreyzhang92 will investigate when back from vacation. Happy holidays!
If dpi_sensitive_call=0 does not work (for 5.52 released from master branch), then just switch to following special release built from win11 branch
https://github.com/kangyu-california/PersistentWindows/releases/download/5.52/PersistentWindows5.52_dpi_unaware.zip
Thank you! I just saw that a window became very large but was sized back down immediately after. I'll check this again tonight.
Edit: Still some issues. Will run debug mode again tonight.
Again takes a few rounds before the resizing issue pops up.
Somehow PW get two different results when calling the same API GetWindowRect() to retrieve Word window size.
Information 2/29/2024 2:09:01 AM
PersistentWindows: Captured 25508.00090d64 WINWORD at (537, 250) of size 1536 x 1075 Document1 - Word fullscreen:False minimized:False
Information 2/29/2024 2:09:00 AM
PersistentWindows: Captured 25508.00090d64 WINWORD at (806, 375) of size 2304 x 1613 Document1 - Word fullscreen:False minimized:False
Please test 5.43 to verify if the problem is really caused by PW upgrade.
Thanks a lot.
Try this new patch even if 5.43 works PersistentWindows5.52_patch289300.zip
This patch can detect inconsistent GetWindowRect() result and print "Reject unexpected scale factor change" message in event viewer
updated patch PersistentWindows5.52_patch289_2.zip
5.43 event log shows it suffers from the same problem as in 5.52 (abrupt change in scale factor when calling User32.GetWindowRect() at different times), and latest 5.52 patch would not be able to fix this.
Information 3/2/2024 9:48:59 PM
PersistentWindows: WindowPlacement.NormalPosition at (450, 97) of size 3540 x 1729
Information 3/2/2024 9:48:59 PM
PersistentWindows: Captured 8972.001c0b8a WINWORD at (450, 97) of size 2210 x 1729 Word fullscreen:False minimized:False
Information 3/2/2024 9:48:54 PM
PersistentWindows: WindowPlacement.NormalPosition at (450, 97) of size 1473 x 1194
Information 3/2/2024 9:48:54 PM
PersistentWindows: Captured 8972.001c0b8a WINWORD at (450, 97) of size 1473 x 1194 Word fullscreen:False minimized:False
You may also try the following procedure
- Revert back to 5.52 main release (PersistentWindows5.52.zip)
- Override high DPI scaling to "Application" for PersistentWindows.exe in the Properties->Compatibility->Change high DPI settings dialog from explorer,
- Run PW with command option -dpi_sensitive_call=0
This will force PW to run in dpi scaling insensitive mode, i.e. calling GetWindowRect() will always return value in native pixels (100% scaling factor). As a result, the same monitor configuration will have a different key name in PW, you may want to redo capture windows to disk to avoid data loss.
If this procedure succeeds, there will be no need to create dpi_unaware patch release anymore.
seems to be that the window looks fine at first glance, but if i drag it around it'll become bigger.
The 150% scaled size change still happens (the strange thing is user does not notice it)
Information 3/3/2024 10:35:21 PM
PersistentWindows: WindowPlacement.NormalPosition at (784, 186) of size 2889 x 2297
Information 3/3/2024 10:35:21 PM
PersistentWindows: Captured 8972.001c0b8a WINWORD at (784, 186) of size 2889 x 2297 Word fullscreen:False minimized:False
Information 3/3/2024 10:35:17 PM
PersistentWindows: WindowPlacement.NormalPosition at (1036, 292) of size 1926 x 1531
Information 3/3/2024 10:35:17 PM
PersistentWindows: Captured 8972.001c0b8a WINWORD at (1036, 292) of size 1926 x 1531 Word fullscreen:False minimized:False
Before kicking the ball back to Microsoft, there is one more thing to try,
It could be that WINWORD wants to manage its own window position/size.
if that is the case case run PW with command option -ignore_process "WINWORD", this tells PW not to capture or restore WINWORD window
Should dpi_sensitive_call still be set to 0?
It should also be noted that Word is not the only application experiencing this behavior. It's just the only one the debug process is initialized with.
Also I suspect this behavior was present before, it's just that it required interaction with the window in order to become larger, until the third or so time when it'll do it by itself.
I think the issue is not related to -dpi_sensitive_call setting. You may do experiment on it.
captures6.txt
without dpi_sensitive_call
The issue is caused by inconsistency in GetWindowRect() system API, which occasionally returns raw pixel value instead of DPI scaled virtual pixel, and according to Microsoft document "GetWindowRect is virtualized for DPI."
I believe the weird behavior of GetWindowRect() is not caused by PW. but it is hard to verify that, very few program relies so heavily on that API like PW does.
Statistics shows less than 2 out of 1000 users downloaded customized 5.52 dpi_unaware release. I expect it will take a while to gather enough feedbacks from the small user group to reveal the secret under the hood.
For what it's worth, I was experiencing issues with both Steam and Firefox on my system, which is still running Win10.
I have two 4k monitors, both running at 150% display scaling (for an effective resolution of 2560x1440).
Steam would resize itself at random times, and this was fixed by telling PW to ignore that process, but I couldn't do the same with Firefox because it was the primary process I wanted to monitor, due to the fact that I often keep a Youtube window open on my second monitor, and that's what I needed to have repositioned when my monitors wake from sleep. If I minimized my Firefox window on my primary monitor, then un-minimized it, it would resize itself to a much smaller window (even though it was "maximized"), which would require me to un-maximize it, then re-maximize it in order to get it to fill the screen again.
Anyway. Long story short, I just tried the DPI-unaware version of PW, and the issue with Firefox and Steam seems to be completely gone. I'm going to replace my existing PW install with this version and test it for a while, but I'm hopeful. I do have a couple of questions, though:
- Can I just replace the files in %appdata% with the dpi-unaware version and leave everything else the same (i.e. the Task Scheduler job and stuff)?
- Will the DPI-unaware version of PW auto-upgrade to future DPI-unaware versions, or will I need to manually install those?
Thanks!
EDIT: I completely forgot that there were a few other applications I had told PW to ignore, due to the same issue of app windows moving around and resizing, and I removed those from the starting parameters as well—and it looks like the DPI-unaware fix has taken care of all of them.
@drew7579
Thanks for the feedback, based on your experiment, I am merging the DPI-unware branch to master to avoid multiple parallel releases in the future.
please try the latest patch
PersistentWindows5.52_patch289_301.zip
Close with 5.53 release