Changes to iOS sizing behaviour in JUCE update? Why?

Hello,

I’ve just upgraded from JUCE 6.0.4 to 6.0.8 and the standalone AUv3 is displaying in a very different way.

When the app first opens on JUCE 6.0.8 and brings up the “Audio input is muted to avoid feedback loop” bar, the standalone AUv3 doesn’t seem to be aware of screen size. Previously it would just size to the full screen and whatever size set In setSize() didn’t matter. Please see screenshots for the comparison (the ones with the default JUCE background colour around the grey are the ones using new JUCE).

Similarly fillAll() has changed behaviour and doesn’t fill the whole screen.

My setSize() code is as follows:

ratio = 1740.0 / 470.0;
setResizeLimits(1740.0 * 0.25, 1740.0 * 0.25 / ratio, 1740.0, 1740.0 / ratio);
getConstrainer()->setFixedAspectRatio(ratio);
setSize(1740.0 * 0.7, 1740.0 * 0.7 / ratio);

Is there a way to get back the old behaviour as it meant that no changes were needed between desktop and iOS builds? I haven’t played with it much but I haven’t found a way to get it to display nicely yet.

Does anyone know where the change is in the JUCE code?

Thanks,
David

Edit:

This now works but getMainDisplay() depreciated so ideally there would be a better solution -

    juce::Rectangle<int> r = juce::Desktop::getInstance().getDisplays().getMainDisplay().userArea;
    setSize(r.getWidth(), r.getHeight());

And this doesn’t work:

    setSize(getParentWidth(), getParentHeight());

You’ll need to switch over to calling getPrimaryDisplay instead. The purpose of that API is to be able to work through situations where there aren’t any displays connected (hence the const Display* return type.).

1 Like

Thanks for pointing that out. I have now tried it but it presents the same odd scaling issue as my old code that previously worked in JUCE 6.0.4 so it isn’t a direct replacement for getMainDisplay().

I have also just edited my post as I have updated to JUCE 6.0.8 not 6.0.7

I’m unable to provide direct suggestions right this moment, but I can provide some context - various scaling and resizing related changes have been put into place based on this thread: VST3 plugin editor resizing glitch/issues - #4 by haroldgroenenboom

Maybe a quick read there will help you uncover what’s going on.

1 Like

Thanks!

I’ll try and dig into it a bit… None of the possible combinations I have found work both in displaying the plugin correctly as standalone AND as displaying it as a plugin within GarageBand iOS (AUM works whatever it seems), at this point it seems to be either or… I’ll see if I can try to find where the breaking change is.

So I’ve found a bit of a hacky way around the problem and also a potential JUCE bug.

In my editor constructor I am simply calling:

setSize(400, 200) //I don't think the values really matter.

Then in resized() I am working out a multiple to change the height of every single component because for some reason resized() and paint() see a width of 1024 (expected) and a height of 1861682880 which is stupidly high especially considering it is running in landscape mode. The first time resized is called after the setSize() in the constructor the width is 400 but the height is 1865464768 so the value of 200 is ignored.

My multiplier I’m using is found with:

screenRatio = (( float ) getWidth() / ( float ) getHeight()) / ratio;