otaylor at redhat.com
Sun Aug 21 18:08:52 PDT 2005
On Sat, 2005-08-20 at 19:46 -0400, Michel Dänzer wrote:
> On Fri, 2005-08-19 at 11:55 +0200, Christian Parpart wrote:
> > Will it be possible to do such amazing things w/o hardware-OpenGL-based
> > X server?
> Yes. The major toolkits seem to be moving to GL backends,
I can't speak for other major toolkits, but there is no current plan
to do this for GTK+:
Is the mail of mine I keep pointing to. Having all the 30 or so
apps that are running to make up your desktop be direct rendering
clients just doesn't make sense. Translating RENDER primitives
into GL and speaking GLX over the wire doesn't make sense.
> and there are proofs of concept of GL based compositing managers.
Well, the most impressive GL-based compositing manager demos have been
the ones that Dave Reveman has been running on top of Xgl... In order
to do a good job with a GL-based compositing manager you need:
- Redirection of OpenGL and Xvideo clients
- The ability to texture with the contents of redirected windows
- Decent video memory management that can handle large amounts of
- Accelerated indirect rendering and/or good cooperation between
multiple clients talking to the hardware.
X-on-gl has some nice properties for enabling this type of stuff,
and David has been making progress in doing so, but it's
certainly not the *only* way to get there. You could tackle the
same things within the existing driver framework. The main reasons
for looking to X-on-gl long-term have more to do with hardware
trends and our needs:
- We want to be able to add new HW accelerated primitives and
code paths to the X server as we find needs in our 2D
- Modern cards allow a large amount of programmability of the
card; much of this programmability is available through
Moving to an OpenGL-based driver model at least potentially allows
us to write software to make the graphics card do what we want
and have it work independent of the particular hardware and
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg