ComboBox dropdown position issue on Windows HiDPI

Platform Specific
1

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.

image
image1498×649 66.1 KB

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

2

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)?
3

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.

4

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.

5

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

6

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.

7

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

8

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

Thanks for your help.

Best,
Andreas

9

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
10

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.

11

Up

12

@op414 @archie3d I’ve finally got around to trying to debug this issue, but I’m struggling to reproduce it. I’m testing with the latest develop branch on Windows 11.

First, I configured my system to match that of @archie3d :

  • Main display (laptop): 125% scaling
  • Secondary display (external): 100% scaling

Then, I built the DSPModulePluginDemo as a VST3 and loaded it in REAPER 6.45. This plugin has a combo box listing several different audio effects, which opens with the current effect selected. I tried moving the window so that the “Audio effect” combo box was positioned in each corner of each monitor in turn (8 positions total) and opening the menu. In all cases, the menu opened at the expected location.

Next, I tried making the menu longer by adding 100 extra redundant items to the end of the menu, then tested again in the same way. Again, the menu always opened at the expected location.

To investigate this further, it would be useful to know the following:

  • Do you see the same behaviour as me when running the test procedure above?
  • If you see the same behaviour as me, are you able to modify the test procedure so that the issue is triggered? If so, please detail what changes you need to make to the test procedure.
  • If the behaviour on your machine differs to the behaviour on my machine, please provide some more details about your system (JUCE commit used for testing, Windows version, monitor arrangement, monitor resolutions, plugin host used) so that I can attempt to match your setup more closely.
13

@reuk, thanks for looking at this. The problem I have is in a desktop application not in a plugin.

14

Thanks. I just tried out the DSPModulePluginDemo standalone and the combo box position seems alright there too, although the window size sometimes seems to change unexpectedly when dragging the window between monitors. This issue seems to go away when using a native titlebar rather than the JUCE titlebar. I’ll investigate this tomorrow.

Does your app use a native titlebar or a JUCE titlebar? Do you see any issues in the DSPModulePluginDemo standalone?

15

Hi @reuk, thanks for looking at this! We are using a native title bar. Also if I remember correctly, the main display is under the the secondary display, meaning the secondary display coordinates have negative Y values, which might be a cause of the problem. Will reproduce on Monday and give more info ASAP.

1 Like
16

Hi @reuk, you have fixed this already with this commit:

I was using JUCE 6.1.2, but the latest 6.1.4 is fine.

1 Like
17

Awesome, thanks for finding the relevant commit!