My own juce plugin has scaling issues in juce plugin host, both with and without DPI awareness toggled.
As a sanity check I tested with the most popular free compressor (AudioDamage RoughRider 2), inside Juce Plugin Host, - both master and dev branch. It looks like this on Windows with 150% scale monitor.
I was just about to post about a similar issue, but I suspect it’s another aspect of what OBO is asking about. I’m writing a JUCE-based plugin host, and I use Desktop::setGlobalScaleFactor for scaling my app’s own GUI. However, it also scales all the windows I create to contain each plugin’s GUI, without scaling the contents, so they look like the first of OBO’s screenshots. This is the case for all plug-ins, so I don’t think it’s related to OpenGL at all. Can anyone tell me how to create DocumentWindow-derived windows that override the global scale factor (or suggest a better approach)?
I cant help thinking that trying to fix “DPI awareness” is a mistake on the JUCE team side. The Juce Plugin Host simply don’t work on Windows since JUCE 5 or so. And it has caused a rabbit hole of quick-fixes for various hosts, and we devs don’t know what to expect anymore.
Traditionally, a plugin knows its own window size. It can also query the DPI of the monitor. As of now, no-one knows if that size is physical or virtual pixel sizes.
Please get back where a pixel is pixel. This way old plugins look small on high DPI screens, but at least then their devs can fix them, instead of trying to fix it from the outside.
My apologies, OBO. When I first commented, I thought we were dealing with two aspects of the same underlying issue. The only reason I commented again with a solution was to help people searching this forum in future, by keeping question and answer together.
But I stand corrected. The core issue you posted about appears to be a separate one, and I join you in asking Roli and the community for guidance.