Xgl/Xegl future?

[Adam Jackson]

On Saturday 20 August 2005 19:46, 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, and there are
> proofs of concept of GL based compositing managers. I'm wondering what
> effect these trends will have on the usefulness of Xgl, has anybody else
> considered that?

There's a few major issues there, in my view.

First is that for any sort of decent performance for image- or 
texture-intensive GL clients, Xgl will need to gain support for the DRI 
protocol.  This is real close to trivial.  The GLX backend would actually 
have it toughest since it would have to translate the cliprects, window 
positions, etc. by the Xglx window's position, and there might be some other 
issues with the nesting there that I haven't thought through yet.  But for 
Xegl it shouldn't be difficult at all.  There's one or two latent 
dependencies in the libdri code in the server on things in the xfree86 ddx, 
but nothing huge.

The second issue then is we have to build into the design some sense of 
fairness.  You'll now have the server and the clients competing for card time 
much more than before, so we'll need to care much more about little things 
like not holding the DRM lock needlessly, etc.

But, backing up from simple issues of GL performance, I think the real reason 
toolkits are attempting to go through the GL path is because you can fake 
Render in terms of GL (hence glitz), and the normal Render path through the 
protocol is dog-slow because it's effectively all software.  If we had a fast 
Render path on the server side, toolkits would use that instead of invoking 
the pain of full GL.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050821/e600bdbc/attachment.pgp>