where clickClip is a Clip.
ptoye wrote:Unless you want to assume that people are purposely withholding information from you, that is a safe bet.
<later> It's now November - no-one got any ideas?
807197 wrote:Worse, it depends on the system. On some it is 10ms, on others 15ms. Windows only though.
AFAIK, currentTimeMillis() is limited by the accuracy of OS. On Windows, for example, it is limited by a granularity of 15msecs (approximately). Something to do with a "timing interrupt signal" or some other mysterious (for me) aspect of the OS.
System.nanoTime() is accurate, and you can use it to determine the accuracy of your currentTimeMillis().Unfortunately it does not work properly on some dual core processor architectures without a system patch.
This thread, over at Java-Gaming.org was an attempt to deal with timing issues "once and for all".The Windows JVM has a hack built in that as long as a thread is asleep, it will keep the granularity at 1ms to make thread wakeup more accurate. Keeping a thread permanently asleep keeps the granularity at 1ms throughout the runtime of your application. This is also a bug workaround, as constantly switching the granularity can make the system clock go out of sync, at least on WindowsXP and below (don't know about Vista and up). It is a good thing to force it to stay at one setting only.
I'm not sure I would call it successful, but there are interesting ideas presented there. One is that one can sometimes make the OS use a more finely grained clock by running the command Thread.sleep(Long.MAX_VALUE); on a background thread.
Don't ask me why it works, or if it is reliable.
I think it also has the drawback of causing computers to run hotter, which is a problem if someone is running off of batteries.Not really, a sleeping thread does not use CPU cycles. However the OS scheduler will trigger much more frequently of course so that can cause more load, but plenty of applications change the granularity already for the higher precision - it is nothing special to do so really.