From: Steffen Seeger <s.seeger@physik.tu-chemnitz.de>
  To  : ggi-develop@eskimo.com
  Date: Mon, 9 Aug 1999 17:24:13 +0200 (CEST)

Re: Matrox GGI accellerator

 
> > > > That is one point, where the SGI HW helps ... Individual windows have tags
> > > > in the graphics RAM that can be regarded as a kind of "stencil-mask" for
> > > > such clipping purposes.
> > 
> > > That would be the hardest part to work. Like I said this is far down the
> > > road. 
> > 
> > It cannot be done without hardware support. You have only two choices on
> > that matter:
> > 
> > 1. Do not allow direct mapping of video RAM. Always go through an accel
> > protocol, which you can clip in software.
> > 
> > 2. Accept the possibility of "crosstalk" between the windows and eventually
> > between the window and the root window. As I outlined, this is not a real 
> > concern with X windows anyway, as one can mess up the screen "legally" by
> > creating new windows or drawing on the root window as well.
> 
> Then how do you suggest we handle the following situation. I'm running two
> OpenGL programs in X windows. I don't want process one being able to
> write into process two z buffer. 

For "non-cooperative" applications and high security concerns you have 
two options: Either the hardware handles window-ID attributes properly,
or it has to go through a central, trusted instance, e.g. a X-server. 

For "non-cooperative" applications and low security concerns you 
have to cope with applications possibly messing up the screen.

For "cooperative" applications and low security concerns you can just
send it a clipping rectangle list, and the application has to reset
the clipping window and send overlapping primitives multiple times.

For "cooperative" applications and high security concerns you don't have
to care, as there is no such thing as a "cooperative" application if
you have high security concerns.


			Steffen

----------------- e-mail: seeger@physik.tu-chemnitz.de -----------------