Poor scaling of GUI on high resolution displays

• Nov 20, 2014 - 16:34
S4 - Minor
won't fix

Ubuntu 14.04 (xfce), GIT commit: 0f5bd23

High resolution displays are becoming more common, but unfortunately, OS and Qt support for them is still erratic, and as a result, MuseScore often does not work as well as it could. More unfortunately, the specific problems are OS-specific.

On a Mac with retina display, apparently OS X handles a good amount of the scaling issues for you by defining most things to use "device independent" pixels that are fixed to 96 DPI (I think) - thus allowing applications to continue to specify sizes in absolute sizes and the OS scales it for you. In MuseScore, this works for everything except the palette labels and the "Concert Pitch" toolbar button. I'm not sure if we understand why. Text within QToolButtons is not scaled automatically, I guess?

For my system running Linux with xfce4, the situation is somewhat different. There is an OS option to scale text, but it pretty much only applies to text, so you end up with applications that have readable text but tiny buttons. So the best solution I know is to increase the system text size (which generally affects default the basic size of menus & dialogs in application) and then hope the application provides enough controls to scale other things.

Right now in MuseScore, here is what a current build looks like on my monitor when run with all default settings:


I can't say how that will look for you, but on my 13" monitor, the menus and palette labels are fine, but the toolbar icons, score, palette contents, and MuseScore Connect are tiny. The problem isn't that my monitor is small; it's that it is fairly high resolution (166 DPI rather than the more standard ~96 DPI).

MuseScore provides preferences to select toolbar icon size and default zoom level for the score window, which partially addresses the issue. But palettes and a few other elements are still tiny on high resolution displays because they are set in absolute point sizes. You can increase palette sizes manually, but that has to be done for each palette one at a time, and needs to be done separately for the magnification and for the cell size.

It seems the software world is only slowly catching up to the hardware world in support for high resolution displays. I have no doubt that at some point, OS and Qt support will be such that we won't need hacks but will instead be able to just do some simple initialization up front. Qt 5.4 provides some guidelines here:


However, I have my doubts about whether QT_DEVICE_PIXEL_RATIO will work for us (it's labeled experimental, we don't use the Fusion style, and it's not like this scaling works perfectly for MacOS / retina as it is). So I think we will need to take some initiative here.

Not having a Mac to test on, I will leave it to someone else to see about solving the text-within-QToolButton issue. Could be a matter of mutiplying the specified font size by QWIndow::devicePixelRatio(), which is 2 for Retina, 1 for everything else. And never having seen a Windows machine with a high resolution display I have no idea what issues we may or may not have,

For Linux - or at least Ubuntu with xfce - a straightforward solution is to implement a command line option to scale the display of elements that are specified in absolute values. I have implemented this and it works well for me. Whether it will work for some other system I cannot say. But here is how it looks on my system if I specify "-x 1.5":


To my eyes, on my high resolution 13" monitor, this looks like how I'd want it to look in comparison to how it looks on my other machines with larger but lower resolution displays.

The long term option recommended in the Qt 5.4 guidelines is to rewrite the portions of the code that use absolute sizes and instead choose values based on screen size. Really, though, that amounts to another way of looking at the same thing. And I might not *want* my icons and score as physically big on my (higher resolution) 13" as they are on my (lower resolution) 17" monitor - it would mean I can't fit a full page on screen. So even if we provide an automatic way of setting this default, I think I prefer to be able to set the scaling manually.

Attachment Size
scaling-none.png 224.57 KB
scaling-150.png 259.74 KB


I assume Qt knows what the screen DPI really is (166 in your case). Wouldn't a simple division result in the proper scaling factor and then use that by default while allowing the user to modify it in Prefs? In your case 166/96=1.7, which is close to your 1.5.

Yes, that would be a way to get a semidefault on my system - although actually, much too large to be useful. It owuld make the controls and score literally the same size on my 13" monitor as on my 17" monitor, meaning I'd fit much less score on the screen at once. Which is why I definitely think a user override is going to be useful either way. I elected to make it a command line option rather than a preference because a) it still feels experimental, b) I don't know that anyone but me (or people with the same type of system as I do) would ever use it, and c) that requires mcking with dialogs and so forth and I wasn't into that last night. I f we decide this really is a good way to go long term, sure, we could move it there.

Meanwhile, on lasconic's advice I have installed Qt 5.4 and am currently doing a full rebuild. Then I can experiment with the new QT_DEVICE_PIXEL_RATIO facility and see if thast will actually work, or if anything else can help.

I submitted this PR the other day to address the specific issue as it affects my system:


As mentioned in the comments there, I don't see QT_DEVICE_PIXEL_RATIO having any effect for me. Not sure if I'm doing something wrong or if it is not supported on Ubuntu, but in any case, it appears that implementing our own solution would still be desirable.

I also started this forum discussion to see if anyone has issues we need to address; so far no relevant responses:


Noticed that FL Studio has added a widget in their preference to change the resolution of the GUI.

Screenshot 2015-03-30 09.00.44.png

If MuseScore has something similar, one would not have to start musescore from the command line with -x

sorry, posted this on the forum and intended it for here:
In other projects I've had great success having Qt find the DPI ratio by querying QScreen and dividing by the constant 96.0. This means Musescore will basically follow the OS setting without intervention, and works on Win and Linux at least (I haven't been able to test this approach with OS X).

MuseScore officially asked package maintainers to use Qt 5.8 or later, but the official AppImage (v2.1.0) was compiled with Qt 5.4.2.

Qt 5.6+ already supports HiDPI scaling. There is an attribute you can set (before a QApplication instance is constructed) to make everything scale.

QApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true);
Status active won't fix
Reported version 2.1  
Regression No
Workaround No

Qt 5.12 works good on high DPI displays :)