Slashdot Mirror
The Power of X
An anonymous reader writes "The license changes in the last version of Xfree86 have caused many distributions to reject the project in favor of the forked X.Org X server. As X.Org prepares to release the second version of the X.Org "monolithic" X Server (dubbed version 6.8), Ars Technica investigates the future of the X platform, as cooperation between X.Org and projects like GNOME and KDE begin to take take hold at freedesktop.org. Already host to an impressive array of projects, it appears that freedesktop.org will become the hub in which other Free Desktop projects can collaborate. Daniel Stone, release manager for freedesktop.org, gets into the details on how it's all going to work, in conjunction with freedesktop.org's upcoming platform release."
I thought Xfree86 was a fork of the original X11 development camp and that X.org is a refounding of the original X11 camp after lots of splits, esp with alot of Xfree86 dev guys getting annoyed and going 'back to their roots' as it where..
Could be wrong (and frequently am)..
What I'd really like to see is some support for X type connections in the next version of windows. I don't mean basing all of windows on X11 but perhaps allow remote windows sessions that are native. Not based on screen redraws like VNC.
I fear that in the long term windows manager features will included into the X server. The cooperation between X.ORG and the KDE / Gnome teams doesn't bode well.
Such an integration would destroy the versatility and uniqueness of the X protocoll. Indeed X would degenerate to a remote enabled clone of the Windows desktop after some time.
Yes, want Linux/BSD on the desktop but not this way.
This is like getting an elephant into your car by cutting him into pieces.
I know I'm going to get flamed by all the 80x24 textmoders out there, but compositing is cool
$ strings FTP.EXE | grep Copyright
@(#) Copyright (c) 1983 The Regents of the University of California.
With all this talk of X, ive remembered Y-Windows http://www.y-windows.org/ Does anybody know whats happened to Y? According to the road map, version 0.3 should have beed out 4 months ago.
He avoids answering the question about XFree86 Driver compatibility, especially with regard to NVidias binary drivers. This is a big issue for a lot of users and I hope that NVidias cards will be capable of using the new extensions.
As far as the article goes all I can read is that they work with both major graphiccards vendors but only ATI delivered so far. Or did I miss something?
One of the things that has always bothered me about XFree86 in the past 6 years I have used linux is XFree86's kind of lag in new releases... development seems to move at a snail's pace, and let's be frank, it's almost the same as it was back in the good ol' unix days.
I for one enjoy X.org and a windowing system that can hopefully be kept up to date and have more active development.
But my question is... how many more forks will we have?
James Carr
Its time a load of heads sat down and decided on the features that are required in the next MAJOR release of the X windows system/protocol. None of this piecemeal "we'll add it in as an extension" rubbish thats been happening for the last 10 years as this is becoming unmanageable; "My server has the dbe extension but not open-gl, your server has shapes but not etc etc etc." Just put ALL modern graphics requirements in the base protocol and write new extensions for Xlib and work from there.
I have not seen real dissatisfaction with the technical side of XFree86 in the last few years.
Have you been listening?
(A) There's apparently a ton of longstanding problems with the XFree codebase that are only now being addressed, both in fixing the current codebase and in a longer-term massive redesign/rewrite. The response for years has been "Well, it works..."
(B) There's been an emormous amount of criticism of X protocol design, going back 20 years. But with the rise of OSS frameworks, this reached a breaking point. The X response has been that the Toolkits serve the Windowing System and "Well, X11 is X11..."; rather than the more sensible attitude that the Windowing System should serve the Toolkits (and user programs). This is probably the biggest philosophical difference giving rise to the XFree fork.
The licence change was portrayed as a legal issue, but it was really just the final case of the "XFree Guys are Assholes". If the project wasn't already forking, there would have been no legal shit stirred up.
And that's exactly why I bought a Mac.
Linux to tinker, Mac to use.
BTW. Windows doesn't really copy/paste well though. Formatted copy in WOrd gives me a headache and Excel doesn't keep to Microsoft's own UI guidelines.
The X developers should rewrite the server from scratch using the Aspect Oriented methodology and for example the AspectJ programming language. Many of the X extensions really touch all parts of the server which is exactly the kind of problem aspect oriented programming was designed to solve.
Using AspectJ, an extension such as the Damage extension could be written in a weekend.
Also rewriting the server in AspectJ would allow the developers to leverage the full power of the Java language. With Java reflection the core dispatch code in the server could be replaced by just a few lines of code. The RENDER extension could be completely removed from the server and replaced by using the delegate design pattern to forward X requests to Java2D
The Fresco project had huge potential, but never managed to escape the legacy language C++. It seems everybody working on window system is stuck in the software engineering practices of the seventies.
Please name an application in which compositing gives a better user interface ...
I worked in a GIS (geoprocessing) application to an electrical company. In the user's screen, a map showed up with all polls and wires that are in a location. If you clicked on a poll with, e.g., a transformer, a translucent (big) tooltip came up with all of the transformers specs, where the electricity was coming from, where it was going to, etc (like 20 lines of text). Without dismissing such tooltip, the user is capable of clicking in another poll in the map, and only the contents of the tooltip changed, (maybe it's position if it were possible to move "away" from the current part of the map. The user could even click thru the tooltip, in a poll that was showing below it! (there was a menu item/toolbar speed-button and a hot-key to close the tooltip, obviously)
This kind of interface is *very* practical and would be impossible without translucency. I implemented it in a no-nonsense 15 minutes under BorlandC++/w2k.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I just installed Slackware 10.0 and it came with the X.org system. I didn't even know about the change. I happily went into the config file and configed my video card, monitors, screen and all just like I used to with XFree86. After saving I started X like normal and all ran just fine.
I wasn't until I was reading later on that I realized there was a different X on my machine. Even then I was getting confused because much of Slackwares online docs have not been updated to refect this change.
I like X. X is good. Some X'es are better!
Where do you actually see the new eyecandy? Dropshadows, transparency, etc ... Don't new window managers and applications have to be built to take advantage of them? (I've only read part of the article, so sorry if I missed this answer there.)
screenshot 2
Here's my take on it:
I use Linux on my systems (with Gnome as a DE) and I know what you mean some times. Part of the problem is that people write programs for different purposes - e.g. some people will write a program using Qt and the KDE libraries causing the programs to look one way, while somebody else will use Gtk or another toolkit.
It obviously isn't just down to the toolkit, but also depending on who the application is targetted at, most developers (generalising I know) don't have the time (or don't want to, or don't have lots of experience) to make their application pixel perfect.
Gnome has some usability guidelines and I think anybody would testify to the fact that Gnome itself and applications based around the HIGs have a very consistent feel. Likewise KDE has some HIGs (currently redrafting I think) but it doesn't have anywhere near the emphasis on the programs in the KDE collection IMO.
As well as defining the HIGs, part of the problem is to educate interface programmers and try to ask them to follow the guidelines - and more importantly, for people who have experience in usability (and that includes all users) to comment, suggest changes etc.
An interesting example was on the KDE Usability mailing list the other day - Celeste Paul posted a usability report on KHangman. The coder behind it appeared shortly after and immediately began following the conclusions of the report. I'm sure almost every programmer will be happy to accept constructive criticism for their work.
If you think a menu item or something isn't right, file a bug report against it - and try to include a suggestion (even if it isn't a complete solution) for how it could be improved. It only takes a few minutes. </rant>
the only major problem with x.org I see at the moment is they are adding mostly eye-candy extensions, but things like screen and printer matching are the practical features missing in Windows that could attract a lot of Desktop Publishing and graphics apps to Linux. I think the composite extension is cool, but I would love to see more usefull stuff added.
Well, the problem isn't so much that free software developers don't care about documentation. It's that technical writers don't get involved so much in free software as developers do. There are similar problems with artwork and music for free software games etc.
If you want good art, documentation, music, etc., then start complaining to your friends who do art on computers just for kicks. They could be helping a worthwhile cause!
I think people are more likely to compare the wealth of slick windows-based apps that wow people with unexpected 3D effects at the drop of a hat. Transparency is interesting, but essentially useless, as most people say, but making 3D easy for APPLICATION developers will really change some things. It may even lead to new, unexpected forms of user interface. THAT's what Free Software has to compete with -- a shifting kind of application; not a shifting graphics capability.
On another note, I'd like to see GPUs used through a lower-level library than X. There are plenty of intensive computing tasks that can use GPUs, so it'd be nice to have X ask for the GPU, from a system that shares the GPU resources properly, rather than just hijack it.
This isn't a problem. All new functionality is done by extension to the old X11. I actually keep arguing that we should standardize an X12 which removes things not used much anymore and which includes (sans extensions) the functionality which is wanted, and provide and X11 interface for compatibility (if you have to make an extension extension because there are so many extensions, you need to move to the next version!). However, they don't want that; they want compatibility (which I don't hold to be orthogonal if things are done right, but I'm not (yet) and X hacker, merely an armchair X pundit. ;)
:)
Anyhow, rest assured that compatibility is top priority with these changes. You just won't be able to see the shinies.
--
Given enough personal experience, all stereotypes are shallow.
Sigh, there we go again...
First, get this: when you see a problem, there can be a whole bunch of causes. The only way to fix a problem is to correctly identify the cause.
Which you are not doing here. "X apps seem to be slower so X must be slow" may make sense from a non-technical user point of view, but that doesn't mean it's correct. In fact, it isn't.
If you benchmark things and stuff, you'll see that the problem is not in X itself: it's in the toolkits. So if people listened to you and ditched X, we'd still have the same problems because the toolkits are still slow.
Try using something like WindowMaker and some non-GTK non-QT apps. You'll find that they usually respond significantly faster (not on my machine though; Athlon 1.4 Ghz here, I don't find X apps slow).
And try playing 3D games. Look at the high framerate (assuming you're using a good card and driver, like NVidia + vendor drivers). How's that possible for a windowing system that's slow?
I've written several testing apps, for Windows and X. On both platforms, I get the same frame rate.
Expose events: Windows does pretty much the same thing. If I wrote an app that only responds to the paint event once, and I move a window above it, you'll see that the window won't be redrawn. Windows in fact uses the very same expose mechanism.
X *does* in fact have a feature which allows you to save the content of the window. It's saved Backing Store and Save Under (I think). QT and GTK don't use it except when popping up a menu. Ask the toolkit authors why they don't, because I don't know.
Data copying: data is *not* copied when transferring pixmaps, which is about 90-95% of the traffic. On localhost, XFree86/XOrg uses shared memory for that.
On localhost, normal X messages are transferred via unix domain sockets (not TCP sockets), which are almost as fast as shared memory (at least on Linux). Remember, this is small amount of data.
No modern windowing system allows the app to touch the hardware directly. Not Windows, not MacOS X, not BeOS. In fact, Windows internally uses the same message-based communication system as X. Windows apps don't draw directly to the hardware.
Actually many normal operations appear much faster with composite on than off. Dragging windows, for example. The other extensions plus the off-screen rendering make X appear to be a lot smoother and faster. I remember running an early beta of xserver (kdrive) with the extensions using only the VESA driver. Without the composite manager on, the system was slow some things were just painful. Turn on the manager and normal operations appeared to be almost an order of magnitude faster. When the synchronization stuff is added into GTK and QT, resizing windows will also appear to be much much faster and smoother.
Try using something like WindowMaker and some non-GTK non-QT apps.
I'll have to disagree with you here, because you're comparing apples to oranges. Those KDE and GNOME apps seem slightly slower and less responsive because they've been jammed packed full of functionality. The KDE desktop does about a hundred times as much as the bare WindowMaker window manager. A KDE application is going to pull in ten times the functionality from the KDE librarieas than a bare xlib application will get from X.
The very same thing holds true under Windows, but few people are honest enough to admit it. Windows 95 was snappy and responsive under a 90MHz Pentium and 8MB RAM. But try putting Windows XP on the same system! The difference is that Windows 95 didn't have a tenth the functionality of XP, and that's not even counting the eye candy. When I compare the workstation in front of me between Windows XP Pro and FreeBSD with KDE, I am finding that while XP apps may sometimes start up faster, they most certainly are NOT more responsive. Your situation may be different, but in my work environment that is what I am seeing.
Don't blame me, I didn't vote for either of them!
You can force it to use backing store by starting the X server with the +bs -wm options. According to Alan Cox this is better and feels snappier on most setups but will kill a tiny machine.