Re: xfree will be the best....

Around 13 o'clock on Apr 6, Allen Akin wrote:

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

Some care may be needed in the Xc library to ensure that library can be 
implemented in terms of other underlying systems.  Xc currently exposes 
Render semantics as that's what we're familiar with.  However, the Xr 
library doesn't need precisely that model, so it would be a good time to 
review the Xc/Xr interface and make sure it was able to run on top of 
Render, OpenGL, PDF 1.4 and (with some limitations) PS.

> 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.

Pictures are just an abstraction to associate colors and a bit of rendering
state with existing X drawables, so resource management should be the same
as between OpenGL and core X, except that Render asks that core X manage
drawables of multiple depths within the frame buffer which it doesn't do
today.

> 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.

If OpenGL state can be encapsulated without reference to mutable global
objects, then Xc could be designed so that applications wouldn't even know
that Xc was using OpenGL.  Otherwise, we'll have some work to do in
exposing precisely how Xc might modify OpenGL state were it to be using it,
or provide appropriate hooks so that applications can control that
interaction.

-keith