Re: DRI integration, sorta

David Morse wrote:
> I'm a clueless slashdot reader, trying to understand this thread and 
> project, with a view to helping in some way down the line.
> 
> So, you've got lots of little applications, most of them obliviously 
> drawing their little hearts out in the old-fasioned XDrawLine way.  They 
> send their cute little commands to the X server, which instead of 
> drawing to framebuffer, (SUPRISE) renders them to a 
> ?raster?pixmap?whatchamacallit which lives in ?video RAM?system memory?.

How about "an off-screen image buffer which can also be treated as 
texture map".


>  a "compositing manager" process can read the various 
> raster/pixmap/whatchamacallits, and blends them based on some rules that 
> are left unspecified (why leaving it unspecified is sooo clever, or even 
> useful, I don't understand).

Compositing with blending to simulate translucency is just the tip of 
the iceberg of possibilties.

Today's (and tomorrow's) 3D graphics hardware allows all kinds of new 
possibilities beyond that:

1. per-window colormap lookups/transformations.  An off-screen 8-bit 
window could be fed through an OpenGL color table to produce RGB 
colors of any depth.  Per-window gamma correction, etc.

2. Rotate all the windows by 90 degrees for portait-mode displays.

3. Geometric warping of the windows, perhaps to adjust the geometry 
for projectors and/or non-planar surfaces.

4. Simulation of hardware overlay planes with OpenGL multitexture.

5. Consider off-screen floating point color buffers and employing 
fragment programs during compositing.  Lot's of interesting possibilities.

6. The window manager itself might want to control the compositing in 
some fancy way.

Since the possiblities are endless so it makes sense to try to 
modularize the compositing system so it might be upgraded/replaced as 
needed.


> There are software compositing managers, and in the future there will be 
> hardware compositing managers, that somehow re-use an OpenGL 
> implementation to do the dirty work.  BUT, are you planning on using 
> everybody's OpenGL, like the propritary nvidia gl?  If so, how to talk 
> to it without using their glx?  Or if you use their glx too, how to talk 
> to it without having the standard old xfree86 xserver?  Isn't the 
> xfree86 xserver the wheel you're trying to re-invent?  (better, with 
> anti-aliased edges ;)

You could probably run a compositing window system on top of a 
conventional X server w/ accelerated GLX, but that's not ideal.

Ultimately, it would be better to have an OpenGL implementation that 
has extentions to facilitate the needs of the compositing X server 
(render to texture, for example)

-Brian