New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DPI Scaling not respected on multiple monitors with different DPI settings #378
Comments
I have to correct myself. The issue with the incorrect scaling is present even on the main display. While Titlebar and Toolbar are scaled correctly on the secondary display they are way to small on the primaray display at 200%. I updated HeidiSQL to 9.5.0.5317 this morning. edit: changed the screenshot for better comparison. The browser window behind is not zoomed, looking sharp and correct. Screenshot has been taken on the primary screen at 200% scaling. |
I am currently working on high-dpi awareness, which is not yet fully supported. See #213 . So it's quite explainable that switching from one monitor to the other has issues. For the moment I would be happy to have it all correctly zoomed on one monitor with one scale percentage. As this is all quite complex stuff and partly not supported by Delphi, I am not sure if I can fix this monitor switch issue at all. But we'll see. |
The buttons are cut because their width is auto-calculated by the (too small) width of the session tree. Make it wider and the buttons are ok. The title bar should be higher, yes. But that should go in ticket #213 . Before I committed these changes, Windows just zoomed HeidiSQL up to your wanted scaling, which made it look very blurry. That's what #213 is all about. |
Thanks for the explanation. In this case let's close this one and continue in #213 |
Let's keep this one open, as it's a more special issue which I want to solve separately from the other high-dpi glitches. |
Similar: #479 |
The weird thing about this is that on the official version 9.5.0.5196 it looks fine. It's only after upgrading to the latest build that I get this scaling issue |
No, it looks blurry in that version. Correctly scaled sizes, but blurry. That's what Windows does for you. In the newer builds, HeidiSQL tells Windows "I am DPI aware, don't upscale me, I'm gonna do this myself in a better way". This is quite complex to solve for me as you can see in the list of issues with label "high-dpi". |
Maybe there can be a setting in Preferences to make it DPI-aware or not? Because I mainly use HeidiSQL on my lower DPI monitors and it looks perfectly fine. Actually it looks fine on my Surface Pro monitor also, because it packs the pixels into half the space |
If you mainly look at a low-dpi monitor then this scaling should not happen, and the issue should not affect you, does it? |
It affects me because I am running the low DPI monitors from my surface, which is high DPI. Anyway I noticed that you just published a new version, and this one looks fine on my low DPI monitors. Thanks! |
Which version have you tried @JGJP ? I checked out v10 released yesterday and it looks like this on my external display. |
I've downgraded to v9.5, which is totally fine regardless of the monitor it's opened on. |
v9.5 looks blurry with high DPI settings - this was discussed in #213. It may look ok enough for some people, but this is just a backward compatibility logic from Microsoft. The right way to go is the complex one - scale every component separately, to make them look sharp. Though that's really hard work, and v10.1 is the first version with support for that, so please have a bit of patience here. |
@mwidmann yes it was that version. |
@JGJP yes, this is a situation that makes me furious. It's been years (an two major Windows versions) that Hi-DPI Laptops have been attached to lower DPI external monitors and Microsoft still hasn't found a way to handle this. Because it's not just the work of the app developers that needs to address this. I have windows opening outside of the screen bounds, I have system dialogs show in 200% on the 100% display, I have window snapping spanning the App over both screens and so on. This used to be so painless when I still was using MacOS. And they figured out how to make this stuff work years ago. 😤 |
I'm sure these new Windows Metro apps don't have such issues. HeidiSQL is just an old-style app :) |
@mwidmann I agree, it's a total pain, getting off-topic though :^) |
Same for me. If I move the main window between primary (DPI 125%) and secondary (DPI 100%) screens, then toolbar icons are getting larger, and larger until it becomes useless. |
@tothandor that is issue #446 , for which I still don't have a solution. Also I suppose the Delphi library needs more fixes for these dpi issues. |
c31cae2 now removes all tweaks for high DPI monitors. I'm giving up here, this does all not work good enough, even different computers and Windows versions behave differently. It's a mess. So, now HeidiSQL is zoomed by Windows again, like it was in earlier v9.5. This does at least display all controls and fonts in the right dimensions. |
@ansgarbecker thanks for looking into this, appreciate that it's kind of an edge case and very difficult to deal with. FWIW it also seems that it's affected by whether external displays were connected or not when the computer is booted up. Anyway, even the version I'm running now is workable, so not an issue. |
Steps to reproduce this issue
My Setup ist the following: Surface Book 2, 3000x2000 (200% scaling, main display) conntected to a Dell U2711, 2560x1440 (100% scaling, secondary display)
Current behavior
The contents of the application are scaled using the dpi scaling of the main display.
Expected behavior
The contents of the application are scaled according to the dpi scaling of the display, the window is displayed on.
Possible solution
It must be a bug introduced in either the last version or the version before that. It worked with no problems until I updated yesterday.
Environment
HeidiSQL version: Revision 5315 (yours: 5315)
Compiled: 2018-10-29 (yours: 2018-10-30)
Operating system: Windows 10, Version 1809 (OS Build 17763.55)
The text was updated successfully, but these errors were encountered: