MuseScore3 resolution way too big

• Jul 27, 2019 - 13:44

I'm sure others have noticed this. Musescore2 was fine. But in Musescore3 it's as if the resolution has changed. Everything is too big, as if it's meant to be on a screen four times as big. I can only see the top left part.

I can still do work by changing the "view" of a score to 25% or 50%, but the menus and buttons are still the same huge size and take up a lot of the screen.

Again, this is unique to version 3. I didn't have this problem with Musescore2.

This happens on both my computers, one of which is Windows 7 and the other Windows 10. help? thanks


In reply to by Jojo-Schmitz

Odd that I would have to go to the Command line. I haven't done DOS commands in 20 years.

I found the .exe file and tried
musescore3 -D 1920x1080

which is the current resolution of my screen.

I even tried

musescore3 -D 3840x2160

Neither changed anything. Something must be wrong with the software, not with how my computer is reading it.

In reply to by Jojo-Schmitz


I looked it up, and set DPI's to ever decreasing values. Finally when I got to DPI 20 the menu fields got down to a normal size, like they were with MuseScore 2, as did the entire window. Also normal size was the font on the palette to the right. But the icons (such as for opening a file, load score, notes, flats, sharps) are now microscopic. Aside from the complicated workaround of having to go into DOS, type in the right director, sub-directory, enter the correct command . . . something is not right here.

In reply to by captcrisis

Aside from the complicated workaround of having to go into DOS

Once you determine a decent DPI (and 20 doesn't make any sense) you can add -D dpi to the end of the Target in your shortcut definition and never have to do that again. What is the scaling you have set in your system settings?

In reply to by mike320

That fixed it for me. I have windows 10 with 125% scaling. For some reason Musescore doesn't detect the resolution correctly, icons are way too small. Set it to "-D 96" and now it looks normal.

Easiest way to configure: open menu, start typing "Musescore", right click on the shortcut, "open file location" from context menu, now in explorer right click on the shortcut, "properties", on the Shortcut tab edit Target field to add "-D 96" like so:
"C:\Program Files\MuseScore 3\bin\MuseScore3.exe" "-D 96"

I would also recommend to change a command in registry for opening files:
Add "-D 98" parameter like so:
"C:\Program Files\MuseScore 3\bin\MuseScore3.exe" "-D 96" "%1"

And similarly HKEY_CLASSES_ROOT\MuseScore.mscx\shell\open\command

Wouldn't it be nice to have a single registry setting for DPI in the app settings, rather than doing it via command line?...
Maybe there is some environment variable for that?

In reply to by Jojo-Schmitz

There is another cause I have discovered. This is on Linux.

Changing the DPI setting for me only changed the size of the text and the splash screen / windows etc were still HUGE!

I searched for the problem for qt5 programs generally and this led me to download the qt5 configuration tool, which told me the QT_QPA_PLATFORMTHEME is not correctly set. Current value: gtk2 Required value: qt5ct.

I then followed the instructions here:…


Set environment variables in /etc/environment and add the following lines:


Restart the system

which interestingly hasn't fixed the error in qt5ct, but has led to Musescore displaying perfectly, which was what I was after!

I do use a TV screen.

In reply to by Widmung

Thanks for this info! I was familiar with QT_AUTO_SCREEN_SCALE_FACTOR and have used it (set both ways) on different system to good effect, but wasn't familiar with QT_QPA_PLATFORMTHEME. Unfortunately there are more variations than we can keep up with in terms in how systems, fonts, and displays can be configured!

In reply to by bobjp

I had never heard of it before today, so I couldn't tell you anything more than a web search would. But I can tell you in most cases you shoudln't need it, simply making your you add "-D xxx" to the command line when starting MuseScore n that system should fix it. Where "xxx" is that actual resolution of your monitor as expressed in DPI. But there are indeed some cases where due to how different OS's scale fonts and graphics, that may or may not solve the whole problem.

In reply to by bobjp

Hi bobjp,
Which operating system do you use? qt5ct is for Linux.
If you use Windows, using the dpi scaling option to see if that works first would be the easiest thing to try. If it doesn't work there are ways to do similar things to what I described in Windows, but the fix will be more tricky than the DPI scaling option.
Good luck!

In reply to by Jojo-Schmitz

I don't doubt that one bit. That's why it's not a big deal. I also know that this is not what the OP was about. It's just interesting to me that every other program displays as I would expect. The TV is connected with an HDMI cable from a nice GPU. I haven't tried with VGA. For the fun of it I might try it as a second monitor from my laptop.

In reply to by Widmung

Thank you so much Widmung! I'm on Linux Mint 20.3 and faced the same problem (using MS AppImage 3.6.2) that made MS3 unusable for me. The problem is obviously still not solved! The line


fixed the problem. I don't need to set QT_QPA_PLATFORMTHEME variable.

BTW: Using value of 1 for QT_AUTO_SCREEN_SCALE_FACTOR give the same bad behaviour as using it not at all.

This is what happens every time I open up MuseScore 3 on my mac, same thing happened with MuseScore2, I can't even begin a project. All I see is 4 large boxes. How do I adjust the resolution, I tried messing around in Terminal but nothing was working. Anyone else have this problem?

I've been having this problem too, on Linux, I keep current with the Linux Mint version. It has made version 3 really totally unusable. I can do a lot of tweaks, to shrink down the ui elements. It seems like they are being sized based on the maximum pixel resolution of the monitor, not the screen resolution. When I move the window to my other high-resolution monitor in my dual monitor system, everything gets tiny, and the tweeks must begin again.

The dialog box graphics size seems to be unaffected by the tweaking, so they have to be scrolled around the screen because they exceed the screen resolution.

Most of the time my high-res monitor is used on my work system. I use a video switch to assign it back to my home box. When the monitor is switched to my other system, all the dialog boxes open on this leftmost monitor, not the "primary" monitor. For some reason, sometimes the can't be seen with metro, and I have to switch to the other monitor to move the them back on the primary monitor.

Here is my screen definitions:
DVI-I-1 connected primary 1920x1200+1920+0 (normal left inverted right x axis y axis) 160mm x 90mm
1920x1200 59.95*+

HDMI-0 connected 1920x1080+0+120 (normal left inverted right x axis y axis) 608mm x 345mm
1920x1080 60.00*+ 59.94 50.00 29.97 23.98

I've been using musescore on Linux since it first became available. I am a professional level arranger and writer, but earn my living writing Java software. Ver 3 has been a non-starter for me. Unfortunately, I would like to be able to use some of the 3 features, but I am stuck on 2.x On 2.x I still have to turn the zoom down to 25%. Before you get all fired up on all the new features of 4, you should look at all the screen rendering problems.

In reply to by Marc Sabatella

yes, of course, -D, -X, zoom size, icon scaling all in combination. Nothing works well, dialog are unaffected. You need to test on some different systems if you are unaware of this. Ver 3 is just unusable on my system, I was hoping it would resolve some of the screen rendering problems of 2.x, but it just amplified them.

Like I said, you should not be using monitor dpi, but defined screen resolution.

In reply to by starboard-leeward

We are aware there seem to be problems on certain systems, but we have been unable to reproduce on any of the dozens of systems we test on. Precise steps to reproduce on any given system would be useful, but meanwhile, since we cannot yet reproduce this we need help from users who can.

To be clear you should calculate an "xxx" value that reflect the actual dpi of your display given its current resolution setting and scaling factor as set in your OS. there are so many many differences from systems it is virtually impossible for us to always obtain a foolproof value here, that is why we provide the override. But assuming you provide the correct value, it should work. You should not also use "-x", or make any other changes in Edit / Preferences. So, can you try that specific combination - no -x, no changes whatsoever in Edit / Preferences (reset all preferences to default if necessary), use a "xxx" value that reflects the actual dpi of your display given your current OS-level resolution and scaling settings. The best judge of when you have the right value is, the score itself will be life sized - same size as when printed, when viewed at 100% zoom. If other things are out of proportion once you find the right dpi value, we'd want to know what specifically is off.

Also try setting QT_AUTO_SCREEN_SCALE_FACTOR=0 (also try 1).

In reply to by captcrisis

To be clear, there is no actual different between MsueScore 2 and 3 here - the difference is in the Qt libraries we use. So no doubt you are right that there is something wrong with "the program", but unfortunately, "the program is the entire system - the way the OS< window manager, libraries, environment, and MsueScore all work together. it's quite unfortunate, but unfortunately there are decades of legacy code all assuming a constant monitor resolution, and tons of variations in how different libraries, window managers, OS, and applications struggle to handle the various combinations of things that now exist.

In reply to by Marc Sabatella

Attached is my analysis. As you can clearly see there is a significant difference in behavior between 2 and 3. Quite frankly, blaming the user and the api is the wrong approach. Unfortunately, if you are having problems with an api, you have to do the deep dive. I know it is not easy because I do it every single day. For me, the answer is rarely in the official doc, but I google, and use stack overflow, and when that fails, I trace through using the debugger.

You should add a synopsis of my solution in this doc to your official guide. This has been so frustrating, I can't imagine non-technical users working their way through it.

I have been using MS since ver.1 on Linux. I think you have generally done a very good job with your feature mix and usability. Otherwise I would not have stuck with it for so long. Keep going!

Attachment Size
Musescore Screen Rendering Problems.pdf 2.03 MB

In reply to by starboard-leeward

I'm not blaming you at all, sorry if I somehow gave that impression. I am saying that it's a very complex problem that relies on communication between many different subsystems and thus unfortunately can behave differently on different systems. I am not blaming the API, either - I am simply pointing out that our code didn't change in this respect while the version of Qt did (from 4.somethng to 5.something). The change was actually big improvement overall, as it caused a lot of system that previously didn't work well to start working well, but unfortunately because of the inherent complexity of the problem, the same change apparently caused some systems to not work as well. So there used to be a lot of systems that required these workarounds, now there are fewer. But indeed some that previous did not require the workarounds, now do. It's very unfortunate indeed. We keep trying our best to handle more and more of the cases by default and providing additional workarounds to handle those that slip through the cracks. As soon as well can completely reproduce the problem that you are seeing on your system, we can consider adding a build-in workaround for it too.

So, anyhow, thanks for the analysis! Looks like you got something workable figured out? Sorry it was so much work. If it's any consolation, very few users run into this compared to the old days, but sorry you had to be one of them.

And yes, we would absolutely love to get a better handle on all the thousands of variations possible and put together a troubleshooting guide that handles all of these. As a mostly volunteer-run open source project, we'd have to hope someone with the necessary time, expertise, and access to lots of different systems to test with volunteers to take this on, though.

BTW, from what I can tell, MuseScore 2 does not seem to be handling things correctly by default, either. You should not have needed to set zoom to 25%; everything should be correctly sized at 100%.

Do you still have an unanswered question? Please log in first to post your question.