Till now I happily ignored its existence and my software worked fine on windows. Then after 40k+ lines of code i build my program on mac, and the GUI lags greatly. Jules suggested it is because I am hammering the event queue with messages (previous thread for context: On latest tip, GUI on OSX is much Laggier than on Windows (w. Video)).
Now, I’ve been scouring the forum and JUCE doc, but I am none-the-wiser: Is it that when I call repaint, use AsyncUpdaters, the MultiTimer and other timers, all such messages aggregate into this one queue?
I use all of the above allover my code, without doing much managing to consolidate messages, since I assumed there was some sort of aggregation and management of the timing of these internally in JUCE/OSX/Windows that I needn’t worry of.
AsyncUpdate says in its documentation that such consolidation happens, I assume repaint too, no?
Since I apparently am doing something wrong, what strategies should I use to avoid problems? Should I have my own queues in which I consolidate and re-prioritize changes before calling repaint, triggerAsyncUpdate?
And if yes, how would I go about doing that with repaint, without essentially reinventing it? Because as I understand it, whenever any component needs repainting, I call repaint(), and it is then up to the framework to figure out if only one component needs updating, or also its containers down the tree, and how often repaints should happen to maintain a good framerate. No?
…Could it be that I use AsyncUpdater throughout, when I want to trigger events between the core and GUI threads, instead of using the CallbackMessage class?
Back when I started this project I didn’t know CallbackMessage existed…
Believe me we are as frustrated about this problem as you are. It’s so bad that it can even effect automation recording. We’ve submitted a bug to apple but it’s been marked as a duplicate of another bug which we don’t have access to.
As the laggy GUI even affects the recording of plug-in parameters, we have added a dodgy workaround for this bug in plug-ins. We basically limit the redraw rate to 30 FPS for plug-ins. The flag that enables this workaround can be found here. Can you try setting this to true and test if this gets rid of your problem? If yes, we might add some kind of API method to enable this workaround for non-plugins.
Thanks for the reply! Just now, I updated to the latest tip anew, and without doing anything the problem is gone - the software behaves just as if on windows. And this without my touching any flag anywhere.
In the meanwhile I realized that I was also re-drawing my custom components once too often, which seems to have made the issue worse. I’ll have to fix my code to address this, but in the meanwhile I am happy it works!
Yes you are right: the GUI will run smoother. However, if you start dragging many sliders and have a lot of automation going on, then Logic will start to drop automation data.
Ok, my parameters-sliders syncro are in a timerCallback: slider->setValue (parameter->getValue(), dontSendNotification); In this case I should not worry about that, right?
Thanks!
