Much too large GUI appearance on 30" screen
Reported version
3.4
Type
Graphical (UI)
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
duplicate
Regression
Yes
Workaround
No
Project
Opening a MS session on a 30" screen seems to cause much too large graphical elements and empty borders around every graphical element in practically every window. Simple font rendering seems okay so far.
I never observed this behaviour for MS 2.x versions.
Reproduce:
Use Xubuntu 18.04 LTS on FHD display notebook (here: Lenovo T series, some of them)
Attach 30" screen as 2nd screen
Use 2nd screen as extension of notebook desktop, not as 2nd additional "side-by-side" screen
=> already the splash image is much too large.
Workaround: none known so far.
Comments
I analysed the bug a bit further: See https://musescore.org/en/node/114856#comment-980792 (last two comments from me) for detailed system settings and screenshots on this behalf.
Bug is still present in 3.50 beta. Really ugly!
And a friend of mine who is using MS as well experiences same problems, not present in the old 2.x versions!
This happens if your display is not correeft6ly identifying itself to the MuseScore in terms of its resolution in DPI. Solution is simply, just add there "-D xxx" command line option where "xxx" is the true resolution.
See #106241: Monitor resolution detected incorrectly, making sizes wrong for more discussion
In reply to This happens if your display… by Marc Sabatella
No: Your suggestion does NOT work.
I have a 30" monitor, with a resolution of 2560 by 1600 pix. Taking the horizontal, this makes 25.2" linear length, hence quite exactly 100 dpi.
Giving the resolution, according to your suggestion, via "-D 100" produces the attached screenshot when invoking the voices menu via F10:
Please note that the F10 dialog covers, even exceeds the whole 30" screen!
Similar with F11:
This time it is the MuseScore window only (with a part of a terminal window superimposed) since the dialog is still docked.
Please mind a) the abundant spacing in the leftmost menu, b) the size of the graphic rulers in the play settings, c) the menu font size in the terminal window compared to the menu display of MuseScore.
Why do all other programs behave well w/r/to graphical display, EXCEPT MuseScore?
Kind regards,
Petra
At what scaling settings?
Additional remark: If I change the manual resolution setting to "-D 50", no change in displaying the MS windows is observed. (Btw, system is Ubuntu Linux 18.04)
Petra
which should mean that it ignores that command line option. Or doesn't see it in the first place
In reply to At what scaling settings? by Jojo-Schmitz
I am not aware of any manual scaling settings given. I just invoke the 3.5.0 AppImage on the command line, with the additional -D parameter given, as Marc suggested.
In reply to which should mean that it… by Jojo-Schmitz
Are there, by any chance, some hidden config files (e.g. from former versions) that the AppImage may consult and interpret in a wrong fashion?
unlikely, but a -F should get rid of them
In reply to unlikely, but a -F should… by Jojo-Schmitz
Well, it does, in a certain way, but results (regardless if invoking the AppImage with -D... or not) look even uglier:
After using -F once, things look like this. Always mind that the screenshots are taken from a 30" screen:
Simple invocation via commandline, without any parameters:
Invocation with the "-D 100" parameter specified:
Any further ideas, please?
Petra
So the symbols grow even larger if the -D 100 option is declared. :-(
I'm talking about the screen scaling. Could well be it takes the one from the primary laptop screen?
In reply to I'm talking about the screen… by Jojo-Schmitz
Wouldn't say so. If I open MS deliberately on the Laptop screen (Lenovo T470, 13"), with no -D option given, of course, menus are almost unreadably small while the graphical elements are way too large even there - not only in relation but in absolute dimensions as well, e.g. the F11 window:
My screen layout: 30" as main monitor, 13" laptop screen (full-hd) put as side monitor to bottom right, extending the large screen respectively. Screenshot taken with MS filing the full screen of the laptop.
And I'd like to mention again that my friend observes similar effects on her system (non-laptop, single monitor), even though I cannot show examples of that. Therefore a qualitative related mentioning only.
Petra
13" full hd certainly means a High-DPI screen (much higher than the ~100 DPI on your 30" one)
Another observation: When I take the MS window opened on the laptop screen and shove it to the large monitor the menu entries become normal sized (as shown in other windows / progs on the large screen) but the graphic elements grow even larger and change the inner layout of the MS window, w/r/to left options bar, main score display, and mixer settings (right). I would expect this NOT to happen. And in other programs (e.g. LibreOffice) this doesn't happen.
In reply to 13" full hd certainly means… by Jojo-Schmitz
Indeed, but what does this imply? As stated: other programs with complex graphic and text menu layouts (LibreOffice etc.) behave as expected.
Setting the -D to sensible values for the large screen obviously doesn't work.
What does the -d option option tell about what MuseScore detects?
Where would I have to look?
Opening a session in the shown command line (either with -d or --debug) yields no further details apart from loaded libs:
Should have been in my last answer:
NOT FOUND: MS-d.png
Grr.
It should show on the command line, strange that it doesn't?!?
Isn't
musescorejust a script that runsmscore?I don't know. Actually "musescore" (as a symlink) starts the AppImage (3.5.0 beta) for me, downloaded from the MS website. Invoking the AppImage immediately with -d works as well but shows the same output. What starting the AppImage means beyond entering this command is hidden from me (as a pure user).
Would an "experimental informatics" session (e.g. by VNC) on my system help you with identifying this strange behaviour?
Like this (on my PC)
Debug: Information for screen: "\\.\DISPLAY1"
Debug: Available geometry: 0 0 1600 x 1156
Debug: Available size: 1600 x 1156
Debug: Available virtual geometry: 0 0 1600 x 1156
Debug: Available virtual size: 1600 x 1156
Debug: Depth: 32 bits
Debug: Geometry: 0 0 1600 x 1200
Debug: Logical DPI: 96
Debug: Logical DPI X: 96
Debug: Logical DPI Y: 96
Debug: Physical DPI: 72.0567
Debug: Physical DPI X: 72.0567
Debug: Physical DPI Y: 72.0567
Debug: Physical size: 564 x 423 mm
Debug: Refresh rate: 60 Hz
Debug: Size: 1600 x 1200
Debug: Virtual geometry: 0 0 1600 x 1200
Debug: Virtual size: 1600 x 1200
In reply to Like this (on my PC) Debug:… by Jojo-Schmitz
I'd love to show you something similar, but it just doesn't show up. I even gave -d -L a try, but to no avail.
I just checked with an older version of MS (3.4.2), but the observations are practically the same.
Since I don't have a 30" monitor to check those images on, it's difficult for me to tell what looks right and what looks wrong. At first glance, though, it appears the main interface is now sized correctly, and the only problem is the Mixer & Play Panel windows? You mention trying -F, but then you don't show a screen shot of the results immediately after doing so. Could you try that?
To be clear: the "-d" lower case option outputs to the console, so you'd need to start from a terminal window, not a program icon, to see the output.
I'm reopening this because it does seem whatever is going on your system is some unique problem unlike the more standard one. Something unusual about your system configuration is apparently causing a problem no one else seems to be experiencing, so we appreciate the work you are doing to help figure out what might be going on here.
@Marc: I DID show the screen shots immediately after -F, either by invocation without any further parameter or with an additional -D 100 in my contribution timed 08:38 today way above in this thread.
And yes: For the -d invocation I showed both the calling console and the resulting MS display. See my contribution timed 10:09. I never start from a program icon!
On behalf of "no one else is experiencing..." let me re-state that my friend observed similar things on her non-notebook machine equipped with just one standard monitor. (Although I cannot relate more than this qualitative report and cannot give further details on her system, as I didn't see it with my own eyes.) She is rather uncomfortable with the 3.x series of MS, contrary to the older 2.x versions.
I don’t see a shot without the Mixer, which would not be visible immediately after -F. That’s what I am specifically wondering about.
Your friend with the single monitor is almost certainly just seeing the more standard issue with high DPI displays, completely solved with -D xxx. If not, we’d need further details to understand.
To define my setup as closely as possible, let me state the technical details once again:
Ubuntu 18.04, XFCE4, two monitors: original full-hd notebook screen 13" on Lenovo T470 + 30" NEC 3090WQXi (2600x1600) attached via dual channel DVI at the docking station. Screen layout: 30" as main monitor (showing the usual desktop additions like menu bars and virtual screen preview, as shown in my previous screenshots) + notebook screen being placed bottom right to the large one by a respective series of xrandr commands, so foot lines coincide.
Comparison to e.g. LibreOffice, that shows a similar screen layout with mixed menu, icons, written menu entries etc.: LibreOffice does not show any of this malformed screen layouts whatsoever. Neither does Thunderbird, Firefox, Chromium, Atril, Evince, TeXWorks, ....
If you need a comparison to any other special program (e.g. because you may know that the internal programming has been done similar to MS): please name it and I test it!
Thanks for your effort, anyhow! thumbs up
Petra
Okay, here are two new screenshots immediately after -F:
First appearance, hides the invoking command line:
And after clicking through the upstart dialog until the final windows appear, with the topmost one a bit shifted by the mouse, so to display some return messages on the command line:
Hope that helps!
It does, thanks! But then how about if you add an explicit -D 100 on that same command line? Just an image of the final result after dismissing the start center.
As for comparisons, I guess LibreOffice is probably the closest because as far as I know they also use Qt for their user interface code. But I don't know if it's the same version or not.
BTW, another relevant variable here could be any scaling settings your OS or window manager provides.
You are welcome! Here it is, with a necessarily shifted main window, to keep the look to the command line open.
W/r/to potential scaling settings: Where would I find them? I don't remember deliberately having set such.
In reply to It does, thanks! But then… by Marc Sabatella
Just in case my last question may have been drowned by the large screenshot image:
Where would I have to look for scaling settings of the window manager (XFCE4).
I am quite sure never to have set such deliberately, but the system may have decided to do so by itself.
Regards,
Petra
Not sure there's such a thing on Linux, but there definitly is on Windows