ComboBox dropdown position issue on Windows HiDPI

Hi all,

we’re seeing an issue with ComboBoxes on Windows where the popup of the ComboBox is opened at a wrong screen position on a HiDPI screen.

As you can see, the scale menu is not in the right place. The actual position changes in relation to the position of the ComboBox component on screen (i.e. where on the screen my editor window is), so I’m assuming the coordinates are just not scaled correctly at some point.

@reuk out of the three Windows HiDPI issues I reported, I’d actually say this one has the most impact, while the other two make stuff tiny and hard to read, this actually has the potential of making the plugin partially unusable, as, depending on where the ComboBox is, when the user clicks on it, they might not even see the menu.

Best,
Andreas

Please check with the very latest JUCE develop and see whether the problem persists. If it does, please provide some instructions and ideally a minimal code example which will allow us to reproduce the issue.

Some information which might be useful to us:

  • Does the issue affect a standalone app or a plugin?
  • Does the issue happen in a specific host? Does it happen in a specific plugin format?
  • Does the project modify the plugin’s scale in a particular way, such as setting the global scale factor or adding an AffineTransform to a subcomponent of the editor?
  • Do you need a specific hardware configuration in order to reproduce the issue, e.g. multiple monitors in a specific arrangement?
  • Does the issue affect JUCE demo plugins with dropdown menus (such as the DSPModulePluginDemo)?

With fa17310dd, if I open the DSPModulePluginDemo VST3 in Reaper 6.29 I’m able to drag the editor window between a HiDPI display and a non-HiDPI display. The editor is rescaled, and the popup menus open at the correct locations on both monitors.

I’ll test with the latest develop tomorrow. In the meantime I’ll answer the questions I can right now

  • Does the issue affect a standalone app or a plugin?

It’s a plugin

  • Does the issue happen in a specific host? Does it happen in a specific plugin format?

So far I’ve tested with Reaper 6 and Ableton Live 10 with HiDPI enabled, VST2 and VST3. Pro Tools doesn’t do HiDPI, so no problems there (well, apart from the ugly rendering)

  • Does the project modify the plugin’s scale in a particular way, such as setting the global scale factor or adding an AffineTransform to a subcomponent of the editor?

Yes, there’s a global scale factor of .85 on the editor.

  • Do you need a specific hardware configuration in order to reproduce the issue, e.g. multiple monitors in a specific arrangement?

No, any HiDPI display will do the trick, regardless if it’s the only display or not.

OK thanks, I’ll try scaling the editor by that amount and check whether I can repro the issue.

I’ve tried modifying the DSPModulePluginDemo source, to add in an intermediate editor component:

struct ScaledEditor : AudioProcessorEditor
{
    ScaledEditor (DspModulePluginDemo& proc)
        : AudioProcessorEditor (proc), subcomp (proc)
    {
       #if 0
        Desktop::getInstance().setGlobalScaleFactor (0.85f);
       #else
        subcomp.setTransform (AffineTransform::scale (0.85f));
       #endif

        addAndMakeVisible (subcomp);

        setSize (800, 430);
        setResizable (false, false);
    }

    void resized() override { subcomp.setBounds (getLocalBounds()); }

    DspModulePluginDemoEditor subcomp;
};

struct DspModulePluginDemoAudioProcessor  : public DspModulePluginDemo
{
    AudioProcessorEditor* createEditor() override
    {
        return new ScaledEditor (*this);
    }

    bool hasEditor() const override { return true; }
};

Testing this version of the plugin with the setup I mentioned earlier, the PopupMenu windows display at the expected location, whether I set the desktop scale or apply a transform to the editor.

For me to investigate further, it would be helpful if you could send a minimal code sample which demonstrates the problem, or provide instructions for modifying the DSPModulePluginDemo so that it exhibits the problem.

Thanks for your help so far, I’ll try to find a minimal example tomorrow. It’s also not my own original code, but code I took over from another developer. I’ll have another look at what else he might be doing to the comboboxes to create this behaviour and see if I can break the DSPModulePluginDemo accordingly :wink:

Best,
Andreas

Sorry for the late reply, I can confirm that it works with the latest develop version (1634d9f42).

Thanks for your help.

Best,
Andreas

Hi, I am still experiencing issues with the ComboBox pop-up positioning on Windows with the latest JUCE 6.1.2.
My configuration is: main laptop screen (scaling=1.25) plus an external screen (scaling=1.0).

The pop-up position is fine on the main screen (scaling=1.25) but is of on the external screen. Setting the main screen scaling to 1.0 fixes the issue. Also the pop-up positioning is correct when there are no selected items in the ComboBox or when the height of the pop-up is small enough. I’ve tracked the issue to the call to the PopupMenu::HelperClasses::MenuWindow::ensureItemComponentIsVisible(). Here the pop-up window position gets adjusted depending on the height (against the scrollZone, hence the effect of the minimal height). The pop-up does not have any scrolling, so I am not sure why it heights gets adjusted against PopupMenuSettings::scrollZone.

1 Like

Also experiencing this, any change this could get fixed soon? We have just updated to 6.1.2 and it would be a shame to have to rollback because of this.