Is there a more accurate method to get change in time other than currentTimeMillis? I really want a higher resolution timer. Edited by - ao on 3/6/00 9:41:01 PM

Look up "QueryPerformanceTimer" on msdn.

Hmmm, I did a search on msdn and found nothing for
QueryPerformanceTimer. Do you maybe mean QueryPerformanceCounter/QueryPerformanceFreqeuncy?? I know those are some win32 functions for higher resolution timing, but I''m looking for a Java one. If thats not what you were talking about, maybe you could tell me a little more?

Swing has a Timer class javax.swing.Timer It is an event driven class much like a Win32 timer is if you supply it a callback function. Of course you''re target platform will have to be JDK 1.2, but making your own Timer is not that difficult either if you can''t target 1.2.

But the javax.swing.Timer also relies on the System.currentTimeMillis which makes it even lower resolution timer (see below) than the currentTimeMillis timer is (on Win32 platforms the currentTimeMillis value changes approximately in 50-60ms intervals).

The only difference is that the javax.swing.Timer uses the repaint thread to invoke the registrable callback, which makes it safe to use with Swing and lowers its accuracy. This is because there is usually a random amount of lag between timer actually reaching the wanted time and the repaint thread being free to invoke the callback method.

Edited by - javanerd on 3/8/00 12:23:41 AM

Well, from the looks of it currentTimeMillis is about as accurate as I can get.

oops, that was me.

Does Thread.sleep(int millis) method rely on System.currentTimeMillis()?

Nope, the threads that Java uses are native threads, so the Thread.sleep() uses whatever timer is used by the operating system (note: behaviour of threads varies from system to system).

But Thread.sleep() is not a very reliable way to time anything as the "awakening" of the thread depends also on activity of other threads running on the same system and the scheduling algorithm the system uses.

Under WinNT 4.0 I''ve found the sleep() method quite usable: in a game loop just spend the extra time (if any was left) within sleep.

Under Win95/98/98SE using this causes noticeable stuttering of the game speed, the System.currentTimeMillis() and a while loop is much more reliable. I blame for this for the not yet robust thread scheduling of Win95/98, but the reason might be something else.