Hi, are there any brute force scaling options included for the UI?
Been developing the UI on Mac, all looks fine. Moved over to my Windows laptop which has a 4K dispay and everything is tiny. So basically, wondering if there is a simple call I can make which says perform this transformation to all GUI components?
thx
You can apply an affine transformation to components, but this doesn't work for desktop members. I'd say the proper way is to use the resized() method of the main component (and all handmade components that are added as child components).
thanks
that makes sense.... essentially then have to layout everything myself rather than what I did in Introjucer
i guess I could just add everything to a collection and run through that on changing size...
Actually, you can do it for the whole app: Use Desktop::setGlobalScaleFactor()
thanks Jules, handy to know!
ah, cool - just tried calling the affine scale transform on my top level component and that works fine - brilliant stuff!
This does work for most things, but not for popup-menus etc. and tooltips. It doesn't work for anything that's a child of the desktop instead of being part of your top level component.
For applications I don't see this problem on windows btw. For me Juce applies the correct scaling value in its Desktop class automatically. For plugins I had to go this affine transform route. For the popup elements I created a custom lookandfeel that knows about my scaling value and applies it to popup menus and such things. This way I can keep all the needed adjustments in one utility class.
Hi, yes, it's a plugin interface I'm working on - I see what you mean, I've just opened some of my combo boxes and they're not scaled... thanks for the tips, will look into how I can apply scaling to those...
Sorry to bring this old thread up again, but I just want to check - is Desktop::setGlobalScaleFactor() supposed to work correctly within VST3 plugins?
I am using it to scale up my UI correctly in standalone, but not in my VST3 build (see this in Windows 10, latest ‘Projucer’ / JUCE 5.4.7 and latest pluginhost, as well as Abelton 10 and Reaper). I made an empty test plugin project to check this where I can select zoom factor, and you can see part of the UI gets cut off after setting the zoom when hosted as a VST3, followed by incorrect behaviour when trying to resize.
There have been a few Windows plug-in scaling fixes on develop since the 5.4.7 release. I’d suggest pulling the latest develop and checking if this issue is still present.
Thanks - will check. Could you or somebody else confirm that Desktop::setGlobalScaleFactor() is even OK to do within the context of a plugin hosted in a DAW rather than standalone app? (Edit - I want to note that I was getting this issue also in JUCE 5.4.3 - it’s the reason I just transitioned to 5.4.7 - hoping there was a recent fix)
Hi. No, it should only be used standalone. In plugin, you should call setScaleFactor on the main window( i.e. getActiveEditor() ).
Thanks - @leehu - I will check again and use the correct method.
Initial test with JUCE develop branch (before your suggestion) it did actually work correctly, but only after I called (in my PluginEditor) setSize with updated values with the scale factor used for Desktop::setGlobalScaleFactor() … tested in the JUCE plugin host so far… will update with getActiveEditor() and check again…
OK… I can confirm that it works correctly now that I check to see if I’m in plugin mode, and use getActiveEditor()->setScaleFactor in that case (even after I reverted back to my JUCE 5.4.3 code set), instead of Desktop::setGlobalScaleFactor() .
Thanks!
FYI for those who might find it useful - check for standalone vs plugin with:
if (PluginHostType::getPluginLoadedAs() == AudioProcessor::wrapperType_Standalone)
This has changed on the develop branch - the DPI handling code has been refactored for plug-ins to use AudioProcessorEditor::setScaleFactor() internally so calling this from user code will interfere with the host’s transform. There’s some info about the change in the breaking changes doc here, but basically you should use Desktop::setGlobalScaleFactor() if you want to apply a top-level scale transform to the editor window.
oh, thx for the heads up - had no idea… i wish there was a better way for us to find out about this stuff 
I’m trying to migrate my own AffineTransform-based scheme to the current Juce method as I’m getting jasserts complaining about the Transform I apply to the plugin editor. So I’m trying to just call Desktop::getInstance().setGlobalScaleFactor(); instead. However that does not resize the window. How is the intended way to use this now with user-controllable additional scaling? I’m running into all sorts of problems when I call setSize() after changing the Desktop scale factor. How is this supposed to work if let’s say the user wants to apply 1.5x scaling to a plugin window in addition to dpi scaling already applied to match the Windows scaling factor.
Here’s what I already tried: I’m trying to do this on a windows 10 machine which has 150% scaling by default. First I just called setGlobalScaleFactor(), but that does not change the window size. So I figured I need to call setSize() after changing the factor and multiply by my custom factor. However this leads to wrong window sizes. Then I called setSize with the original size, just to find out it won’t do anything as long as the size doesn’t change. Then I called it with a slighly different value and the again with the original size. This half works as it forces the update, but now I get some exception when I try to make the GUI smaller in the VST2 audioMasterSizeWindow callback, it seems calling setSize twice in a row leads to issues. So the question is… how can I notify the wrapper, it needs to adjust the window size if my component size hasn’t changed?
So, will this be the way to do it for plugin editor windows as well as standalone editor windows AFTER 5.4.7 ?
I’m on 5.4.7, and currently using ‘getActiveEditor()->setScaleFactor’ for plugin editor windows, and ‘setGlobalScaleFactor’ for standalone - seems to work - I hope that is correct for the moment.
(I don’t use any ‘AffineTransform’ method - relying on the scale factor to scale up everything)
The docs clearly say you should not use getActiveEditor()->setScaleFactor anymore. Don’t you get the jassert in AudioProcessorEditor::editorResized()?
**void** AudioProcessorEditor::editorResized ( **bool** wasResized)
{
// The host needs to be able to rescale the plug-in editor and applying your own transform will
// obliterate it! If you want to scale the whole of your UI use Desktop::setGlobalScaleFactor(),
// or, for applying other transforms, consider putting the component you want to transform
// in a child of the editor and transform that instead.
jassert (getTransform() == hostScaleTransform);
Unfortunately Desktop::setGlobalScaleFactor() currently doesn’t work for me as I can’t figure out how to safely notify the host to update the window size after changing the factor.
@pflugshaupt
Is the doc you mentioned on the dev branch?
I’m not on the develop branch, and no I didn’t get any asserts.
