I recently updated the version of Juce we are using from 8.0.1 to 8.0.4 and very quickly noticed some strange behaviour. We have a VST3 plug-in running in a very basic wrapper (it’s just a shell that uses the Juce VST3 host classes to host a plug-in and pipe some audio in for testing purposes).
After the update, we noticed that about 30 seconds into playing the audio, the plug-in continues to update graphically and process audio as expected, but we can no longer interact with it. In this particular plug-in, the GUI is relatively complicated so when audio is playing, there are lots of elements being updated. After the audio has finished being processed, the GUI starts responding again.
A binary search in git narrowed the issue down to commit 29213e0 on the 6th of September. This commit is related to a change in the Fonts, and I can’t see anything that directly relates to the issue I’m seeing.
To try and track down what might be going wrong here, I added a call to PeekMessage() in InternalMessageQueue::dispatchNextMessage to log out any messages in the WM_MOUSEFIRST to WM_MOUSELAST range to see if the mouse messages were going missing. Note that this only looks to see if a message in that range is in the queue. It doesn’t handle it, and it doesn’t remove it from the queue.
Whilst the GUI was responsive, the log included lots of MW_MOUSEMOVE messages as I moved my mouse around, and stopped logging when I stopped moving my mouse.
When the GUI stopped responding, the WM_MOUSEMOVE messages reappeared, but they continued to be logged even when I wasn’t moving my mouse.
When I checked which messages were getting handled (as a result of the call to GetMessage, the mouse messages were never in the list. The only message getting handled appears to be the Juce custom message (WM_USER+123), so the mouse messages remained in the queue unprocessed.
From the documentation on MSDN, it looks like the message queue should behave like a FIFO with the exception that the messages are processed with the following priority:
- Sent messages
- Posted messages
- Input (hardware) messages and system internal events
- Sent messages (again)
- WM_PAINT messages
- WM_TIMER messages
It looks like the issue is that there are custom messages being posted to the queue faster than they are being handled. Subsequently, the input (mouse) messages never get a look-in, so the plug-in stops responding.
I suspect that there is a rogue GUI element that is just spamming the message queue when it doesn’t need to, so I’m going to track that down, but I’m curious as to why this specific commit has made this happen.
If anyone has any suggestions, I’m all ears!