Default GUI margins are too big with larg(er) system fonts

[jballi]

Much of the following description was taken from the AutoHotkey documentation [v1.1.16.05]...
The default GUI margins are set when the first control is added to a window. They are set proportional to the size of the currently selected font (0.75 times font-height for top & bottom, and 1.25 times font-height for left & right).

So, if the font height is 10, the default X margin should be 12 and the default Y margin should be 7. The font size (width and height) is automatically scaled to the system DPI and so the DPIScale feature introduced in AutoHotkey v1.1.11 should not affect the calculations for the default GUI margins.

Unfortunately, it appears that AutoHotkey is now increasing the size of the margins on top of the calculations that are already DPI aware. For 120 DPI, the default margins are 25% larger than they should be and for 144 DPI, the default margins will be (didn't actually test it on 144 DPI) 50% larger than they should be. For small fonts, the extra margin space is hardly noticeable. However, for large fonts, the extra margin space can be substantial. I tested this on AutoHotkey v1.1.09.00 to confirm that the margins were correctly calculated pre-AutoHotkey v1.1.11.

BTW, this bug occurs with or without -DPIScale. This part is good since the DPIScale feature should not change the default margin calculations.

Thank you for your consideration.

[fincs]

I'm afraid you're wrong.

Code: Select all

mMarginX = DPIScale((int)(1.25 * sFont[mCurrentFontIndex].point_size));

point_size stores a font's height in "points" and not pixels (actually 72 DPI resolution points, and it looks like Chris originally failed to take this into account so AHK originally mistook it for a plain 96 DPI pixel height); therefore DPI scaling must be applied too. Since the default margin sizes depends on font sizes (which are bigger on high DPI screens in terms of pixels despite having the same 72 DPI point value as their nominal size) the conversion needs to be applied to -DPIScale Guis too.

However, I think the documentation should be corrected to reflect the real behaviour.

[jballi]

Boy, did I drop the ball on this one! I noticed that the default GUI margins were different than pre-v1.1.11 and so I created a report based on my findings and the AutoHotkey documentation. Since the documentation somewhat matched my observations, I believed what I was writing. I completely forgot that I researched this same topic when writing the first version of the Fnt library a while back. My sincere apologies for the confusion.

Yes, the default margins are based on the point size of the font but it's not based on the height of the font (documentation) or a conversion of the point size to pixels (same as the documentation but converted manually assuming a 96 DPI display as you implied). Instead, the default margins are calculated based on the point size number itself, i.e. 10, 12, 16, etc. So, for a 16-point font, the X margin is 20 (16 * 1.25) and the Y margin is 12 (16 * 0.75).

Although some may argue that the default margin calculation is crude or wrong, it does create a consistency that would not be available otherwise. The method makes the default margins for a specific point size (Ex: 16) the same for all typefaces. These margins are increased and decreased the exact same amount as the font sizes increase and decrease for all typefaces. So if the default margins are based on Arial 16-point one day, the default margin values won't change at all if Comic Sans MS 16-point is used another day.

OK, let's get down to the problems at hand. It's obvious that the default margin calculations are now DPI aware. For this reason, the "DPI aware" component of the calculation should be removed if the "gui -DPIScale" command is used.

Also, the documentation is wrong and needs to be corrected. If I were to guess, emphasis on guess, the default margins were originally based on the font height and so the documentation was written accordingly. When the calculations were changed to be based on the point size number of the font to create a more consistent look, the documentation was never corrected. Like I said, it's just a guess.

That's all I got for now. Thank you for your consideration.

[fincs]

For this reason, the "DPI aware" component of the calculation should be removed if the "gui -DPIScale" command is used.

I disagree:

Since the default margin sizes depends on font sizes (which are bigger on high DPI screens in terms of pixels despite having the same 72 DPI point value as their nominal size) the conversion needs to be applied to -DPIScale Guis too.

-DPIScale doesn't remove DPI awareness, it merely disables DPI-aware scaling for user-provided coordinates and sizes (in order to let the user manually do it). The calculated margin sizes must be DPI scaled too in order for them to have the same apparent size on higher-DPI screens.

[lexikos]

Yes, the default margins are based on the point size of the font but it's not based on the height of the font (documentation)

Yes it is.

Instead, the default margins are calculated based on the point size number itself

The point size number is the height of the font. Therefore, the default margins are based on the height of the font.

The default margin, in pixels, is not 0.75 times the pixel height of the font, but the documentation doesn't say that. The documentation doesn't specify what units are used for the font height in the calculations. Perhaps it should say "0.75 times font point size" or more to the point, include the actual formula, which is something like 0.75 * Round(height * 72 / DPI). I'd sooner leave it as it is (ambiguous), because I likely got that wrong...

[jballi]

For this reason, the "DPI aware" component of the calculation should be removed if the "gui -DPIScale" command is used.

I disagree:

Since the default margin sizes depends on font sizes (which are bigger on high DPI screens in terms of pixels despite having the same 72 DPI point value as their nominal size) the conversion needs to be applied to -DPIScale Guis too.

-DPIScale doesn't remove DPI awareness, it merely disables DPI-aware scaling for user-provided coordinates and sizes (in order to let the user manually do it). The calculated margin sizes must be DPI scaled too in order for them to have the same apparent size on higher-DPI screens.

The DPIScale feature introduced in AutoHotkey v1.1.11 breaks scripts. Your argument that the feature helps more users that it hurts or that it was wrong to begin with doesn't take away from the fact that the feature breaks scripts. I, like some, have spent countless hours adding the "gui -DPIScale" command in my scripts to remove the effect of the feature which is enabled by default. The default GUI margins are the another component of the DPI aware features that were affected by the changes included in v1.1.11. As such, it should be removed if the "gui -DPIScale" command is included.

As I've written in the past, the DPIScale feature is an excellent feature and many developers benefit from it. However, the developer must be able to turn it off when it is not needed or when it interferes with or breaks the script.

Yes, the default margins are based on the point size of the font but it's not based on the height of the font (documentation)

Yes it is.

Instead, the default margins are calculated based on the point size number itself

The point size number is the height of the font. Therefore, the default margins are based on the height of the font.

The default margin, in pixels, is not 0.75 times the pixel height of the font, but the documentation doesn't say that. The documentation doesn't specify what units are used for the font height in the calculations. Perhaps it should say "0.75 times font point size" or more to the point, include the actual formula, which is something like 0.75 * Round(height * 72 / DPI). I'd sooner leave it as it is (ambiguous), because I likely got that wrong...

I think that ambiguity is the problem. Unlike some people who remember everything, I forget stuff all the time. I depend on the AutoHotkey documentation to tell me what's what. This is at least the 2nd time (that I can remember) that I have gone to the documentation to see how the default margins are calculated and got it wrong because it was ambiguous. Yes, I'm not a smart man.

Any clarification would be helpful. This is what I came up with. It's just an edit of the current documentation.

Gui, Margin affects only the default window, while Gui, Name:Margin affects only the named window. If this command is not used, default margins based on the currently selected font are used when the first control is added to a window. The default margins are calculated using the point size number of the current selected font. For the X margin (left & right margins and the default horizontal spacing between controls), 1.25 times the point size number is used. So for a 16-point font, the default X margin will be 20 (16 * 1.25). For the Y margin (top & bottom margins and the default vertical spacing between controls), 0.75 times the point size number is used. So for a 16-point font, the default Y margin will be 12 (16 * 0.75).

I'm sure it can be improved.

Thank you fincs and lexikos for your consideration.

[lexikos]

This is at least the 2nd time (that I can remember) that I have gone to the documentation to see how the default margins are calculated and got it wrong because it was ambiguous.

I can't say that I've ever needed to know the exact calculation for the default margins. When the margin size matters, it's easier to just set it. Usually I don't even know what the default font size is, so I probably couldn't calculate the default margin size even if I wanted to.

The point size is obviously a number. Why do you think it's clearer to say "point size number"?

It's rather verbose/redundant with regard to the two axes (X and Y).

It's still not clear that although point size is used in the calculations, the result is a number of pixels.

That said, I care little. Feel free to fork the documentation and submit a pull request if you think it's better that way.

[fincs]

The default GUI margins are the another component of the DPI aware features that were affected by the changes included in v1.1.11. As such, it should be removed if the "gui -DPIScale" command is included.

Once again, I disagree. The v1.1.11 changes introduced DPI awareness. This included correcting wrong calculations that were internally done without any regard whatsoever to DPI, and one of these calculations were the default Gui margin sizes. Note that versions prior to v1.1.11 aren't flagged as DPI aware and so Windows performs DPI virtualization, and the client area of all windows created by the program were upscaled (using bilinear interpolation after virtual 96 DPI rendering) by Windows. The incorrect internal margin calculations were visible when you checked the "Disable display scaling on high DPI settings" checkbox in the compatibility settings, and margins were smaller than what they should be. Note that e.g. a 12 point font size on a 144 DPI screen is equivalent to a 18 point font size on a 96 DPI screen. This needed to be taken into account in v1.1.11, regardless of whether DPIScale was being used or not.

As I said before, it is true that the documentation is inaccurate concerning default Gui margin sizes. Therefore, as lexikos pointed out, you can fork the documentation and submit a pull request.