ajax at nwnk.net
Sun Aug 21 15:07:00 PDT 2005
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg