One user reported a slow and unresponsive UI in Ableton 11 on windows when moving a knob on the UI. Even the Ableton live meters start to be slow and unresponsive. VST2 and VST3’s are affected.
He tested all our plugins and only the ones built with JUCE 7 have this problem. Even plugins with few UI elements. The older JUCE 6 builds of the plugins work as expected and are responsive.
I wasn’t able to reproduce this with my virtual windows system in Parallels. I can imagine that this has something to do with the screen framerate and maybe only happens without a VM.
My guess is that moving a slider on the UI triggers a lot of repaint calls that are synced to the screen framerate without any throttling and this finally overloads the main thread on some systems. But this is just a wild guess. I will try to reproduce this on a real windows machine.
This is a huge problem for us. We maybe need to roll back to JUCE 6 if this persists. Any help is welcome! Maybe there is a switch or something we miss?
Edit: We are using the standard JUCE infrastructure for the sliders to update the values with parameter attachments.
I would probably make a test plug-in with a knob that isn’t attached to anything and does nothing when moved, to isolate it to it being related to the knob. There’s plenty of stuff downstream that you could be doing with a knob to cause issues.
Although this issue could be related to the screen refresh rate, the actual cause will likely be different. The recent changes dramatically reduce the number of repaint messages sent, where previously they were completely un-throttled.
Is the unresponsive behaviour due to high CPU load, or is it something different?
Are these changes already in the 7.0.3 master branch?
The user didn’t notice a high CPU load on the Ableton performance meter. Maybe 5 percent, but this measurement maybe only shows the processing thread. Not sure if the main thread is overloaded. I will try to find out.
This raises the question in my mind, how long should we generally be supporting Win 7 as an industry (frameworks and plugins) given Microsoft has stopped providing updates for it now. Would backing out changes in 7 to the state they were in 6 hold back Juce? Windows 10 has been with us since 2015 and it’s still a free update as far as I understand it. What are the reasons people are sticking with Win 7, and how much time should we spend to accommodate those scenarios? How many of us are even maintaining credible Win 7 test rigs to check for things like this as they develop?
I’m pretty sure this is related. Looks like the problem only happens with Windows 7. I didn’t spend more time on this anymore.
I think the changes in the JUCE rendering pipeline affect the performance in a positive way on later Windows systems. Because of this, a rollback is not a solution for me.
Like @Verbonaut I also think it’s time to drop official Windows 7 support. We also don’t have a Windows 7 test machine anymore.
Anyway, it would be great if someone with a Windows 7 system and some time could invest a few hours and maybe find a simple solution for this. But I think I can live without Windows 7 support.