Opening window from plugin has wrong DPI

General JUCE discussion
1

On Windows, opening another window from a plugin has wrong DPI. Works fine in standalone, but not from VST. Any reason for the difference?

2

I don’t know the answer to your issue, but I do know that, in general, you should avoid doing that if at all possible.

Plugins are notorious for having problems when opening other windows, most notably with crashes if the user closes the DAW (or just the session/song) while any such sub-window is open. (Even popup menus can cause problems if they are not all automatically closed prior to the Editor being destroyed.)

We have removed all alerts and dialogs and replaced them with Components that are hidden by default. To keep them acting as modal-style windows, we make them have backgrounds that are the same size as the plugin itself, so that nothing from “behind” the window can be clicked on by the user.

1 Like
3

It’s a log window, so it’s pretty much just used by the dev team. But every once and awhile a user needs to use it to report an issue and it tiny. The more annoying thing is, we usually work on the standalone app, so we position the log window where we want it. Then go to VST, and it’s tiny, so make it bigger. Then come back to standalone, and it’s off the screen.

4

I really don’t get how this works. In standalone when I query the displays, their sizes are logical pixels and the scale is correct. In a plugin, when I query displays, they are always in physical pixels and the scale is always 100%. Therefore my window appears too small. Makes sense so far.

But why is my plugin window the correct size? And any menus it opens? Stepping through the VST3 wrapper, I can see the host can send the scale factor for the plugin – but it never does. So why is the plugin, menus and any floating components the correct size?

5

This is so weird. If I open my log window from the editor constructor, or from a timer, the log window opens with with the incorrect scale. I’ll I create my log window from a menu item, then the scale is correct.

6

I want to support the @RolandMR request.

I’m in the same situation and I’m trying to find a solution without modifying the juce framework, but it is impossible…

The main problem is that in the juce_Windowing_window.cpp it uses ! JUCEApplicationBase::isStandaloneApp() to verify the DPI management. Doing this if you are a window hosted in a daw the DPI management is simply skipped.

A solution could be to verify if you are the plugin-hosted window or not replacing the isStandaloneApp() … Or if juce doesn’t want to support this natively, simply give some API to manage the scaleFactor from outside.