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:
- When you create the plugin, that sets the internal hwnds, message thread DPI awareness right? So that stays static for the lifetime of the
- 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
- 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:
- Ensure a
ScopedDPIAwarenessDisableris active if the
falsewhilst a window is created
- If you want to change the DPI awareness of a plugin, you need to delete the instance and recreate it with a
ScopedDPIAwarenessDisableractive 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?