Plugin resize issue after 6.1.3

[aleFX]

Hi guys,

After the latest update (JUCE 6.1.3) I’m experiencing a strange behavior with the resize of my standalone audio plugin. I’ve set an aspect ratio and max/min size in pluginEditor constructor:

AudioProcessorEditor::AudioProcessorEditor (AudioProcessor& p) :                                                                                          
{
    getConstrainer()->setFixedAspectRatio(1.3);
    setResizeLimits(806, 620, 1170, 900);
    setResizable(!(JUCEApplicationBase::isStandaloneApp()), true);
    resizableCorner->setAlpha(0.0f);
    
    if(JUCEApplicationBase::isStandaloneApp())
    {
        TopLevelWindow::getTopLevelWindow(0)->setUsingNativeTitleBar(true);
    }
}

When I’m not at the maximum size everything is ok, and the bottom part of the plugin is rendered correctly, like this:

But when I set the maximum size it gets cropped:

In order to understand what was happening I’ve placed this code in the resize function of my Editor:

void AudioProcessorEditor::resized()
{
    int w = getWidth();
    int h = getHeight();

    std::cout << "----- RESIZE -----" << std::endl;
    std::cout << w << "   " << h << std::endl;
    std::cout << TopLevelWindow::getTopLevelWindow(0)->getWidth() << "   " << TopLevelWindow::getTopLevelWindow(0)->getHeight() << std::endl;
    std::cout << "------------------" << std::endl;
}

And when I set the maximum size this is what it prints:

----- RESIZE -----
1170   900
1169   872
------------------

So, for some reason the topLevelWindow is not the same size as the plugin UI, and also is not respecting anymore the aspect ratio constraint I’ve applied.

What can I do to fix this problem?

I’m currently on macOS (intel) Big Sur 11.6.2 with the latest JUCE 6.1.3 .

[aleFX]

Update: the problem does not arise when using JUCE titleBar, only happens with the macOS native title bar

[modosc]

i’m seeing this too on macos 12.1 in a vst3 in ableton live 10.

[MBO]

Maybe it is related to this commit?

Linux setResizeLimits()

Thanks, I think you’re right to point out the inconsistencies in the existing behaviour. The old behaviour is quite confusing and buggy. I’ve tried to improve things in the following series of commits: The goal is that the behaviour should be almost identical on Linux and Windows, where the windowing models are quite similar. The fullscreen button will always set the window to fullscreen, regardless of the resize limits. If you don’t want to allow the window to enter full-screen mode, dis…

[attila]

Thanks for reporting the problem.

Using the code shared by AlessandroProverbio I can reproduce it in the Standalone build, and it is related to a change in the StandaloneFilterWindow.

@modosc So far I’ve been unable to reproduce an issue in Live so that could have an unrelated root cause.

[attila]

There’s a change out on develop that should fix the issue with the standalone plugin window.

StandaloneFilterWindow: Take native window borders into account when constraining size

[dxp]

It looks like this issue came back in 6.1.6 with the commit StandaloneFilterWindow: Respect editor’s size constraints when adjusting size of component peer. Would it be possible to include the peer’s window border (from attila’s earlier commits) in the new computerBorder() method? e.g.

BorderSize<int> computeBorder() const
{
    const auto outer = owner.getContentComponentBorder();

    const auto windowBorders = [&]() -> BorderSize<int>
    {
        if (auto* peer = owner.getPeer())
            if (const auto frameSize = peer->getFrameSizeIfPresent())
                return *frameSize;

        return {};
    }();

    return { outer.getTop() + (shouldShowNotification ? NotificationArea::height : 0) + windowBorders.getTop(),
             outer.getLeft() + windowBorders.getLeft(),
             outer.getBottom() + windowBorders.getBottom(),
             outer.getRight() + windowBorders.getRight() };
}

[leehu]

Glad I found this, having lots of resize issues with constrainers and pulled 6.1.5 and they all went away.
In 6.1.6 for me, when using constraints, alot of the time the window resize corner is not present and so the window cannot be dragged. Remove the constraints and it appears as expected, go back to 6.1.5 and it appears as expected.
6.1.6 has been a bit of a nightmare so far

[leehu]

@reuk

commit c0b78adcdad72c68c6c593e7bf835f3978be4c6c (HEAD)
Author: reuk reuk@users.noreply.github.com
Date: Thu Feb 17 17:45:49 2022 +0000

StandaloneFilterWindow:  Respect editor's size constraints when adjusting size of component peer

Was the cause of this issue.

Commenting out the following line in the StandaloneFilterWindow gets back to previous behaviour:

setConstrainer (&decoratorConstrainer);

[leehu]

@reuk any updates/comments on this? thx

[reuk]

Thanks for reporting, the issue should be resolved here:

StandaloneFilterWindow: Account for native frame size in constrainer

[leehu]

yep, all looks good. thx