Is anybody but me using monitors with different scaling?

[dummzeuch 1505]

I just wasted two days with chasing a display problem with GExperts and Delphi 11, that apparently happens on my computer only because I am using two monitors set to different scale factors and on top of that making the high DPI monitor my secondary monitor.

 

In my case it looks like this:

• Two monitors placed side by side.
• On the left hand side, there is a 31" monitor with a resolution of 3840x2160 and the scale factor set to 150%.
• On the right hand side there is a 24" monitor with 1920x1200 and the scale factor  set to 100%.
• The smaller monitor is my primary monitor.
• I'm placing the IDE on my secondary (left hand side) monitor and use the other one for the programs I am working on (because most of the company does not have high DPI monitors).

Is anybody else using a similar setup? Or has everybody but me two or more 4K monitors?

 

Many display problems I experience in GExperts and also the IDE itself disappear if I set both monitors to a scale factor of 150% (and I would bet that this is also the case for other scale factors as long as both monitors use the same one.).

Also, there are quite a few problems with the IDE placing dialogs on the wrong monitor, that is, the primary monitor instead of the one the IDE is showing on. This has been the case since basically forever. I reported a few ones to Embarcadero and some of these were even fixed, but they mostly seem to be unable to either understand the problem description or to reproduce them.

[Fr0sT.Brutal 900]

I have 1920*1080 sec and 1920*1200 pri. IDK how to make per-monitor scale

Edited September 13, 2021 by Fr0sT.Brutal

[Angus Robertson 574]

Never really saw the point of 4K monitors for development (except for image applications), for I have two 2560x1440 monitors, the main 32in at 100%, the 28in at 125% so text is the same size on both.  I run Delphi on the larger screen, browsers and text editors on the side screen.  Done that for 15 years, with varying sized monitors.

 

So no scaling issues. 

 

Angus

 

[Lars Fosdal 1792]

My computer is a Lenovo P52 with a 15.6" 4K screen (which is absolutely a waste at that size), which is set up to 200% scaling.

My main display is a 31.5" 4K monitor at 100% scaling.  I can't imagine not working off a 4K screen. So much more code on screen.

 

[David Heffernan 2345]

2 hours ago, dummzeuch said:

Many display problems I experience in GExperts and also the IDE itself disappear if I set both monitors to a scale factor of 150%

Does GExperts and/or the IDE that you are using support per monitor DPI?

[Uwe Raabe 2057]

I have two 32" 3840x2160 monitors both 150% scaled. That gives me the same resolution as my 24" 1920x1080 previous ones on 100% ( 24 / (32/2) = 1.5 ), but with 33% more real estate. Lower scaling doesn't fit my eyesight.

 

For testing I use different monitor and scaling layouts in a VM.

 

I can confirm from my own experience with MMX that supporting High DPI in an IDE plugin can be a bit tedious.

[Pat Foley 51]

I am running 17" 1920*1080 main and a 23"1920*1080 sec.

since the 17" T550 laptop is smaller it's at 125. (running D10.4.2)

 

Anyway using pbrush and alt-screen I took snapshots of your ASCII chart and it was reduced in size depending on monitor taken.   I snapped a form in the different monitors and it "pasted" the same even though the form appears bigger on the bigger monitor.  Shank when form scaled set to true. Grew when setting pixelsperinch to 120 was 96. 

Edit //

Just dragging a form across monitors produces an interesting effect if

Scaled := True.  Hard to capture with alt-PrtScr.  Using PrtScr key the image shows the form across the screens not adjusted for the dots per inch of the monitors. // end edit. 

  

Edited September 13, 2021 by Pat Foley
Add dragging comment

[sakura 45]

3 hours ago, dummzeuch said:

Is anybody else using a similar setup? Or has everybody but me two or more 4K monitors?

 

When I am in the office, I actually use three different scalings 🙂 However, I do not use GExperts, but yes, strange setups are part of the Windows environment.

[luebbe 26]

3 hours ago, dummzeuch said:

Is anybody else using a similar setup? Or has everybody but me two or more 4K monitors?

not 4K, but two monitors with different resolutions HD and  WQHD. Setting one of them to a scaling >100% screws up a lot of things in and around the IDE.

[dummzeuch 1505]

4 hours ago, David Heffernan said:

Does GExperts and/or the IDE that you are using support per monitor DPI?

The Delphi 11 IDE says so in the manifest, but it doesn't really work in many places.

GExperts doesn't, not sure whether I'll bother if the IDE doesn't.

Edited September 13, 2021 by dummzeuch

[Uwe Raabe 2057]

3 hours ago, dummzeuch said:

not sure whether I'll bother if the IDE doesn't.

Putting bad things onto a non perfect system just makes it worse, not better. I know it can be hard to get things working when the fundaments are fragile, but I found and reported a whole bunch of issues while working on MMX for Delphi 11. It was expected that not all of them make it into the release, but a good portion will probably make it into update 1. They wouldn't if I would have given up halfway.

[dummzeuch 1505]

I have now tracked down the reason for my display problems down to the following:

1. primary monitor set to 100% scaling
2. secondary monitor set to 150% scaling
3. IDE located on the secondary monitor

It works fine if I make any of the following changes:

• Make the secondary monitor the primary one (this is the workaround I will be using)
• Set both monitors to the same scaling

I reported this issue:

https://quality.embarcadero.com/browse/RSP-35431

but I expect it to be closed as too unspecific and/or not reproducible.

In the following environment the IDE has quite a few display problems:

1. primary monitor set to 100% scaling
2. secondary monitor set to 150% scaling
3. IDE located on the secondary monitor
(Other combinations seem to work fine, e.g. primary monitor set to 150% scaling,
secondary set to 100%. So to reproduce this you must use exactly this setting.)

Problems include:
1. Dialogs that are scaled incorrectly (in particular the font is too small to read).
   e.g. the progress dialog when opening a project.
2. The selection displayed when using the search field in the configuration dialog
   is partly hidden behind the dialog.
3. The popup dialog used while debugging to display values when hovering the mouse
   pointer over a variable name.

These issues are reproducible. There are others that are spurious, e.g.:
* The status bar of the editor window sometimes is blanc
* The font of the tab titles of docked windows is too small
* The font in the object inspector is too small

 

Edited September 14, 2021 by dummzeuch

[Uwe Raabe 2057]

I may be wrong, but I think the underlying reason is: Font.Size and Font.PixelsPerInch do not respect per-monitor scaling

 

This has been discussed a lot and font scaling is now re-evaluated. I proposed some changes for the VCL that can even be rolled out as a hotfix (i.e. no interface breaking changes), although not really a perfect solution, which requires TFont.PixelsPerInch moved to published. These changes do work, at least for the test cases we currently have. Unfortunately it cannot be used when compiled with packages.

 

The easiest workaround for the moment is to use ParentFont = True as much as possible. TForm.Font is currently handled quite well and that can be adopted with this setting. Of course one loses some design variance.

[pyscripter 689]

6 hours ago, Uwe Raabe said:

I may be wrong, but I think the underlying reason is: Font.Size and Font.PixelsPerInch do not respect per-monitor scaling

 

This has been discussed a lot and font scaling is now re-evaluated.

A few points related to this:

 

• It has been like this since High DPI support came to Delphi many versions back.
• Developers of High Dpi apps have been taking this into account.  Changing this now will break many applications.
• PixelPerInch is not part of FontData.  It is Delphi that sets it to Screen.PixelsPerInch when a font is created.  Bear in mind that the same font can be used in different devices with different  DPI
• Font.Size is a calculated property.  It has always been.  Font. Height is what is persisted.
• The correct way to set a Font to a GivenSize in a form is:  Form.Font.Height := MultDiv(GivenSize, Form.CurrentPPI, 72)
• When a form is scaled it is the Font.Height that is scaled.
• Given that both Font.Height and Font.Size are integer properties, they will never be in perfect match.  One of them will be off by a little.  I think it is better to get the pixels right and get used to think in terms of Font.Height.

 

Also bear in mind that the Windows Font dialog is not per monitor DPI aware and should not be used to set the Font size in per Monitor DPI aware applications.  See High DPI Scaling Improvements for Desktop Applications and “Mixed Mode” DPI Scaling in the Windows 10 Anniversary Update (1607) - Windows Developer Blog for a way to work around this, but it is messy.   It is better to just let the user select a font size from a drop down box and set the Font.Height as suggested above.

Edited September 14, 2021 by pyscripter

[Uwe Raabe 2057]

While your points may be valid, I actually disagree with some of these statements. As always everyone can have ist own view on these things. Often there is no simple right or wrong.

 

The advantage of my suggested approach is, that it fixes a whole bunch of scaling errors still existent in Delphi 11. If the cost for this is breaking existing code - I can live with that.

[pyscripter 689]

5 minutes ago, Uwe Raabe said:

The advantage of my suggested approach is, that it fixes a whole bunch of scaling errors still existent in Delphi 11.

With due respect, I think the bugs can be fixed without implementing your proposal.  I have made a number of components (SpTBXLIB, zControls, VirtualExplorerTree, JvDocking, SynEdit, helped with VirtualTreeView) and applications per monitor DPI aware, so I am talking from experience.

[Uwe Raabe 2057]

Well, I see the font size (and thus TFont.Size) as an invariant in regard to the dpi of the media it is displayed. Keeping the font size constant when changing dpi will always neutralize any rounding errors due to consecutive dpi changes. It doesn't matter if that the current and past implementation doesn't follow this approach. It is never too late to do it right.

 

Nevertheless I respect when you disagree with this.

 

BTW, regarding TFontDialog and High DPI: https://quality.embarcadero.com/browse/RSP-34122

[Guest]

17 minutes ago, pyscripter said:

Also bear in mind that the Windows Font dialog is not per monitor DPI aware and should not be used to set the Font size in per Monitor DPI aware applications.  See High DPI Scaling Improvements for Desktop Applications and “Mixed Mode” DPI Scaling in the Windows 10 Anniversary Update (1607) - Windows Developer Blog for a way to work around this, but it is messy.   It is better to just let the user select a font size from a drop down box and set the Font.Height as suggested above.

That is legit point, but you missed the other blog, the one with more details discussing the four modes of DPI handling

https://blogs.windows.com/windowsdeveloper/2017/05/19/improving-high-dpi-experience-gdi-based-desktop-apps/

 

I don't think PixelPerInch will solve this as it might fix the text but will make the sizes of the controls ugly and messy, while as Uwe said that might fix the symptoms in one case and ruin the UI in other cases, like when your application was created on a monitor but by its setting showed its windows on different one with different scaling.

 

I love custom drawing and i do it a lot, but only for application i use or people i know will customize it as they see fit, for anything else i delegate this to either AlphaSkins Controls or Delphi Html component, the HTML components do there rendering and have there scaling that will work every time, while AlphaSkins to my knowledge has no problem and can handle even dragging windows between two monitors and stay scaling right at runtime, every time someone asked about DPI and visual problem i forwarded that email to AS support and got the fix fast ( sometimes in 15 minutes and sometimes it took a week per their request to wait to next update), but in general it was few hours.

 

As why Embarcadero insist on doing this for years and still not getting it right, that beyond me, i don't know what messages they are adding and handling in the VCL but it is very complicated and should be done right by someone who know how to do it, instead of wasting years and years trying to convince everyone it is fine and perfect, every form should have received specific messages to render and get notified for scaling and for changes, if they fail to handle this in few years, then they should think about different approaches, by either hire someone who know or at least, really the least is to ship the IDE with DCP files for the most (if not all) VCL parts of the IDE, no need to ship sources just the DCP files and many people can fix or try to find workaround these details, (DCP files for CoreIdexx.bpl, Vclidexx.bpl , xxdebugide...), yes workaround the difference will be work arounds you need to months of waiting for and few days.

 

 

What i suggest, and might solve this problem for the IDE, as i see the main problem is the IDE itself with its plugins/packages is to try "Application Compatibility Toolkit" in the blog i pasted above, i installed it, there is punch of setting that might fix the IDE, but can't test it, as i don't have two monitors for few years now and my current one is on 100% 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd837648(v=ws.10)?redirectedfrom=MSDN

https://docs.microsoft.com/en-us/windows/win32/win7appqual/application-compatibility-toolkit--act-

https://docs.microsoft.com/en-us/archive/blogs/yongrhee/download-windows-10-assessment-and-deployment-kit-adk

[pyscripter 689]

45 minutes ago, Uwe Raabe said:

Well, I see the font size (and thus TFont.Size) as an invariant in regard to the dpi of the media it is displayed. Keeping the font size constant when changing dpi will always neutralize any rounding errors due to consecutive dpi changes. It doesn't matter if that the current and past implementation doesn't follow this approach. It is never too late to do it right.

I actually agree, but I wish this was implemented a few years back.

 

46 minutes ago, Uwe Raabe said:

BTW, regarding TFontDialog and High DPI: https://quality.embarcadero.com/browse/RSP-34122

Voted for that.