Finishing Composite to handle transformed windows
akin at pobox.com
Mon Jan 9 11:40:06 PST 2006
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.
More information about the xorg