stakira / OpenUtau

Open singing synthesis platform / Open source UTAU successor
http://www.openutau.com
MIT License
2.06k stars 285 forks source link

UI scaling options #245

Closed kokoropaint closed 1 year ago

kokoropaint commented 2 years ago

As it is, OpenUTAU can be hard to use on monitors with a high DPI/resolution, so adding UI scaling would help make the program usable in more environments

lbrame commented 1 year ago

I tried out OpenUTAU on Linux today and I, too, noticed the lack of hidpi scaling option. I tried with all the various ways programs usually determine the dpi to use GDK_SCALE environment variable etc. but nothing seemed to work.

However, I found this issue on Linux users having trouble with Avalonia's hidpi scaling on Linux. From here, it appears Avalonia uses an heuristic to auto determine the optimal scale factor from RANDR but unfortunately that is far from optimal, especially since Wayland is the default and the X Server is no longer the default on major desktop environments. This documentation page explains how it was made and it explains how to override it. In my case (Fedora Linux 36, GNOME, Wayland), the following worked:

xrandr --listactivemonitors                             
Monitors: 1
 0: +*XWAYLAND0 1920/340x1080/190+0+0  XWAYLAND0

listed the name of the XWayland X server (the compatibility layer that allows to run old clients that target X11 APIs still on a Wayland session) and noted down the virtual display was called XWAYLAND0.

After that, running OpenUTAU with the AVALONIA_SCREEN_SCALE_FACTORS set as such worked fine and I was able to launch OpenUTAU at arbitrary scale factors!

AVALONIA_SCREEN_SCALE_FACTORS='XWAYLAND0=1.5' ./OpenUtau

Most consistent results were recorded with integer scale factors of course, but I found fractional scale factors to also work in a very acceptable manner.

Here's OpenUTAU running at 1.5x:

image

I am not sure if it's possible to override Avalonia's DPI detection within an Avalonia app or if this bug must be fixed at toolkit level, I might be able to do more digging when I get more downtime.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open for 60 days with no activity. It will be closed if no further activity occurs. Thank you.