| |||||||||||||
|
| |||||||||||||
The X Window System, past and futureThe X Window System, past and futurePosted Mar 27, 2003 9:51 UTC (Thu) by paulsheer (guest, #3925)Parent article: The X Window System, past and future Each and every one of the criticisms about X is either completely unfounded, or applies to any other piece of software anyway. Myself I have been programming under XLib for many years. In the first place, X is not bloated. It is in fact the minimal piece of software for what it needs to do. Considering the range of types of raster devices out there, X conanicalizes their differences perfectly. Its protocol needs to be exactly as it is to facility interclient communication. One cannot think of a better way of coping with the problem of creating a hardware independent network transparent Windowing system. Try and see. Let us compare X to MFC (microsoft foundation classes). MFC is the most chaotic mess a developer could ever wake up screaaming to in the middle of the night. The capacity to transparently use other machines on the network has never been so successfully achieved as by The X Window System. It is an essential cornerstone of Unix computing in the world today. Most people who critisize X do so from a single home machine that is used mostly to play games. Such people want to strip the computing world of network transparency (to break their network card in half) just to get a few more FPS out of their first person shooter. Of course there are performance penalties resulting from network transparency. But you don't see them if you are doing productive things with a computer (i.e. not gaming). X is also extremely light on resources - consider that X runs on a 2 floppy Linux distribution. Really no one could ever critisize X for that.
(Log in to post comments)
The X Window System, past and future Posted Mar 27, 2003 22:20 UTC (Thu) by slamb (guest, #1070) [Link] Of course there are performance penalties resulting from network transparency.I think you're confusing two arguments here: (1) X is slow because it supports network transparency, which is unnecessary and (2) X's network protocol is inefficient. I agree with #2 but not #1. Its network protocol is slow because it talks at such a low level: draw these shapes here, the mouse moved, etc. Basic operations like moving the mouse and adjusting a scrollbar seem unusably slow over the Internet to me, and I have broadband. If the server did buttons, scroll bars, and other primitive widgets, this would not be a problem. Fresco does this. In other words, it moves much of the toolkit to the server side. Events only need to be sent from the server to the client if your code is interested in them, and it's not that often people register a mouse movement listener. That approach isn't perfect either, but you have to admit that it's dramatically more efficient. Like the difference between applications feeling unusable over the Internet to me and feeling responsive. Less time waiting for a response = more goodness.
The X Window System, past and future Posted Mar 28, 2003 0:23 UTC (Fri) by josh_stern (guest, #4868) [Link] Agree with slamb as far as it goes, but further analysis argues that the *real* problem with X is the social/organizational one of getting new extensions to become standard. The universal design of the protocol communicating primitives works great for its intended application - non graphics intensive applications in a LAN environment - in a programmer transparent way. But as you imply, extensions are needed for graphic intensive and internet use. In fact, a general purpose, suitable, substitute already exists: display lists with GLX. But usage is only possible for particular combinations of client libraries and X servers, which are still not common enough (and bug free enough) to make it a viable, general purpose, application programming strategy. So here is an example where we can see how a larger programming team (more horses for implementation) and a more aggressive approach to promoting change and new standards could help! So the current debate is key, *because* the issues are not fundamentally ones of technical design.
The X Window System, past and future Posted Mar 28, 2003 1:16 UTC (Fri) by iabervon (subscriber, #722) [Link] The X protocol used to be fast, because those drawing primitives were what people used to make the interfaces of the day. Now it's slow, because many modern interfaces need more complicated operations. But the operations they need still don't have to involve policy or determine how things look. X ought to have splines, (more) anti-aliasing, blending of lines, etc; essentially, the set of primitives in SVG. Then applications would be able to use the primitives that their interfaces are composed of and wouldn't have to resort to the messy use of the inadaquate primitives they currently use.
The X Window System, past and future Posted Mar 28, 2003 1:10 UTC (Fri) by iabervon (subscriber, #722) [Link] Of course there are performance penalties resulting from network transparency. But you don't see them if you are doing productive things with a computer (i.e. not gaming).Or if you connect to :0.0, which uses a UNIX socket, not the network. X is sufficiently clever to *not* be network transparent if there happens not to be a network.
The X Window System, past and future Posted Mar 29, 2003 17:36 UTC (Sat) by ptr (guest, #5885) [Link] I think that slightly misses the point. The criticism of efficiency applies to the protocol whichserializes display updates into a data stream. This protocol is used no matter whether a remote network connection or a local unix socket is used. This protocol is claimed to be inefficient, because the supported drawing primitives are too low-level (as mentioned earlier in this thread). Another fundamental question is, if there are better approaches for inter process communication than serialization which scale up better in the case that the applications run on the same system. Of course, also security issues are of concern...
|
|
||||||||||||