Finishing Composite to handle transformed windows
brian.paul at tungstengraphics.com
Mon Jan 9 14:13:35 PST 2006
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
See Keith Whitwell's recent posts to the Mesa/DRI lists about a new
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.
More information about the xorg