Re: xfree will be the best....

On Sun, Apr 06, 2003 at 10:09:13AM -0700, Keith Packard wrote:
| 
| Applications can't depend on Render, OpenGL or any extension as they must
| be able to run on old X servers that have none of them.  ...

It's important to some people that Mesa work even if the target X server
doesn't support GLX, so that's a shared problem.

|                                                      ... To make this
| easier, I'm helping build application libraries that mask the underlying
| system -- Xft and Xc both expose an API independent of the mechanism used
| to draw the graphics.  ...

Yes, this is clearly a good thing.

|                   ...  It would be interesting to see these targeted at
| an OpenGL backend.

We need to take care, especially where Render exposes objects whose
semantics might not match those of the corresponding objects in OpenGL.

I'm particularly worried about surfaces that can be drawn into and then
re-used as sources during later drawing operations.  A lot of care went
into defining the OpenGL PBuffer and render-to-texture semantics so that
they work well with hardware, with the extended Visuals in GLX, and with
texture internal formats.  If Pictures create a new, parallel entity
that doesn't fit into the existing mechanisms, then we've forced a lot
of redundant work on the driver writers and tricky resource management
problems on the application writers.  This is not to say that Pictures
definitely present a problem; I don't know that for sure.  It's just an
area where experience suggests we need to be extra cautious.

One other concern is that if the libraries are intended to support
OpenGL back-ends then the semantics of the libraries need to be designed
so that they can be integrated smoothly with OpenGL applications.  For
example, it needs to be clear which parts of the OpenGL state are
destroyed by the libraries and which parts are preserved, whether the
libraries make independent demands for shared resources like texture
memory, etc.

Allen