VSTs not scaled properly on HiDPI displays

[tresf]

When running Windows VSTs (either natively on Windows or via wine), they do not scale properly when run on HiDPI (e.g. 200%) displays.

Platform	Scaling is honored by VST
Windows 11 (mingw)	✅ PASS
Windows 11 (msvc)	🚫 FAIL
Ubuntu 24.04	🚫 FAIL

• Windows (mingw):
  

• Windows (msvc):
  

• Ubuntu 24.04 (AppImage)
  

Previously reported here: #4411

[tresf]

Related:

• Very small font and UI on zynaddsubfx #5386 Not related, see Update FLTK in the AppImage #7710
• Scaling issues on high DPI displays #2510

Duplicate:

• VST UIs do not scale on HiDPI screens #4411

[tresf]

Workaround using X11:

• Change plugin embedding to "none" inside LMMS (you can leave LMMS open)
• Use winecfg to set the DPI (e.g. 192)
• From a terminal, run:

  wineboot -k

Workaround using Wayland (taken from winehq's forums: https://forum.winehq.org/viewtopic.php?t=38372)

• Change plugin embedding to "none" inside LMMS (you can leave LMMS open)
• Extract the appimage (e.g. --appimage-extract)
• Force wine to use wayland by adding the following lines to usr/lib/32/RemoveVstPlugin32 and /usr/lib/RemoveVstPlugin64 (from within squashfs-root).

    #!/bin/sh
  + export DISPLAY=
    appname="RemoteVstPlugin32.exe.so"

• Run the AppRun file.

[SpomJ]

I can't help but wonder why doesn't wine pull dpi automagically under X11. If it's a lack of standard, we could end up making a custom wine prefix and just automating the workaround since I don't see any other sensible way to resolve this.

A more interesting question though is windows-msvc. I'm genuinely confused here.

[tresf]

I can't help but wonder why doesn't wine pull dpi automagically under X11. If it's a lack of standard, we could end up making a custom wine prefix and just automating the workaround since I don't see any other sensible way to resolve this.

Yeah my thought is to add a button next to Vestige's wrench that sets the wine dpi and calls wineboot. It won't work in mixed dpi setups and will need a way to toggle back off, but would save a lot of headache.

On the other hand if Wayland is better at scaling maybe it's less of an issue and we just need to focus on Wayland. Although gnome doesn't play well with the Wayland version so IDK.

[SpomJ]

Yeah my thought is to add a button next to Vestige's wrench that sets the wine dpi and calls wineboot. It won't work in mixed dpi setups and will need a way to toggle back off, but would save a lot of headache.

Honestly my guess is even simpler. QT already tells us DPI scaling, so we could just hardcode running wineboot at startup if using X11. Especially since the original issue is about decorations not matching the window dimensions. Though this probably needs to be toggleable.

Regarding wayland, I don't use gnome so I'm not aware of any issues with it specifically; but what I am using is a random ahh compositor called hyprland which so far didn't have any issues besides the discussed drag & drop problem. However I don't think we should be abandoning x11 support yet.

A solution for wayland embedding is also imminent and we're not getting away with something as easy as XEmbed this time We probably just want to use the Qt solution once it's done

[tresf]

we could end up making a custom wine prefix and just automating the workaround since I don't see any other sensible way to resolve this.

Honestly my guess is even simpler. QT already tells us DPI scaling, so we could just hardcode running wineboot at startup if using X11. Especially since the original issue is about decorations not matching the window dimensions. Though this probably needs to be toggleable.

I already thought about this and I'm sorry I did't comment on it specifically... IIRC, custom prefixes use custom install locations, won't this hide all the VSTs?

[tresf]

Regarding wayland, I don't use gnome so I'm not aware of any issues with it specifically;

Although I don't particularly care for it personally, it's the most common default desktop config for end-users, so it's tremendously important that we keep this in mind when adding feature or workarounds. AFAIR, there's a qt shim on startup that disables Wayland back-end in Qt because it's tremendously buggy on Gnome.

[tresf]

hardcode running wineboot at startup if using X11

Wouldn't this close any running Windows applications? This just seems dangerous.