This issue only happens in Windows Bitwig host when desktop DPI scale is set to higher than 1. The mouse position in MouseEvent struct in mouseWheelMove callback has an extra fixed deviation. In addition, the mouse wheel actions trigger an extra mouseMove callback with the same deviated position deviation.
We have a brief browse on JUCE’s win32 event handling. It seems mouse position for wheeling events are obtained differently from all other mouse events (in HWNDComponentPeer::peerWindowProc).
I used the Audio Plugin Example and just painted the location of the mouse wheel event onto the PluginEditor component. I tried it with JUCE 6.1.0 and develop, Bitwig Studio 4.1.6. I experimented with 125% to 200% scaling settings.
Do you have components maybe that are scaled in JUCE?
Can you share some more pointers about how to reproduce the issue?
Thank you for this hint. I can reproduce the problem and looking further into how to solve it.
Removing the WindowsHooks from the VST3 wrapper really seems to be a working solution in the case of Bitwig. There is a chance though that it will break one of the many DAWs that made the addition of this hook necessary.
Generally the hook is working well, but when scaling is enabled Bitwig is trying to block it, but it still gets triggered in a small rectangular area in the upper left corner of the editor. When this happens Bitwig seems to intercept/change the message before it’s sent to the window peer, hence the observable offset.
I’ll update the thread as I find out more about the solution.
