Fix scaling of PixmapButton in layouts

[michaelgregorius]

Fix the scaling of PixmapButton when used in layouts. In this case PixmapButton::sizeHint is queried which used devicePixelRatio to divide the size of the active pixmap. As a result the size is always the same in pixels regardless of the scaling factor of the application. This is fixed by removing the calls.

Example: If the scaling factor is 2 then the pixmap will also report twice the size in pixels and hence request more space in layouts, etc. However, if we divide by the device/pixel ratio then the original size of the image/pixmap will be reported and therefore it will be too small in layouts.

The calls to devicePixelRatio have been introduced with pull request #4950 (via commit c3b4d51) which replaced the old Spectrum Analyzer. The pixmaps of the Spectrum Analyzer still look good with this change.

Can be tested on any system by building LMMS and then starting it with:

QT_SCALE_FACTOR=2 ./lmms

Fixes #7052.

[he29-net]

The division by devicePixelRatio() was added to support high resolution bitmaps used first in Spectrum Analyzer. They are generated at runtime directly from SVG, resulting in sharp icons drawn at native resolution.

Without this division, the sizeHint() returns a value that assumes it's a standard "96 DPI pixmap". Qt presents everything in "logical pixels", so the 2x (or other) scaling factor is included in the reported pixmap size – ignoring the fact it is already rendered at 2x scale, so the bounding box should not be scaled up again.

This is how it looks before / after this PR:

Not that terrible (the layout absorbed the extra space quite gracefully), but it leads to wasted space (both windows are at minimum size) and weird spacing between control elements.

I'm thinking maybe it could be solved by a native or high_res flag for the pixmap button, which informs it whether the size needs to be adjusted or not. I didn't think it was needed, since I did not run into any issues when testing the Spectrum Analyzer (→ sorry, it was me who introduced the bug in the end :) ). Probably because most of the GUI used fixed placement without layouts at the time, so the issue had no opportunity to surface.

[michaelgregorius]

Sorry @he29-net, I was not aware that some other elements of the dialog also use the PixmapButton. Because I was in a context of "the LED buttons are too small" I had only checked these. 😅

I am not really sure if such "knowledge" should go into the PixmapButton. For me the PixmapButton is a class that can be configured with two pixmaps and which displays either of these depending on its state. It should not really care about how these pixmaps came to be. So if it is possible the correction should be along the line of "SVG -> Pixmap" IMO.

[he29-net]

For me the PixmapButton is a class that can be configured with two pixmaps and which displays either of these depending on its state. It should not really care about how these pixmaps came to be.

Yeah, that makes sense, a custom class derived from QPixmap would probably be a better place to handle the correction. As a bonus, it could then be used for other GUI elements as well.

Although I'm not sure if that would be the right way forward for LMMS-wide native scaling, since it feels like a bit of a hack: it just counteracts what Qt really wants to do, which is scale all physical-pixel dimensions by a constant. It does not tie into all the other bells and whistles; for example, the SVG gets rendered only once during initialization, so if the application dynamically changes scale when moving between HighDPI and standard screen, the pixmap won't not refresh. It just receives some form of "dumb scaling" and ends up blurry (or otherwise mangled) anyway.

Last time I checked the SVG icons were also broken on our Windows builds due to a missing Qt SVG library, so if that issue still persists, the easiest solution may be to simply fall back to standard pixelated icons in the analyzer until we have a "proper" solution that could be applied to everything (which in practice probably means Qt 6 or something).