On Thu, 2004-11-18 at 12:52 -0500, Joshua Gargus wrote:
> When you say "frame buffer" do you mean more generalized GPU memory
> access than just the pixels that are directly displayed on the screen? 
> For example, will it be possible to directly map an X window to a chunk
> of memory corresponding to an OpenGL texture?  That would be cool.

Exactly.  That's where we are going, as fast as we can.  We try to be
cool ;-).

It is non-trivial; we really need superbuffers, which aren't fully
implemented in GL implementations, and sharing of X pixmaps as such
superbuffers, along with shared memory management.

Getting X up on top of OpenGL is underway; an Xgl server is at least
limping at this date.

I'm hopeful that sometime in 2005 we'll have all this going for real,
to the point that live video conventional X applications can used
as textures in Croquet or other 3D environments, and textured onto
anything you like, all without leaving the frame buffer :-).

Come help ;-).

> 
> If this is not the case, wouldn't we have to do something akin to the
> kludge you describe in order to map the window onto 3d surface anyway?
> 

The kludge is running today. (or limping; having to copy pixels around
is far from a wonderful thing to have to do).
			- Jim


> Joshua
> 
> 
> On Thu, 18 Nov 2004 12:30:22 -0500, "Jim Gettys" <Jim.Gettys at hp.com>
> said:
> > 
> > On Thu, 2004-11-18 at 17:37 -0400, lex at cc.gatech.edu wrote:
> > 
> > > 
> > > The Croquet project is working on letting you display X programs inside
> > > a shared 3D world.  I don't know how far along that is, but you might
> > > try there.
> > 
> > We have a kludge version of this running today; the bits have to get
> > copied from a fake X server to become a texture, rather than full
> > integration in the frame buffer which will become possible when we get
> > further with other X driver work.
> > 
> > It does work well enough even so that most applications are perfectly
> > usable, however.
> > 				- Jim
> > 
> > 
> >