From: Allan Schaffer (allan++at++sgi.com)
Date: 03/25/2004 08:32:52
faculaganymede wrote:
> 1) In my program, I use pfQueryFStats with the
> PFFSTATSVAL_PFTIMES_PROC token to track the processing
> times for each frame. For the DBASE process, I am
> keep getting dbase=0.000800 msec or dbase=0.001600
> msec, though I don't do any data loading (i.e. no
> pfdLoadFile) in the simulation loop. Can someone
> explain to me what dbase=0.000800 msec come from?
Not much of an explanation but those timings are taken as follows (pseudocode):
start timing
if user has a DBASE function callback
call it
else
call pfDBase()
end timing
This happens each frame. There's a few if's & etc in pfDBase() to handle
async updates if there are any queued up. Other than that it's pretty much
empty. If you have a separate forked DBASE process then it also includes
some lock synchronization.
> 2) In my program, I have a call to pfGetFrameRate
> after pfFrame in the simulation loop. pfGetFrameRate
> always returns -1.00 twice before returning any
> meaningful values. Accompanying the -1.00 values are
> two warning messages:"...Actual frame rate is unknown
> until after graphics window is opened..." Is this a BUG?
I don't think so, at least not if you're in APP_CULL_DRAW. Remember that
App->Cull->Draw is a pipeline, the first call to pfFrame(), frame 0 data will
travel app->cull; next pfFrame() frame 0 data goes cull->draw and frame1 data
app->cull; next pfFrame() frame 1 data goes cull->draw and frame2 data
app->cull; and so on. The graphics window doesn't get opened until that
first DRAW frame.
A lot of folks just drop two calls to pfFrame() early in their app for this
reason, so they don't have to deal with odd synchronization issues like this.
Allan
-- Allan Schaffer allan++at++sgi.com Engr. Manager, Core Rendering 1-650-933-2160 Silicon Graphics http://www.sgi.com
This archive was generated by hypermail 2b29 : Thu Mar 25 2004 - 08:33:05 PST