Finishing Composite to handle transformed windows

[Deron Johnson]

At one time there was a counter proposal to allow GLX attributes
of a window be dynamically changed rather than requiring that a
static configuration be selected up front. The static configuration
proposal was adopted primarily because it dealt with the issue
of what happens if the hardware doesn't support a particular
configuration. It was felt that it is better to know that before running
the application than getting partially into the initialization and then
discovering that insufficient hardware resources are available.

But it is far, far too late to switch to a dynamic configuration
approach now. That ship sailed long ago. The static configuration
approach is now embedded in thousands upon thousands of OpenGL programs.

At one time I had responsibility for all the visual issues at Sun
related to the X server and I spent many years dealing with visual
issues and the one thing I learned is that changing the way visuals
work is very, very tricky and dangerous. Clients always embed a
whole plethora of assumptions on how they expect visuals to behave.
The issues surrounding topmost windows will pale in comparison to
the issues that you will take on if you start changing how GLX
visuals work.

Keith Packard wrote On 01/09/06 11:10,:
> On Mon, 2006-01-09 at 11:44 -0500, Adam Jackson wrote:
> 
> 
>>The other usual problem with doing GL to the root window is that the root is 
>>typically created on a single-buffered visual, so GL to it looks extremely 
>>flickery.
> 
> 
> That's what I thought. The whole evil hack of using different visuals to
> represent different GL parameters is now officially hurting us...
> 
> 
>>This is fixable if we really want to.
> 
> 
> Fixable in what way? Can we change what GL options are associated with a
> visual? Or do you mean just changing what GL options the default visual
> has? If the latter, that seems inadequate and we'll want a different
> solution.
> 
> I guess my question is whether doing this right would require
> diffcult-to-implement changes to GLX. I'm not entirely averse to
> changing the GLX protocol to make this work, but I'd like to know
> whether it's even possible. My recollection is that SGI used a visual
> because they didn't have any other handle to hook frame buffer
> configuration information to, and that fixing it was 'too hard'.
> 
> -keith
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg