Repaints bumpy with spectrum analyzer component?

Question

Hi everyone,
I have created a spectrum analyzer component for the MP3 player part of my open source application Playlist Editor. It works quite well but I currently struggle with some strange paint 'behaviour'.
The component constantly paints amplitude values for a number of frequencies during playback. But although repainting is controlled by a Timer object so that repaints are equally distributed over a given time interval the repaints are done quite bumpy, even with more than 30 repaints per second.
I have done plenty of testing without finding an explanation or solution. I finally prepared a preview of the appliciation with all sources included and a detail description of the issue.
Perhaps I made a completely trivial mistake and there is a simple way of doing the painting differently?
Anyone interested in looking into the component could you please visit http://www.lightdev.com/page85.htm and give it a try?
Your help is most appreciated. Thank you for any help!
Ulrich

Answer 1

I think something in the rendering
cycle must be programmed incorrectly,well, that is what I try to locate...; here is what tests have proven meanwhile
java.util.Timer is not accurate enough to trigger repainting at a constant rate faster than approx. 300-500 ms
with an own timer using the new System.nanoTime() method it is possible to call a method more exact, for instance every 150 ms or even every 10 ms
a call to drawImage takes approx. 0.22 - 0.25 milliseconds
calling drawImage more often than every 150ms does not lead to faster repaints so far (i.e. paints are done approx. every 150ms although drawImage is called more often)
the rendering of such a small component
should also be able to reach at least 10 FPS
(possibly even 50-60 FPS)that is what I got from the document too, but the question is whether or not this can be done with 'normal' calls to paint() or drawImage() or whether there is another mechanism one can/has to use inorder to exectute calls to redraw an image more direct/imediately....
from the other test figures it shows that neither the FFTs nor other computing inside the application take so much CPU load that it would be necessary to put these functions out for testing. There is plenty of CPU time left for faster painting but something stops the calls to drawImage from being executed faster than approx. every 150ms
I'll keep everyone posted with new results but still anymore insights to painting and especially some more direct painting is most welcome!
thanks a lot best regards
Ulrich