Size of icons of toolbar breaks again

[0tkl]

The same problem to arch1t3cht#99 resurrected in build r9503.

[arch1t3cht]

If I understand you correctly, this is intended. The buttons above the subtitle edit box do not scale with the "Toolbar Icon Size" setting, and I don't believe they should, since they're in line with various other controls that also don't scale with it. They do correctly scale with the system-wide DPI, so they don't end up too small on high DPI settings.

[0tkl]

Alright the size of buttons from edit box makes sense.

My actual question is, all controls look kinda squished together on high-DPI screens (See below, both programs are using 16px toolbar icons). The old bitmap-stretching strategy is blurry; but weirdly, the relative sizes of the different controls feel more natural (I guess it's because the paddings and margins are larger in the old strategy).

From what I understand, Win32 controls (buttons, text inputs, combo boxes, etc.) are kinda just not designed for high-DPI screens. I don't expect some easy fix to make them look great. However, one thing we could try is playing around with the toolbar button sizes. I guess we have to create a 20px icon set? Or is it possible add more margins and/or paddings to icons on Hi-DPI screens?

[AdventurerRussia]

by the way, I wanted to mention that the size of the icons does not change if in some values of their size, you drive 18 and they take on a size, why 19 or 20, they go the same size, and if you enter 22, then their size changes already. in general, not all size numbers change their size in the program.

[arch1t3cht]

See below, both programs are using 16px toolbar icons

What's the difference between these two screenshots? Is the one in the background with DPI compatibility disabled?

I guess we have to create a 20px icon set? Or is it possible add more margins and/or paddings to icons on Hi-DPI screens?

One thing to note is that wxWidgets can render bitmaps from SVGs now (and there are SVG sources for all icons in the repository). That would allow icons to be drawn in any desired resolution. However, this comes with a number of quirks and limitations (see https://docs.wxwidgets.org/latest/classwx_bitmap_bundle.html#a148dc26191f48f22e57c1ef2d8ff611b), so I'd first need to test in detail whether this will work for all current icons. That's why I stuck with the existing PNG icons for now.

If this doesn't pan out, creating a 20px icon set sounds like a viable alternative. While I don't like creating icons for every size under the sun, adding one for 20x20 sounds like a reasonable compromise since 125% scaling is quite common (and the difference between 100% and 125% is much larger than the one between 150% and 175%).

not all size numbers change their size in the program.

Yes, this is because there are only bitmaps in the sizes 16x16, 24x24, 32x32, 48x48, and 64x64. I know that this may be confusing to users, but that is also how the setting behaved before. There are still a lot of things that can be improved here (e.g. I'd like to make the buttons under the video display not scale with "Toolbar Icon Size"), but at this point the work on high-DPI support has reached parity with the previous status, which made it good enough to merge on master.

[0tkl]

What's the difference between these two screenshots? Is the one in the background with DPI compatibility disabled?

This is not two screenshots, but a single screenshot comparing two instances under the same screen, with the one in the foreground having DPI awareness turned on (the default), and the one in the background letting the system take over the scaling, which is equivalent to the program not providing DPI awareness.

I'm using Linux (GNOME), Linux (KDE), and Windows all at the same time on a 3072×1920 screen, and I'm using 200% scaling on all three desktop environments. Before I learned about the lack of modernization of Win32 controls, it's reasonable for a Linux desktop user to expect a Windows program with DPI-awareness turned on should have the relative size and position of the widgets equivalent to the bitmap-stretched instance, only clearer and sharper.