Giant UI

[theluckyfellow]

The UI is huge and zoomed in. LMMS 1.2.0-rc8 Linux Mint 19.1 Cinnamon 64bit 1920x1080

[musikBear]

Try this: as root user create a file name it gnome-qt.sh and place it in the /etc/profile.d directory In this file type : export QT_AUTO_SCREEN_SCALE_FACTOR=0

did it work?

[theluckyfellow]

Thank you for your assistance, but I believe Open Source needs to be held to a higher standard. I will only accept a new version of LMMS which resolves this issue.

[DeRobyJ]

@theluckyfellow The problem is most probably in your configuration, as most people with 1080p don't get this behavior. But if you believe LMMS should be able to detect and fix this problem, you can contribute to this open-source project yourself, and raise the standard :)

[theluckyfellow]

rc7 did not have this issue. I doubt that it is a complicated fix for anyone knows the codebase. I have my own projects to work on. "Fix it yourself" is not the correct response. I am running a fairly standard install of a popular Linux OS.

[theluckyfellow]

I'm a highschool teacher. I teach all my students how to use LMMS. Shall I tell them to fix all their own bugs too? "Found a bug, kid? Report it?! Why would you ever do that? Fix it yourself, kid!"

[DeRobyJ]

"I will only accept a new version of LMMS which resolves this issue" is not the correct question.

The right way to do this is:

• You report the issue
• The developers ask for anyone else having this issue (that is, another Linux Mint 19.1 user on a 1080p screen, or another linux user in general if the problem is more widespread)
• If the bug is confirmed, the developers will spend some of their time to find what changed between rc7 and rc8 that could break it, and fix it

In the meantime, you can downgrade to RC7, which will work just fine, instead of coming here and ranting that open-source should have a higher standard. You've done your job for this bug, and you also got a way to fix it on your configuration. Don't like it? Use RC7.

Remember these are all beta versions.

[theluckyfellow]

Yes, that's what I'm doing. Thank you for your understanding of the situation. Maybe it is only an issue on my system. I'll have to wait and see. Also, you're right. I should not have replied to any of the comments. My apologies. Let's end this pointless discussion and let the bug fixing process proceed.

[he29-net]

Hmm, I just had something very similar happen on Master after I upgraded from Debian Stretch to Debian Buster, which likely included a Qt5 upgrade:

It seems like Qt guesses or computes the screen DPI, uses it to scale all GUI elements, and then, on top of all that, it takes the system DPI setting and scales all fonts (and some other elements) once again, making them overly big. The funny thing is, when I drag the window to my secondary low DPI screen, it gets scaled down (making the fonts the correct size and all icons too small). So there must have been some changes to the default Qt settings -- it is obviously trying to use per-monitor aware DPI scaling and I am pretty sure this is the first time I saw it in action.

If I reduce the system DPI to 96 (my screen is about 180), the problem goes away and LMMS renders almost exactly the right size for my screen. Obviously that does not solve anything, since every other application is now unusable. Setting the auto screen scale factor to 0 does not help either: the window just gets smaller but the relative sizes remain messed up.

[DeRobyJ]

Have you also tried if this happens to other Qt applications?

[he29-net]

I tried to look around and did not find any obvious problems in other applications. But I'm not even 100 % sure which of them are using Qt, so I may need to collect some more representative sample.

The ones that stand out are Qt5 Assistant and Qt5 Designer (didn't even know I had these installed) -- both exhibit the per-monitor scaling behavior and both seem somewhat large on my main (high DPI) screen. But all the GUI elements are scaled properly, the text is not too large compared to icons (as expected, these should be as close to the "reference implementation" as it gets).

The fact is is too large on my main screen seems to unrelated to the LMMS issue -- Qt is simply going from 1x scaling directly to 2x, while my main screen would need something like 1.5. So the issue with LMMS is probably not that some parts are bigger, but that some components react to the scaling and some do not.

[he29-net]

Update: I just downloaded and tried 1.2.0 RC8 and it renders correctly on my system. So the issue on Master is not the same as originally reported in the first post.

EDIT: As a workaround for the "big fonts" problem on master, setting QT_FONT_DPI to 96 seems to do the trick.

[SecondFlight]

Xenoslyce#6243 on discord has reported this issue happening. They are using 1.2, though they didn't specify which one.

Here's the related conversation:

Linked issue: #4831

[TheGrandmother]

I had the exact same problem. Se my last comment on #2510 for a solution that worked for me and does not affect other applications.

[paperdave]

i've had this same problem here, and it happened before on another software. cool thing about the other software is they had something in the settings that let you change the user interface scale.

since both of these programs started out with the 2x scale on first launch, i'm going to assume they both use qt for their ui.

i don't know how hard an option like this would be to implement, since i've never looked at any of the code for lmms, but i don't imagine it being too difficult.

edit: should also note that the export QT_AUTO_SCREEN_SCALE_FACTOR=0 from above DOES fix this problem, so i'll just be using that on my computer. it solves the problem of automatic scaling actually working

[tresf]

I'm a highschool teacher. I teach all my students how to use LMMS. Shall I tell them to fix all their own bugs too? "Found a bug, kid? Report it?! Why would you ever do that? Fix it yourself, kid!"

Absolutely! Please! Or buy software that doesn't have bugs! There's no warranty here!

This bug you mention is specific to Linux only. We've patched it on Windows (using a workaround) and MacOS (proper HiDPI support).

The workarounds mentioned are correct, Linux still is the black sheep because different machines behave differently. Eventually, the Qt framework that we bundle will support HiPDI better. It's still bad (so is Java in many instances, HiPDI is actually tricky for these frameworks to support)

Believe it or not the reason RC7 didn't have the issue is it didn't have our patch which was intended to fix HiDPI (not make it worse).

Some machines work 100% with this setting, others do not. Not many people have dedicated any time to testing and working on this (I have helped, and I use MacOS, not Linux). I digress.

Anyway, it is and should be part of culture to help open source projects. It's also a fantastic learning experience as a music student to understand the tools that make the software, not unlike organ specialists that were responsible for both playing and repairing.

That said, it's not your responsibility to fix anything, but please be kind when asking volunteers to fix problems. It's just a bunch of hobbyists here, many of which just want to make music too.

Sometimes all it takes is one student to fix a problem for thousands of users. You could even offer extra credit for it.

[tresf]

So the specific "regression" that occured from RC7 to RC8 was the following code:

1. We removed the QT_AUTO_SCREEN_SCALE_FACTOR=1 from our launcher. This was done after complaints that the software was unusable (in contrast, @theluckyfellow's software appears to be usable, just ugly) too.
2. We added a Qt 5.6+ check in our C++ code here and toggled HiDPI support from within the App. To @oeai's point in #5376, now that it's controlled by C++, it can be toggled on/off. Unfortunately, we don't know if it'll be effective without the QT_AUTO_SCREEN_SCALE_FACTOR setting, so this requires testing.

What's a bit concerning is that the OP isn't mentioning if they're running the AppImage or not, meaning we may be chasing a unicorn here.

@theluckyfellow did you install from Mint or from our AppImage? Can you screenshot the About dialog?

[BryanEmmerson]

LMMI: 1.2.1 AppImage (Linux/x86_64, Qt 5.9.7, GCC 4.8.4) OS: Ubuntu 19.10 64-bit Screen: 13.3" QHD screen, running at 1920 x 1080 (40Hz)

Just for another data point, I am having the same issue, with the UI being very zoomed. I used the export QT_AUTO_SCREEN_SCALE_FACTOR=0 workaround above and it works fine.

I'm on a HP Spectre x360, which has some issues in Ubuntu with the high screen resolution (specs say 2560×1440 max.) I've largely worked around this by slightly zooming text in other applications to make it comfortably readable.

[tresf]

I have a newer Spectre I can test on. I think it runs Windows 10 at 300%, so should be a good candidate. I'll see what I get.

[tresf]

I'm able to reproduce this on my HP Spectre 360 running LMMS 1.2.1 Qt 5.9.7, Ubuntu 19.10 using X11 at the "natural" 200% zoom that Ubuntu chose for me.

I'm curious whether or not this issue occurs with all Qt versions. The fact that it occurs with a stock version of Ubuntu at 200% zoom is quite troubling.

I can say with certainty that this isn't as bad as the issues we had reported prior, but now I'm not sure what combination of settings we should be using moving forward.

I used the export QT_AUTO_SCREEN_SCALE_FACTOR=0 workaround above and it works fine.

Really? Not here. Check it out, it's horrible. This horrible experience is what the aforementioned patches aimed to correct.

The interface is absolutely too large, I can agree with that, I'm just not sure if this is something that the latest Qt will eventually fix. I don't think it's unusable, but I agree it's too big. Here's what it looks like on my Spectre with no changes to the environment:

[tresf]

Really? Not here. Check it out, it's horrible. This horrible experience is what the aforementioned patches aimed to correct.

Same with 1.2.0-RC6, 1.2.0-RC7 it's too small to be usable on a 13" display for both versions.

[BryanEmmerson]

Interesting. The difference could be that I'm running at 1920x1080.

With QT_AUTO_SCREEN_SCALE_FACTOR not set. This also makes it very hard/impossible to use any dialog windows, as they go off-screen:

With QT_AUTO_SCREEN_SCALE_FACTOR=0:

My 13" screen is a bit tough to work with for an application like this, but I feel the second one is usable.

Edit: Let me know if there are any settings (LMMS or system) that you would like me to check.

[tresf]

I'm running at 1920x1080.

I'm skeptical of that value as that'd be a standard 1080p resolution. Something's going on if HiDPI is affecting the experience. That must be your virtual resolution. I'm interested what your zoom is. Mine's 200% in Gnome Settings.

Interestingly I have a near identical problem to yours on my Ubuntu VMs running in Parallels (I have some VMs setup using HiDPI) so I'm sure there's a way to fix this, but I'm not really sure what's causing it to begin with.

[BryanEmmerson]

I'm a little confused as well. My resolution and zoom are 1920x1080 and 100%, according the Screen Display window:

I did have the Gnome desktop interface text scaling factor set to 1.25 to make things easier to read:

I reset this to 1, but the only difference is in some text areas (such as the menu bar):

I happy to work with LMMS as it is, but let me know if there is anything else I can do to help track down the source of the issue.

[he29-net]

I'm skeptical of that value as that'd be a standard 1080p resolution. Something's going on if HiDPI is affecting the experience.

A 1080p screen at this size definitely should be considered HiDPI: if you compute the DPI of a 1080p 13.3 inch screen, you get:

sqrt(1920^2 + 1080^2) / 13.3 = 2203 / 13.3 = 166 DPI.

Or, compared to the 96 "reference DPI", the correct scaling factor for such display would be 173 %.

In my opinion, the problem here is simply that both Ubuntu and Qt prefer scaling either to 100 % or 200 % and nothing between. Qt likely has a threshold at 150 % and rounds the computed scale factor to either 100 or 200 % depending on what is closer. I personally hate this "integer multiples" behavior, but I understand there is not really any other clean solution that would preserve the sharpness and quality of bitmaps, which are still very common in GUIs.

If you have a screen near the 150 % scale, it might be best to just let the user choose if they want to round up or down, depending on what they hate the most: UI that is too small to see, or too big to fit to the screen. Unfortunately, there seems to be no configuration standards -- every desktop environment does its HiDPI settings differently. So perhaps Qt may be falling back on its own DPI calculation, based on the pixel count and physical size of the screen, ignoring the user settings. So far it looks like the only reliable way to make sure the user always has a choice would be an override switch inside every app..

[tresf]

In my opinion, the problem here is simply that both Ubuntu and Qt prefer scaling either to 100 % or 200 % and nothing between.

The entire Linux desktop, actually. Fractional scaling isn't really supported on anything but Windows. MacOS handles this by controlling the hardware and defaulting to 2x on Retina (their name for the HiDPI displays). Linux is forced to try to emulate the Windows fractional scaling, which is a terrible experience.

So if it's a font-size caused issue, I think adding a toggle for the code snippet linked above will do it.

I'm curious if there's a Qt setting we're missing, or a case where we can handle both HiDPI and large fonts together.

[oeai]

i've opened surge synth source and they got GuiEditor https://github.com/surge-synthesizer/surge/blob/master/src/common/gui/SurgeGUIEditor.cpp so there is a template switcher for fonts and bitmaps and they use different workarounds for mac/linux/windows, but it is made in C++ i guess.

[tresf]

but it is made in C++ i guess.

Yes, it is, I see no references to Qt other than a note in the readme about potentially porting the UI over to Qt. If there are specific portions of that code you think will help, please point them out.

[oeai]

i think that creating profiles to make GUI bigger or smaller is a way that can solve it. So that code can be useful in terms of how they did it.

[theluckyfellow]

Fractional scaling isn't really supported on anything but Windows.

I just thought I'd let people here know that Linux Mint Cinnamon 4.6 is getting fractional scaling soon.

Please don't throw any rotten food at me; trying to be helpful. eeekk runs

[PhysSong]

Can we move to #2510?

[L00sedna]

This fixed the large lmms gui that occurs when dragging from a 24inch to a 22inch in a dual monitor environment. Hope it helps: echo "export QT_AUTO_SCREEN_SCALE_FACTOR=0" >> /etc/X11/Xsession.d/99gnome-qt

[elibiz443]

Had the same issue with my 1080 screen, and here is how I solved it.

In Terminal, run: cd /etc sudo nano environment Add:

QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=1

Then CTRL + O To Save And CTRL + X To exit

Restarted my computer, so as to load the new settings When I opened my executable file after that, it was all fine.

[Rossmaxx]

Was looking for something else but found this issue. Apparently, linux mint 21.2 has fractional scaling. Consider checking now (if you are still around using LMMS). Also, @michaelgregorius made a series of PRs to improve hidpi support. Might be helpful.

[farvardin]

My problem is somehow related, but reversed: I'm with 1920x1080 on a 14" screen and the interface was way too small, so I'd wanted to increase the UI and the fonts. So far I've managed to do this on all other applications, but LMMS was not usable. As a workaround, I've set my screen as HiDPI... Now it's fine but maybe a bit too big, so it's generally better to be able to fine tune the fonts and such :)

[michaelgregorius]

@farvardin, setting your screen as HiDPI worked because your screen actually is HiDPI. If my back of an actual envelope calculations are correct your screen should have a DPI of around 157.

I think we can even deduce how to correctly set the scaling of your system from that. Dividing 157 by 96 gives a ratio of around 1,63. So if you set the scaling of your system to something around 150% or even closer to 163% then you should be able to set your system font sizes to "sane" sizes a la 11pt and everything should display well (at least in applications that support HiDPI).

In general you can think of your screen as a HiDPI screen with a rather small viewport.

[musikBear]

@michaelgregorius How is it -Afair scaling UI is a nogo with qT, ot was it the issue with mutiplatform that blocked scaling? ( My usage of LMMS has next to halted, my eye-sight is simply not able to cope with LMMS horrible small fonts and display of value for buttons sliders etc. I get a headache after ½ hour or so SIGH

"A wise man said: It is rotten to get old, but the alternative is lousy"

[michaelgregorius]

@musikBear, I can only speak for my system but cannot comment on different/multiple platforms.

On my Linux system LMMS takes the system scaling of 125% into account and scales text and images accordingly. This applies to fonts that are defined in pixel sizes as well as the ones defined in point sizes.

However, the point fonts are mostly still just scaled up versions of a 7 pixel font. So it will still look something like a 7 pixel font on a low DPI display which is rather small.

The images are scaled in a very ugly way. I don't know if some computationally cheap algorithm is used by Qt or if it's not possible to get better results. Although my gut feeling tells me that scaling to 125% should be possible with nicer results. Would be interesting to experiment with SVG graphics although these might give unsatisfying results at lower resolutions/sizes.

As noted in #2510 some issues have been fixed and have gotten merged recently. Feel free to download a nightly and give some feedback.

P.S.: I am also slowly getting to an age where I realize that getting older is no fun. 😅

[farvardin]

@farvardin, setting your screen as HiDPI worked because your screen actually is HiDPI. If my back of an actual envelope calculations are correct your screen should have a DPI of around 157.

Apple's retina HiDPI is at 218 ppp it seems. It's difficult to tell the limit, but I feel like with HiDPI on my 14 screen, everything now looks a bit cramped, especially buttons, bars and such. I felt somehow better with HiDPI disabled and bigger fonts. But I understand that's not an easy question :)

[michaelgregorius]

@farvardin, do you mean cramped in general, i.e. also with other applications, or with LMMS in particular? The thing is that 14" is a rather small view port.

Let's say you have several displays of different sizes with different DPI. If you set the DPI correctly for all of them then this will make sure that text with a point size of 11 will have about the same physical size on all of them. If the text has the same size on all displays then you can obviously fit less text content on a smaller screen than on a bigger one.

Or put differently: if you want to put a lot of content on a small screen then everything needs to be scaled down but then it might become hard to read, e.g. due to small font sizes. If you want text and images to be larger then you cannot display as much content as with the previous option.

[he29-net]

I think the main takeaway from this conversation is that it's impossible to autodetect the best scaling factor for everyone, because different users may have different requirements.

A laptop user with 14" 1080p screen (157 DPI) probably won't appreciate a UI mostly designed for 1080p at 96 DPI being scaled at 2x, because there won't be enough space for comfortable work; since they are sitting close to the screen, they could prefer dealing with the smaller text.

On the contrary, someone sitting about a meter away from a 28" 4K screen (also 157 DPI) probably prefers readable text in exchange for losing some workspace.

Using fractional scaling could get us a good default value (157 / 96 = 1.64), but it would be still helpful to offer some user-friendly override for all the inevitable cases where out initial guess won't match the expectations.

---

Off-topic: Looking at the problem from another direction, there are actually two separate problems mangled together. First, the system should know and respect DPI of the screen, so that it knows what physical size are the elements it is drawing. This could (and should) be autodetected. Second, there should be a separate scaling factor, so that the user can scale everything up or down, depending on the device or their preferences.

In practice, all I ever see is single value: either DPI, or scaling factor. (There are sometimes extra options that only affect font size, but that just tends to break GUIs by bringing everything out of the correct proportions.) So if I want more work space on my 4K screen, I have to lie to the system about my DPI and set it to a lower value. Which works, but obviously breaks the wonderful ability to draw a 10 cm line and have it appear as a 10 cm line on the physical screen. Oh, the curse of three decades of fixed DPI design...

[michaelgregorius]

Second, there should be a separate scaling factor, so that the user can scale everything up or down, depending on the device or their preferences.

I think that separate scaling factor is exactly the scaling factor that's provided in the display settings of more and more systems. To my knowledge it scales everything, i.e. text and images, regardless of the point text size that has been set in the general settings. So if you select an 11 pt font in the settings and then move the slider then the text size will also vary.

In that case you can think of it as a slider that lets the users select the DPI values that used regardless of whether they match the physical DPI or not.

I think Windows tells you what setting is the recommended one. I guess it does so by checking the physical DPI and selecting the slider position with the "virtual" DPI that best matches the physical one.

[farvardin]

@farvardin, do you mean cramped in general, i.e. also with other applications, or with LMMS in particular? The thing is that 14" is a rather small view port.

It's cramped in general, but also in LMMS in particular. 1920x1080 divided by a 2 factor is like a 920x540, it almost like the first eeepc...

It's what I'm calling cramped:

But it's not much better on firefox

I think I'll go back to the non HiDPI screen. With a higher resolution even with a 14" (like on Apple retina), it would look more decent.

[Kitsune64]

LMMI: 1.2.1 AppImage (Linux/x86_64, Qt 5.9.7, GCC 4.8.4) OS: Ubuntu 19.10 64-bit Screen: 13.3" QHD screen, running at 1920 x 1080 (40Hz)

Just for another data point, I am having the same issue, with the UI being very zoomed. I used the export QT_AUTO_SCREEN_SCALE_FACTOR=0 workaround above and it works fine.

I'm on a HP Spectre x360, which has some issues in Ubuntu with the high screen resolution (specs say 2560×1440 max.) I've largely worked around this by slightly zooming text in other applications to make it comfortably readable.

I have put this line in the sh file that run lmms and it work.

[M4rotte]

Shall I tell them to fix all their own bugs too? "Found a bug, kid? Report it?! Why would you ever do that? Fix it yourself, kid!"

You should, if possible, make them understand they may do it, yes.

Why? Because it is the essence of opensource.

[mikelpr]

don't understand why this is a problem on linux (KDE, Plasma 6). I do not run into this problem with any other Qt 5 app

[tresf]

don't understand why this is a problem on linux (KDE, Plasma 6). I do not run into this problem with any other Qt 5 app

There may be more to it, but my general understanding is that the OS struggles with hard-coded font sizes. This is not unique to LMMS, many other applications struggle with HiDPI problems. What makes LMMS a bit more unique is that it suffers from a fragmented volunteer base, so no one person/team has swept the source code to standardize these decisions.

What's even worse is the issue is not nearly as noticeable on non-Linux platforms.

• For example, Windows uses a 1x render and just pixelates the interface on HiDPI. This is a degraded experience, but the UI components are sized properly.
• MacOS does not use any of these tricks yet still looks and behaves just fine at all scalefactors.
• Linux behavior varies depending on environmental factors, there's never been one patch to make this "good enough"; The problem will persist until the code can been fixed.

There's a lot of UI code, so help is appreciated with this effort.