Everything too big in v3.0 / -D command line option

I guess 3.0 and it's newer Qt version just detects you high DPI screen better and is not too big, but 2.x was too small

True. What screen is it, by chance a TV?
You could try the command line option -D DPI

See https://musescore.org/en/handbook/command-line-options

the current development build and 2.3.2 looks like having the same size for me, Windows 7, 1600x1200 on a 20" LCD screen

Indeed, both versions should be detecting your monitor size. Be sure you are invoking them the same way - that you aren't specifying a "-D" or "-x" ption on one but not the other. Also check that you don't have QT_DEVICE_PIXEL_RATIO or any similar environment variable set differently (that particular one I think gets ignored for 3.0, not really sure).

The easiest test as to whether the monitor resolution is being detected correctly is to look not at the icons but the score. At 100% magnification, it should be life size - same exact physical size on screen as when printed (eg, 8.5" wide if your score page size is set to US Letter size). I can see it's different 2.3.2 vs 3.0 on your system, as one is clearly right and one wrong, but I can't tell which as I don't know the scale.

OK. In that case, we'd want to know what OS and also any particulars you can tell us about your display - the actual resolution in DPI, how it is connected (VGA vs HDMI vs integrated etc), anything else that might give us a clue why your system seems unique in this issue. Assuming you've also tried to revert to factory settings. Also, once you determine the actual resolution in DPI, you might want to try using the -D option to see if that produces the right effect.

Interesting. What if you try "Medium"?

Unfortunately, most operating systems and many applications were developed long before high resolution monitors, so support for these devices kind of had to be retrofitted on, and each OS and application has to kind of retrofit things, leading to all sorts of issues. For example, getting Chrome to work reasonably on my first high resolution display (a Chromebook, of all things) was next to impossible. Windows 7 is pretty old, things have improved in more recent versions of Windows, which may be why others aren't seeing this, but again, each system is different, unfortunately.

BTW, DPI isn't something you "set"; it is something that "is". It is dots per inch - literally the number of dots divided by the number of inches. You have 1900 dots across your screen, divide that by the number of inches across it is (21" is not the answer, that's the diagonal measure) and you have the DPI. This info is also normally listed in the specs for the device.

Applying a little back-of-the-envelope Pythagorean math here, I'll guess your display is a little over 16x12" (exactly 16x12" would be 20" diagonal). Thus the DPI is around 100 DPI - or more likely, very clsoe to 96 DPI, which actually is completely, not high resolution at all. So it should be no surprise that if you tell the OS to scale everything by 150%, you get things quite large. By that calculation, you should actually get correct results - score display actual size - at the default 100%. If your goal is to make the text larger while not scaling everything, you may find a separate setting for that somewhere.

MuseScore has no concept of system-dependent (Windows-specific) variables like this. All MuseScore knows is what Windows reports as the DPI for the monitor, and MuseScore then sizes things appropriately. My guess is that Wibdows is apying the scaling twice, once to the DPI value reported to MuseScore and then again to what we draw on screen. As to why it is different from MusseScore 2 to 3, I'm not sure. The code didn't change that I know of, bit it's a different version of the Qt libraires. So they could be confusing things. Definitely needs investigation, so thanks for the report and initial legwork!

OK, so your screen is 1600x1200 pixels at 21"
Pythagoras says: sqrt (1600² + 1200²) = 2000 picels diagonal. 2000/21 = 95 DPI
Not sure there is a place in the Windows settings where you can read what the monitor reports, but there is one where you can set it, see your screenshot above "Set custom DPI"

DPI isn't something you set, it's just a mathematical fact, as I explained earlier. It's the literal number of dots divided by the literal number of inches. So, Windows gives you control over the number of dots (eg, you can presumably set a resolution of something other than 1600x1200 if you choose). This in turn determines the DPI. I don't know that Windows 7 exposes this calculation anywhere - there may or may not be a place you can go to see that number calculated for you. The control you see in that dialog for setting text size is another hack of the sort that OS's sometimes provide to get around the fact that proper high DPI support was not built in to begin with. it isn't changing the actual DPI of your monitor, but may indeed have an effect on how Windows reports it.

If you can run MuseScore in a terminal or debugger window and capture the console output, you'll be abel to see the DPI value that it is receiving from the system (it queries Qt for this value, and as I said, it's a new version of Qt, so maybe the way it communicates with the OS has changed). An interesting expeirment would be to try "-D 94" and see what that produces, with the scaling set to the default. In theory that should result in everything properly sized - meaning your score will the same dimensions on screen as when printed. Can you verify this?

96 is close enough to your ~93.9

Interesting! That should be helpful in understanding what might be going on.

BTW, you say the text and icons look "small" at the 100% and -D95, but to me those look about normal. In particular, the duration icons are about the same size as actual printed notes using the default staff size. Maybe slightly smaller at most. For me it's virtually identical sizing on 2.3.2 and 3.0.

The top row of icons (below the menus) is noticeably larger.

but the rectangular button area it sits on is twice as big in 150% -D48
Look again though, it isn't. Compare with the MIDI button, pressed in both screenshots and thus showing the border/background of the button size.
The row that contains that has a bigger line-height; my guess is this is caused by the dropdown(s). Somehow the 150% is applied to the combobox itself, but not (or negated by the -D48) for the individual entries within it.

I'm curious to see how the dropdown looks if you click it open.

If that's how you like to view all applications, that makes sense, but do note that MuseScore provides it's own setting for the icon sizes, in Edit / Preferences. Currently, there is no equivalent setting for text size, but one was implemented as part of Google Summer of Code, it just hasn't been merged yet.

Dear Jojo,
one problem with that -Dxx display density option in Windows 10 is that you need to create an extra link ("Verknüpfung") to call MuseScore, then. To me, it seems that standard users shouldn't be bothered by setting an important GUI application configuration option on the command line (it is the very first time I needed to do this in my life and into computer science for more than two decades now).
Hency, I kindly suggest to make that add that option -D to the MuseCore preferences dialog.
Best regards - Tobias

That option is meant to be used as a workaround.

@Jojo: Yes. It is indeed a workaround.
Please do take note that I need to create my own hyperlink to call MuseScore in Windows 10 to use that workaround.
That does not reflect the well overall user experience that MuseScore 2 is giving. Your users want to compose music, they do certainly not want to fix application problems on the command line.
Moreover, the problem persists with with the 3.0.0 develoment version, see the attached screenshot.
Best regards - Tobias

Yes, this is only a workaround. Unfortunately, as explained elsewhere, OS support for high-DPI displays is still very inconsistent, so it extremely difficult to get it to work right for every single possible system configuration. Things work well for the vast majority of users, but indeed, those who have something non-standard going on will currently still need workarounds like this, until such a time as the world standardizes better on how these things should work. Things are hopefully moving in that direction, but it's still a slow process.

Came up again in #296900: Everything (UI, score page, buttons) displays enormously too large

Hi! I installed the AppImage on Ubuntu 20.04 LTS and ran into the same issue. The comman-line option -D only seems to scale the fonts/icons but UI elements stay large. For example the Splash-screen takes over almost the whole screen (1920x1080) as do preference panels and the like. Has in the meanwhile come up a solution for this?

After some digging and trialing I found the solution mounting the app-image from commandline and pre-fixing it QT_SCALE_FACTOR=0.5 and doubling the font-sizes in the settings gives me a properly sized UI. Not very elegant for the time being it works. The Snap-Version of the app doesn't have that graphical issues but crashes when setting up PortAudio so I'm happily using this for now :-)

Ah yes, I forget about those QT environment variables (there is also QT_AUTO_SCREEN_SCALE_FACTOR (set to 1 or 0). Depending on the specifics of how your OS does things, different combinations of these controls might be what is needed.

And we have a WINNER! Aweseome. QT_AUTO_SCREEN_SCALE_FACTOR=0 is doing exactly what is needed without having to change the the font sizes! Great, thanks! While my earlier version worked, it caused one minor issue with for example the CTRL-O dialog box, making the icons there miniscule! Now things are like they should be!

Fantastic! I will try to remember to suggest that to others as well, although unfortunately it's not a workaround a lot of people would be comfortable with (the whole concept of environment variable being something most on Windows have never even heard of).

I'm going to go ahead and close this, as a duplicate of #106241: Monitor resolution detected incorrectly, making sizes wrong. The specifics may differ, but the basic issue is the same. Someday maybe all monitor manufacturers, OS designers, and the folks who develop Qt will all settle on one foolproof system for all this. Meanwhile, we do need to come up with ways of handling the plethora of different possibilities we are presented with, so it's good to see the discussions in one place.

Maybe collect all the hints and options in a howto or faq