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?
They are doing it in a way, that X server doesn't know about implementation details. It may run in software, it may be implemented in hardware (using OpenGL for example). X server just doesn't care, it is job for Composition manager. It may do another things except alpha blending windows - for example capturing screen changes for vnc or screen recorders.
I would post the link, but freedesktop is slashdotted.
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.
at http://www.herrvinny.com/sdmirror/
KDE doesn't handle transparent windows. It fakes transparency by getting the content of the lower windows and using them as the background to higher-level ones. So you'll notice that if you have any kind of changing content underneath a transparent window, you won't see it update.
It's not a matter of transparency being implemented at a lower level- transparency isn't really implemented at all at this point.
KDE doesn't do real transparency. It takes a screenshot of the underlying windows and then alpha blends the menu over that screenshot and draws the result to screen. If the contents of the windows below the menus change while the menu is still open, you'll see it.
But how much faster and snappier will the response be with the transparency done at lower level?
I don't know the answer, but I can make an educated guess. A lot. And I mean a whole crapload faster.
If the server does not support alpha, then the only way wm to blend things is to ask X politely for the background, do the compositing in software, and send it back to X to draw. In fact, in many cases the only "background" you can ask X for is the desktop background, which means that semi-transparent windows are an illusion that only works when windows do not overlap.
If the server does support alpha, then the app simply says "draw me" in it's usual way, with some transparency information, and X does it, overlapping windows and all. The blending can even happen in hardware.
Skipping all this sending of pixels and blending in hardware instead of software can easily speed things up by on order of magnitude or two.
However, given that it's a good design for a GUI program to communicate with the GUI layer using sockets, then you get the ability to run commands remotely almost for free, with the only extra work required being the security & authentication system.
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
The first web browser was World Wide Web and written by Tim Berners Lee. Mosaic came out some years later.
Err correcting myself: Keith Packard's server was called KDrive, not XDrive.
Am I a hipster-doofus?
I don't think this is the issue anymore - the extensions used for this translucency don't require any driver changes, as RENDER (or any other rendering method/extension) can be used.
;-)
Here's to hoping XFree86 gets these extensions. Having an X server that doesn't work that well for the hardware most people are using is going to limit how many people can use these new extensions...
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.
Getting over square brackets was very easy for me, especially since the corresponding semantics in Objective-C are much nicer for writing complex programs in fewer lines of code. The resulting return type from an [object message] expression is always the generic object type, and you are free to send the resulting object any message...if it won't respond to the message, it's quiet about it...even if that object is NIL. (Thank the maker!) Of course, if you want stricter type checking, you have that option too...but at least Objective C gets out of your way when what you really want is to be maximally expressive while being minimally verbose.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
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.
> the fact remains though that kde has been throwing hacks into their desktop for ages with no real substance.
Fake transparency is certainly a hack, but the GNOME folks are as guilty as the KDE folks for using it. Both KDE and GNOME support fake transparency in their terminal apps. GNOME supports it in it's panel, and KDE supports it in it's menus. Other window managers even support fake transparency in their titlebars (like kahakai, afterstep). Tell me how again how KDE has thrown more hacks into their desktop versus others?
> And as far as kde goes with adopting standards they tend to be very against taking any freedesktop work and using it although i guess they may have other reasons than "its the KDE way or no way" D-BUS comes to mind as one such standard.
Uhm, there have been around fifteen standards put out by freedesktop.org. KDE has implemented nearly every single one. You provided one example (D-BUS), that isn't, but might I remind you that D-BUS isn't part of GNOME, or xfce, or ROX either. There has not been a firm agreement or disagreement on the KDE side to use D-BUS or not, because it could only be done in KDE 4.0, which is still a bit far off.
yes, linux had transparent terminals way before OSX(before it existed even...). it was one of my reasons for switching to linux way back when... i don't remember the thumbnailed apps in enlightenment, but i love the dock implementation, particularly when you have dock magnification maxed out. you get a nice clean representation of your app as you mouse over. how did it work in enlightenment?
The blending is being done entirely in the X server.
The speed with depend on whether the X server has hardware support for blending.
The prototype doesn't; it is, however, fast enough to be useable even doing it all in software with a Vesa server, so I think we're ok on performance.
The bits never leave the X server.
The current implementation is software only, and
runs at usable speed.
So I expect when we start using the alpha blending hardware, we'll run like a bandit...
Something like http://www.freedesktop.org/Standards/menu-spec maybe?
Your personal, subjective views on Objective-C without supporting materials does not add weight to your proclaiming your stance is fact.
The syntax to Objective-C that draws from Smalltalk-80 flows grammatically and is quite self documenting.
C++ on the other hand isn't designed to be self documenting and doesn't discourage poor grammar practices.
The problem is is that the current implementation of the features in KDE is very inefficient -- lots of hacks, etc to get "transparency" that doesn't work properly a lot of the time. The freedesktop project rocks because it places all of these functions in the compositing level, which means that any x app can use them, without relying on one specific windowmanager. There are lots of performance gains to be had with this new method, as all of the actions are handled once, at the server level, instead of on a toolkit-by-toolkit basis.
Marxism is the opiate of dumbasses