FPS Timer ?

What is the standard solution for determining elapsed time in a rendering loop? I’ve searched the forums and seen references to System.getTimeMillis, but I’ve also seen references to a higher resolution timer capability that was expected to migrate to the core API from com.sun space. Does anyone have current info on this?

Java 1.5 and up: System.nanoTime();

Thank you. :slight_smile:

Oh, I almost forgot to mention it goes totally bezerk on speed-step (like) processors. This is your one chance to go back in time or flashforward every once in a while.

I thought in LWJGL you have Sys.tick(); (or something like that) that has reliable 1ms precision.

Yikes!! Damn.

Yeah, but I hate to link an entire library for one function! I’m surprised there isn’t a high res timer built into the core API, or into JOGL, anyway.

so am i! a native highres timer like in LWJGL would be a great feature for jogl.

I agree, can we have one please!?

I’m not sure if there is a solution for systems that use speed-step or throttling, you can read this blog for a lot more detail about the use of clocks and timers in the Java VM: http://blogs.sun.com/dholmes/entry/inside_the_hotspot_vm_clocks. But if there is a solution it would be better to ask Sun to fix the implementation of System.nanoTime() than adding yet another implementation IMHO.

Another interesting source of information is this bug report: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6440250

LWJGL timer would only be needed for Windows. I believe on Mac and Linux, currentTimeMillis() already has 1ms precision.
For a guaranteed 1ms timer, maybe it’s an idea to have a very small library for getting a 1ms precision timer which just uses System.currentTimeMillis() on non-Windows OS-es, but uses a little DLL with the same timer from LWJGL on Windows. I think that would be better than integrating it in JOGL (timing != OpenGL).

Because timing is such a difficult thing to get right, I doubt that ‘fixing’ System.currentTimeMillis() on Windows is viable without creating new problems. System.currentTimeMillis() basically works fine now for what it was intended to do.

edit: Regarding System.nanoTime(), my understanding is that it’s not so much a problem with it’s implementation, but that it’s just sensitive to hardware quirks. You might be able to work around it by disregarding results that are likely to be wrong.

Thanks for the input, guys.

After reading Holmes’ blog article I agree, I think nanoTime is what I’m looking for. It sounds as if it’s as close to a reliable, portable solution as I’m likely to find, and I’m more interested in measuring elapsed time than triggering events on a timed basis, anyway.