Use font and size from DAW in juce popup menus?

I write because you write before this

But on windows on 4k screen all midi plugins that you write with own code are too small. only main window is scale correct. plugins that support correct scaling are correct(see scaler in this screenshot). only the window title is too small. and the popup menu is too small in your code,

here is a screenshot that show more of your own written unify plugins that are too small.

it seem the forum scale my 4k screenshot down, to 1920. I hope it is now clear what the problem is.

in short;
All plugins that support scaling are correct in juce/unify. all plugins/or childwindows you have written support no scaling and are too small.

so you need a solution hat your own unify plugins or child windows are scale to correct size

that juce/unify show old plugins that not support scaling too small is another thing

@reuk: So it appears that, in some (not all) hosts, the current desktop scale-factor does not get propagated to new juce::DocumentWindow based windows created by a JUCE-based plug-in.

I’m well aware that plug-ins are not supposed to create extra windows at all, so I don’t really expect JUCE to support it. Any advice would be welcome nonetheless.

1 Like

problem happen on all systems with cubase too, when HiDPI is enble(it is default off) so notice this not. When it is not enable then all is blur so a 4k monitor make no sense then.

It seem the Mac have no scale setting and a user can not choose how large the buttons and GUI is. I have no mac so i did not know how large 4 k look. i have a Dell 13 inch win 10 2 in 1 tablet too. it have for 4 k default scale setting 300%. it is good usable with touchscreen but unify is extrem small on this.

please read steinberg information about that

https://helpcenter.steinberg.de/hc/en-us/articles/360001589520-Cubase-10-HiDPI-support-on-Windows-10

HiDPI enabled

HiDPI is only supported on Windows 10 systems.
To enable HiDPI support in Cubase, go to Edit ▸ Preferences ▸ General and check 'Enable HiDPI'. HiDPI support will be enabled next time you start Cubase.
When enabled, the user interface will use graphical assets in high resolution.
Currently Cubase supports only integer monitor scaling settings from Windows, for example.:
    Monitor scaling setting of 125% displays Cubase with 100%
    Monitor scaling setting of 150% displays Cubase with 200%
    Monitor scaling setting of 175% displays Cubase with 200%
    Monitor scaling setting of 200% displays Cubase with 200%

see screenshot how cubase with unify look with HiDPI enable

Hello
there is now juce 6.1.2. it have this enhance

  • Improved the scaling behaviour of hosted VST3 plug-ins

is this problem he writes then fixed too ?.

or can it fix in future that all child windows get the desktop scale factor of parent window ?

No, I’m still working on the problems described in this thread.

2 Likes

Thanks for the suggestion, we’ve added that here:

1 Like

Hello
there is some progress done but on VST 2 VST 3 still not work. here is simular problem with the desktop scale factor AlertWindow and DialogWindow won't scale and center after setGlobalScaleFactor or when JUCE_WIN_PER_MONITOR_DPI_AWARE disabled - #4 by mucoder

I see in your exmple that you not use the windows function SetThreadDPIAwarenessContext . it seem need. see the explain in this thread . link seem not work thread title is high-dpi-support-for-non-plugins-on-windows here is the text he write

Hi, I’m back with my DPI issue fix for Windows :slight_smile: See my previous post which holds a potential fix for Juce 5.3.2. We’ve now upgraded our code base to use Juce 6.0.5 instead, and so I needed to re-apply a similar fix again.

The issue is that (on Windows) standalone Juce applications have proper DPI scaling, and I imagine VST plugins have proper support too (I read something about the host passing on the scaling to use to the plugins?), but plugins for unrelated applications are left at the mercy of their host application’s DPI handling setting. In case we’re not a standalone app, Juce defaults to a 100% DPI scaling, so when the host informs Windows it’s perfectly DPI aware, this results in tiny controls on high DPI monitors in standalone Juce dialogs.

The fix I applied is that when we’re not a standalone app, I query for the DPI support the host has set once, and then (where needed) toggle the DPI support to “per-monitor aware” using SetThreadDPIAwarenessContext for the current thread (and revert it back when not needed anymore). This way no matter which DPI support the host has, the Juce dialogs get sized correctly and look nice and crispy.
Where this is not supported (pre-Windows 10.1703), the code could fall back to use SetThreadDPIAwareness instead (for everything from Windows 8.1 upward); this has to be added to the code though.

There are probably quite a few issues with the code though… For one, I added all of this behind the preprocessor define JUCE_WIN_PER_MONITOR_DPI_AWARE, so for code bases not using this define the fix won’t work (don’t know if that would even make sense though). But I tested it on Windows 7, Windows 8.1 and Windows 10 for one particular host (Adobe Premiere), and on all those combinations the result is good. Then again the changes might very well wreck havoc for VST plugins under their hosts; there’s no way for me to test for that.

… or see my original post for the full post incl. attachments and more details (the post quoted by calvin is a partial re-post by a new user).

2 Likes