| |||||||||||||
|
| |||||||||||||
The X Window System, past and futureThe X Window System, past and futurePosted Mar 27, 2003 22:20 UTC (Thu) by slamb (guest, #1070)In reply to: The X Window System, past and future by paulsheer Parent article: The X Window System, past and future 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.
(Log in to post comments)
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.
|
|
||||||||||||