MultiPar
MultiPar copied to clipboard
Yutaka-Sawada
Blurry on secondary monitor
I have two monitors:
- 27" 4K zoomed to 200%
- 19" SXGA zoomed to 100%
The program looks fine on my 4K monitor. On the other monitor, it's really blurry. Not because the resolution is lower, but definitely more blurry than it can be. Definitely more blurry than before I had my 4K screen.
Tried with the beta version as well - same deal.
Please note: you don't need a 4K monitor to test this. You just need one monitor at a different zoom level than the other.
Thank you for bug report. The incident is same as the previous one. Because I cannot test the behavior myself, I didn't not solve this issue. I made two samples of different application manifests. I'm not sure how it affects on dialog base application like MultiPar GUI. Please test them on your PC.
I put the sample (gui_sample_2021-05-02.zip) in "MultiPar_sample" folder on OneDrive.
I have a 4K 144Hz monitor coming in soon, so I will have 2 monitors with very different sizes and scaling (currently, I use a pair of 1080p monitors @ 1920 * 1080), supposedly shipping this (coming) week sometime. And, technically I have an older VGA monitor that has a much lower resolution than 1080p - I did bring it out but I haven't had the opportunity to connect it as I was working on 2 laptops with ChromeOS. But I'm done with those, so I have space on my desk again.
Once I have them set up I'll post back and can test the issue much better.
Once I have them set up I'll post back and can test the issue much better.
I see. Thank you. The GUI consists of Microsoft Common Controls. There is little thing which I can do for this issue.
An app I use daily for file management, Xplorer², had some issues with monitors with different DPI settings. He eventually added in support for that via a Multiple Monitor Manifest for the installer for X².
If you would like, I can talk to him (I already am on an email-conversation basis with him).
See this thread post https://forum.zabkat.com/viewtopic.php?t=11796 for more information on the Multiple Monitor manifest that he implemented.
I failed to set dpiAwareness to be PerMonitorV2 on manifest. The setting of gdiScaling seems to over-write dpiAwareness or dpiAware item. From my test on primary monitor, gdiScaling looks better than Unaware (with old scaling method). But, dpiAware is always better than gdiScaling on primary monitor. I updated the sample and included screen-shots of each DPI percent.
From Microsoft's sample, PerMonitor dpiAwareness requires additional code to scale all GUI elements at start or WM_DPICHANGED. It's very complex. So, I feel that gdiScaling is simple and may be easier.
I put the sample (gui_sample_2021-05-03.zip) in "MultiPar_sample" folder on OneDrive.
I came up with a simple way to support different DPI monitors. It supports start-up only, and change font size at creating dialog. It doesn't support moving window between monitors. Because MultiPar GUI include a feature to change font size already, it's easy to implement a function to check monitor DPI and set proper font size.
But, I don't know how it looks at starting on a secondary monitor. (Initial DPI at PerMonitor setting.) When Mr. thany has time, please take screen-shot on each monitor with new sample PerMonitorV2 version. In the PerMonitorV2 version, I didn't scale window yet. If it uses DPI of the secondary monitor, it should not be blurry, but may be different window size. It may be shown as 200% DPI (same as primary monitor) and big size, or be shown as 100% DPI and small original size. Before I make a scaling function, I need to know the original state.
It seems that Windows 10 changes dialog size for the monitor's DPI automatically, when dpiAwareness is set to PerMonitorV2. But, the method isn't complete. While some controls are resized automatically, others are not. It's difficult to adjust them, while moving between monitors. So, I gave up to implement PerMonitorDPI method.
I prefer gdiScaling method for different DPI. But, it over-writes SystemDPI setting, and looks bad on a primary monitor. So, I made a function to switch scaling mode by DPI of monitors. When there is no difference between monitors's DPI, it adapts SystemDPI mode. When MultiPar's starting monitor's DPI is different from the primary monitor's DPI, it adapts gdiScaling mode. Though the gdiScaling is still blurry, it would be better than old scaling method.
I put the sample (gui_sample_2021-05-07.zip) in "MultiPar_sample" folder on OneDrive.
Thank you for bug report. The incident is same as the previous one. Because I cannot test the behavior myself, I didn't not solve this issue. I made two samples of different application manifests. I'm not sure how it affects on dialog base application like MultiPar GUI. Please test them on your PC.
I put the sample (gui_sample_2021-05-02.zip) in "MultiPar_sample" folder on OneDrive.
Sorry about that. 😔 There are a few applications with this problem. I did a cursory search and couldn't find an issue I created here.
Anyway, good to see this is beeing looked at 👍🏻
Because Microsoft failed to design DPI per monitor method, other developers cannot solve this problem. Microsoft might gave up to implement also, as it introduced gdiScaling mode. It's not a perfect solution, but a possible better one. My implemented automatic switching DPI mode requires Windows 10 version 1703 or later. If it works enough (or a least acceptable level), I will enable this feature in the next version MultiPar 1.3.1.8.
It's easy to blame Microsoft, and I can't say if it's a correct judgement, but it's safe to say that all built-in Windows tools work absolutely perfectly between my two screens...
Because I don't have multiple monitors and cannot test myself, I cannot determine that this problem is possible to solve or not. There may be a way to fix. But, it requires help of a tester's effort. For example, I don't know what happens when moving a window between monitors. Though Windows OS seems to send some Window messages to the application, the kinds and order are unknown. So, I cannot write code for those Window messages for scaling task.
By the way, from watching Windows Explorer 's behavior, it's not perfect. (It must be Microsoft's built-in OS tool.) Windows Explorer doesn't seem to follow the change of DPI dinamically. (I found this problem, while changeing DPI to check multiple size icons.) While the window basement and most components are scaled, some are not. It doesn't change icon size for new DPI. It doesn't scale dialog (property of file) correctly (looks blurry). (Restarting OS fixes these issues in Windows Explorer.) I don't know that it works between monitors.
Anyway, I cannot solve this problem without testing the behavior. When Microsoft itslef doesn't fix a bug of Windows 10 's basic application, it would be more difficult for me.
I mentioned that I would be getting a new 4K monitor - well, I am, , the tracking number has been sent to me - I should be getting it within 2 weeks at the latest, so I will have 1 1080p monitor and beside it 1 4K monitor to play with in depth.
It is supposed to arrive within a week, but I am allowing for an extra week due to shipping irregularities and reduced work forces due to COVID.
As soon as I have confirmation that it is in my locale and delivery is imminent I will let you know so hopefully we can test thoroughly how to make the scaling work correctly on different resolutions, if you are willing to test, @Yutaka-Sawada - and I expect that @thany will be thrilled to help test further development as well.
The FedeEx tracking number shows delivery date of the 4K monitor of Monday, 17 May 2021. I should have it, even with reasonable delays, by 19 May.
I got lucky. The monitor was delivered today. I have some things to do but I should be able to play with it a little tomorrow or Sunday to test this.
Thanks John L Galt. I made a sample to see the effect of "dpiAwareness = PerMonitorV2". It's for test with Create window. Manual resize is disabled to see Windows OS's automatic resize on different DPI. When I check behavior by changing my monitor's DPI, it's difficult to pre-calculate exact window size of different DPI. When DPI is 120, result is 1 pixel different on my PC. But, this isn't so much problem. (Human being won't distingush the difference of a few pixels.) I think that openning MultiPar on a secondary monitor without blurry will be possible technically in future. Though it may have some small problems, it may work mostly.
The most problem is how to add some functions to manual changing before/after Windows OS's automatic resizing. It needs to set window's min size before Windows OS's automatic resizing. (Without setting proper min size, OS cannot scale the window to smaller.) It needs to adjust/resize the dialog after Windows OS's automatic resizing. (A user may change window size manually.) To see order of window messages, the sample saves them on debug.txt. Please test it. I put the sample (gui_sample_2021-05-16.zip) in "MultiPar_sample" folder on OneDrive.
I'm unboxing the monitor today, so I'll grab this version and test with a few different versions and see if I can notice a difference.
OK, here come pictures. Some strange things going on.
I use folder of 1.3.1.8 βeta that I created on 13 May 2021 (No other build info available from About button) and ran both Auto and PerMonitorV2 on 2 monitors, 1 with true 4K resolution and one with my usual 1080p resolution.
MP_Auto on 4K Monitor:
MP_Auto on 1080p monitor:
MP_PMV2 on 4K (this happens every time I open it):
MP_PMV2 after manually resizing to normal dimensions:
MP_PMV2 after dragging to older 1080p monitor (Note - it was not resizable smaller, only larger, on 1080p monitor):
Debug Log:
There is still a little blurriness when moving from large to small window, and also note that Windows has set the 4K monitor to 150% Scaling for 4K monitor, and 100% for 1080p monitor.
OS: Windows 10 21H1 (OS Build 19043.985) HW: https://valid.x86.fr/tf5prr
EDIT: I just realized I had not run Clear Type tuner on the machine since clean install of Windows 2 weeks ago.
I'll post new pictures shortly - it's a lot more clear now on smaller monitor with V2, I'll check Auto also.
OK, here come pictures. Some strange things going on.
Thank you for test. By watching the screen-shot, gdiScaling feature seems to be enough for me. Though it's a little blurry still, it would be acceptable level in 150% DPI. It may depends on the scaling factor. If I cannot solve problem of PerMonitorV2 mode, I will use this method.
There are many problems in PerMonitorV2 mode. About the strange initial size, it might set wrong min size of window. I modified my sample to set 0 as min size. When I set my monitor's DPI to 150%, there is no problem. I don't know the case of Multiple monitors of different DPIs. Please test with new sample version. Also, please send "debug.txt" (made in a MultiPar.exe's directory) to see what happened. It writes initial window size and resize when. I put the sample (gui_sample_2021-05-18.zip) in "MultiPar_sample" folder on OneDrive.
Tested with newly downloaded Sample 05-18 extracted into folder of duplicated MP 1.3.1.8 as before. System has been set up with Cleratype settings for clarity according to my own visual reference.
MP_Auto on 4K Monitor:
MP_Auto dragged from 4K monitor to 1080p monitor:
MP_PMV2 on 4K Monitor:
MP_PMV2 dragged from 4K monitor to 1080p monitor:
Debug Log:
It looks a little better, but MP_Auto now was a much larger window than normal. I think this is because of 150% scaling enabled?
Tested with newly downloaded Sample 05-18 extracted into folder of duplicated MP 1.3.1.8 as before.
Thank you for quick tests. From new screen-shot of PerMonitorV2 mode, setting minimum window size is important. It must set the min size before Windows OS's automatic scaling for different DPI. To do so, it needs to know the DPI change before actual scaling (auto resize window). While I see the series of window messages, WM_GETDPISCALEDSIZE may be good trigger.
When I change DPI of my monitor, the order of messages seems to be like below; WM_GETDPISCALEDSIZE <- OS starts DPI change task. WM_GETMINMAXINFO <- OS refers min size of the window. WM_SIZE <- OS scales the window. WM_DPICHANGED <- OS finished DPI change task.
If this order is same as moving window between monitors, I can write code in the message process. These messages are written on "debug.txt". I made a sample for the messages. Please test with it. I put the sample (gui_sample_2021-05-18b.zip) in "MultiPar_sample" folder on OneDrive.
I think this is because of 150% scaling enabled?
No, it's because window size was changed ago. MultiPar_Auto.exe tries to resume the previous window size. Scaling itself works well.
MultiPar_Auto.exe switches DPI mode by monitor's DPI. You might set primary monitor to 4K Monitor. When MultiPar's openned monitor's DPI is same as system DPI (primary monitor's DPI), it uses the system DPI without blur. Because your new screen-shot of "MP_auto on 4K Monitor" has no blur, I think that system DPI is 150%. Then, moving the window to another monitor gives blur like the screen-shot of "MP_Auto dragged from 4K monitor to 1080p monitor".
When MultiPar's openned monitor's DPI is different from system DPI (primary monitor's DPI), it scales the window by gdiScaling method. Because your old screen-shot of "MP_auto on 4K Monitor" was blurry, I think that you moved the window from secondary monitor to primary monitor. This is a fault of auto switching DPI system, and it's not good at moving a window between monitors.
No, it's because window size was changed ago. MultiPar_Auto.exe tries to resume the previous window size. Scaling itself works well.
Ahhh. That actually makes sense to me.
OK, testing with new set right now.
Results in a few minutes.
Sorry, delayed by other stuff. Testing now.
V2 on 4K:
V2 on 1080p (dragged over from 4K):
Debug Log:
Sorry, delayed by other stuff. Testing now.
Thank you for test. It seems that dragging a window to another different DPI monitor gives same result as changing DPI of a monitor. But, the initial state is different. Because I did not read "debug.txt" yet, I don't know the actual changing steps. From my tests on my PC, the Create window can follow dynamic DPI change now. It will re-load icons and adjust child controls on the dialog. Though minimum size of the window has a little calculation error, it's ignorable. Nobody will care the difference of a few pixels. (Because each window has some padding space inner border, there is no controling problem.)
I'm not sure it works with moving window between monitors, or openning MultiPar on a secondary monitor. Please test these cases. I put the sample (gui_sample_2021-05-19.zip) in "MultiPar_sample" folder on OneDrive. If it works, I will disable printing out of "debug.txt". If it doesn't work, send the "debug.txt" file, so that I can see what happened.
Something weird here.
V2 Start on 4K:
Above window dragged to 1080p monitor:
Above windows closed, then MP run again, opens on 1080p monitor:
Above windows dragged to 4K monitor:
Above windows closed, and MP run again (so open on 4K monitor once again):
Debug Log:
Something weird here.
Yes, the steps of openning window on secondary monitor seems to be different. I don't know what happened without "debug.txt". I cannot write proper code now. I will try in future, when someone tests. Thanks John Galt for many tests.
Oh, sorry, you wanted a copy of the debug.txt - I totally forgot to upload it.
I'll upload each debug.txt for each test shortly.
I kept each test in a separate folder, and have not deleted any folders yet. I can upload them all.
I'll link to the tests I conducted above, then upload the appropriate debug.txt for each.
First test:
https://github.com/Yutaka-Sawada/MultiPar/issues/32#issuecomment-842647479
Second Test:
https://github.com/Yutaka-Sawada/MultiPar/issues/32#issuecomment-842794700
Third Test:
https://github.com/Yutaka-Sawada/MultiPar/issues/32#issuecomment-843607506
Fourth Test:
https://github.com/Yutaka-Sawada/MultiPar/issues/32#issuecomment-843720517
That's all of them.
To make it easier, I'll now also go back and edit each test post and upload the relevant debug.txt inside them, so if you want to look at post directly, debut.txt will also be there. <-- Done
Again, my apologies, I completely forgot about uploading these files, and I apologize.
Oh, sorry, you wanted a copy of the debug.txt - I totally forgot to upload it. Again, my apologies, I completely forgot about uploading these files, and I apologize.
There is no problem. Because you don't owe testing nor it's not obligation, no need to apologize.
From reading the "debug.txt", Windows OS doesn't send WM_GETDPISCALEDSIZE message before changing window size at first. Maybe it's because the window was not shown yet. I improved code for a case of opening position monitor DPI is different from system (primary monitor) DPI. As it's complex and depends on order of incomming messages, I'm not sure that it works on all users cases. I put the sample (gui_sample_2021-05-20.zip) in "MultiPar_sample" folder on OneDrive.
In this time, please check icon, text and column size, by adding source file on file-list. I might forget to adjust the window's child controls, while Windows OS updates most of them. If it works well, I need to change all other dialogs in same way.
No, you did ask for debug.txt in one of your posts:
If it doesn't work, send the "debug.txt" file, so that I can see what happened.
and I completely ignored it and only posted ss.
I'm reading more carefully now ;p
I'll be taking screenshots here and posting them and debug after - maybe 30 minute or so.