VST and HiDPI

SDK for VST 3 audio plug-in and host development.
Post Reply
bradr
Posts: 18
Joined: Tue Jun 21, 2016 11:06 pm

VST and HiDPI

Post by bradr » Thu Aug 29, 2019 7:00 am

Is there a way for a plugin to declare to a host that it supports HiDPI monitors?

I ask because my host program (Cantabile) currently assumes plugins are unaware of HiDPI and uses Window's Per-Monitor Resolution support to display those plugins in low resolution - even though the rest of Cantabile is running in high-resolution mode. This causes old plugins to be scaled up to a usable size and works well for most plugins.

Recently however it seems that more and more plugins either have some sort of HiDPI monitor support built in and/or a scale setting that can be used to manually scale up the UI. These plugins don't need the low resolution support from the host and often the plugin/host clash resulting in a messed up display or other weird artifacts.

It'd be nice if a plugin had a well defined way to indicate that it doesn't need any scaling/DPI support from the host.

Arne Scheffler
Posts: 297
Joined: Mon Jun 20, 2016 7:53 am

Re: VST and HiDPI

Post by Arne Scheffler » Thu Aug 29, 2019 11:10 am

See pluginterfaces/gui/iplugviewcontentscalesupport.h

Cheers,
Arne

bradr
Posts: 18
Joined: Tue Jun 21, 2016 11:06 pm

Re: VST and HiDPI

Post by bradr » Fri Aug 30, 2019 1:26 am

Thanks Arne,

That sounds useful. So under Windows, would the recommendation be to use a DPI aware thread context for VST 3 plugins that support this interface and a DPI unaware context for VST 2 plugins and VST 3 plugins that don't?

One concern I have here is that in order to determine if the plugin supports HiDPI the host would need to create the plugin instance, create the IPluginView, query for IPluginViewContentScaleSupport, call setContentScaleFactor and then check the return value just to determine if HiDPI mode is supported. By this time the plugin may have already performed actions that are dependent on the thread DPI awareness context and it might be too late to change.

eg: suppose a plugin creates its GUI window handle in IEditController::createView() and reparents it IPluginView::attach(). That window handle will have the wrong DPI awareness context by the time the host has determined it supports HiDPI and wants to switch the thread context.

In Cantabile I've got to great lengths using Windows per-monitor resolution support to scale up old plugins so they appear at a usable size on hi-dpi monitors - while simultaneously allowing Cantabile's own UI to run in high-resolution. What I've found is that in order for this to work with plugins that don't support HiDPI the thread DPI awareness context needs to be set to DPI_AWARENESS_UNAWARE at every entry point into the plugin . Any time there's a mismatch and the plugin isn't completely isolated in this way things tend to break in strange an unexpected ways.

In other words for this to work well with unaware plugins, the host needs to call the plugin on with an unaware DPI context from the very moment the plugin is loaded.

Suggestion: what if the host could call IPlugView::isPlatformTypeSupported("DPI_AWARE_HWND") and the spec makes it clear that if you support this, then the thread context may be switched and the plugin needs to be prepared for that.

Brad

Arne Scheffler
Posts: 297
Joined: Mon Jun 20, 2016 7:53 am

Re: VST and HiDPI

Post by Arne Scheffler » Fri Aug 30, 2019 8:06 am

The IPlugView should only create hardware resources when the attach() method is called. So you should be safe to first create the plugview instance and then check for the IPluginViewContentScaleSupport interface before calling attach().

Cheers,
Arne

Post Reply