VST3 plugin editor resizing glitch/issues

Can you try the latest develop? The resizing moving editor bug should be fixed there.

I was already using the latest commit on develop for these gifs. (this one to confirm VST3: Fixed an issue with jumpy resizing when using a fixed aspect r… · juce-framework/JUCE@e813531 · GitHub)

I have a similar problem on OSX and Ableton, as seen in the gif. With Max and DemoRunner it works as expected. The AU version worked fine in all Hosts including Ableton.
I used the updated Wrapperfile, but it makes no difference for me.
Glitch

So for everybody who has to deal with this glitch thing I may have a workaround for you.
I made a small slider which I placed in the bottomrightcorner. I recommend to use RotaryHorizontalDrag for Sliderstyle. Now I rotated it by 0,75. Draging the slider will change the GUIsize, and the rest of your Resizable components. Just the resize-slider itself will not be replaced and resized until you stopped dragging.

#include "PluginProcessor.h"
#include "PluginEditor.h"

//==============================================================================
NewProjectAudioProcessorEditor::NewProjectAudioProcessorEditor (NewProjectAudioProcessor& p)
    : AudioProcessorEditor (&p), audioProcessor (p)
{
    setResizable(false, false);
    setSize(300, 300);
    
    addAndMakeVisible(ReSize);
    ReSize.setTextBoxStyle(juce::Slider::NoTextBox, true, 0, 0);
    ReSize.setSliderStyle (juce::Slider::RotaryHorizontalDrag);
    ReSize.setRange(1.f, 2.f, 0);
    ReSize.addListener(this);
    ReSize.setBounds(260, 260, 50, 50);
    
}

NewProjectAudioProcessorEditor::~NewProjectAudioProcessorEditor()
{
}

//==============================================================================
void NewProjectAudioProcessorEditor::paint (juce::Graphics& g)
{
    // (Our component is opaque, so we must completely fill the background with a solid colour)
    g.fillAll (getLookAndFeel().findColour (juce::ResizableWindow::backgroundColourId));
}

void NewProjectAudioProcessorEditor::resized()
{
}

void NewProjectAudioProcessorEditor::sliderValueChanged (juce::Slider* sliderThatWasMoved){
    if (sliderThatWasMoved == &ReSize){
        x = ReSize.getValue();
        setSize(300*x, 300*x);
    }
}

void NewProjectAudioProcessorEditor::sliderDragEnded(juce::Slider* sliderThatWasMoved){
    if (sliderThatWasMoved == &ReSize){
        y = x;
        ReSize.setBounds(260*y, 260*y, 50*y, 50*y);
        ReSize.setTransform(juce::AffineTransform::rotation(0.75, ReSize.getWidth()/2 +ReSize.getX(), ReSize.getHeight()/2 +ReSize.getY()));
    }
}

You may now make the slider transparent and place a picture of that well known Resize-triangle underneath it.

I can’t reproduce this using the latest develop in either Live 10 or 11, I’ve created a blank plug-in from the Projucer and added the following to its constructor:

setResizable (true, true);
setResizeLimits (600, 400, 1200, 800);
getConstrainer()->setFixedAspectRatio (1.5);

setSize (600, 400);

The plug-in is resizable using the bottom-right resizer and there are no artefacts like in your gif. Can you post a minimal example which reproduces the issue?

I solved the problem using the code I posted above. However I did not have the line “getConstrainer()->setFixedAspectRatio (1.5);” in it.

I just made a quick testproject including that line and it worked fine.

And without it? I’m still not able to reproduce the glitches you’re seeing with orr without that line. A minimal example would be very helpful in tracking this down.

1 Like

So this is the code if that line is there it works, with that line it produces the glitch. The difference to your example is that I used a resized picture background and that the ratio between width and height is always the same.

#include "PluginProcessor.h"
#include "PluginEditor.h"

//==============================================================================
NewProjectAudioProcessorEditor::NewProjectAudioProcessorEditor (NewProjectAudioProcessor& p)
    : AudioProcessorEditor (&p), audioProcessor (p)
{
    //setSize (400, 300);
    setResizable (true, true);
    setResizeLimits (600, 400, 1200, 800);
    //getConstrainer()->setFixedAspectRatio (1.5);

    setSize (600, 400);
    
    drawable1 = juce::Drawable::createFromImageData (BinaryData::Hintergrund_png, BinaryData::Hintergrund_pngSize);
}

NewProjectAudioProcessorEditor::~NewProjectAudioProcessorEditor()
{
    drawable1 = nullptr;
}

//==============================================================================
void NewProjectAudioProcessorEditor::paint (juce::Graphics& g)
{
    {
            jassert (drawable1 != nullptr);
            if (drawable1 != nullptr)
                drawable1->drawWithin (g, juce::Rectangle<int> (0, 0, getWidth(), getHeight()).toFloat(),
                                       juce::RectanglePlacement::stretchToFit, 0.997f);
        }
}

void NewProjectAudioProcessorEditor::resized()
{
    setSize(getHeight()*1.5, getHeight());
}

Here’s a link to the project Dropbox - NewProject.zip - Simplify your life

This is definitely a bad idea. Calling setSize() in your resized() callback is just asking for trouble with recursive resizing loops. If you want to enforce a specific aspect ratio that’s what ComponentBoundsConstrainer::setFixedAspectRatio() is for as it will actually be handled at the plug-in wrapper level.

Oh ok good to know. So I’ll try that next time.

Hey Ed, I can reproduce the exact same issues with the same code I’m afraid. I’ve doublechecked that I’m using the same develop commit and cleaned the project and what so ever. I’d love to help more on this issue since this is still blocking me, so please let me know if there anything I can do

    setResizable(true, true);
    setResizeLimits(400, 300, 800, 500);
    getConstrainer()->setFixedAspectRatio(1.5);

    setSize (400, 300);

What do you think of the proposition of making setResizable(false,true) work:

  • Use the JUCE resizable corner, which works great
  • Disables the host resizing window (by indirectly returning false via the VST3 sdks canResize())

This would still be the best fix for me, since I actually for other reasons don’t want the plugin to be resizable from all corners. If I’m right currently the only way to disable the resizing done by the host is by calling setResizable(false, <true/false>) in the plugineditor

These values don’t make sense. 400:300 = 1.33333 not 1.5
800:500 = 1.6

You are telling JUCE to use a fixed aspect ratio of 1.5 and then use 1.333333 as you minimum and 1.6 as your maximum.

setResizeLimits(400, 266, 800, 533);
getConstrainer()->setFixedAspectRatio(1.5);
setSize (400, 266);

Looks more sane. Maybe that’s the whole issue?

Fair point! I just used some arbitrary values here to be fair, since these issues are also happening with my product code with a valid aspect ratio. But I’ve just tested it in an empty product with a valid aspect ratio as well and I can still reproduce the issues in both ableton and fl studio on Windows

    setResizable(true, true);
    setResizeLimits(400, 300, 800, 600);
    getConstrainer()->setFixedAspectRatio(1.3333f);

    // Make sure that before the constructor has finished, you've set the
    // editor's size to whatever you need it to be.
    setSize (400, 300);

Hey Ed, sorry to keep bugging you with this, but we are still experiencing this issue
and it’s a major blocker.

What do you think of the proposal to enable the setResizable(false,true) option.
Here’s a diff to get the idea for what I’m suggesting. I’ve tested this and this works so far:

Is anyone else here able to still reproduce this? Would be helpfull to get a confirmation from someone else for Ed as well I think.

I was able to reproduce the issue you described and I’m not sure there’s anything we can do in the resizing code to fix it. It seems to be just a quirk of some DAWs that if they try to resize the VST3 editor to a size that it doesn’t support it results in the window moving whilst staying the same size.

Modifying the behaviour of AudioProcessorEditor::setResizable() to allow host resizing and user resizing via the bottom-right corner resizer have different values is probably the way to go here and I think that was always the intention of that method since the first parameter name is allowHostToResize. The documentation in that class with regards to resizing/constrainers isn’t particularly clear so it’s easy to see why it might be confusing. We’ve added this change and updated the docs to be clearer on develop in 5a59c92 - please let us know if this fixes the issue for you.

1 Like

Awesome, thanks for this fix! I always asumed this was the intent of the method as well. We will test this out shortly!

Still no dice on the AAX resizing issue. Any word on that fix?

1 Like

Thanks! It kinda works when calling setResizable(false, true) after setResizeLimits, because otherwise setResizeLimits will magically reenable “resizableByHost”.

If I use setResizable(true, true), I’m getting a pluginwindow that magically increases in size every time I open the plugin using a display scale factor of 125% and “per monitor aware”, so that’s not an option I guess…

Somewhat related to this, there are still semi random issues when dragging the plugin window (vst3) between screens with different scale factors in a compatible host (e.g. reaper and cubase). sometimes the window boundaries don’t get updated properly and you can end up with a “cropped” view, or additional blank space.

I tried to disable “per monitor dpi awareness” in the gui basics module settings (with the idea being, once resizing works properly, to leave size completely to the user).
Sadly, there is a very foundational bug that can prevent text editors from working.

Here is what I observed:

when disabling “per monitor dpi aware” on windows, labels can’t be edited properly, because the repaint invalidation area is calculated incorrectly.
see juce_Component.cpp, internalRepaintUnchecked, auto peerBounds = peer->getBounds();
this usually returns the correct (physical) size of the plugin window, but apparently NOT so when called from the keyboard handler (keyboardHookCallback, entering a char in text editor).
this leads to the wrong area being redrawn.

tested with reaper and cubase 10.5 on windows 10, with a primary display @ 125% and secondary displays @ 100%

I understand that all of this is terribly intertwined, thanks for your continued work on these topics!

looks like the not-working labels are a problem with 6.0.8 now too, even if “per monitior dpi” is enabled.

has it been fixed in juce 7

1 Like