Dialogs not scaling in certain configurations

• Jan 23, 2021 - 13:27
Reported version
Graphical (UI)
S3 - Major

I have two MuS icons on my desktop: one to run when my laptop is connected with a big display (icon's property TARGET field : "C:\Program Files\MuseScore 3\bin\MuseScore3.exe" ), the second when I'm only with my laptop (icon's property's TARGET field : "C:\Program Files\MuseScore 3\bin\MuseScore3.exe" -D 10).
When I run the second one, only the score windows are smaller vis-a-vis of what I get when I run the first one, all other windows keeping the same size. See the two attached images on the occasion of opening the "Musescore Preferences" window..
This is a big problem since, associated to the other issue that a sub-windows cannot be reduced in size in order to reach the [OK/CANCEL] position, prevents the proper use of the application unless I connect a big display.

Attachment Size
MuS-1.jpg 135.63 KB
MuS-2.jpg 141.33 KB


Title The [-D dpi] startup option affect only score windows Dialogs not scaling in certain configurations
Status active needs info

You have a laptop that is only 10 DPI? Or did you mean 100?

The "-D" option isn't meant to affect dialogs, as those should already scale properly in virtually cases. The only things -D affects are the things we need to draw manually, like the icons, palette, and score. If other things aren't scaling properly, this is more likely an issue with the high DPI settings in your OS. You can also try experimenting with the environment variable QT_AUTO_SCREEN_SCALE_FACTOR (setting to 1, 0, or unsetting it).

Title Dialogs not scaling in certain configurations The [-D dpi] startup option affect only score windows
Severity S2 - Critical S3 - Major
Status needs info active

10 DPI is not really a good number is it? Such low-res screens just don't exist

In reply to by Marc Sabatella

Obviously I don't have a 10 DPI laptop! I've used that value in order to put emphasis on the differences amongst the two pictures. Any value will show proportionally what I'm saying here.
The reason for me opening this bug case it's because it is really blocking.
I don't think I'm the only one expecting that all windows get reduced in order to operate as expected.
As it is now it's not possible to use the "preferences" windows, as well as others, since the OK/cancel position cannot be reached.
Even with the display connected I could not reduce the "preferences" window, although I could get to the OK/Cancel button.
As for the suggestion on the environment variable, thanks but I'm not in search for a workaround but for a proper solution whenever that will be possible.

In reply to by Jojo-Schmitz

I'm sorry but I'm not sure what you mean and what I'm supposed to do with your "frequency" post.
For me it's "many" insofar it is persistently behaving as I've explained.
Am I misunderstanding it's meaning? Thanks in advance for your explanation.

My point is that the -D option is not supposed to have any effect whatsoever on most dialogs. Only the specific things I mentioned: the score view itself, the toolbar icons, the palettes, and other things we draw ourselves. Everything else - the menus, the dialog text, the various standard controls like checkboxes, dropdown menus, etc - all that is handled by your OS and whatever scaling it provides, plus whatever Qt provides.

My guess is you have a bad setting of the scaling options in Windows, but there are so many different possible configurations it's impossible to advise really specifically. But I can say, relevant to the specific symptom you mention of a dialog being so big you can't get to the OK or Cancel buttons - in the properties for the .exe file, try settings the high dpi scaling to "system (enhanced)". That's something I recently saw work on one other system that described a similar symptom. Also try the environment variable setting I mentioned.

Again, it is by design that -D doesn't mess with dialog sizes - it's not supposed to to, as that is normally handled by the system. So you need to look tot he system for solutions if on one that isn't behaving as expected.

It's possible that someday Windows or Qt will improve to the point that workarounds like that aren't needed, or that we will discover yet more workarounds for the unfortunate fact that different systems handle this stuff differently and its virtually impossible to work perfectly on all systems. But for now, we all have to work with things as they are. And that means not trying to make -D do something it wasn't designed to do and would in fact break the option for everyone who depends on it currently to do what it actually does do well on most systems.

To summarize,: you say it's a "blocking" issue, but also that you are not interested in workarounds. Those two statements are incompatible.

Until the world improves - a lot - with respect to how high DPI scaling handled by the OS, device drivers, an libraries like Qt - applications have to do their best to work well on as many systems as possible., And on the very few where it doesn't work out of the box, a workaround might be required. It's the price we all pay when people start building higher DPI displays before providing proper OS support.

In reply to by Jojo-Schmitz

I've found this page that goes around the DPI and GDI stuffs.
May be the developers have already applied all the required tricks..
I'm not a graphics expert, I put it just in case:


Yeah, that's definitely a page with good info for Windows. Most of what we do in the UI is handled for us by Qt. For MuseScore 4, it will doubtless change big time as we migrate much of the UI code to QML and also update from Qt 5.9 to whatever we will end up using, at least 5.15 I assume but possibly 6.something. So we'll have an opportunity to take advantage of the latest and greatest at that point. For now, it's mostly a matter of finding the right bandaids.

I'd just as soon leave this open because it really does describe a kind of different issue from the usual one that is solved by "-D". And hopefully for MuseScore 4 we can do another round of trying to handle as many different configurations automatically as possible.