Re: frame rate control with IRIX 5.3

New Message Reply Date view Thread view Subject view Author view

Dennis Pierce (dpierce++at++zirmong.orlando.sgi.com)
Thu, 16 Feb 1995 21:12:08 -0500

On Feb 16, 5:39pm, Beaver, Jim wrote:
> or LOCK, the application runs at the frame rate specified by pfFrameRate just
> fine until, say, it has to draw a lot of terrain, for example, such that it
> can't get done in the specified time frame. When this happens, instead of the
> frame rate slowing down to whatever it takes to complete the drawing,
theframe
> rate gets cut to half its specified rate. For example, in my application I
> specify a frame rate of 12 HZ and if I get to a point that everything
can'tget
> drawn that fast, the frame rate gets cut to 6 Hz. This is only a problem
with
> PFPHASE_FLOAT and PFPHASE_LOCK. When I tried running with
PFPHASE_FREE_RUN,the
> same application drawing the same terrain runs at from 10Hz to 14Hz,
varyingas
> different objects come into or go out of view. This causes me problems
because
>-- End of excerpt from Beaver, Jim

Jim,

image generation frame rates are ALWAYS some integral divisor of the
vertical refresh rate since it makes absolutely no sense to generate an
image faster than the display device can present it - for large IG's,
the rate was typically 50 Hz since this was "fast enough" to reduce
transport delay effects and "long enough" to allow more image time (20 ms
vs 16.67 ms) to generate a picture - plus the 50 Hz CRT's were nice and
bright

with these systems, if the scene was too complex (even after a year of
database development and tuning), the scene manager (or frame controller)
in the IG would simply jerk the image generation chain and cause a partial
image to be displayed

with the rocketing of workstation technology into the low-, mid-, and
now high-end IG community, the screen refresh rates associated with these
more workspace-friendly boxes are becoming known - for example, the new
systems SGI ships come set to 72 Hz for the refresh rate - you can set
it back to 60 Hz or 30 Hz interlaced, but the 72 Hz prevents the beat
pattern that resulted when a 60 Hz display was placed under 60 Hz fluorescent
lights

so, to finally get to some point here (sorry for the length of the background),
your Indigo2 is probably set to 72 Hz, so when you ask IRIS Performer to
lock down a rate, it can either "blow" the frame and cause a partial
draw, or drop down to the next lower video refresh divisor - so, for 72 Hz,
you can have frame rates of 72, 36, 18, 9, 3, 1, 6, 12 and 24 Hz (I may have
missed one or two) - if you ask IRIS Performer to lock at 36 Hz and it
can't maintain that rate for one frame, you will see the rate drop to 24 Hz
since there is no "rate" between 36 Hz and 24 Hz if the base rate is
72 Hz

the other numbers you see, such as 32 Hz or some "smeared" average is
simply a time varying average of bogus rate calculations - the actual
rates are ALWAYS an integral divisor of the base rate - however, if you
take 5 36 Hz frames and average this with one 24 Hz frame, you get a
number that is (5*36+24)/6 Hz as the average rate for those 6 frames - this
is what you are seeing with the IRIS Performer 'tween rate framing

so, the fact that you see discrete steps when using locking is good because
it means that IRIS Performer is maintaining your desired rate always, except
in the few instances when your database is too complex for the Indigo2
to handle

the powerflip demos show the same averaging

bye.

-- 
Dennis Pierce
SGI / Ste 130 / 900 Winderley PL / Maitland FL 32751


work: 407.660.0073
late: 407.660.2789
cell: 407.256.8447

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:58 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.