Xgl/Xegl future?

[Owen Taylor]

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+:

 http://mail.gnome.org/archives/gtk-devel-list/2005-June/msg00166.html

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
   textures. 
 - 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 
   applications.

 - Modern cards allow a large amount of programmability of the
   card; much of this programmability is available through
   OpenGL.

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
driver.

Regards,
							Owen

-------------- 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/20050821/350aca20/attachment.pgp>