Re: Problem with frame managemnent in Performer

New Message Reply Date view Thread view Subject view Author view

Simon Bennett (simonb++at++wormald.com.au)
Thu, 23 Nov 1995 09:32:52 +1100 (EST)


On Wed, 22 Nov 1995, Bill Storma wrote:

> Our company is currently developing an application using a 3 pipe
> ONYX, using IRIX 5.3 and Performer 1.2. The 3 pipes have been
> genlocked together, both via software (using setmon) and hardware
> (cabling the sync, genlock and swapbuffer ports as described in the
> SGI manuals).

> During the process of testing the different frame rate controls
-- snip --
> the other two will start at different refresh cycles. I have also
> informed Paradigm Simulation of this problem (we are using their Vega
> products), and they could re- create it on their equipment.
>
> Since the draw process does not start at the proper time, the frame
> synchronization does not always take place properly. Example: if
> the frame rate is set for 15 Hz, even though the draw process can run
> well within the frame, the frames will drop to 7.5 to 10 Hz. This
> apparently is because the draw process overruns the frame, because it
> started late.

I've been led to believe that Performer 1.2 did not synchronize the video
clocks on multipipe systems -- and that this has been fixed in 2.0...

We had a similar problem under 1.2 on our 3-pipe Onyx... I could get the
pipes to sync just fine using GL - but no joy under Performer 1.2... :(

> Because of this problem, I find it difficult to write a real-time
> application that will run at the proper frame rate.

I wish this didn't sound familiar! :)

> Has SGI seen
> this problem and if so, is there a fix to the problem ?

2.0?

+----------------------------------------------------------------------------+
  Simon Bennett simonb++at++wormald.com.au
  Wormald Technology Advanced Systems Engineering Ph: +61 2 9981 0611 (x512)

          Meeting - an event where you take minutes and waste hours.


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:52:03 PDT

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