BR: Desktop Components have wrong scale unless opened by PopupMenu callback

1

Desktop Components have wrong scale unless opened by PopupMenu callback. This is a strange one, no idea what is going wrong. I have reduced it to minimal example with latest develop juce.

Setup:
Windows 10
Desktop scale 150%
VST3
AudioPluginHost

Start a 1000 ms timer. Create a desktop component from timer, scale will be wrong.
Create desktop component from PopupMenu, scale will be correct

Video:

Code:

2

I figured out the cause of the issue. Any new Windows created will have the same DPI awareness settings as the current window. In mouseDown or mouseUp the current window is the plugin editor window.

However, if you are creating a window from a Timer there is a hidden Window that is used to pass the message from the background timer thread to the UI thread. When the new Window is created, it has the same DPI awareness as this hidden window, which is not correct.

Work around for now is to only create new windows from Component events.

3

Yes, this is something that needs to be addressed in the AudioPluginHost - we have an option for disabling DPI awareness for plug-ins but it will only disable it for the main window.

An alternative for the time being is to create an instance of ScopedDPIAwarenessDisabler before opening your new windows.

4

Is this something that is on to TODO list? I notice my plugin looks good in FL Studio, but it’s stretched and obviously blurry in the AudioPluginHost.

5

If you right-click on the plug-in node and toggle “Enable DPI awareness” the editor window will be opened in DPI aware mode and won’t be bitmap stretched by Windows.

6

Ah, got it, thanks.

7

We’ve added an application-wide setting for DPI scaling hosted plug-ins on Windows to the AudioPluginHost on develop:

If you enable Options->Auto-Scale Plug-in Windows menu item and then add an instance of your plug-in to the graph it’ll use the correct DPI-awareness setting for all windows.

1 Like