I have an ongoing issue where the repaint area on OS/X is far, far too big - and thus my program's CPU usage becomes extremely high.
My main page has a cursor moving in front of a waveform. Unfortunately, even tiny cursor movements generate a repaint for the entire waveform. When the cursor is moving rapidly, as it does when it is entirely zoomed in, this results in my program being so CPU-bound it won't even reply to menu commands.
I first encountered this issue last year
. The code has changed a lot since then, we've finishing through beta testing and found it solid, but I still have this issue.
I have instrumented my code - I am never directly calling repaint. All I am doing is moving this tall, thin (<10 pixels) cursor in front of my generic Component, and yet when paint is called, all or almost all of the visible canvas is repainted every time.
I had some complicated hack before involving internalRepaint - which doesn't work any more. I could rewrite it using CachedComponentImage - but when you look at that solution, you can see why the internalRepaint hack was stupid.
Basically, what I'd have to do was implement CachedComponentImage but simply ignore any calls to invalidate, instead invalidating "by hand".
This is a terrible solution. It resulted in bugs: when I brought up the "about" screen (a floating component), it would (of course) mess up the waveform and it wouldn't know about it. When I minimize and maximize, it (of course) doesn't know it needs to repaint and the whole waveform is messed up - I never even managed to fix that issue.
My current solution is simply to prevent the user from zooming in too far so the cursor can't move too fast - but that's really lame
since that makes the minimum window about 10 seconds.
I'm VERY open to the idea that it's some bug of mine, but I'm hard-pressed to see what it could be now I have everything instrumented... I move the thin component a few pixels, and then I get a repaint for a huge area, my code literally isn't called in the interim.