Scale of palette incorrect for high (or low) DPI displays

• Nov 18, 2019 - 17:40
Reported version
3.3
Priority
P1 - High
Type
Graphical (UI)
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

For MuseScore 2, we made all elements of the interface respond to the monitor resolution, the physical size of everything on screen is the same across all systems by default (well, except for fonts, we rely on the OS font scaling for that, and provide an override in preferences also).

For MuseScore 3, the code responsibile for scaling the palettes was removed, not really clear why, but it happened as part of an apparently unrelated commit here:

https://github.com/musescore/MuseScore/commit/337e885896d793f9893c2b8d4…

As a result, all 3.x releases so far (both "old" and "new" palettes) have had inconsistent scaling of the palette items, with the size of the palette elements depending on monitor resolution as well as OS & OS settings. macOS typically does the scaling for you, so most Mac users probably see the correct sizes, and users with "normal" monitors on Windows or Linux generally do as well. But users on high DPI monitors on those systems generally see palettes that are too small, and users on TV sets or other low DPI monitors see palettes that are too big.

I plan to reinstate the palette scaling code, so everyone gets the same size again. The correct size being, 100% scale on the palette itself (like on the keysigs palette) means the display of the symbols within the palette is the same size as they actually appear in a score when viewed at 100%.

However, depending on your actual monitor resolution, and any scaling settings made in your OS, it is possible your palettes aren't unusably small, and you might find the return to "correct" sizes to be disconcerting. I find I actually prefer the palettes slightly smaller than life (so I'm happy that a number of them are already set to 80% or less).

In order to reduce user pushback, and provide new flexibility, I also propose including an advanced preference to control palette scaling relative to the correct nominal size. The default will be 100%, so by default, everyone gets a life-sized key signature palette regardless of OS or monitor resolution. But users who prefer smaller palettes (or larger) can turn that setting down (or up).

I have this mostly implemented and will submit a PR soon as a WIP.

Comments

• Nov 18, 2019 - 17:46

Here is how the key signatures palette is supposed to look (how it looked in MuseScore 2, and how it looks for users on macOS or users with "normal" monitors:

Screenshot 2019-11-18 at 10.43.03 AM.png

Here for comparison is how it looks on my current system with a 166 DPI display:

Screenshot 2019-11-18 at 10.41.44 AM.png

Reply

• Nov 18, 2019 - 18:13

I love your proposal to add a setting allowing to chose the scaling relative to the "normal" size.
That will really make all users happy.
And that will allow to select "smaller" on laptop screens to minimize place taken by palettes, and "normal" on bigger screens.
Excellent.

Reply

• Dec 3, 2019 - 07:33
Status PR created ⇒ fixed

Fixed in branch master, commit 66765c6c2a

_fix #297287: scale palettes with monitor resolution +collect_artifacts

MuseScore 2 used to scale the palettes according to screen resolution,
so they were the same physical size on all systems.
This was broken in MuseScore 3 development, so palettes are too small
on high DPI systems and too large on low DPI systems.
This fixes the issue by reinstating the code in palette.cpp
that scales the grid and mag by the global guiScaling setting
(same setting used to scale the score view itself).
That only affects places int he code where the "old" palettes
are still used - keysig and timedig dialogs, etc.
Similar but much code accomploishes the same in palettemodel.cpp
for the "new" palettes.

In addition, because users may prefer larger or smaller palettes,
I added an advanced preference to specify global palette scaling
(applied on top of the automatic DPI scaling).
This value is factored in to the main palette scaling._

Reply

Fix version
3.3.4