Draft: Fractional scaling for most button icons based on DPI

Summary

Inkscape should have useable icon sizes out of the box (without any configuration fiddling) on monitors with 150%*96 DPI and other non-integer scaling factors.

Motivation / Previous State:

Currently, GTK uses integer scaling factors for the scaling of button icons and everything else: 96 DPI = 100%, 192 DPI = 200%, 3*96 GPI = 300%, ..., but nothing inbetween. This is particularly annoying on screens that have about 1.5 * 96 DPI (e.g. 4K 30inch, or FullHD with 13" notebooks), where you get tiny icons (1x scaling) or with workarounds you can change them to very large icons (2x scaling), but nothing inbetween.

Only the toolbars can currently be adjusted but not the dialogs.

(2x scaling can be enabled, on Linux by setting GDK_SCALE=2 GDK_DPI_SCALE=0.5. Note that on GNOME, GTK_SCALE has no effect and you instead have to switch your display from "100%" to "200%". On Windows you don't need any environment variables, just change the system settings from 150% to 200% sizing. In all cases, Inkscape needs a restart.).

Change:

Scale most icons continuously depending on the DPI, so that the icon size grows proportional to the UI font size.

For example, at 1.5 * 96 DPI, a default (16px logical GTK size) button icon will be scaled to 1.5*16 physical device pixels.

At 2 * 96DPI, the icons will have the usual size as before (2 * 16 px for default button icons). At 2.3 * 96, the size will be 2.3 * 16px, split into a factor 2 done implicitly by GTK (1 GTK pixel = 2 screen pixels due to GTK_SCALE) and a factor done by this code (GTK screen_get_resolution will return 2.3/2 * 96 DPI, and we accordingly scale the icon to ceil(16 * 2.3/2) logical GTK pixels, approximately 16 * 2.3 physical device pixels. ).

How to test:

Start inkscape with the configuration of GDK_DPI_SCALE=1.9 (for a more extreme effect, increase this to a value of 3) and observe that most icons grow proportional to the text size, e.g. in the align and distribute and layers dialog. If text does not scale, this is a separate issue. If icons do not scale, then this code should be improved.

For a more realistic test, try different PCs with different DPI configurations. On Windows change the Display scaling setting to "odd" sizes like 150% or 175% and compare the size of Inkscape to other applications.

During testing you may have to clear your inkscape settings or you have to ignore some other bugs (toolbar needs manual resizing because it remembers old width values).

Screenshots: (100% means 96DPI)

FullHD, 100% (unchanged):

FullHD, 150% (here you see the improvement):

FullHD, 150%, Before: Note that the text grows to appropriate size but the icons do not grow and are therefore too small.

FullHD, 150%, After: Several icons (fill type, "lock" icon, colored fields in color palette, ...) grow according to DPI:

4k, 200%, after = before (unchanged):

4k, 280%, after (before, the icons would look like 200%)

And just for fun, an absurd configuration: FullHD but 300% DPI Scaling (96 DPI with GDK_DPI_SCALE=3; yes, this makes no sense), after:

Not shown here is the same thing on Windows, which works as well.

Future work / Open issues:

• Adjustment using a configuration option is not yet implemented but could be added easily. There are only two functions where the actual scaling computation happens.
• Resizing the icons on DPI change is not implemented, this currently needs a restart.
• The scaling should be applied to further details of the UI (menu entries, CMS preview button near the scrollbar, ...).
• Detailed testing in many OS and theme configurations.
• Maybe upstream to GTK (just hijack the point where the icon sizes are looked up and return a scaled value.)

Related issues:

I couldn't find an exact matching issue, but there are many similar problems:

• Dialog icons are too small and not adjustable inbox#6491 (closed)
• Generic "Icons are too small" issues inbox#7847
• Scaling on 2K monitors not optimal inbox#7283
• Some system icons are rendered too large (colud be 'accidentally' solved in all places where we force a pixel size) #431

Staus of this MR:

Currently this is draft, not ready to merge but good enough to have a first discussion if this is the right way to go.

I am also happy if someone else finds a different solution.