Jim Helman (jimh++at++surreal)
Tue, 09 Nov 93 06:18:32 -0800
It all depends on how expensive the dynamics are to compute and how
important the latency is.
Anything that is time critical can go after pfSync() and before
pfFrame(). It doesn't matter much single processed, but MP'd anything
occuring after pfSync() eats into the culling and drawing time.
Since wasted graphics time is pricey, only very latency critical and
quick things usually go after pfSync() and before pfFrame(), e.g.
getting already present bytes from a head-tracker out of the serial
buffer and setting the eyepoint. Usually, dynamics are
computationally expensive and when computed by the APP are done before
pfSync(). A better, but more complex, scheme might have a process
forked or sproced by the application compute the dynamics and and have
the results utilized just before pfFrame() kicks off the backend.
rgds,
-jim helman
jimh++at++surreal.asd.sgi.com
415/390-1151
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:05 PDT