sean@ms.uky.edu (Sean Casey) (10/22/88)
Here at UK, we're running both X10 and X11. I've noticed that X11 is
so much slower than X10 that no one wants to use it.
What gives? Usually, software becomes tighter, faster, and more refined
in future revisions. X11 is as slow as a dinosaur.
Is anything being done to correct this? Is X11R3 addressing this?
Sean
--
*** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet
*** The Hacker from Hell. {backbone|rutgers|uunet}!ukma!sean
*** U of K, Lexington Kentucky, USA ..where christian movies are censored.
*** ``The World... she's a flat! She's a round! Flat! Round! Flat! Round!''jim@EXPO.LCS.MIT.EDU (Jim Fulton) (10/25/88)
As has been pointed out many, many times, it depends greatly on the platform that you are using. Most of the MIT servers stress portability over speed, which isn't surprising given that they are all donations. People from a number of organizations have started building their own speedier versions for some of the more popular workstations. The game is still young enough that this sort of work is one way of gaining a short-term proprietary advantage. There is a sort of Catch 22, though. Companies that have done their own servers on other people's hardware have had to do so to make their own products competitive. If they were to release the work, then their products would lose some of their value. But, in the long run, the vast majority of these companies will punt their private servers in favor of implementations done by companies whose job it is to do window systems and to do them well. Small organizations usually aren't in a position to give away their engineering; large organizations haven't finished yet. This started with X10 servers (a certain MCAE company that I know introduced its first product on its own port of the X server in the fall of 1985), and I suspect that it will continue for at least another year. > X11 is as slow as a dinosaur. Depends on your hardware. Several of the R2 servers were quite nice. > Is X11R3 addressing this? Not explicitly. Bottlenecks in some of the common code has been fixed, but we haven't had the time to do pure optimization work. We concentrated on adding backing-store and save-unders, divorcing font names from file names, and fixing the arc code (talk about zippy :-). There will be several patches in the user-contributed section that were donated by people who started delving into the R2 server. We didn't have a chance to integrate and test them on all of our platforms, so we are including them in contrib for other people to use. We hope to have the time in R4 to focus on some of the more major problems. Of course, help (primarily in the form of working, tested code) is ALWAYS welcome. If you're at all interested in drawing pretty pictures, optimizing ddx's can be a pretty exhilarating. The long term goal is that the server will become just another part of the operating system. People who want lots of supported, machine-specific optimizations will run a vendor-supplied version. People who want to be on the cutting edge so that they can hack it themselves will run the public sources. Jim Fulton MIT X Consortium