Scaling issues on high DPI displays

[samkcarlile]

Edit: tresf, added checklist and workaround:

• [ ] Windows: - Partially working via d2e50df3ce2f8a56fd1750cc077eff3e76a6867d.
• [x] Linux: - Implemented via 8a39302571c96e130dd6db1f466011760fd7f1ec reverted. reimplemented bbedfa9. (Qt5.6+)
• [x] MacOS: - Implemented via 8a39302571c96e130dd6db1f466011760fd7f1ec

Unfortunately some HiDPI displays don't scale properly. There's more discussion around this here: https://github.com/LMMS/lmms/pull/4800#issuecomment-461681138

# HiDPI workaround for problematic screens
export QT_SCALE_FACTOR=1
export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_SCREEN_SCALE_FACTORS=2

Or permanently (use with caution!)

# HiDPI workaround for problematic screens
echo -e "QT_SCALE_FACTOR=1\nQT_AUTO_SCREEN_SCALE_FACTOR=0\nQT_SCREEN_SCALE_FACTORS=2" | sudo tee -a /etc/environment

---

This is my first time submitting an issue here, so If I'm doing it incorrectly, please let me know.

I'm on Windows 10 and would like to use LMMS, however, being on a Surface Book with a high DPI display, I can't comfortably use this software without squinting to see the various menu items and text. This application doesn't seem to scale when I scale Windows up. Is this a known issue or is it just me?

[tresf]

Known issue, unfortunately. Closing, marking as duplicate of #455, #2209, #1913, #82.

Edit: Reopened. :)

Quote from @BaraMGB

In the arch Linux wiki is an article which explains how to setup several desktop environments on hidpi resolution screens. This can help in the future for testing. https://wiki.archlinux.org/index.php/HiDPI

Quote from @michaelgregorius:

@Wallacoloo Yes, there are still several places where the fixed font sizes are used. For example in the song editor's tracks, also in lots of plugins and other places where custom widgets are used. I'd say there is still tons of work to do.

Here is a list of places where pointSize and pointSizeF are still called:

$ grep -l -r pointSize | sort | uniq
include/gui_templates.h
plugins/audio_file_processor/audio_file_processor.cpp
plugins/carlabase/carla.cpp
plugins/DualFilter/DualFilterControlDialog.cpp
plugins/ladspa_browser/ladspa_browser.cpp
plugins/monstro/Monstro.cpp
plugins/patman/patman.cpp
plugins/stk/mallets/mallets.cpp
plugins/vestige/vestige.cpp
plugins/VstEffect/VstEffectControlDialog.cpp
plugins/zynaddsubfx/ZynAddSubFx.cpp
src/core/audio/AudioAlsa.cpp
src/core/audio/AudioJack.cpp
src/core/audio/AudioOss.cpp
src/core/audio/AudioPortAudio.cpp
src/core/audio/AudioPulseAudio.cpp
src/core/audio/AudioSdl.cpp
src/core/midi/MidiAlsaRaw.cpp
src/core/midi/MidiAlsaSeq.cpp
src/core/midi/MidiOss.cpp
src/core/Track.cpp
src/gui/AutomationPatternView.cpp
src/gui/editors/AutomationEditor.cpp
src/gui/editors/PianoRoll.cpp
src/gui/PianoView.cpp
src/gui/SetupDialog.cpp
src/gui/widgets/ComboBox.cpp
src/gui/widgets/EffectView.cpp
src/gui/widgets/EnvelopeAndLfoView.cpp
src/gui/widgets/FxLine.cpp
src/gui/widgets/GroupBox.cpp
src/gui/widgets/InstrumentFunctionViews.cpp
src/gui/widgets/InstrumentMidiIOView.cpp
src/gui/widgets/InstrumentSoundShapingView.cpp
src/gui/widgets/Knob.cpp
src/gui/widgets/LcdWidget.cpp
src/gui/widgets/LedCheckbox.cpp
src/gui/widgets/MeterDialog.cpp
src/gui/widgets/MidiPortMenu.cpp
src/gui/widgets/ProjectNotes.cpp
src/gui/widgets/SideBarWidget.cpp
src/gui/widgets/TabBar.cpp
src/gui/widgets/TabWidget.cpp
src/gui/widgets/TextFloat.cpp
src/gui/widgets/VisualizationWidget.cpp
src/tracks/BBTrack.cpp
src/tracks/InstrumentTrack.cpp
src/tracks/Pattern.cpp
src/tracks/SampleTrack.cpp

Do you want to open a new issue for some of the remaining changes or reuse this one?

[musikBear]

@tresf Looks like all topics around this issue specific resolution on high-end screens/displays has been closed, or consolidated with font issues. Imo at least one with high-resolution monitors should be kept open. Some users even now has 4K monitors: http://lmms.io/forum/viewtopic.php?f=7&t=4843&p=15906#p15906 But are -every- 'normal' application not suffering from exact that same issue? How does anything, even Word, manage a 4K monitor? Surely this cant just be a LMMS issue. :confounded: I can only think of advising users with 4K monitors, to select a different general resolution. Can anyone suggest something better? Imo. Schedule 1.2.x

[tresf]

Imo. Schedule 1.2.x

Stop.

I can only think of advising users with 4K monitors, to select a different general resolution.

No.

Can anyone suggest something better?

Buy an Ultra-HD display and try some things for yourself. :) No, there's no easy workaround here.

How does anything, even Word, manage a 4K monitor?

Perfect(ly).

But are -every- 'normal' application not suffering from exact that same issue?

No, they don't. Install QT Linguist on Windows. It does not suffer this scaling problem.

Some users even now has 4K monitors:

The exact resolution is immaterial, the fact that it doesn't scale is the problem.

@tresf Looks like all topics around this issue specific resolution on high-end screens/displays has been closed, or consolidated with font issues.

Yes, we've been making progress on some fronts by removing hard-coded values, but they still may be wrong as we aren't testing each CSS patch with the super-HD folks in mind.

But why are you resurrecting this topic specifically? And why tagging me? If you read them all, you'll find that QT5 is supposed to help this. We need more QT5 testers to confirm. We also need to decide if moving Windows and/or Mac to QT5 is sensible/feasible, but that carries its own tasks... You see... QT4 is available via Homebrew, Macports and via Toby's Ubuntu PPA which we then package into our desktop installers. The switch to QT5 will require these steps are taken to properly fetch and then package the libs for Mac and Windows OS. The library names changed a bit and I'm not sure we're ready for this in the middle of a stable release. It's not something we'll do before 1.2 and it's certainly not something we'll track in a scaling issues thread. :beers:

I suppose if we don't have ANY open bug reports on High DPI/Large Font support we can reopen this one.

[tresf]

@musikBear here's what LMMS looks like on Windows 10 running scaled desktop...

• :white_check_mark: File/Menu bar does scale
• :white_check_mark: MDI window titles do scale
• :no_entry: Images do not scale
• :no_entry: Fonts do not scale

[tresf]

More resources...

http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/ http://doc.qt.io/qt-5/highdpi.html

[tresf]

Edit, Qt5 alone does not fix this problem...

LMMS built with Qt5 running on Windows 10 hi-res display:

[musikBear]

Very good explanation. Thanks! :gift:

[tresf]

I created a graphical representation of what works and what doesn't based on overlaying 100% with 125%. This should help understand where the problems stem from and how to start identifying them and eventually fixing them.

It appears ALL pixmaps are drawn at their natural size, so that may be a fix-it-everywhere type patch.

Some Qt items, such as minimize and close buttons are out of our control and we'll have to live with what the framework gives until it is patched upstream.

Obvious but

• :white_check_mark: Green = Scales properly.
• :no_entry: Red = Does not scale properly.

Font/Zoom Factor: 100%

The raw data...

Font/Zoom Factor: 125%

[IvanMaldonado]

Yo, where can I find the fork to test lmms with qt5?

[tresf]

No fork needed.

Just export QT5=True should do the trick .

All of our wiki tutorials have been updated to reflect this.

[IvanMaldonado]

When or where do I have to do that?

I followed the instructions on https://github.com/LMMS/lmms/wiki/Compiling-lmms (Using Qt5) and it didn't work for me, since the only time I use cmake is in "cmake ../" that's where I put the flag.

[tresf]

export FOO=bar is quite common on Linux, it really needs no explanation.

Your system has to have Qt5 available of course, but I'd rather not use a bug report about HiRes support as a Q/A for a tried and true build process. Can you move your questions to the Qt5 thread please?

[tresf]

Some more interesting information... (I tried this without much success, but I'd like to hear feedback from others... )

Scale factor of 200%, Qt 5.4 or higher required

#include <QtGlobal>
qputenv("QT_DEVICE_PIXEL_RATIO",QByteArray("2"));

The article also claims that export QT_DEVICE_PIXEL_RATIO=2 works too, but I couldn't get it to work on Windows or Mac.

Allow high-dpi pixmaps, Qt5.1 or higher required

QApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true);

And to prevent crashes on older Qt versions...

#include <QtGlobal>

#if QT_VERSION >= QT_VERSION_CHECK(5, 1, 0)
    QApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true);
#endif

References: http://blog.davidedmundson.co.uk/blog/kde_apps_high_dpi http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/

[tresf]

Some additional information on this topic:

http://doc.qt.io/qt-5/highdpi.html

Microsoft Windows

Scaling

The user can choose a scaling factor from the control panel or via context menu. This works by making the functions for querying the system metrics return different values for standard font sizes, sizes of window borders, and so on. It does not perform any actual scaling.

DPI Awareness

An application on Windows can assume one of the following levels of "DPI Awareness":

DPI Awareness Level	Meaning
DPI Unaware	This level has been introduced in Windows-Vista. Windows will pretend to the application that it is running on a standard display of 96 DPI of 1920x1080 and scale the application accordingly. It is intended to accommodate older applications designed for low DPI displays. Some artifacts may result from this type of scaling.
System‑DPI Aware	This level has been introduced in Windows-Vista. It differs from Per-Monitor DPI Aware only when multiple monitors are connected. Windows will calculate a scaling suitable for all connected monitors.
Per‑Monitor DPI Aware	This level has been introduced in Windows 8.1. Windows does not perform any scaling at all.

Qt applications by default are Per-Monitor DPI Aware on Windows 8.1 or System-DPI Aware on older versions of Windows. As of Qt 5.4, the level can be specified by passing a parameter to the platform plugin (see Using qt.conf):

<application> -platform windows:dpiawareness=0,1,2

[tresf]

An interesting photoshop write-up which allows a Windows application to notify the OS of dpi-awareness through an exe manifest file:

http://neoshamon.blogspot.com/2015/06/adobe-app-scaling-on-high-dpi-displays.html?view=sidebar

[zapashcanon]

I would like to add two things.

First, I'm not sure, but as I didn't saw it mentioned, it's the case on linux too:

And, in the @tresf's graphical representation, the menu is already in red, but there's also another problem with icons:

[michaelgregorius]

@zapashcanon From the attached screenshot I take that you are running a resolution of 2880 × 1800? I assume that Qt checks the resolution and DPI value and then decides to scale all icons to twice their size. It seems that our menus can't cope with that due to some hard coded values either in the CSS or in the code itself.

[zapashcanon]

Yes, it's 2880 * 1800. And yes, I think it's probably something like that.

[ghost]

Same problem on 4K (3840x2160)

[BenMcLean]

This issue also affects me as a visually impaired user even at normal 1080p. I have to use Windows Magnifier to be able to read most of the text.

Fixing everything so that it scales properly should fix it not only for the 4K people but for users with visual disabilities too.

[BaraMGB]

@BenMcLean providing Screenshots of your issues could help us, perhaps.

[tresf]

@BaraMGB we've identified the poorly scaling items here: https://github.com/LMMS/lmms/issues/2510#issuecomment-193475365. Anything that doesn't scale with the display also will not scale with accessibility features which increase font size, etc.

[BenMcLean]

Yeah, I wasn't raising any new issue: the screenshots above show it. I was just pointing out that fixing this will help more people than just the 4K crowd.

[jcward]

Yes, the HIDPI situation in 1.1.3 is not good. I have a Surface Pro 3, which is 2K x 1440, 12", 216 dpi, and LMMS looks like the above to me.

And just wrt Windows OS built-in scale setting: Yes, you probably should respect the OS setting... But 1) changing that setting sucks and makes all your programs look weird, and 2) you're not going to please everyone, so...

I'd argue for an in-app "UI Scale" parameter. Multiply it with the OS setting to allow user tuning. Pianoteq does this, and it can result in fuzzy graphics, but it sure as heck beats being completely unusable. Another example -- most browsers can zoom webpages also.

A one-size-fits-all OS-level setting is not enough.

[tresf]

A one-size-fits-all OS-level setting is not enough.

This is residual. The code needs to be fixed and it's quite a large task. I invite anyone with the ability to help to please jump in on this task. The components that need fixing are identified here: https://github.com/LMMS/lmms/issues/2510#issuecomment-193475365. Bugs can be in C++ code or in the style sheet or both.

[tresf]

A workaround for Windows is available here: #3531, ready for testing.

This does not fix HiDPI support but rather creates a workaround by telling Windows to scale the entire UI by making LMMS as non-HiDPI capable, a compatibility feature flag which should make it large enough to use on a high resolution display.

[ghost]

Added 1 line to source code, compiled LMMS with Qt 5.9, set an environment variable, and boom:

(See #3558)

[ghost]

Please note that you need at least Qt 5.6 to use Qt.AA_EnableHighDpiScaling and QT_AUTO_SCREEN_SCALE_FACTOR

[tresf]

@flynn16 currently, we pass environmental variables to LMMS here: cmake/linux/lmms.desktop#L11. Would you be willing to create a Pull Request with this feature enabled? We'll (I'll) also need to add it to our AppImage desktop file as well.

[tresf]

@flynn16 thanks for the information, we'll get this added for the next release candidate.

I added that line to gui/GuiApplication.cpp. I compiled a LMMS AppImage with Qt 5.9. Then I set an environment variable:

$ export QT_AUTO_SCREEN_SCALE_FACTOR=1
$ ./LMMS-x86_64.AppImage

The beautiful GUI showed up. (Ubuntu 16.04)

[ghost]

Tres is looking for Mac testers. If you have a Mac computer with a Retina display, you can subscribe to #3814.

[tresf]

@flynn16 thanks for the work on this. I've updated the original bug report to reflect our progress on this feature.

[fractalbach]

Just got lmms, noticed this issue, read https://github.com/LMMS/lmms/issues/2510#issuecomment-330323872 and tried it.

System

Before

./lmms*.AppImage

After

export QT_AUTO_SCREEN_SCALE_FACTOR=1
./lmms*.AppImage

[tresf]

Yeah unfortunately for dual (mixed DPI) displays there have been issues, so it's toggled off for now. macOS is the only platform making use of true HiDPI. Windows is using scaling and Linux is disabled.

[ghost]

Yeah unfortunately for dual (mixed DPI) displays there have been issues, so it's toggled off for now. [..] Linux is disabled.

On Kubuntu, there are two environment variables controlled by the DE to reflect scaling settings: QT_SCREEN_SCALE_FACTORSand QT_AUTO_SCREEN_SCALE_FACTOR`

QT_AUTO_SCREEN_SCALE_FACTOR=1 tells Qt to calculate a scale factor on their own. However, this calculation is not always accurate, so QT_SCREEN_SCALE_FACTORS exist as a fallback. QT_SCREEN_SCALE_FACTORS are the scale factors for each monitor identified by its xrandr name. When QT_SCREEN_SCALE_FACTORS are set, QT_AUTO_SCREEN_SCALE_FACTOR must be set to 0.

Therefore, if you want to scale any Qt 5.6+ application, consider setting these environment variables. I set my scale factor to 2.5 via Plasma settings, so Plasma sets the following environment variables every time it starts.

$ export | grep -E 'QT.*(SCREEN|SCALE)' declare -x QT_AUTO_SCREEN_SCALE_FACTOR="0" declare -x QT_SCREEN_SCALE_FACTORS="eDP-1=2.5;HDMI-1=2.5;"

To find your monitor names, run

$ xrandr --props | grep -E '(dis)?connected'

[tresf]

export | grep -E 'QT.*(SCREEN|SCALE)'
declare -x QT_AUTO_SCREEN_SCALE_FACTOR="0"
declare -x QT_SCREEN_SCALE_FACTORS="eDP-1=2.5;HDMI-1=2.5;"

This helped. I added the QT_SCREEN_SCALE_FACTORS with a value of 1.5 to my /etc/environment file and it helped. I'm running the 1.2.0-RC7 AppImage, which uses Qt 5.9. Has this improved in newer Qt versions? I notice that on Ubuntu 18.04, the font scaling has issues with more than just LMMS. For example, Discord's text is a bit too small to read and the Accessibility settings don't affect web pages, just the OS-fonts like window titles and the terminal.

[TheGrandmother]

The above solution worked for me. Since I don't want to faff with my /etc/environment i just created the following shell script:

#!/bin/bash
export QT_AUTO_SCREEN_SCALE_FACTOR="0"
export QT_SCREEN_SCALE_FACTORS="eDP-1=2.5;HDMI-1=2.5;DP-0=2.5"
.<absolute path to lmms App image>

Then i just did a chmod +x <script name> and made a symlink in /bin/ to it and it works like a boss.

This solution will not affect other applications since the changes to the env variables will only apply to stuff run by this shell script.

Note that you have to add all your connected monitors to QT_SCREEN_SCALE_FACTORS in order to make it work with all connected monitors.

[musikBear]

@TheGrandmother Thanks for sharing!

[PhysSong]

As https://github.com/LMMS/lmms/pull/5098#issuecomment-515743076 shows, it seems like QT_FONT_DPI also affects some components. Try this:

export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_SCREEN_SCALE_FACTORS=2
export QT_FONT_DPI=48
lmms

[PhysSong]

As long as I've found:

• QT_SCALE_FACTOR affects both font size and scaling factors, on all monitors
• QT_SCREEN_SCALE_FACTORS affects only scaling factors, per-monitor
• QT_FONT_DPI has effects on X11 platforms only

[Glitchy-Tozier]

Hey everyone, I just wanted to mention that this is a really bad problem which makes lmms feel unusable on big screens. And on Linux, as far as I know, there isn't even a scaling-setting you can use the relief yourself of some pain.

You can't even read the settings and dial-descriptions. Screenshot: (it looks the same when using the default theme)

[musikBear]

@Glitchy-Tozier -im afraid that your screenshot is not even showing the problem. Your screenie shows a 'perfect' scaled UI. Insufficient scaling looks like this: -And that is solved in >1.2.1. What your screenie shows is that LMMS has simply has way to small text in general, but that is a different issue, and is of cause related to accessibility, -but also general usage, because text that small does lead to headache and other ergonomic issues

[Glitchy-Tozier]

@musikBear I see, I guess I named it the wrong way / posted in the wrong thread. Hope the text gets corrected soon as well. Rewriting the .css file unfortunately doesn't help with some texts like the one in the settings. Anyway, I'll stop posting here.

[AaronRecord]

On my Windows 10 laptop using v1.2.1, things are the right size, but they're blurry (notice how crisp the system font is compared to the LMMS text):

Here's a zoomed in version:

[BenMcLean]

I agree with @LightningAA that it would be desirable to have an option to turn off anti-aliasing on the fonts.

[Spekular]

Anti-aliasing isn't the issue, the system fonts are also anti-aliased. The issue appears to be that our fonts are rendered at a lower size and then scaled up. For non-integer scaling this will result in interpolated pixels.

The issue occurs when a scale other than 100% (including 200%) is set in Windows settings ("Make everything bigger"), both in 1.2.2 and a recent master build.

For comparison, I tested a few other programs:

• Audacity, Spotify, and MusicBee scale poorly (same as LMMS)
• Telegram doesn't change at all
• Blender scales nicely

[tresf]

Anti-aliasing isn't the issue, the system fonts are also anti-aliased. The issue appears to be that our fonts are rendered at a lower size and then scaled up.

Agreed however this is because -- on Windows -- the version of Qt we ship with the installers is just a bit too old to support HiDPI, so I use a registry hack instead.

https://github.com/LMMS/lmms/commit/d2e50df3ce2f8a56fd1750cc077eff3e76a6867d

Disabling the registry hack will fix the blurriness, but the entire interface will be too small to use. The issue can be resolved when our Windows installers ship with a modern Qt version which can handle this.

[musikBear]

lmms simply needs a general font scaling feature Like (AAS-edit)

-Or at least what Audacity has

I honestly has issues working with lmms now....

[tresf]

lmms simply needs a general font scaling feature

Perhaps, but that's not what this bug report is about.

[PhysSong]

The issue can be resolved when our Windows installers ship with a modern Qt version which can handle this.

master uses 5.9(MinGW)/5.12(MSVC) for Windows installers, so we can use modern Qt features in 1.3 series.