Hi Guys,
I’m having issue with my VST plugin in HiDPI mode under FLStudio.
Just wondering, is this just my plugin or other Juce based plugins have the same issue ?
Thanks,
Might be a Juce issue
getDefaultMasterScale only work in Standalone, maybe it should check instead if the host is DPI aware using what it uses in setDPIAwareness.
For what it’s worth, Presonus have made some extensions for the VST and VST3 sdks, including one to let the host tell a plugin what the current DPI scaling factor is:
http://presonussoftware.com/en_US/index.php?id=developer
FL supports this extension, so that would be a good way (in this case) to get the plugin to scale along with the host.
Another option is to simply also check the system DPI scaling for the plugin version. This isn’t perfect (FL for example gives the user the option to choose another factor manually), but it would probably be better than not supporting it at all.
2 Likes
If I remove JUCEApplicationBase::isStandaloneApp() check in getDefaultMasterScale of juce_win32_Windowing.cpp
then resize the VSt host window with the current Desktop scale, my plugin works fine in FLStudio.
We should probbaly add some
typedef HRESULT (WINAPI* GetProcessDpiAwareness) (HANDLE, Process_DPI_Awareness *);
static GetProcessDpiAwareness getProcessDPIAwareness = nullptr;
if (getProcessDPIAwareness == nullptr)
{
HMODULE shcoreModule = GetModuleHandleA("SHCore.dll");
if (shcoreModule != 0)
{
getProcessDPIAwareness = (GetProcessDpiAwareness)GetProcAddress(shcoreModule, "GetProcessDpiAwareness");
}
}
and check the value in getDefaultMasterScale
What is your opinion on this Jules ?
Yes, that sounds like a good plan - now that some hosts are DPI-aware and other aren’t we’ll need to do something like that to figure out what to do.
Maybe Fabian can have a look ? 
Bumpity Bump
It’s on our backlog. There are some inconsistencies in the scaling code in JUCE which makes it fail on Android/Linux for opengl. We first need to fix this.
Any updates on this? This is the main issue we’re seeing with our plugins on Windows at the moment.
Our hands also seem to be tied with using setScaleFactor to do anything about this since transforms to the editor don’t seem to play nice with our OpenGL components / context.
Would it be possible to add some more documentation about how setScaleFactor is intended to be used and how it compliments or should work with the display scaling factor?
We’re on a fairly recent develop (https://github.com/WeAreROLI/JUCE/commit/22c187826daa808eea4912f549c2bb9c04f6c0fe). Were the fixes after that commit?
Looks like updating to the latest develop as of this morning results in the same behavior for us on multiple high DPI machines in FL Studio.
Reporting back here. This was also happening in some Mac VST hosts for us because setScaleFactor is applying a scaling factor to our editor on top of the scale factor we get for the retina display.
Overriding setScaleFactor to do nothing fixes this on Mac for us.
Sorry for all the posts! The same behavior we’re experiencing can be seen in Studio One with the example GainPlugin:
In StudioOne, setScaleFactor is called with “2.0” on a retina Mac, and the GainPlugin is scaled to 2x size:
I doubt this what the host (or user) is intending.
If I modify the GainPlugin to have an openGL attachment, the plugin is resized to 2x, but the content is not:
Hi Fabian, no, this doesn’t change the behavior.
We are no longer getting the setScaleFactor change that originated in handleManufacturerSpecific, but we still get the one that originates in createEditorComp(). Should this also be wrapped in those macros as well?
Also worth mentioning, this issue exists for VST3 on Mac as well.
1 Like
I see this made it into Juce 5.1, is there any information available on what hosts support this extension (beyond FL Studio and Studio One) to help support a testing regime?
Any indication on whether Steinberg will adopt this when they make a version of Cubase that is High-DPI aware?
VST3 officially supports HiDPI via the Steinberg’s IPlugViewContentScaleSupport interface - so any DAW fully supporting the latest VST3 spec should handle hi-dpi correctly.
Vanilla VST2 does not support hi-dpi so various daw vendors have come up with competing VST2 host extensions which are usually only supported in their own DAWs. For now I think we only support FL Studio’s and Studio One’s VST2 hi-dpi extension.
Lookin good based on the commit! Any progress on the openGL scaling issue? I think that’d be the last piece of the puzzle for us to have full scaling support.
Thanks for your help!