David Reveman on AIGLX, Meta
http://lists.freedesktop.org/archives/xorg/2006-February/013306.htmlI've been getting a lot of mail from people asking me about my thoughts
on AIGLX, the GL compositing work being done on metacity and nvidia's
xdevconf paper. Instead of replying to everyone individually, I though
I'd send a mail to the Xorg list.
AIGLX . It's great that we finally have accelerated indirect GLX
working in the xfree86 ddx, something that we should have had many years
ago. And with texture-from-pixmap support it should work well with
compiz, I like that. The DRI driver requirements for Xgl and AIGLX are
very similar so both Xgl and AIGLX will benefit from DRI driver work
being done for one of them.
Nvidia's paper on why they don't think X on OpenGL is the best way
to go is not a huge surprise to me. Xgl will work equally good across
drivers, without requiring high-quality X drivers from all the vendors.
In that way Xgl "levels the playing field" for hardware vendors. Nvidia
already has good drivers with some functionality that it will take a
while before Xgl can support. Compiz will work fine on Xorg with the
nvidia driver once they release a version with the texture-from-pixmap
support Xgl already got. But nvidia isn't the only hardware vendor on
the market, and we want the X desktop experience to be as rich as
possible for everyone.
An important goal with X on OpenGL is to make it easier for X to keep up
with the advances in graphics hardware. Eliminating the custom 2D
acceleration code will reduce the development burden and make this
easier. This can probably be achieved through AIGLX as well, I know that
the people working on AIGLX have discussed putting some of the
acceleration code I have in Xgl inside Xorg with AIGLX and that would be
a step in that direction. However, I strongly believe that going all the
way to an X server completely on top of the OpenGL API is the best
solution in the long run.
I think the arguments made by nvidia to why X on OpenGL would be worse
than the current driver architecture can be debated on until forever. I
think it all boils down to if we want put some more effort to it and
take the big scary step to something new or if we want to stick to the
old well known. Not too surprising, we have people who are in favor of
both and we'll likely have development being done on both, which I don't
think is that bad after all.
So far I haven't heard a single argument for why X on OpenGL is a a bad
idea other than that it's a big step and a lot of work will have to be
done. If that would stop me from working on Xgl, I wouldn't have started
working on it in the first place.
Except the fact that it might slow down development of Xgl a little, I
think that both AIGLX and nvidia's plan to support texture-from-pixmap
are really good things that will make the X desktop better in the
near future.
I'm a little bit concerned about the work being done on GL compositing
in metacity. During the first couple of months when I was experimenting
with GL compositing on Xgl I had similar plans but after a few months I
realized that starting from scratch and trying to reuse as much code as
possible was the best idea. Others might be able to do a better job than
me on figuring out how to extend metacity but I think it's to early to
tell as the people working on metacity that I talked to at xdevconf
didn't seem to be aware of issues I'm solving by not using an ordinary
window manager like metacity for compositing. An important reason to why
I favor compiz over metacity is that it works with other desktop
environments than gnome. I definitely don't want all these effects that
people are starting to write to only be usable on one desktop.
I don't like a compiz/metacity split but I'm not sure what we can do
here. I'll continue to reuse metacity code in compiz as plugins and I'll
have a look at libcm asap and consider the possibility of integrating it
with compiz somehow.
There seems to be a lot of people confused about this, so to clarify
things, I also like to respond to this paragraph from the fedora aiglx
page:
"We've been working on the AIGLX code for a some time with the
community, which is in direct contrast with the way that XGL was
developed. XGL spent the last few months of its development behind
closed doors and was dropped on the community as a finished solution.
Unfortunately, it wasn't peer reviewed during its development process,
and its architecture doesn't sit well with a lot of people."
I've been developing Xgl in the open since November 2004. Only the last
few months have been behind closed doors. I can agree that this wasn't
the best thing but no architectural changes have been made during this
period, just a lot of hard work implementing missing functionality,
tracking down and fixing bugs in xgl and various other places in the x
server tree. We didn't drop a finished solution, we dropped a much
improved version, that's all.
At the time the decision was made to stop push things into CVS for a
while, no one except me was really contributing to the project and the
testing and bug reports we got from the community didn't give us much.
If we had to make architectural changes or if the interest in
contributing to the project got bigger, the idea was always to open
development again.
-David
页:
[1]