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

• Oct 14, 2018 - 05:40
Reported version
3.0
Priority
P2 - Medium
Type
Graphical (UI)
Frequency
Many
Severity
S4 - Minor
Reproducibility
Always
Status
duplicate
Regression
No
Workaround
Yes
Project

Why is everything twice as big in v3 as in v2? Is there some setting that is doing that? Is this setting editable?

See attached screen capture of v2 and v3

3TooBig.PNG


Comments

In reply to by Jojo-Schmitz

It's not a TV. It's an LCD monitor like other LCD monitors.

I have two LCD monitors. One is 1600x1200 the other is 1920x1080. The double size effect is evident on both.

Are you saying that this double size is only occurring for me, no one else, and that it is my monitor that creates this?

How do i use the command line option with MuseScore??

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.

I can tell you that I'm not invoking command line options on either one.

v3 is being started by clicking on the nightly.exe icon and v2 is being run by clicking on the shortcut it placed in my start menu.

v3 is producing an overly large display.
v2 is producing an appropriately sized display.

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.

Title Everythign too big in v3.0 Everything too big in v3.0

Windows 7
The monitor is a Cintiq 21UX 1600x1200 pixels 21" diagonal measure. I'm not aware of a specific dpi setting I can make for it.

I think I know what causes this. Windows 7 has a Display control panel where you can set the system text size.

At the 100% setting both MuseScore v2 and v3 show icons and notation at identical sizes. The default 100% setting produces system text that is too small, however.

100%
21UXText100.PNG

Setting it to 150% produces better-sized system text.

MuseScore v2 shows larger icons and notation that are appropriately larger. MuseScorev3 shows icons and notation that are insanely larger.

150%
21UXText150.PNG

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.

In reply to by Marc Sabatella

If i grab the graphics off the screen and count pixels i find that both v2 and v3 draw a 5 line staff as being about 27 pixels high when the display is set to 100%

When the display is set to "Medium - 125%" both v2 and v3 draw the 5 line staff as being 33 pixels high.
27 x 1.25 is about 33. That is a correct scaling result

When the display is set to "Large -150%" v2 draws the 5 line staff as being 40 pixels high
27 x 1.5 is about 40. That is a correct scaling result.

However, v3 draws the 5 line staff as being 80 pixels high. That is not a correct scaling result. 80 is about 3x 27, not 1.5x

MuseScoreScaling.png

If this is really the fault of "Windows 7" or "the monitor" then how do we explain that V2 handles the setting properly and v3 does not?

I'll note that no other program I use has this problem of overscaled graphics when the display is set to "Large -150%". They all either scale appropriately or don't scale at all.

I'll also note that Windows 7 may be old but it remains the dominant OS on laptop and desktop computers, 42% of users by one measure I've seen.

It might be old but it's still very significant.

In reply to by robert.holmen.7

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!

Where in Windows would i find the control panel that reveals the "dpi" that a monitor is reporting for itself?

I don't see it in the Properties of the monitors themselves.

Would it be in a registry key?

The written manual for the Cintiq 21ux doesn't state a dpi but it does state a "pixel pitch" of .27mm
.27mm works out to a dpi of about 94

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?

With the display set to 100%, if I run Nightly.exe from the command line with -D95, I get screen output that matches printer output (-D94 and -D95 create screen output that is noticeably different)
The interface icons and text are small, as expected.
Display100.jpg

With the Display set to 125%, -D95 still produces screen output that matches printer output. The interface text is slightly larger. The icons look to be the same size as at 100%
Display125.jpg

With Display set to 150%, -D95 creates screen output that is about 2X the size of printer output. The interface text is about 150% larger than at 100% but the interface icons become very large.
Display150.jpg

With Display still set to 150%, but using -D48, the screen output closely matches the printed output. The interface icons are about the same size as the Display 100% example but some of them are on buttons that are twice as big as usual.
Display150-D48.jpg

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.

If you compare the graphic of the floppy disc icon in the 100% -D95 picture with the graphic in the 150% -D48 picture they are about the same size, but the rectangular button area it sits on is twice as big in 150% -D48

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.

In reply to by Marc Sabatella

"BTW, you say the text and icons look "small" at the 100% and -D95, but to me those look about normal."

Although I am sure it's 100% of whatever 100% is intended to be, at this default setting for Windows, at the distance I sit from the screen and with the eyes i have, interface text on menus and icons tends to be too small for me.

That is why I prefer to have Windows set to the 125% or 150% options and how I happened to discover this strange behavior of v3 when 150% is chosen

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.

For anyone looking in, I'll note that you can add the -Dxx command line parameter to the "Target" in the properties of a shortcut to the exe so you don't have to get up CMD window and type in a command line every time you want to run the app with this alteration.

NightlyProps.PNG

In reply to by Jojo-Schmitz

Title Everything too big in v3.0 Everything too big in v3.0 / -D command line option
Severity S4 - Minor S5 - Suggestion

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

Using that work-around is the first time I've ever gotten screen size to match printer size in MuseScore.

Before that, it was not apparent what "100%" was supposed to be 100% of.

:D

@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

Attachment Size
Screenshot - 22.10.2018 , 20_20_33.png 56.68 KB

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.

Reported version 3.0 3.4
Reproducibility Always

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?

Workaround No Yes

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.

In reply to by Marc Sabatella

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.