HiDPI and FLStudio

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 ?


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:

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.


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 ? :slight_smile:

Bumpity Bump :slight_smile:

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?

Are you on the newest develop? I think @jules fixed all of this recently.

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:

Does this commit (bfc5708) fix it?

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

OK - second try c0f6918

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!