sfztools/sfizz-ui

Support for high resolution scaling (HiDPI, 4k, etc)

Audiojunkie opened this issue · 6 comments

First and foremost--Thank you so much for creating this nice SFZ tool! I am watching the development very carefully. :-)

Second, as a Linux user, is there currently a way to make Sfizz scale up for high resolution displays or have upsized bitmaps for high resolution systems?

Currently, the plugin is tiny, and I've found no information on theming (other than just colors), or any other information that can help me to make this tool more usable. I couldn't even find what graphics widget kit Sfizz is using, unless its using straight libx11. At any rate, I'm not a programmer, but I've very interested in finding a way to better use sfizz with my system.

If it turns out that there is no current workable solution, I would like to make a feature request for supporting HiDPI scaling for all platforms (I use Linux).

Any guidance or suggestions would be appreciated. Thanks!

Currently, the plugin is tiny, and I've found no information on theming (other than just colors)

I'm afraid a color theme and a background image via image opcode is all you can get at the moment.

I couldn't even find what graphics widget kit Sfizz is using

It's VSTGUI and from what I can see in their documentation Linux is not listed as a supported platform. Here the related API.

Is there a way to create a double-sized GUI with double-sized fonts without requiring true HiDPI support from VSTGUI for Linux? I'd really like to use the plugin. :) I wish I knew how to code. :)

I don't fully understand everything, but I gather that these are the available methods for supporting HiDPI:

  • Resize everything post-raster. Easily doable in the widget toolkit or even the window manager, but looks ugly. This is what your web browser does.

  • Actually provide raster graphics (and in some cases, raster programming) for a reasonable set of resolutions. Hopefully I don’t need to explain why this is a huge amount of work.

  • Use vector graphics for everything. Requires code changes to your application, and requires those assets to exist. While that’s more common these days, it’s not guaranteed. Also, graphics designed to align to pixel boundaries will look bad at non-integer scaling factors. This is why most text looks good at any resolution; most fonts have been vector for a long time, and a lot of effort has been expended making them look good at any size over the course of decades.

Isn't there a currently existing cross platform way to provide HiDPI support for all platforms? At this point, I'd even be happy with resizing everything post-raster, or even using font scaling of some sort to make things a bit bigger. Even if it was a little blurry, I could still probably see and use it. Right now, it's just too small to see well enough.

Edit--Source:

https://community.frame.work/t/state-of-hidpi-on-linux/8301/22?page=2

Update: After communicating with the VSTGUI team, it appears that HIDPI on linux is supported. Please read the following thread for details:

steinbergmedia/vstgui#272

TL;DR

"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."

AFAICS there are 2 types of factors: the zoom (they have 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. There is a function (CFrame::platformScaleFactorChanged) that sets it but it seems to be called only in the macOS version.
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.

See also #107