[Mesa3d-dev] Re: GLX and Xgl

[Adam Jackson]

On Tuesday 12 April 2005 14:52, Ian Romanick wrote:
> Owen Taylor wrote:
> > On Tue, 2005-04-12 at 10:18 -0700, Ian Romanick wrote:
> >>You can be 90+% sure that nobody will hardware accelerate rendering to
> >>pixmaps.  Of course, that doesn't seem to be a problem for you anyway. ;)
> >
> > I get the impression that you are looking at the wrong side of rendering
> > to pixmaps ... the ability to render to a pixmap via the GL API is
> > really pretty uninteresting. The *implementation* of such is what
> > we need.
> >
> > Hardware acceleration to "pixmaps" is exactly what we need
> > here, because a redirected window is (from the point of view of the
> > server internals) a pixmap, and in fact can be named as a pixmap via
> > the Composite API.
>
> ...which will quite likely never happen.  There *are* reasons that
> OpenGL implementors abandoned pixmaps and invented pbuffers.

Some confusion over terminology here, I think:

surface - generic rendering target.  has pixels in it.
Pixmap - an X rendering target containing a surface and some X state
GLXPixmap - a GLX rendering target containing a Pixmap and some GLX state

We need accelerated rendering to offscreen surfaces but not necessarily to the 
other two.  The compmgr needs a way to get at the offscreen surface of a 
window, which is done by binding it to a Pixmap (note capitalization).  This 
will remain the case for non-GLX clients.

For GLX clients we merely need access to the offscreen surface that rendering 
has been redirected to by the Composite machinery.  This surface could be 
exposed as a pbuffer or an fbo, or through EXT_render_target, or whatever.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050412/ffae3b1d/attachment.pgp>