I'm trying to optimize the drawing of some things to a component and I've come across something I don't quite understand. I call repaint() each time the my data is updated( a lot). But I've noticed that my application runs the same amount of CPU whether my paint() routine is actually drawing something or not. Removing the call to repaint() will dramatically reduce the CPU load, but calling repaint() with an empty paint routine makes no difference? Is this normal? For what it's worth I'm currently testing on Linux.
You need to profile your app properly and see where the real hot-spots are.
It's either impossible or just a very inefficient use of your time to try to track down performance problems by only looking at the overall CPU usage.
Fair point.
I've attached a screengrab of my profiler output below. All the expensive drawing functions are called as a result of my calling repaint() at a fairly rapid rate. But I don't actually do anything in that paint() method. It's empty. I'm at a loss as to how to make my paint method more efficient, when even an empty one is causing a CPU spike. If I remove the call to repaint() everything behaves as normal, and I no longer see any references to those drawing functions. I'm not looking for spoon feeding here, merely pointers to where I should start looking :) Thanks.
It's silly to say that an empty paint() method consumes CPU - clearly something is doing a lot of drawing, and if it's not your paint method, then it must be that of some other component.
Maybe your repaint() call is repainting far more than necessary, e.g. redrawing the whole window when it doesn't need to?
Thanks. That particular component is most likely a red herring then. I will start looking elsewhere. Profiling is so much fun.
Doesn't your profiler show stack traces? That's normally how you go about tracking down things like this.
Is your Component opaque? If not then the Components behind it will also have their paint method called for compositing purposes.
As Jules, says, a full callstack should show you which Components are taking the time to render.
Thanks Dave. I'm still tying to decipher callgrind's output and display modes, but having lots of fun along the way!
Got it. Thanks for the help. It was another control that was being repainted in the background.
I have another quick question about this. As has been pointed out, working with opaque components has seriously improved performance. But I've noticed the following behavior which I find a little odd. The following component hierarchy prevents redrawing of my entire editor:
Parent: FFTManager(NON-opaque)
Child: FFTComponent(opaque)
Child: FFTComponent(opaque)
While this setup results in my editor being redrawn on each FFTComponent update:
Parent: FFTManager(opaque)
Child: FFTComponent(NON-opaque)
Child: FFTComponent(NON-opaque)
Is this expected behavior? I was rather hoping that setting the parent FFMManager to opaque would be enough to prevent the underlying editor from redrawing.