Slashdot Mirror
XGL Development Opens Up
An anonymous reader writes "David Reveman has made the latest XGL source code available for download. This comes a few weeks after development of the project was criticized for being done 'behind closed doors'. There have been huge changes to XGL, the most significant being restructuring of the code, allowing XGL's GLX support to function on other drivers than the proprietary Nvidia one. Xcompmgr can currently be run under XGL with full acceleration provided that the proprietary ATI or Nvidia drivers are used. An OpenGL based compositing manager, 'Compiz' is currently in the works and a release is expected in February. David intends to get the code into freedesktop CVS as soon as possible, after which the code should eventually merge with Xorg."
No free (gratis) software should be proprietary; that's just a general rule! If you're giving your software away free of charge, people generally would like to contribute back whether it be in donations, patches, QA, etc. With a closed-source model, you're blocking off the useful traffic of free bugfixes! If your software is useful in the corporate world, it's also likely that some companies will contribute back if they tinker around with it enough.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
Can anyone translate this into English? What is XGL and why should we care?
Find free books.
Xcompmgr can currently be run under XGL with full acceleration provided that the proprietary ATI or Nvidia drivers are used.
What good is Open Source if it's inextricably tied to proprietary software? Where do I send my money to get someone to write a Free Software video driver?
Don't blame me, I didn't vote for either of them!
http://live.gnome.org/Luminocity
There. Fixed that link for you.
There are 11 types of people. Those who understand binary, those who don't and those who are sick of this lame joke.
"Compared to the xserver module code in freedesktop CVS a lot have changed. The new code contains an uncounted number of bug fixes, some major restructuring and a few additional features."
...if they didn't count them?
To say the development of XGL opened up is to assume it was closed before, which is absolutely untrue.
Dave did major changes to XGL (as you can read in his post), and it's simply not possible to merge the code back while in the middle of a transition such as that. On top of that the X.org tree was pretty much frozen to allow the transition to modular X and the release of 7.0.
The "Novell closed XGL" conspiracy came from people with their own personal agenda against Novell (and Ximian).
If you're talking about 3D acceleration (through OpenGL), the NVidia drivers for Linux are just as fast as the Windows drivers, if not faster. XGL is about rendering a 2D desktop using OpenGL (and thusly, taking advantage of the graphics card moreso to speed up rendering and get nifty effects), which Windows doesn't do. XGL really has nothing to do with games, and Linux isn't "now matching" Windows in any respect, it's pulling further ahead of it.
Game! - Where the stick is mightier than the sword!
What about Luminocity? It was an experimental window manager created so that some of the Gnome guys could start work on using compositing and to begin to understand the connection between Opengl and the Linux Desktop.
I wrote a guy to install it if you want to try playing with it. Once you do use it you see what it really is- a tech demo. Its not a full window manager (it does not replace Metacity) and it actually seems that the compositor that is going into Metacity borrows almost nothing from it, so now it seems like it was a fun dead end.
Try it, you will see what I mean.
Open Source Sushi
.. is that future video cards might well be 3D-only, and the old 2D interfaces that X relies on won't be available. You'll have cards designed pretty tightly around the OpenGL spec and related specs, and if you don't have a way to do X with such a beast, forget using the card with Linux.
The point of XGL is to take the 3D engine in most graphics cards and use it as the basis for X's acceleration.
Before, the 2D acceleration engine was used, but 2D has fallen behind in terms of performance, and 3D can do everything 2D can do, plus more. XGL uses OpenGL to render bitmaps, as well as to render video, composite alpha-channeled windows, rotate and deform windows, etc. I think font antialiasing will benefit, via a (potentially) faster XRender implementation. I gather it's also integrated with glitz already, which means that vector graphics like SVG and scalable icons, buttons, widget themes, etc. will also be done via OpenGL.
The one remaining gap (that I know of) is hardware support. The Novell guy releasing this (sorry, I forget his name right now) seems to say that it works with relatively minor changes on Free Software DRI drivers. I know that was always an intention, at least. So, hopefully, we'll see more drivers trying to support DRI as base level of driver compliance, rather than as an afterthought. The X desktop will be faster, smoother, and more featureful... so long as desktop developers don't go overboard and expects everyone to have next-generation 3D engine performance just to run a wordprocessor ;)
All in all, a very good thing :)
Does the source open during development matter? Look how much David Reveman got done by himself "behind closed doors". Really what matters is the source is available upon release to the public. Before that it doesn't really matter. The truth is the majority of the Xorg community doesn't believe in an OpenGL accelerated desktop. Look at the mailing list. The only people who do are a small group of coders who most likely do not have the time to actually achieve something worth using.
However if a company like Novell did pick up the project and paid developers to work on it full time but the source would be closed until release... well tough luck. In reality the only reason David released the code now was to get it into the Xorg tree. That way they can continue to "code-drop" to a tree that can be used by everyone, instead of kdrive which is for developers.
Also the Xorg developers seem to be concerned with Xegl which David isn't even working on. I dont care either way. Just get it done.
The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend
Not really -- Vista will be doing this too, with Direct3D rather than OpenGL.
(And OSX has been doing it since day one.)
What it comes down to is that people want nifty translucency and fluid animation effects even in a 2D GUI, and the best way to implement it is by compositing the desktop using the video card's 3D engine. The Composite extension currently available in Xorg facilitates an alternative approach, based on XRender which still uses the video card's 2D engine, and that's quicker to implement, but not as robust or flexible. (And XRender doesn't benefit from hardware acceleration -- they're working on that now, under the name "Exa", but the nice thing about OpenGL is that we already have it accelerated.)
Hopefully this WILL make development more transparant. The Xgl is needed for the future Linux desktop and I am glad Novell decided to play ball with everyone.
Oh course, the Xgl is still YEARS away from being shipped as the default on the desktop of a major distro. But we have to start somewhere, and people like me need the new eye candy fix!
Open Source Sushi
Just a few minor corrections :).
The Composite extension currently available in Xorg facilitates an alternative approach, based on XRender which still uses the video card's 2D engine, and that's quicker to implement, but not as robust or flexible.
Repeat after me. There is no formal relationship between XRender and Composite. The Composite extension simply provides a method for an external program to handle how the desktop is rendered. It hands that program a bitmap for each window, and it is up to the program to do something with them. xcompmgr and KDE's composite manager, which is based on xcompmgr, use XRender to blit those bitmaps in the proper order. Luminocity, gnome's next gen window manager, contains a composite manager that uses OpenGL to render the desktop. The point is that composite manager can do whatever it wants to the bitmaps it recieves. It can invert the colors, make it translucent, flip it upside down, or tile a picture of elmo all over every window. That is the power of Composite.
And XRender doesn't benefit from hardware acceleration -- they're working on that now, under the name "Exa"
EXA is the replacement for XAA. XAA and EXA are 2D acceleration architectures. Much like OpenGL is to 3d. They provide the raw methods for hardware accelerate bit blitting, line drawing, 2d polygons, etc. Some cards accelerate more things than others. A video driver can provide 2d acceleration using XAA or EXA and not accelerate the XRender extension. The default configuration for the propietary nvidia drivers does this. However it uses neither EXA or XAA, but a propietary acceleration architecture. Not that it matters much as it is transparant to applications. XRender can, and is accelerated under many drivers. EXA and XAA do not depend on it, though, and it does not depend on them.
but the nice thing about OpenGL is that we already have it accelerated.
We already have 2D acceleration as well. The nice thing about OpenGL is it is usually faster and more feature rich. XGL aims, as far as I am able to tell, to replace all the functionality your typical driver comes with using OpenGL: EXA, XRender, Xv, RandR, etc.
Basically, what this boils down to is that XGL will draw the content of the windows: the text, the buttons, the images, etc. Then, if there is a composite manager, it will send the content of those windows to it, and it will do with them as it sees fit. Once the window contents are sent to composite what happens next is beyond the scope of XGL.
The greatest use of accelerated 3d graphics would be the independence of the GUI display from the physical screen resolution without loss of detail (resolution permitting, of course). But the X protocol is pixel-based, and therefore OpenGL is almost useless. Windows can be treated like textures, but GUIs would be much better if they were vector-based.
"So don't worry about that."
That's sort of hard in this alphabet soup of acronyms for myriad projects and libraries.
I really really hope, and hope somebody can confirm this, that at the end of the day there is a STRONG inclination to:
* developer a SINGLE (SINGLE! (SINGLE!! (i mean it))) X server binary which can either render through hardware acceleration OR software, which can be determined dynamically at startup (through configuration or auto-detection), as well as the slew of other acronyms. A separate standalone OpenGL-only X server would be a configuration, maintenance and end-user documentation nightmare.
All this stuff sounds really really cool, but it all appears very fragmented, with each fragment dependent on some other alpha-quality fragment that has not yet been merged into anything other than a nice dream.
So I really hope all these exciting fragments get unified under a consistent X server and set of modules/libraries, instead of remaining really enticing fragments forever.
It's 10 PM. Do you know if you're un-American?