Slashdot Mirror
Not Just Eye Candy At Freedesktop.org
Jim Gettys writes "While Keith Packard's eyecandy at freedesktop.org, including drop shadows, translucent menus and windows with alpha channels is nice to look at, and in some ways useful, *much* more important
is that the same facilities are useful for
thumbnailing, screen magnifiers, and arbitrary transforms of applications on their way to the screen, just to name a few of the potential
applications. So enjoy the eyecandy, but remember, too much candy can rot your brain. And if you want to
avoid fattening your brain, you can come help us
make this ready for prime-time, and work off
the candy you ate and pitch in at freedesktop.org."
For background, see this earlier Slashdot post about Freedesktop.org, and the brief description below.
An anonymous reader sums up this effort to revamp X: "The new X server features full support for transparency, and has window-level image compositing among other things. It allows applications to present alpha-blended content to the screen. A new X Visual was added to the server. At 32 bits deep, it provides 8 bits of red, green and blue along with 8 bits of alpha value. Applications can create windows using this visual and the compositing manager can take those contents and composite them right onto the screen. The X server project holds sources to build an X server separately from a full X distribution."
Image saved before slashdotting, Here
The objectives of Xouvert and the freedesktop.org Xserver are different. Xouvert is intended to be an experimental "bleeding edge" branch of XFree86 with opportunities for developers to contribute easily and will remain in sync with XFree. Xserver on the other hand has no connection or relationship with XFree and is wholly an alternative (not a fork ... this code is based on Keithp's own XDrive server which has a brand new core, not XFree86, although some code is reused I believe). In other words they are in fact separate projects.
I'm not sure exactly how the Xouvert folks respond to this, but I believe they are interested in eventually collaborating with this effort in the future, from, my discussions with a couple of them.
And no, it's not just FB/Vesa. There are servers available for r128, mga, mach64, and a couple of older cards (S3 savage/trio and trident).
Am I a hipster-doofus?
That will be up to the compositing manager. It can choose to do it all in software or use OpenGL if available.
We will probably see a lot of window managers get composite managing built in, but there is also likely to be a few compositing only manager, which will work with your favorite window manager.
So in the end it is up to the manager to uo decide how to do the compositing.
I take it you've not used Windows in the last few years then. Take a look at the menus and toolbars in Wordpad, Visual Studio, Office 2003, Windows Media Player and Encarta.
What? They're all different? How dare those people not use the builtin toolkits - what are they thinking?
I think that really you don't understand the Windows architecture (which is really quite similar to X except for no network transparency and a kernelized WM), otherwise you'd realise that multiple conflicting toolkits happen all the time there.
This is even true of MacOS X. There are some well known incidents where it was shown that different apps in the MacOS X base distribution reinvented the same widget multiple times over.
"and the ability to run programs remotely is good, but now days for the average desktop user, this is not very practical,"
This is a complete non-issue. By default, X doesn't allow connections from outside so you can't use it unless you really *want* to use it.
And local applications doesn't communicate using a TCP socket, but through shared memory and Unix Domain Sockets (which are as fast as shared memory, at least on Linux), so performance problems for local apps are gone.
Network transparency doesn't stand in your way. It doesn't bother you. But when you need it, it's there.
And you people should look beyond the home desktop. Think about the corporate desktop! A server serving hundreds of thin clients can save a lot of money. Many, many people today rely on X.
Network transparency *does not* block desktop acceptance.
I'm wondering how long before we see this in XFree86.
:)
It probably won't go into XFree86. The freedesktop.org X server contains a rewritten core and relies on many X extensions that the XFree86 project is really not embracing. Despite the good work the XFree86 team has done over the years, they have a long history of hesitation and, even worse, conflict with those that would take XFree86 in a non-standardised direction.
I applaud the new efforts on freedesktop.org, especially by the evergreen Keith Packard, and this is what we need to see in the FLOSS world.
X11 is one of the few areas where there is no real competition between projects. Linux vs. BSDs (vs. each other) or KDE vs. GNOME. It's healthy; it pushes the projects to higher levels of progress. Once freedesktop.org's X server is ready for mass consumption (hopefully not too long) then this 'lack of competition' changes.
FLOSS will see a whole new world of graphical coolness as Window Managers and Desktop Environments add Compositing Managers to produce awesome effects using freedesktop.org's X server and the group of projects supporting it.
The freedesktop.org X server intermingles with things like Cairo and lots of other exntensions. Conversely, XFree86 seems to fight any hopeful extensions.
What will happen is that in a couple of years, many DEs and WMs will ship with a 'feature X requires freedesktop.org's X server and will not work with XFree86' and XFree86 will lose backing and momentum.
The only downside to freedesktop.org's X server is that it will no longer run well on a 20mhz 486.
Yeah, I don't care either.
Free Gamer - Free games list and commentary
In the long run, KDrive will become the standard: it's a much better server. KDrive does share much code with XFree86, but it has major cleanups and simplifications. It will need more driver support (though this is much simpler in the KDrive architecture) as well as 3D support before it is ready to take over, though.
In the short run, the right answer is to fold the changes back into XFree86. This should be no big deal technically: there's nothing terribly KDrive-specific about them. Politically, it may be harder: the reason that Keithp was ejected from the XFree86 project was essentially for trying to change things. :-)
The XFree86 DRI project server is on freedesktop.org, and will probably have these fixes well before the XFree86 core server. This server is likely the immediate future of XFree86 anyhow.
Actually, KDrive runs better on a 20MHz 486 than XFree86. It's much smaller, and has things like a shadow frame buffer VESA mode that make it work well with pathetic graphics HW. I've used KDrive on an 8MB 386 to good effect.
Of course, you won't want to use the fancy compositing managers on such a box, but at least you can have some kind of window system on it instead of just being stuck with console mode.
X11 isn't like the stuff Microsoft or Apple churn out. Microsoft and Apple just hack something together, throw it out, and call it a "standard API". It's easy. It's quick to market. And it locks people into proprietary APIs and has all sorts of other problems.
X11 is a protocol, not an implementation. As part of defining protocol extensions, people build a reference implementation of the protocol extension. It makes perfect sense to build the reference implementation in software. Hardware vendors and implementors can then build hardware accelerated versions of it and compare it with the software implementation.
This approach has worked very well. It means that X11 has remained backwards and forwards compatible over more than a decade and that X servers have been able to take advantage of new hardware technologies as they have come out.
Note that Apple is not using the "innate RGBA capabilities of the video card" to its fullest extent either. Furthermore, even good 3D cards may not do the right thing for 2D rendering--2D desktop rendering is not simply a subset of 3D rendering.