Writlaus

Is there a way to get the framerate of an applet? Or maybe something to just keep track of the time between calls to a certain method?

Writlaus

Nothing?

Polyphemus_

Depends on what you're doing with the applet. Does it contain 2 buttons and a textbox, or anything similar? The applet will only be redrawn when there is need to be redrawn.
If you're drawing things yourself for an animation or anything, just measure the time between each repaint() call.

lectricpharaoh

Java, like Windows and (I assume) many other GUI-based environments, will only issue an event signaling that repainting of a window is needed when a portion of a window is 'invalidated' (happens when it is moved, resized, or overlapped). In other words, like Polyphemus_ said, only when necessary.

If you're manually drawing stuff in, you're probably doing it in one of two ways:

First is to draw it in as fast as possible, ie in a tight loop. This is usually a waste of cycles, as you spend time drawing when the state of your program hasn't changed (so you end up drawing exactly what's already on screen). If your program can't render that fast, though, you generally hit the opposite problem, where your program is rendering frames that it should actually drop.

The second common way of doing this is to use threads, and loop, but in the loop put your thread to sleep for an appropriate amount of time. This way, it's not eating up cycles rendering over and over. If you're doing it this way, you should be able to calculate the frame rate from your sleep time (for example, 100 millisecond sleep equals 10 FPS). The only problems here are that if your program can't render that fast, you hit the 'should drop frames' issue above, and you can't calculate an accurate framerate (if it's spending 100ms in rendering each cycle, and then 100ms sleeping, you've effectively got a frame rate of 5 FPS).

A better way is a modification of the second approach. In one thread, determine the state of your program, and if it's changed (in the context of what needs to be rendered), call your rendering function. If it hasn't changed, sleep for a specified length of time. You can even use sleep(0); this will have the benefit of allowing other threads to run if they need to, and if they don't, your thread will be immediately reactivated by the scheduler.

You could also use the javax.swing.Timer class. This will fire an ActionEvent whenever the specified interval elapses; it will also (by default) merge multiple pending events into one, so if you can't render frames fast enough, you can easily drop frames by just rendering the latest state of your program.

In many ways, it's hard to do exact timing with Java since their thread model is built on top of that of the native OS. You can query for the current time, and use the difference between two such times to calculate how long it took your pgoram to render x frames, but you'd better have a large value for x to offset the overhead of thread switches, etc. Even if you're not using threads in your program, remember that Java is using them behind the scenes to determine when to do things like call your event handlers.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

Mjordan2nd

I would also suggest the java.util.Timer.

__________________
"Every gun that is made, every warship launched, every rocket signifies, in the final sense, a theft from those who hunger and are not fed, from those who are cold and are not clothed. The world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children." - Dwight D. Eisenhower

JavaMan

For myself, I use System.currentTimeMillis(). To get frame rates, you have to not rely on the regular paint method. You can not accurately time that. A real frame is a process through:
1. Update - Perform any updates to the applet.
2. Render - Renders to a double buffer.
3. Paint - Paint the double buffer to the screen.