zdraw

[Kurt Akeley]

In article <1990Sep4.161847 at bucrf11.bu.edu>, tjh at bucrf11.bu.edu (Tim
Hall) writes:
|> 'zdraw' only seems to work when in double buffer mode.  When in singlebuffer
|> mode things are drawn into the front buffer even when 'frontbuffer( FALSE )'
|> and 'zdraw( TRUE )' have been called.  Is this a bug or a feature?  
|> This is on a 4D-240 running 3.2.

It is possible to disable drawing to the frontbuffer while zdraw is enabled
and the GT/GTX is in singlebuffer mode.  However, a coding error makes it
difficult.  On my 3.3 machine you must call frontbuffer(FALSE) after you call
zdraw(TRUE) for this to work.  The code was originally correct (I wrote it) but
has since rotted because it is trying to do a complicated thing.  The documents
indicate that frontbuffer() is ignored while in singlebuffer mode.  This made
sense before zdraw() was introduced to the GL, but became a problem after.  Our
coding solution was to save the requested frontbuffer() state, but to disable
drawing to the front buffer only while zdraw() was TRUE.  Thus old code that
counted on frontbuffer() being ignored in singlebuffer mode is unaffected, but
drawing to the front buffer can be disabled while drawing to the zbuffer is
enabled.

Any way, a code change some time back caused frontbuffer state as well as
actual enable to be changed only while either in doublebuffer mode or while
zdraw is TRUE.  Thus an initial call of frontbuffer(FALSE) is completely
ignored, and a subsequent zdraw(TRUE) call cannot disable drawing to the
frontbuffer.  Only when frontbuffer(FALSE) is called while zdraw is TRUE can
drawing to the frontbuffer disabled.

|>
|> Will 'zdraw' ever be fully supported on PI's?

I don't do development for the Personal Iris, but from what I know of its
hardware, I doubt it very much.

-- kurt

p.s. There is a good chance that future GL releases will NOT ignore
frontbuffer()
     while in singlebuffer mode.  This will simplify the code and probably
     satisfy current usage.