Finishing Composite to handle transformed windows

[Brian Paul]

Allen Akin wrote:
> On Mon, Jan 09, 2006 at 11:10:10AM -0800, Keith Packard wrote:
> |                         ... 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'.
> 
> It's from before my time (Phil Karlton came up with this approach early
> in the OpenGL days).  But my recollection is that the goal was to ensure
> that all windows could be operated upon by both X and GL, and that as
> much compatibility as possible could be preserved for X apps.  That
> implied preserving the Visual mechanism and changing the GL side to work
> around things like X's 32-bit maximum pixel size.
> 
> GL apps were forced to make some major changes, however, since they were
> accustomed to modifying window attributes (attached buffers, color
> depth, etc.) dynamically.
> 
> Years later, when the decision was made to support GL drawing surfaces
> that X couldn't access, an independent configuration mechanism
> (FBConfig) was added to GLX.  That project did happen on my watch, and
> if I remember correctly it wasn't especially hard.
> 
> In recent years the trend seems to have been to move back toward a more
> dynamic system.  The wheel of reincarnation at work again, I suppose.
> 
> I haven't been following this discussion closely, but I don't see any
> major problem with making the root's Visual GL-capable, provided you
> have a good idea which ancillary buffers you really need so that you
> don't waste framebuffer memory.  I defer to the experts on matters of
> clipping and event delivery.

In the not too distance future we may be able allocate ancillary 
buffers on demand and/or allow them to be "paged out"/deallocated when 
not used.

See Keith Whitwell's recent posts to the Mesa/DRI lists about a new 
memory manager.

Then you could perhaps create the root window with a full-featured GLX 
visual and not worry too much about how much memory it might use.

Otherwise, I don't think we'll have a way to dynamically change the 
attributes of GLX visual (or change a drawable's visual) anytime soon.

-Brian