Jim Helman (jimh++at++surreal)
Mon, 06 Nov 95 02:04:25 -0800
1) Impact and Elan/Extreme like RealityEngine do not block
the CPU until the RGBcolor command is issued.
swapbuffers();
RGBcolor(255,255,255);
clear();
2) Moving the clear to right after a swapbuffers is an
incredibly lousy idea. Screen clears do take a long time, but
this would block and really slow things down. This would
require a non-blocking swap-and-clear which we don't have.
But in single-processed FREE_RUN it is sometimes worth using
CULL_DL_DRAW, since then the CULL does not block (nothing blocks
until the channel draw callback is invoked). Without
CULL_DL_DRAW, single process operation causes a combined
CULLDRAW traversal to be invoked from pfDraw. In this case it's
possible that culling and sorting can leave some deadtime on the
graphics pipe, but only if the cull+sort time in pfDraw exceeds
the screen clear that was started just before the combined
traversal triggered by pfDraw.
LOCK and FLOAT are different. In single-procssed LOCK or FLOAT,
pfSync locks to a frame boundary. So when a lot of culling &
sorting are being done (before the channel draw callback is
invoked), it would often be faster to clear the screen after
pfSync in the APP (illegally & not portably for MP operation)
rather than waiting until the draw callback is invoked.
We need to make this simpler.
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:52:01 PDT