Finishing Composite to handle transformed windows

Brian Paul brian.paul at tungstengraphics.com
Tue Jan 10 07:26:35 PST 2006


Allen Akin wrote:
> On Mon, Jan 09, 2006 at 05:21:59PM -0800, Keith Packard wrote:
> | ... I'm wondering if we can't use some other method, while retaining the
> | option of using just the visual ...
> 
> Perhaps FBConfigs can be pressed into service.  FBConfigs are already
> independent of Visuals to some extent, because FBConfigs can apply to
> drawing surfaces which don't have Visuals.  I took a quick look through
> the GLX spec and didn't see any requirement that there be a one-to-one
> mapping between FBConfigs for windows and Visuals (although the language
> clearly leans in that direction).  Relaxing any implied requirement of
> that sort might be a feasible change.  Then you'd simply pick one of the
> FBConfigs associated with the Visual of the root window that has the
> attributes you want.  "Applying" that FBConfig to the root probably
> needs help from an extension.

I think you'd just use the GLX 1.3 glxCreateWindow function:

glXCreateWindow(Display *dpy, GLXFBConfig config, Window win, const 
int *attribList)

You'd pass in the desired FBConfig and the root window ID, then get 
back a new GLXWindow identifier.


> |                                            ... This means we need some
> | way to change what the root window capabilities after the server has
> | started. ...
> 
> FBConfigs might provide an interface to do that, but I have no idea
> whether there's enough mechanism already available in the
> implementations.

I'm not sure how much of the GLX 1.3 spec is actually implemented.  I 
think we're still on GLX 1.2.

-Brian



More information about the xorg mailing list