High resolution Timers

OpenGL Development JOGL Development
#1

There are significant flaws in the millisecond timer that ships with the normal JDK. I am suggesting that we write a High Resolution Timer to give microseconds, just as Magician did, otherwise I’ve found java animation to be a little jumpy. Take a look at : http://www.javaworld.com/javaworld/javaqa/2003-01/01-qa-0110-timing.html?

I think this is the way to go.

Another question is that If I wanted to write this and submit it back, what is the process to do that. I tried to register as a developer but the jogl admins said they weren’t accepting that role yet.

-Jason

#2

If you read around a bit, there are high resolution timers available in:

  • Java 3D
  • GAGE
  • A hidden on embedded in JDK1.4.2 (which I suppose will be made available properly in the next release?)

Either way, use one of them, lets not get another one going…

Kev

#3

I need a true cross platform API for the timers, Java3D isn’t going to cut it. I have not run across the GAGE timers before and unfortunately there is only a Windows implementation.

The fact that it’s a hidden on JDK1.4.2 and may be exposed in a later version is a trend in the right direction, now all we need is unsigned primitives and we’re all set… :slight_smile:

I will look at writing more of the ports for the GAGE timers, it appears to be not quite what I need, but thanks for the heads up.

-Jason

#4

What do you need better than 1/1000 of a second for? I designed GAGETimer to give at least 1/1000 of a second no matter the platform. That’s about 10 times what is needed to provide 100 frames per second. The reason why there’s only a Windows DLL is because Windows is the only OS that doesn’t provide millisecond resolution.

#5

jbanes et al-

I just looked at GAGE’s AdvancedTimer. It’s the exact right solution.

In defense of moorej’s request, sometimes it’s fun for benchmarking/profiling, like with a ProfileGL.

Cheers, Jason

#6

[quote] In defense of moorej’s request, sometimes it’s fun for benchmarking/profiling, like with a ProfileGL.
[/quote]
True. I was just curious as to why he thinks he needs better than millisecond resolution. There are actual needs for such a timer, but the need is pretty rare and usually has little to do with games. Profiling is “fun”, but any code that runs in less than a millisecond probably doesn’t need to be optimized anyway. :slight_smile:

#7

1/60 second = 0.0167 second or 16.7 millisecond

So if you want get it right you need better than 1 ms…

#8

[quote]Profiling is “fun”, but any code that runs in less than a millisecond probably doesn’t need to be optimized anyway. :slight_smile:
[/quote]
If we are talking about games, you have, let’s say, 5 ms per frame for computations - another 5-15 for rendering. I think that ANY method which comes close to 1ms mark is a target for HEAVY optimalization :slight_smile:

Bigger problem is that you cannot measure too small periods with even good timer, because overhead of measurement comes into play. But this point is well below 1ms.

#9

[quote] 1/60 second = 0.0167 second or 16.7 millisecond

So if you want get it right you need better than 1 ms…
[/quote]
You’re going to need better than a millisecond of play room for each loop due to scheduling concerns of the OS. If you try to deal in the .7 ms range you’re going to get burned.

[quote]If we are talking about games, you have, let’s say, 5 ms per frame for computations - another 5-15 for rendering. I think that ANY method which comes close to 1ms mark is a target for HEAVY optimalization
[/quote]
Yes, any method that is 1ms or greater should be optimized. Anything in the sub-ms range is probably fine. Of course, that assumes that you’re profiling chunks of code such as map drawing vs. sprite drawing vs. collision detection. My own experience tells me that trying to profile the individual components of these tasks is pretty pointless (scheduling tends to interfere) unless you are looking for a “hotspot” that’s eating away at your time.

#10

The Java3D high resolution timer uses the highest res timers available in each OS. The timer is in the utils class so should
be reusable in jogl.

#11

The Windows QueryPerformanceCounter method gives areound 1us resolution on a single processor machine but CPU clock frequency on dual processors. My own timer for Win32 uses the CPU clock counter all the time (for both single and dual processors).

I use this for profiling short sections of code that might typically be called 10s of millions of times. Discarding high value outliers strips out the scheduling interference and gives reliable and accurate results for code taking as little as 10us.

#12

imho a serious programming language should have serious timing tools.

you know… i keep hearing: “java for games? lol that has only 50ms timing resolution!”

come on sun guys. give yourself a little push and roll out a neat little timer for us. please? :-*

#13

I never expected my little request to cause such a fever of discussion. ;D Timers are critical to accurate animation and for profiling. While you may all be looking at uses for jogl that are for games. I am not. I am currently using GL4Java to write the realtime visual portion of simulations, for scientific analysis, and for non-realtime rendering to generate MPEG’s. I do not know if there is a concensus here, I am feeling that there is not, but it brings up a more important question on how the open source community is going to deal with Requests For Enhancements (RFE) for jogl? The jogl site has an area for votes, are we to use that?

-Jason

#14

The explanation I heard, from Jeff I think, for the resolution of currentMillis on windows being so bad was because Sun didn’t want to have to load the Media libs which was slowing startup time of the JVM. I can understand that and I think that is a valid reason, but what I don’t understand is why they don’t start up with the low resolution timer and then 10 or 15 seconds after the JVM is loaded swap in the higher resolution timer. Yea, it’s a hack. Yes, it means you could get different resolutions at different times. But the resolution is undefined so it’s legal wrt to the API docs. It solves the JVM startup problem, and it satisfies the game community. Also, you cannot tell me it isn’t possible because we already know the JVM can load dynamic libraries at run time.

#15

Even more to the point there are techniques for doing high precision timing without using the media libs.

The good news is that there is a high res timer now (1.4.2) in the the com.sun.* space and I am hopeful it will migrate to standard API space by 1.5

Why wasn’t it done before? 'cause before you guys came along noone made enough noise about it :wink:

Jeff

#16

I can’t remember if the Windows media timer is properly synchronized to ‘time of day’. We currently use java.System.currentTimeMillis for two different purposes: finding the current date and time, and for measuring (usually short) intervals. Windows provides at least 3 different timers:
a) Date/time
b) media timer
c) performance counter
You certainly can’t use the performance counter to obtain the current date. I think Java should provide separate interfaces for each of these classes of timer, which might on some systems use a common timer internally.

#17

Just kinda read through this thread and kinda received an interesting vibe from something. Are you guys saying that the best way to get a certain frame rate from Java is to do a:

render()
Thread.sleep( sleepTime );

where sleepTime = (1/fps) * 1000 ?

#18

If you ask me, that is a terrible way of setting frame rate. You need to ask yourself whether you want a FPS construct at all. Most of the time, games want to render as many frames per second as possible. If that is the case then you want to record the time between the last time that you rendered and the next time and that would dictate the amount on animation that has taken place and update the locations of elements accordingly.

-Jason

I am sure someone is going to argue with me on this, so look for some good discussion.

#19

I’m not going to disagree. Your method is perfectly valid. I will point out though that there are many types of games that don’t have enough action to warrant that method. For games on PCs, particularly games that would run in a window, it makes sense to throttle back the actual CPU usage instead of actively drawing the exact same frame a hundred times a second. I could be playing a game while I wait for my disk to defrag, or I’m printing a large document, etc. The idea of taking over the machine doesn’t always fit. Be friendly to multitaskers when appropriate.

Gregory left out a bit in his sleepTime calculation… the amount of time it took to execute the render() call should be subtracted from the sleepTime. If sleepTime < 0 you can’t keep up at that framerate and might be able to do something about (like lower detail).

#20

From my perspective I’m more looking for consistency than high frame rate. If I can guarantee 60Hz that’s actually fine by me - that’s what I want to do, moreso trying to get hundreds of frames per second.

You are correct palmer about the time computation, I was speaking in more general terms. I didn’t expect that Thread.sleep() ran at such a resolution to allow one to lock a framerate using that method. I assumed that the resolution was such that native code would be required.