Plugin Windows, VST3, DPI Awareness Issues

Audio Plugins
1

I’m basically stumped on how and when to use the juce::ScopedDPIAwarenessDisabler. It seems pretty much impossible to not hit the assertion HWNDComponentPeer::createWindow about mismatched hwnd and window dpi-awareness.

There’s two main reasons I can see for this:

  1. When you create the plugin, that sets the internal hwnds, message thread DPI awareness right? So that stays static for the lifetime of the AudioPluginInstance
  2. The window might come and go with the user enabling/disabling DPI awareness during the plugin lifetime. So the only way around that I can see is showing the user a message to save and reopen the Edit/project if they don’t want problems
  3. For VST3 plugins, they seem to have an internal embedded hwnd which gets created when the plugin AudioProcessorEditor gets added to a window (e.g. through setContentNonOwned), not when the editor is actually created

So it seems pretty much impossible to keep all of this in sync. As far as I can tell, to get things behaving correctly we need to do two things:

  1. Ensure a ScopedDPIAwarenessDisabler is active if the isPerMonitorDPIAwareWindow (juce_messageWindowHandle) returns false whilst a window is created
  2. If you want to change the DPI awareness of a plugin, you need to delete the instance and recreate it with a ScopedDPIAwarenessDisabler active or not

Given the above, wouldn’t it be simpler to just have an accessor to isPerMonitorDPIAwareWindow (juce_messageWindowHandle) and then internally create a ScopedDPIAwarenessDisabler so it matches? At the very least we should have an accessor so we can attempt to put our own ScopedDPIAwarenessDisablers in place.

Does that make sense/sound sensible?

2

N.B. This is also tricky to get right if you show a PopupMenu from a window holding a plugin as you have to make sure you have a ScopedDPIAwarenessDisabler in place when you show those too.
It would help a lot if this was done automatically.