Feature Request - Timer with 1ms accuracy!

[richardl]

Would it be possible for JOGL to incorporate an accurate timer with 1ms precision please? Under Windows, System.currentTimeMilis() has always had poor precision.

System.nanoTime() looked like it might save the day, but it is problematic on multi-core AMD Windows boxes (time travel anybody?).

I strikes me that timing is critical for the smooth display of real-time 3D graphics that it would be a worthwhile addition to an already great solution.

Yours hopefully,
Richard.

[emzic]

i second that feature request!

LWJGL has a very good timer! why does jogl not have one?

but 1ms precision is still not enough! todays graphicscards can render small opengl apps beyond 1000fps, which would result in a zero-time difference between frames!

the jogl gears demo gives 1200fps on my GF8600.

so on windows i would suggest an implementation with the WinAPIs QueryPerformanceCounter.

thanks!

[cylab]

Don’t know, always thought that System.nanoTime() already uses QueryPerformanceCounter and the multi-core problems are caused there.

[CommanderKeith]

You can wrap System.nanoTime in your own static class and do a check that the last value isn’t greater than the current value.

[oNyx]

@cylab

Don’t know, always thought that System.nanoTime() already uses QueryPerformanceCounter and the multi-core problems are caused there.

Yes, it does use QPC. That’s why it’s so problematic. (It also has a way higher resolution of 1msec.)

The 1msec timer from LWJGL uses System.currentTimeMilis() on Mac and Linux (it got a 1msec res there) and TGT (timegettime) on Windows.

[richardl]

@emzic

I tend to find that there’s little to be gained from running the GPU faster than the refresh rate of the monitor, which is typically 60 or 100Hz these days. If you don’t lock down to vertical sync and your frame rate exceeds this frequency, then tearing is possible as well as theoretical reduced longevity of the GPU due to the additional load. On the plus side, you could probably fry and egg on the side of your graphics card if you run it at maximum frame rate for a while. Of course, if we were fortunate enough to be given a reliable JOGL nanosecond timer then I won’t be queuing up to complain.

[quote]so on windows i would suggest an implementation with the WinAPIs QueryPerformanceCounter.

I agree with Cylab - the WinAPI call seems to be the source of the problem:

System.nanoTime and multiple cpus/cores

[quote]You can wrap System.nanoTime in your own static class and do a check that the last value isn’t greater than the current value.
[/quote]
I tried that and unfortunately it doesn’t work - still very choppy.

A JOGL timer would be the perfect solution.

[emzic]

@richardl

I tend to find that there’s little to be gained from running the GPU faster than the refresh rate of the monitor, which is typically 60 or 100Hz these days. If you don’t lock down to vertical sync and your frame rate exceeds this frequency, then tearing is possible as well as theoretical reduced longevity of the GPU due to the additional load. On the plus side, you could probably fry and egg on the side of your graphics card if you run it at maximum frame rate for a while. Of course, if we were fortunate enough to be given a reliable JOGL nanosecond timer then I won’t be queuing up to complain.

i am mainly speaking from a developer point here. of course as a user you want to have vsync on, but developers should have it off in order to go for the maximum framerate. and development is nearly impossible when you have time-differences of zero. in a few years only, also mainstream graphics card will be able to push 1000fps+ so this is becoming more and more a problem!

I agree with Cylab - the WinAPI call seems to be the source of the problem:
http://www.velocityreviews.com/forums/t151271-systemnanotime-and-multiple-cpuscores.html

I tried that and unfortunately it doesn’t work - still very choppy.

A JOGL timer would be the perfect solution.

oh, i didnt know that queryperformancecounter was causing this problem. so it is probably not a good idea to use it.

however i still largely support the feature request of a native timer in JOGL!!!

[kbr]

Going forward any utility routine like this will go into the joglutils project. It is likely that joglutils will start to incorporate some native code. Contributions of this or other functionality would be welcome.