baconpaul/airwin2rack

High DPI Scaling Not Working

Closed this issue · 15 comments

Bitwig 5.1.8 Clap and VST3 menu doesn't seem to observe High DPI Scaling. Easily resolved by setting Bitwig to not use High DPI Scaling and sandboxing Airwindows Consolidated or by running Bitwig's pluginhost.exe in HDPI Compatibility mode to force correct scaling on High DPI monitors, but would be nice if the menus could be High DPI aware so they are not so small? Great work on this though, thank you!
image

This is on windows yes? Thanks for the report.

OK I'm not sure why the HDPI isn't scaling but I see why the menu isn't following the parent. I have a fix for that that I just tested.

I'm going to leave this open to figure out why it doesn't come up as an HDPI plugin but will push the menu fix this morning.

OK I just merged a change which does two things

  1. Make the popup menu scaling follow the parent window scaling and
  2. Increase the font size of the menu a smidge on windows. Seems the font metrics in juce 7 between win and mac respond a bit differently

It usually takes about 20 minutes from a merge to the plugin being updated. But if you download later today and test I would greatly appreciate it.

As to why its not responding to HDPI properly, I'll leave this issue open to explore that another day, when I have a bit more patience for Windows HDPI :)

Fantastic, thank you and yes, was Windows. Will have a look tomorrow.

Hi! Just curious how the absolute latest version does for you? Lots of changes this week and it would be great if I could know issue status of the open issues over the weekend

thanks!

Hi Paul, sorry work got busy to test again. Looks good. Bitwig 5.1.8 CLAP.

image

Awesome thanks for confirming

so only thing left is: why doesn’t bitwig launch as hdpi and set the scale right? Or is that working also now?

Bitwig itself scales fine, probably the best I've seen in any DAW in fact. It's a little different though because it uses a JAVA JRE for the GUI and then C++ for the audio engine I believe. This way they decouple all graphics processing from the audio processing for stability and offload it to the GPU instead of CPU which many plugins still seem to use for some reason.
The plugins themselves can either be set to run in Bitwig's audio engine or sandboxed by developer or individually within their own .exe host so if they crash, Bitwig carries on playing as if nothing happened. This is BitwigPluginHost-X64-SSE41.exe for 64-bit plugins.
image

What I do for problematic plugins is set that .exe hosting them to a compatibility mode for HDMI overriding the default plugin/application behaviour and that usually fixes the issue if Bitwigs own plugin scaling checkbox didn't work.
From the plugins I've reported scaling issues, it nearly always turns out to be because the development was done on MacOS, but it's relatively common issue in plugins and applications. As I said it took Blackmagic 15 years just to add Windows HDPI support as it's been standard part of Windows for 15 years or something now.

I thought on windows bitwig had two host processes an hdpi one and not? I was more asking if somehow bitwig is choosing the non hdpi one here

last I checked all claps run in the hdpi host but I’m not sure what the vst3 semantic is

(and windows has had hdpi for 15 years but it’s still a mess of an api. The reason it works well on Mac is because they broke old apps and windows not doing that makes plugins hard)

Anyway lemme ask the bitwig devs to remind me again how they choose the right host. We are scalable vector graphics so it should work if in a host with hdpi support and that sends us the scale factor

would be curious if the clap and vst3 behave differently for you also

thanks for your help here

I suppose you could say Bitwig itself has two scaling modes. e.g. if I set Windows Display to 175% scaling, Bitwig set to 'auto' mode will simply inherit the 175% dpi scaling from Windows OS.
image
But if I disable 'auto' Bitwig can then scale itself to whatever independently of Windows scaling.
In the plugins settings, the default scaling mode is to enable high dpi scaling for them. I assume this is essentially running the host in high dpi awareness mode and then plugins it hosts should inherit the scale as Bitwig inherits from Windows? But this doesn't always work for some plugins (if I were to guess, maybe Juice plugins don't observe it reliably).
image
The other issue is some plugins simpy don't scale whatever you do. If Windows isn't set to 100% 1:1 scaling, you simply can't use the plugin as it gets cropped in its own window.
Here's Clap plugin:
image

and here's the VST3 plugin.
image

Scaling is working fine too.
200% Bitwig Scaling, Plugin Scaling On
image

150% Bitwig Scaling, Plugin Scaling On
image

imo that is how it should be when Bitwig isn't set to adopt Windows scaling, so your plugin is fine. The Plugin shouldn't be affected by the DAW scaling, the plugins should adopt what Windows is set to.

And with plugin scaling off, nothing should change if the plugin observes scaling from the OS, which is what happened for Airwindows Consolidated.
image

OK so it sounds like we are all good then! Thank you for the detailed explanation. I'll tell my bitwig friends that we got it sorted and close this, then, since it seems we are all good now we've fixed the font rendering and menu scaling.

Appreciate the help. Enjoy the plugin!!