Drawing into backplanes

[Kurt Akeley]

In article <1514 at disuns1.epfl.ch>, leblanc at disuns2.epfl.ch (Andre Leblanc) writes:
|> Is it possible to open a gl window and give it priority 
|> back bitplane access over any other window?  

No it is not.

|> That is, I would like to render an image into the backplanes, 
|> with z-buffering, then retrive content of the back color planes
|> and save it into an image file.  While the image is being rendered
|> (which takes quite a bit of time, even if its a VGX system),
|> I would like to continue working in other text windows
|> (wsh, text editor,...).  The problem occurs when I bring
|> text windows in front of the gl window.  It seems that gl clips
|> the backplane drawing according to visibility of windows.
|> Am I right?  

You are right.  Because front and back are concepts that are local
to a given window, one window's front buffer is often another window's
back buffer.  We make no attempt to sort this out, but instead simply
allocate all the resources of each pixel to only a single window.

|> If not, what am I doing wrong?  
|> If so, do you have any suggestions to assure that the image 
|> that's being rendered in the backplanes is not affected by
|> text windows in front?

It's a dirty trick, but I believe that the GL routine fullscrn() will
allow you to fill pixels regardless of which window they "belong" to.
On machines that really have 2 full color buffers (GT, GTX, VGX) this
should allow you to write to the back buffer under a singlebuffer
window.  A tip - to insure that everyone agrees about which buffer is
which, open your backbuffer window in double buffer mode and NEVER
call swapbuffers().  Also, because fullscrn() messes with both the
viewport and with the projection matrix, you'll have to respecify these
after calling it.

|> Thanks,
|> Andre LeBlanc
|> Swiss Federal Institute of Technology
|> Lausanne, Switzerland.

Please let us know if it works ...

-- kurt