Skip to main content

Progress Listener Architecture

No replies
Joined: 2003-07-08


I had a thought concerning progress bars and the current progress listener architecture (I don't think I've mentioned this one yet, though I ran across the problem some time ago).

In the current architecture a ProgressListener registers with some object to receive progress notifications (progress started, finished, % completed, etc). These notifications must be fired off in a background thread and then perhaps posted to the gui thread via SwingUtilities.invokeLater. The gui then receives the notifications and updates the ui accordingly.

However, when using this architecture I found that my reading of bytes from an InputStream (in this case, what I was monitoring) was slowed down tremendously. Of course I was being naive and firing off a progress message for every byte/byte buffer read. It brought up a concern however -- that naive implementations may bring programs to a crawl and the blame may well be placed on Java as opposed to the offending code (how many times have I had to deal with this one?!!).

Also, it seemed to me that the optimal number of messages would be one every 1/25 of a second or so (25fps) since there's no point passing messages faster than the eye can detect and very poor form to pass messages slower than the eye can detect.

However, the listener architecture precludes this kind of logic -- unless all listener sources buffered messages and had a separate thread that fired off every 1/25 of a second and sent the latest progress message to the gui. Another approach would be to have the progress monitor ask the background task what its progress was every 1/25 of a second (with the use of a Timer or something).

A utility class was provided that did the message buffering properly might be the best approach. Just a thought. Should I file an RFE for it?