Good point. First of all if you are counting frames in a behavior other
than elapsedFrame(0) then you are not guarenteed it will run when the
criterion is up. For example the elapsed time behavior is notoriously
inaccurate. Our first FPS counter used elapsed frames (40) and examined the
view frame number and measured the elapsed time using
System.currentTimeMillis(). We just implmented a new, more accurate frame
counter. Almost every scene update we make is done directly or indirectly
from our SceneUpdater object. This processes a list of transactions which
have been queued up by other threads. It is running using a wakeup elapsed
frames (0). We created a clock object using a system level high resolution
timer which is referenced throughout our system as the current time, and it
is updated at the beginning of each frame. It also keeps a running total
of the last 100 buckets of elapsed frame times. When we implemented this
new FPS counter our frame times improved from around 70-80 to 90-110.
Dave Yazel
-----Original Message-----
From: Nathan Bower [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 05, 2001 2:30 PM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Win2000 vs. WinNT
Sofar everyone has assumed its the jre / hardware that is causing the
bottleneck.
How about if the fps couning code is defunct?
N
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
