Finishing Composite to handle transformed windows
Keith Packard
keithp at keithp.com
Mon Jan 9 17:21:59 PST 2006
On Mon, 2006-01-09 at 11:40 -0800, Allen Akin wrote:
> 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.
Yeah, I remember when this plan was generated, but I think at that
point, GLX was an SGI proprietary extensions, and the X consoritium was
busy rat-holing on PEX, so deep technical decisions like this probably
didn't get a lot of play in the wider community (sigh).
From my recollection, the requirement was that somehow the X window ID
completely specify the rendering configuration. I'm really unsure why
the Visual was recruited to transmit the GL configuration information,
and I'm wondering if we can't use some other method, while retaining the
option of using just the visual
> 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.
To me, it looks like the issue is that any fixed configuration is
unlikely to meet all application requirements. This means we need some
way to change what the root window capabilities after the server has
started. If this isn't feasible, we can stop trying to force GL to draw
to the root window, that won't ever be useful.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060109/d3273460/attachment.pgp>
More information about the xorg
mailing list