HiDPI and FLStudio

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!

I rebuilt with Juce 5.1 to test, and I’m pretty happy with the High DPI support in Studio One 3.5 and FL Studio 12 though I’ve found that Juce pop-up menus are coming up too small (as though they’re not recognising the double resolution sizing the rest of the plugin UI is now picking up correctly).

Nothing special about them, I’m just making an instance of a juce::PopupMenu, adding items to it, setting a look and feel, then calling show() on it. Can I do anything differently to get them larger?

I think this was addressed here: Breaking Change: PopupMenus now scale according to the AffineTransform and scaling factor of their target components

I found it’s necessary to use showAt or the PopupMenu::Options to make this work by attaching to a component, so show() been a bit broken by this change.

I’m also using TooltipWindow and that suffers from the same problem. I don’t think I can attach that to a component though because the recommendation is to use it in a shared resource pointer (otherwise there are issues with multiple plugin instances).

I’m finding the detection of whether a pop-up is too long to fit on the screen is not working on Windows High-DPI mode. Usually if it is too long then the pop-up appears higher up so everything fits, but this isn’t happening and it just falls off the bottom of the screen without scrolling or making columns.

– Edit: Suggested a fix here: Breaking Change: PopupMenus now scale according to the AffineTransform and scaling factor of their target components