Finishing Composite to handle transformed windows
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
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
I'm not sure how much of the GLX 1.3 spec is actually implemented. I
think we're still on GLX 1.2.
More information about the xorg