Lower GUI repaint priority during CPU-heavy calculations

That’s very interesting, thanks for the insight. Unfortunately, I use the juce::Graphics object and it’s drawRect methods etc. for my rendering, so I can’t disable component painting altogether.

To round this thread up:
My actual issue was the tons of repaint() calls per second. By setting a shouldRepaint flag to true instead, and checking if a repaint should be done at a limited frequency using a Timer, my problem was solved.

1 Like

I have to correct myself:
The mass of repaint calls had nothing to do with the bad performance. I verified this by executing for (int i = 0; i < 1000; i++) repaint() where I would usually call repaint() - the performance is still smooth now, which makes me believe that the OS has a reasonable internal timer fetching the repaint() dirty flag itself.

My actual mistake was that I locked the Message Manager Thread in the Audio Thread to be able to register a ChangeListener… Pretty dumb in hindsight, but I got that sorted out now with the atomic boolean approach suggested by @Xenakios.


That is correct, the repaint() does not execute the individual paint() calls directly. But sending loads of repaint() calls still mean, that it is all painted every time, so there is still a penalty for loads of unnecessary repaint() calls, but in a way less figure than you experienced it.

A lock in the AudioThread is indeed the much better explanation for what happened. I don’t comment that, happened to the best :wink: