Component Resizing

Windows
#1

Relatively new with Juce, currently I’m trying to work around a frustrating issue I’ve found with the automatic resizing of windows across screens.

Here visualized: 4k monitor to the left and 2k monitor to the right.

2019-08-29_17-20-07
2019-08-29_17-20-07.gif972×497 3.79 MB

Any help / making sense of what’s going on here would be appreciated. Best I can tell, this might be dpi related, though getting dpi / scale information and playing around with scaling the widths and heights hasn’t fixed the end result, so far I’ve only succeeded in making the dialog too small, or too big and I’ve yet to have any impact on the size of the the contained AudioProcessorEditor. This same issue isn’t isolated to the DialogWindow class, the same result occurs with the AudioProcessorEditor if I do roughly the same steps. Currently the only reason I have for the wrapping class is just to allow the window to close.

Here’s the related code, inst is an AudioPluginInstance*:

class PluginWindow : public DialogWindow {
public:
	PluginWindow(const String &name, Colour backgroundColour, bool escapeKeyTriggersCloseButton,
			bool addToDesktop = true)
		: DialogWindow(name, backgroundColour, escapeKeyTriggersCloseButton, addToDesktop)
	{
		setUsingNativeTitleBar(true);
	}
	~PluginWindow()
	{
	}
	void closeButtonPressed()
	{
		setVisible(false);
	}
}
...
			if (!dialog)
				dialog = new PluginWindow("", Colour(255, 255, 255), false, false);
			dialog->setName(inst->getName());
			editor = inst->createEditorIfNeeded();
			
			if (dialog) {
				juce::Point<double> mouse_point(mouse.x(), mouse.y());
				if (editor) {
					editor->setOpaque(true);
				}
				dialog->setContentNonOwned(editor, true);
				if (!dialog->isOnDesktop()) {
					dialog->setOpaque(true);
					dialog->addToDesktop(ComponentPeer::StyleFlags::windowHasCloseButton |
									ComponentPeer::StyleFlags::windowHasTitleBar |
									ComponentPeer::StyleFlags::
											windowHasMinimiseButton,
							nullptr);
				}
				dialog->setVisible(editor);
				if (editor) {
					juce::Point<double> mouse_double  = physicalToLogical(mouse_point);
					juce::Point<int>    logical_mouse = mouse_double.roundToInt();

					logical_mouse.x -= (dialog->getWidth() / 2);
					logical_mouse.y += 20;

					editor->setVisible(true);
					dialog->setTopLeftPosition(logical_mouse);

					editor->grabKeyboardFocus();
				}
			}

Also confusing aspect in working through this it’s difficult to judge in the api what functions make use of / whether “logical pixels” or regular ones. I spent a decent amount of time working out that the functions expected logical pixels after noticing that all my windows were appearing way off target but in a scaled way. I’m guessing most of these functions return logical pixels because of all the ones so far they all appear to use logical pixels, eg the dialog->getWidth() / 2 only would make sense functioning if it were logical pixels because that centers the window in the exact right spot for me on the mouse, if I didn’t copy over the physicalToLogical function similar problems with positioning happen for me on the 2k screen.

Important Edit: Not on the latest 5.4.4, I’m slightly behind on 5.4.3*
Second Edit: Played around with windows dpi settings, this appears to have an impact, so I think this is related to the earlier post. I’m going to test their code and see if it helps.

#2

All of the public JUCE API that you’ll interact with uses logical pixels, physical pixels are only used under the hood when interacting with the native APIs on Windows and Linux. This means that, in theory, you shouldn’t need to interact with the native scale factor of the display at all as JUCE will just handle all of this for you, but the exception to this is plug-ins as things get a little more complicated when you are hosting a plug-in in your process or running as a plug-in in a host’s process as, on Windows at least, the two can have different DPI “awarenesses”. One workaround for this which we use in the JUCE plug-in host is to disable the DPI awareness of the plug-in window as this allows Windows to bitmap stretch the plug-in to be the correct size. This needs to be done at the point at which the plug-in window is opened and can be done using the ScopedDPIAwarenessDisabler class - see this line.

#3

Thanks, I was digging around trying to work out how to disable the thread awareness of the plugins because I wasn’t using OpenGL. I’m not using the PluginGraph class, what I found was this line:


which looks like the disabler is being turned off right before the window is opened.

If I’m reading this right, it seems like it should be the plugin that should report whether its dpi aware. If that’s the case I’m less worried about it, at the moment though all the plugins I’ve tested seem to have this dpi awareness mismatch.

Also trying out the dpi disabler before a createEditorIfNeeded function I’m finding Bias FX now draws a black screen. While I do think this is dpi related I’m not sure this was the solution, it seems to me that the size of the component being drawn is not quite right when the plugin is dpi aware on other monitors.

Been testing with the ScopedDPIAwarenessDisabler, what I’m finding is that like in your example code I’m having issues with particular plugins, namely BIAS FX.