Scaling issues on high DPI displays #2510
Comments
|
Edit: Reopened. :) Quote from @BaraMGB
Quote from @michaelgregorius:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@musikBear here's what LMMS looks like on Windows 10 running scaled desktop...
|
|
Edit, Qt5 alone does not fix this problem... LMMS built with Qt5 running on Windows 10 hi-res display: |
|
Very good explanation. Thanks! 🎁 |
|
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
Font/Zoom Factor: The raw data... Font/Zoom Factor: |
|
Yo, where can I find the fork to test lmms with qt5? |
|
No fork needed. Just 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. |
|
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 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);
#endifReferences: |
|
Some additional information on this topic: http://doc.qt.io/qt-5/highdpi.html Microsoft WindowsScalingThe 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 AwarenessAn application on Windows can assume one of the following levels of "DPI Awareness":
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 <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 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. |
|
The fixes for the elements mentioned in this comment are now also merged via #6789. So the setup dialog changes shown here are the last of the batch. But it looks like they need some more adjustments. |
|
Did something change in the way we build AppImage between versions 1.2.2 and the current nightly builds? I wanted to check out the latest fixes, since the fix in Sample Track seems to introduce two very different font sizes into the same window, which doesn't look that great. So I wanted to test it on my system, and I found that the nightly AppImage does not scale at all for me:
Using banana for scale, you can see that the 1.2.2 fonts are uniform in size and properly scaled for a 4K screen (maybe a bit larger than needed if anything). Not only that, but if I drag LMMS to a lower resolution laptop screen, it detects the difference in density and scales down. So 1.2.2 works perfectly (at least for a scaling method limited to integer multiples). With the 1.3 nightly, no scaling is applied except for the OK / Cancel button labels and the main menu, and nothing changes when I drag the window to a different screen. The buttons in Song-Editor are aware that the Playing around some more, I realized this probably matches the appearance common in screens from @michaelgregorius (most of GUI not scaled, and non-fixed-size fonts being notably larger than everything else) that I never managed to replicate on my system until now. I can finally experience the issue you have been dealing with the whole time. :) When I build locally from the source, LMMS always behaves like the 1.2.2 version (apart from the automatic scaling when dragging to a low-res screen, that does not work). And I have no idea how to build or debug an AppImage, so I'm not sure where and how exactly should I look for the root cause of this difference. Environment variables exported before running the AppImage do seem to have some effect, but so far I had no luck replicating the 1.2.2 behavior (which seems much more "release-ready" compared to current nightlies). |
If anyone is interested why my desktop looked as described here's a coarse description of the setup at the time:
It seems that with this configuration images were not scaled at all (due to the 100% setting) but text was still scaled according to the DPI value. Therefore all images/pixmaps looked small compared to text. Only recently I had to reinstall my system and now I am not using the DPI arguments anymore. Instead I use the fractional scaling that's provided by Plasma. It is set to 125% and now I can also enjoy images/pixmaps that are scaled in ugly ways as well as flickering sub window borders when they are being moved. See here for an example:
Note for example the missing light gray border on the left side of the window. It appears and vanishes when the window is being moved, hence the flickering. Almost all elements look ugly now: knobs, LED numbers, gear icons, button images. The button on the top right flickers when I move the right window border. In general it seems that HiDPI is still a mess under Xorg/Wayland/Qt. I mean, why did I even have to specify the DPI explicitly in the first place? Shouldn't Xorg know best how to find out the DPI and provide that information to Qt?
I wonder if AppImage builds can include environment variables and if both build are configured with different ones which then steer Qt in different directions. Perhaps the new builds have been configured to work around fractional scaling due to the issues shown above. However, I don't know much about AppImages and unfortunately I wasn't able to find out where their builds live. |
|
@he29-net, can you please show how the elements that have been fixed so far look in the 1.3 AppImage on your 4K screen? This would for example be:
|
|
@michaelgregorius Sure. I had to do the screenshots on the smaller screen (because imagemagick cannot grab the screen when a menu is open, and Kazam refuses to store anything on the main screen for some reason), but the proportions are the same (i.e. the big text is properly sized, everything else too small). System is Debian 12.1 + Xfce 4.18 with DPI set to 155. The mixed scaling also happens in the Spectrum analyzer, as you reported in #5088, just with even larger difference in font sizes. The Add effect dialog is also a bit wonky: all the fonts are scaled up, but the window itself has a default size that does not scale with DPI, so it looks really tiny. I think that is a common problem with many similar windows as well (same goes for the side panel, which is too narrow by default and cuts off the check box labels). As for the fractional scaling, yeah, that looks pretty terrible. Maybe if we only allowed 1x / 1.5x / 2x, it would be more acceptable, but the only good solution is probably to draw everything from vectors, and that's going to take quite a bit of effort. Meanwhile, there are other small bugs even with the "2x fallback scaling" done by the 1.2.2 version, like the borders of combo boxes (2x scale vs. 1x scale for comparison): Taking care of all things like that seems like a major GUI rework, so I think for 1.3.0 it would be better to just focus on making the scaling at least "acceptable" and "consistent". And either aim the "proper scaling" for 1.4.x, or 2.0 (along with single-window mode, since that's also a complete GUI rework, so might as well do everything at once). |
|
Thanks @he29-net! This looks as expected then. All the remaining small elements are likely caused by:
The way forwardI think the way forward is:
Places where pointSize is usedCurrently the
EffortAs you have already noted this will be a ton of work. This first set of fixes were mostly low hanging fruits, except for the setup dialog. The goal was to make the application at least a bit more usable on HiDPI screens. Example for the introduction of layoutsSome while ago I have started hacking on the effects boxes so that they also work with layouts. Their name labels use a larger font now and they elide the name if it is too long. Ideally they should be horizontally resizable. They currently look as follows in my branch:
"Add effect" dialog and side panelOne option might be to resize the "Add effect" dialog according to the screen size when it is opened. The dialog is resizable, so it might also be a good idea to store its last size when it's closed so that it later opens at that size again. The same applies to the side panel. It it likely initialized with a pixel size instead of for example a percentage of the available width. On my screen I can fully read the check boxes but because you have a higher DPI screen (155 DPI vs. 117 DPI) the fonts are made bigger relative to the fixed pixel width and hence they are cut off on your screen. |
Not a whole lot, although in my experience, the Qt version we bundle can drastically influence the behavior, so it may be worthwhile to baseline compare the Qt versions.
@PhysSong offered some debugging steps here: #4286 (comment), the relevant parts are:
Since There's also a small chance that the |
…youts Solve the HiDPI issues of the setup dialog (#2510)
|
The fix for the scaling issues of the setup dialog (see here) has been merged via pull request #6779. This might be of interest for @Glitchy-Tozier who has mentioned the problem. |
|
I have opened #7159 which might fix the text scaling issues but i don't really have time to confirm it. Would appreciate if someone gives a heads up. |
|
Does anybody know if all of the targeted system (Linux, Windows and MacOS) have a notion of global (fractional) scaling? If they do, does the scaling apply to all of the following elements in a Qt application?
Windows has support for fractional scaling and Linux also seems to be gaining support for it, e.g. via Wayland. Does MacOS also support this? If all system supported global fractional scaling (for all of the elements listed above) then the solution might be to follow these rules:
With global scaling the way forward to fix the problems with HiDPI would be to either use flexible, scalable widgets that can take different font sizes as preferred by the user or use hard coded widgets with text sizes set in pixels. More details can be found in #7178. There's also a screenshot which shows problematic elements in the GUI that need work. The quickest fix for some of these elements might be to use |
|
Pull request #7185 should fix most scaling issues for users that use global fractional scaling. It for example fixes #7178 and does so in a consistent way. There is still room for improvement though as it might still be desirable to have a flexible GUI that can scale, e.g. for users that cannot use global fractional scaling. If wanted the items that are described below can also be turned into potential tasks of a new project. Areas for potential improvementsI have identified the following areas that could be worked on. The gist of it is that the individual plugin GUIs likely cannot be changed if they are not reimplemented completely. Several other areas outside of the plugins could be adjusted though. Mixer channel viewThe name of the mixer channels is still presented using a pixel sized font. It should be attempted to switch it to a fully dynamic layout, so that it can also be defined using a point sized font.
Automation editorThe automation editor uses a pixel sized font to display the min and max values on the left size of the editor. Might be switched to a point based size.
Piano rollThe piano roll uses a pixel sized font to display "Note Velocity" and "Note Panning" on the lower left side of the dialog. Might be switched to a point based size if everything around this area can scale accordingly.
Instrument dialog:This is the dialog that displays the different instruments. It shows the following information:
It should be attempted to reimplement the instrument dialog using layouts so that only the actual instrument GUI is displayed at it's fixed size. Everything else around it should be resizable and implemented using layouts. This is a rather big undertaking though but could also make the instrument window much more attractive as it could use more real estate to display the different aspects, e.g. envelopes and LFOs.
Effect viewIt should be attempted to switch the effect view to a dynamically layouted implementation so that the view that shows the effects can be resized as well. Some time ago I have attempted to do so (see screenshots at the bottom here) but have not continued yet. This will also involve the effect chain list though. Therefore it has a dependency to the changes made to the instrument dialog because this dialog also shows an effect chain and ideally it should also be resizable.
WidgetsThere are several custom widgets that use hard coded sizes and rendering. Due to this they cannot be used sensibly in layouts, i.e. they do not scale. For each of these widget there should be an alternative version that can use points size fonts and that can scale accordingly. In some cases it might be enough to inherit from an existing Qt widget, extend it with the additional functionality and to style it via a style sheet. The widgets are (each under
If possible the old non-scalable widgets should be removed so that they do not get used in the future. Widgets that are used in the context of the plugins with fixed sizes cannot be removed though. It should be attempted to isolate the classes to only the plugins and make sure that they are not used outside of this context. PluginsThe plugins can be found under |
Not officially, no. AFAIK, all displays that they ship use integer scaling, so this would be more common with Hackintosh laptops or perhaps some oddball external displays. |
Thanks for the info @tresf! So the idea is that Apple sells displays that are close to multiples of 96 DPI so that users can scale with an integer factor? And people who use other hardware must live with the consequence of everything being either a tad too small or too large? |
|
I have a branch where the instrument window currently has the following layout: The idea is that the individual instrument design is always visible and that the other options which shared by all instruments are shown right next to it. This design makes more use of screen real estate and less clicks are needed to sculpt a desired sound. The next step would be to make the tabs appear less crammed by using layouts where they are not already used so that the dialog all in all becomes more scalable. The other layouts would likely be redesigned to give more breathing space. Is it feasible to continue in this direction? |
Correct. They do offer accessibility setting to increase font sizes, but as is the norm with Apple, anything outside of the hardware that they ship requires unofficial 3rd-party software. Oddly, I've never had scaling issues with Qt apps on Mac (LMMS included), so this strategy has been effective in my opinion. |
|
I remember @LostRobotMusic ranting about how every instrument has the same envelope setting. Michael's unification approach (two messages above this one) looks helpful. Perhaps it would even make sense to remove the seperate envelope tab and Integrate it per instrument but that's a rather huge change. |
Envelopes should not be like this |
No, I said absolutely nothing of the sort. What I have been ranting about is that LMMS's envelopes are strictly linear which sounds extremely awful, the time it takes to drop from 0 to -6 dBFS is the same amount of time as it takes to drop from -6 to -infinity dBFS. This is one of the main contributing factors behind people making the claim that LMMS simply "sounds worse" than other programs. I never once expressed any opinions against LMMS's instruments coming with an envelope supplied by the DAW itself. |
Slightly off-topic.... I've mixed feelings about the overall layout, but "front-and-center envelope" I think is a win-win (both for newcomers and seasoned users). |
@tresf, are you referring to the current "old" layout or the new one? If it's the latter what gives you the mixed feelings? In my opinion the current instrument screen is much too small and hides too much information. Compared to some VSTs that strive to have everything quickly accessible on one screen it takes much more clicking to get the same things done in LMMS' instrument dialog. The design above also isn't meant as the ultimate implementation anyway. The idea would rather be to start moving into a better direction and get a more and more improved solution via incremental steps. In the end this might even result in a complete redesign which shows all envelopes at once and that redistributes the other elements. Technical motivations for a redesigned instrument dialogThere's also a technical motivation to change things. The current implementation of the instrument dialog uses LMMS' own IMO one goal should be to get rid of LMMS' own non-scalable widget implementations and to replace them with styled Qt widget wherever possible. This was for example done in the screenshot above with regards to the tabs. They are using a styled |
It's just aesthetically worse. Much more dead space in the interface, controls stretched to places they don't belong, LMMS-themed controls next to plugin-themed controls. I understand that it's no small task to rearrange the plugin controls for the future, but this side-by-side looks more like a deconstructed sandwich because it's obvious that it's an explosion of its parts. A bit extreme (and in my opinion, over simplified) is @budislav's mockup. See "instruments and effects" section here: https://www.behance.net/gallery/194917259/LMMS-Redesign-Concept. ( Many will argue that this will take the branding out of our plugins (this statement would be true). There may be a way to marry the ideas, but I find the existing "background plugin artwork" as a base for the panel-size to be a regression. I can't argue its utility, but I do not think the tradeoff is worthwhile. I hope that is clear and that this is not intended -- in any way -- as a way to minimize the effort involved. The community is always indebted to those that care enough to fix and improve things. ❤️ |
Yes, I believe this summarizes it best on a technical level. |
|
Thanks for you input, @tresf! I appreciate it! Let me first emphasize that the design above is not meant to be final. It is meant as a proposal for a direction to solve the problems of the users (and also of some of the code). With that in mind I'd like to address some of your remarks:
At least technically the dead space could be removed by moving the controls at the top (Vol, Pan, ..., Save) to above the plugin window. Although that might not make sense logically.
That's the current nature of the thing, also with regards to how it is implemented. The only thing the plugin provides with regards to the GUI is the individual plugin window. Everything on the right is implemented in the underlying instrument base classes and therefore it also looks the same for every plugin (but also different from most plugins).
No, it is definitively not a small task and that's the exact reason why I am advocating for small steps into the right direction even if none of the steps may be "perfect" and might have its "warts". The important thing would be that each of the step improves upon the previous steps.
I agree that the fixed plugin artwork/GUI size is a hindrance. It pains me to see that new plugins like SlicerT have to be crammed into that small space, limiting the functionality they can provide. Some proposals to marry both ideas would be:
Finally, I think what's most important is that some sort of direction is given, e.g. in the form of a project that describes the goal, the strategy and its intended steps. Because no one wants to go through all these steps without being sure that all the work will not be done in vain.
Yes, it is. 🙂 |
|
The envelope and LFO graph are now both scalable. So the design proposed here #3067 (comment) would be possible now. |
and others
Edit: tresf, added checklist and workaround:
8a39302reverted.reimplemented bbedfa9. (Qt5.6+)Unfortunately some HiDPI displays don't scale properly. There's more discussion around this here: #4800 (comment)
Or permanently (use with caution!)
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?
The text was updated successfully, but these errors were encountered: