Why does this code sometimes report 21.3 FPS when I ask for 30 FPS?

I've run into an interesting issue with the FPSAnimator that I describe in this StackOverflow post:
Why does this code sometimes report 21.3 FPS when I ask for 30 FPS?

Basically I am using an FPSAnimator and asking for 30 FPS, and I'm getting ~21.3 FPS.  The machine is adequate, the machine isn't busy doing anything else, and the display function does nothing but print the FPS.

Any thoughts?

Thanks!
Luke

Hi

At first, read the documentation:
"The target FPS is only an estimate and is not guaranteed"

Secondly, you don't use fixed-rate scheduling when creating your FPSAnimator.

Thirdly, rather do animator.setUpdateFPSFrames(30, System.out);

At last, if you want a steady frame rate, just enable V-sync, avoid using Swing and switch to NEWT if possible.

Julien,
Thanks for your response.  I tried all of the things you suggested and it was the "fixed-rate scheduling" that made the difference.  However, I'm not sure I completely understand this.  I changed the program so that it is printing out the FPS automatically, as you suggested.  After that change, my display function is totally empty.

After making all the changes (except V-Sync, I didn't make that change):

animator = new FPSAnimator(window, 30, true); //gives me 30.3 FPS
animator = new FPSAnimator(window, 30, false); //gives me 21.3 FPS

The problem is, I don't think I want fixed rate scheduling.  If I understand it correctly, it uses scheduleAtFixedRate on a Java Timer, which is not the functionality I'm looking for.  That is, if one of my frames is "missed", I do not want it to queue them up for rapid execution later.  I just want them dropped.

I'm still not sure I understand how the framerate could differ so drastically in a program with an empty display function.  By the definition alone, I would think fixed-rate scheduling should only matter if a frame is missed (i.e. the display function takes too long).

Thanks,
Luke

You're welcome. Don't use Swing except if it is really necessary. I don't understand why you don't simply avoid Swing and enable V-sync. I don't see what you try to achieve. FPSAnimator has a non consistent behaviour across different platforms, I avoid using it. Why not using a simple Animator with V-sync on?

Julien,
What I'm trying to accomplish is:
Limit my frame rate to 30 FPS max.
Drop frames when the rendering time gets to be too long.
Recover quickly from a single frame that takes a while to render.
Get as many FPS as I can and should, up to the max of 30.

By reading the documentation and looking at examples, this is exactly what FPSAnimator(..., 30, false) should give me.  Or at least it should be reasonably close to 30 FPS (I understand timing may vary a little, but 9 FPS difference not a little).

If FPSAnimator cannot provide this, isn't it a bug?  Or should it be deprecated?  If I shouldn't use it anymore that's fine, but if it's unreliable, then there really should be a stronger warning than "is only an estimate and is not guaranteed".

It sounds like if I change my ceiling to be 60FPS, then I can achieve all of my requirements above with a simple animator and setSwapInterval(1).  I have tested this and it seems to work just fine.

Also, for what it's worth, I did look into using NEWT instead of AWT but there are quite a few reasons that will make the change difficult for me:

- I already have Mouse and Keyboard listeners setup and I'd have to change them all to the NEWT equivalent listeners (this may be trivial).
- My current implementations has a class that inherits from JFrame, I cannot inherit from GLWindow.  This would require some major rework of my architecture.
- My application allows users to drag-and-drop things onto the main 3D view by using a javax.swing.TransferHandler.  GLWindow does not have a setTransferHandler method to support this so I'd have to manually implement drag-and-drop.

NEWT sounds good for 3D applications, but my application is a hybrid Swing and 3D application.  I think I'm stuck with JFrames for now.

Luke

Yes, just use a simple animator and setSwapInterval(1).

Yes, switching to NEWT listeners is trivial because they look like those of AWT. Maybe you can use NewtCanvasAWT with Swing, it is a nice compromise. If you need some drag and drop support, maybe we can talk about that, you're not alone.

Julien,

I tried using a NewtCanvasAWT with swing and it cripples the performance of all of my other swing windows and components.  I have 3 large tables in my application and I can barely even scroll them with only a few hundred entries.  Resizing the window is choppy too.  There's something that just doesn't seem quite right.

I did notice that the performance of the GLWindow does not seem to be impacted by anything done in a Swing component, but it seems to be at the cost of the performance of the Swing components.  For my application, the Swing components are more important.

EDIT - So I also tried with just a GLWindow (I disabled drag-and-drop so I could do the test).  The performance was still poor.  That is, I have a single application with Swing JFrame's and a GLWindow and the performance of the Swing components was poor when used with the GLWindow.

Luke

I don't understand what is wrong. I used JOGL 2.0 with Eclipse RCP and in Swing applications without such trouble but I probably did some hack to make it work better. For example, I often use setIgnoreRepaint(true), I often override paint().