search

steinbergmedia / vstgui

A user interface toolkit mainly for audio plug-ins
Other
857 stars 122 forks source link

FR - Linux HIDPI support #272

Closed Audiojunkie closed 1 year ago

Audiojunkie commented 1 year ago

With most modern equipment coming with HIDPI capabilities, and many applications (including DAWs) already supporting HIDPI, it is imperative to support HIDPI for those using these capabilities. Currently, VSTGUI supports HIDPI for all of the platforms except Linux. Please support HIDPI in VSTGUI for Linux. An example of a plugin that would immediately benefit from this is sfizz, currently one of the most robust and complete SFZ parsers/players. Thank you!!

scheffle commented 1 year ago

Hi, can you elaborate on what is missing to support HiDPI on Linux? Thanks.

Audiojunkie commented 1 year ago

Hello! I am not a programmer, but I was informed by a developer a software that I am trying to use that VSTGUI doesn’t support HIDPI on linux, and that is the reason his software doesn’t support HIDPI. See here:

https://github.com/sfztools/sfizz-ui/issues/35

The documentation indicates that Linux isn’t supported for HIDPI. I felt that it would be proactive to request this feature. More and more plugin users on Linux are using HIDPI screens. Wayland is even supporting fractional scaling now. This is a feature we need. 🙂

Audiojunkie commented 1 year ago

Edit: This is the correct link:

https://github.com/sfztools/sfizz-ui/issues/35

scheffle commented 1 year ago

Concerning VSTGUI: it supports any scale factor you throw at it. The developer only needs to call CFrame::setZoom. The problem on Linux may be that the host needs to tell the plug-in which scale factor to use.

Audiojunkie commented 1 year ago

Very interesting! I'll direct the developer to this comment. Maybe the two development teams can get a solution into Sfizz. :)

Thank you for the info! 👍

scheffle commented 1 year ago

Hi @Audiojunkie, I just checked this on Linux and when building the VSTGUI standalone examples they support HiDPI without issues. So it's up to the host and plug-in developers to properly implement this in their hosts and plug-ins.

Audiojunkie commented 1 year ago

Thank you everyone! I really appreciate you looking into this! 🙂

redtide commented 1 year ago

The problem in the end is not the HiDPI support, but the lack of the system scale factor.

AFAICS there are 2 types of scale factors: the zoom (get|setZoom() functions) which is an user preference and the system wide scale factor, which in VSTGUI is represented by the platformScaleFactor variable, set by default to 1 at least on Linux. There is CFrame::platformScaleFactorChanged that sets it but it seems to be called only in the macOS version (protected function and the class is declared as final, so no way to derive and override the former, probably just to call the default implementation to pass the system scale). The resulting scale factor is obtained by getScaleFactor() function, which returns the product of zoom and system scale, so that on Linux is the same as getZoom() if platformScaleFactor is never set.

In brief what it's not there (except on macOS) is the system scale factor auto detection. The documentation looks a bit confusing to me, because setZoom is a custom user setting, not the system wide (no setScaleFactor()).

scheffle commented 1 year ago

For VST3 there's a dedicated interface (IPlugViewContentScaleSupport) to set the scale factor of a plug-in editor. This interface must be called by the host to set the desired scale factor and the plug-in can then call CFrame::setZoom(scaleFactor). The platform scale factor is only used on macOS, because there the system uses this factor throughout the system. If you ask a window on macOS for its size you get the size divided by the scale factor. If you do this on Windows or Linux you get the actual size in pixels. So on Linux you need to use CFrame::setZoom(scaleFactor) and the host has to tell the plug-in editors the scale factor.