So far I’ve been setting the repaintrate on the AudioVisualiserComponents my plugin uses to 80, and it seemed to perform well on my pc, and on a modern mac machine. However, on my friend’s slightly older mac machine, which uses a core 2 duo @ 2.4ghz with integrated graphics, the AudioVisualiserComponents (2 of them) causes my plugin to use a huge amount of cpu, around 60% in fact. Is this normal, and is 80 an absurdly high repaint rate? Is the AudioVisualiserComponent known to not play nicely with older integrated graphics chips? I do find that values below this appear to look stuttery.
For me 30 Hz worked fine. It should not be noticable.
When it looks stuttery, I would assume, it actually doesn’t paint as fast as called.
There was a throtteling in place for repaint rates above 30 Hz on certain OSX versions, I don’t know if that is still in place.
But what helped me in a similar situation, to make sure, that I really only call repaint from one timer. If I had the timer and a callback from a calculation calling repaint, they would fight each other, even making the host’s repaint chopped.
The AudioVisualiserComponent has a timer, if the parent also has a timer to call repaint, maybe they fight each other?
Yeah just tested again in 30hz and looks nasty, very jittery. The parent component does call repaint, but only if I change the value of a certain slider. I tried setting a breakpoint on its paint() and looking at the stack trace but cant find anything useful there.
I ran into the same issue and created an OpenGL version of the AudioVisualiserComponent. It’s pretty hacky right now, and it doesn’t support rendering multiple channels, and looks a bit weird - but maybe it will help
