Xgl/Xegl future?

[Michel Dänzer]

On Sun, 2005-08-21 at 20:53 -0400, Adam Jackson wrote:
> On Sunday 21 August 2005 20:17, Michel Dänzer wrote:
> > On Sun, 2005-08-21 at 18:07 -0400, Adam Jackson wrote:
> > > 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.
> >
> > I'm afraid you're oversimplifying things. E.g., how will Xgl know the
> > locations of redirected windows in the framebuffer for passing them on
> > to the client-side driver as rendering buffer locations?

[...]

> If you are direct rendering, then you need some cooperation over the protocol: 
> the server needs to tell the client to render offscreen rather than to the 
> front buffer, and the client needs to inform the server of the offscreen 
> buffer's location.  

Even ignoring issues with the server trusting that kind of information
from clients, I think that's backwards, AFAIK the vast majority of
clients creates the window via X alone and only then sets up the GLX
stuff.

> The only challenge is deciding what channel to do that 
> over, SAREA or DRI protocol or maybe GLX protocol + DRM interface.

In which case this wouldn't be completely abstracted in the GL
implementation, and Xgl wouldn't be vendor neutral.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer