I was testing our plug-ins in Waveform 10 Windows with HiDpi enabled and found a bug.
As I assume it’s built with Juce, I believe this is the right place to report this.
All other hosts I’ve tested (Cubase, Studio One, FL Studio, Wavelab, Bitwig …) expect to send and receive mouse coordinates in screen / device pixels (unlike macOS which works in device-indepent coordinates) - this is a legacy of win32 I believe.
The result is that the context menu is displayed at the wrong coordinates (Waveform must be applying dpi ratio a second time), as can be seen on the screenshot below (using a vst3 official sample just to check it’s not a bug in our code).
What version of Waveform 10 is this? Could be something that has been fixed in JUCE.
Can you replicate it on your machine with the JUCE Audio Plugin Host?
Cool, thanks.
I built the AudioPluginHost too from master #4048a5f, but it doesn’t seem to support HiDPI plug-ins, they all open with system scaling.
Seems strange as I can see there is Steinberg::IPlugViewContentScaleSupport in juce_VST3PluginFormat.cpp and I can see the plug-ins support it by breaking in there.
Yes, thanks I tried the new build with dpi awareness enabled.
The problem is that the plug-in is not drawn properly (it uses OpenGL),
so I cannot test the context menu behavior …
Strangely enough it displays fine in Waveform.
[Update] I added a Juce AudioPluginHost workaround for IPluginContentViewScaling,
and the UI is now displayed correctly, with the context menus appearing at the correct locations.
FYI, the VST3 docs state this for IPlugFrame::resizeView()
Inform the host about the resize of a given view.
Afterwards the host has to call IPlugView::onSize().
And in IPlugViewContentScaleSupport
When a plug-in handles this (by returning kResultTrue), it needs to scale the width and height of its view by the scale factor and inform the host via a IPlugFrame::resizeView(), the host will then call IPlugView::onSize().
However my logs show no Juce based host actually do this.
