lmms
lmms copied to clipboard
LMMS
Scaling issues on high DPI displays
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?
~~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
pointSizeandpointSizeFare 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.cppDo you want to open a new issue for some of the remaining changes or reuse this one?
@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
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.
@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
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
Edit, Qt5 alone does not fix this problem...
LMMS built with Qt5 running on Windows 10 hi-res display:
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%
No fork needed.
Just export QT5=True should do the trick .
All of our wiki tutorials have been updated to reflect this.
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.
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?
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/
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
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
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:
@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.
Yes, it's 2880 * 1800. And yes, I think it's probably something like that.
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 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.
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.
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.
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.
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.
Added 1 line to source code, compiled LMMS with Qt 5.9, set an environment variable, and boom:
(See #3558)
Please note that you need at least Qt 5.6 to use Qt.AA_EnableHighDpiScaling and QT_AUTO_SCREEN_SCALE_FACTOR
@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.
@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.AppImageThe beautiful GUI showed up. (Ubuntu 16.04)