nope, no assert for me on latest develop.
Yes the assert only happens on the develop branch so far. I get it if I try to apply my user scaling to the plugin editor affine transform as described in the comment.
Ok I see now thereâs a difference between changing the affine transform and using setScaleFactor. In my case using setScaleFactor will use as I anyway use two nested editors and the outer one can now scale for the host while the inner can apply my user scaling.
However as the Juce team stated, if an editor is exposed to the host calls, setScaleFactor() should be used to do your own scaling as it is now âreservedâ to be used by the host to apply scaling.
While I can go on now, it would still be interesting to know how it is supposed to work using Desktop::setGlobalScaleFactor(). The question remains how to make the host change the window size if the scale factor changes and the editor size stay the same. Currently the resize callback are not being triggered and so far I found no way to manually trigger them safely.
Anyone else getting Tooltips that donât scale with system DPI on windows Hi-DPI? It seems while the host can use setScaleFactor() now, the scale information doesnât end up in the right spot when tool tips need to be drawn inside a plugin.
Weâve added a fix here so host windows should now resize correctly when using Desktop::setGlobalScaleFactor() dynamically.
Iâm not seeing the tooltip issue though - is it reproducible in the AudioPluginHost? Are you adding the TooltipWindow as a child of the AudioProcessorEditor or another component? In order for it to scale correctly it needs to be a child of the editor.
1 Like
No, the tooltip window is free floating and not added to the editor as tooltips need to be able to overlap at the borders of the window so they feel like OS-wide tooltips. The problem only occurs on windows if system dpi scaling is not 100%. Ideally the tooltips would pick up the OS scaling from the component they are spawned above. Isnât it the same situation with the popup-menus?
Iâll check the new fix now.
I canât check the fix as it is on the Juce6 branch and Iâm on Juce5 develop because thatâs what I have a license for.
1 Like
Weâve cherry-picked the fix onto the develop branch now here:
For the TooltipWindow scaling, itâs best to add it as a child of the editor so it can scale correctly. The docs state:
For audio plug-ins (which should not be opening native windows) it is better
to add a TooltipWindow as a member variable to the editor and ensure that the
editor is the parentComponent of your TooltipWindow. This will ensure that your
TooltipWindow is scaled according to your editor and the DAWs scaling setting.
However, is this a new issue or were they scaling correctly before? If itâs something weâve changed with the recent scaling fixes weâll sort it out.
1 Like
I think itâs been a problem for a while, but I just now saw it again when checking this new fix. I believe it happened with the previous round of windows hidpi fixes when you had to add special code to the popup-menu so they would scale even when using floating windows. The same code could make tooltips scale the same way by fetching the factor from the component they fetch the tooltip text from. I guess I missed to correct time to complain back then 
.
For me itâs not a problem as I fixed it in my own custom LookAndFeel and maybe Iâll switch to doing the tooltips as child windows anyway. That way they could probably also work on iOS AUv3 now that we have a mouse pointer that can hover.
Hi - had to move back to the old code on Mac as calling setGlobalScaleFactor() in Live is causing Live to crash. Is there any reason why I shouldnât be using the old call?
Where is it crashing? If you can you provide a stack trace that would be really helpful. Using AudioProcessorEditor::setScaleFactor() on macOS should be fine as the hosts donât need to pass display scale factors, but the recommended way to do it is to wrap your content in a top-level component of your editor and scale that instead.
I donât know. Since the updated security in MacOS and having to rewrite the entitlements of Live, debugging is somewhat dodgy I find on Mac. 99% of the time Live crashes without writing anything to console app and wonât even stop in a debugger - the process just completely dies and Iâm left with nothing.
Sorry, Iâm a bit confused, I thought the recommendation now was to use setGlobalScaleFactor() all the time and never scale the components directlyâŠ??
If you donât need a separate scale factor for each of your plug-in editors then yes using Desktop::setGlobalScaleFactor() is the simplest way to scale your editors. However if you do need this then transforming a child of the editor and not the editor directly is the way to do it.
ok, i guess global is ultimately desirable. Iâll keep trying to get a stack trace but as said, itâs a rare thing when running Live these days. Any tips on how I can get things behaving as they used to do?
Just use an extra wrapper component to scale the entire UI. That way the host&Juce can use the editor for their scaling and you control yours separately.
This gives you full control and you donât have to wait for the new way to fully work. It also cannot go wrong as it doesnât do anything that Juce couldnât do before these changes.
1 Like
So, this is where Iâm at.
Iâve been using setScaleFactor() on the editor for a few years - before that I was using setAffineTransform().
setScaleFactor() appears to work and Iâve never had any problems and was recommended a couple of yeas ago over using setAffineTransform() - something to do with tooltips etc. not being handled properly iirc.
@pflugshaupt My app has a top level Component which is placed on the editor. Component class doesnât have a setScaleFactor() call on it, so does this mean I have to go back to using setAffineTranform() with itâs associated issues, e.g. resizing windows myself etc.
Sorry for the confusion, but that seems to have been a round trip journey to end up where I was a few years ago.
Itâs ok @ed95 - looks like it was ok, in my code for desktop I resize the window after setting the globalscalefactor and was still doing this in the plugin - this was causing the crash. Stopped doing that and the plugin is scaling fine now.
Hi, top image is standalone, bottom is VST (windows). Both of these are at normal scaling. Is the issue here Juce or Live do you thing?
thx
Do you mean the blurry rendering? This is what a non-DPI aware window will look like when it is on a screen with a scale factor set to something other than 100% - Windows will bitmap scale the UI. In Live you can enable DPI-aware windows by right-clicking on the plug-in and deselecting âAuto-scale plug-in windowsâ.
2 Likes
lovely - wasnât aware of that - thx
This just saved me, thanks! I am bumping this in case anyone else doing a new plugin and testing in Live was wondering why their plugin looks blurry even when they are doing everything else right!