Xgl/Xegl future?

[Michel Dänzer]

On Sun, 2005-08-21 at 12:56 +0200, Clemens Eisserer wrote:
> > 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?
> 
> Well I think its quite problematic, since all applications us etheir
> own OpenGL contexts, 

Is that only a disadvantage though? It might allow exploiting SMP (think
multi-core CPUs) better, e.g.

> upload their own glyph-cache textures and have a lot of common data 
> that shouldbe shared somewhere.

Good point, I hadn't thought of that. FWIW, it might be possible to fix
this in different ways in the toolkits, possibly via GLX extensions? I'm
not suggesting that there's anything wrong with the RENDER approach,
just exploring the possibilities.

> Another problem I see is that those backends are absolutly not
> network-transparent (how could they) - 

I may be missing your point, but GLX is network transparent.


Basically, what I'm wondering is: Assuming that more or less the same
functionality that Xgl provides can be provided with EXA + (possibly, if
even necessary) toolkit GL backends, could that be the faster way to
achieve the goal of a smooth and eye-candy-rich X desktop? And would it
also allow making improvements in other areas like input more easily
available to users with hardware that doesn't support GL (well enough
for Xgl)?

Of course, if this approach would inherently preclude something
important that Xgl would enable, it's no go. But I haven't seen
something like that yet.


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