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
