Path: utzoo!attcan!uunet!crdgw1!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!ucsd!pacbell.com!tandem!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga Subject: Re: Where should X concentrate its CPU cycles? Message-ID: <1990Oct24.221622.3575@zorch.SF-Bay.ORG> Date: 24 Oct 90 22:16:22 GMT References: <2382@trlluna.trl.oz> <6877@sugar.hackercorp.com> Organization: SF-Bay Public-Access Unix Lines: 31 peter@sugar.hackercorp.com (Peter da Silva) writes: > [...] I'm sure people will find any window system acceptable if it's > what they started with, but I've been spoiled by having the O/S > (Server, etc) do it's job for so long that I'm not about to put up > with one that expects the application to. Whether it's MS-DOS (which > requires every program to do thir own serial drivers), MacOS (where > every program is responsible for scheduling) or X (where the > application is responsible for maintaining display integrity) it seems > to me a waste of time to duplicate functions needlessly. To the contrary, this is exactly in line with the move from mainframes to microcomputers. Remember the horrid bottleneck when 20 students all logged onto a VAX 11/750? The common (server) device is going to be the bottleneck, so the appropriate thing to do is to offload as many cpu cycles as possible to the client machine. Anything else would lead to _dreadful_ performance. You pay for this with huge executables on the client, but that's perfectly fine when memory is cheap and cpu cycles (especially shared ones), as well as network bandwidth on a common ethernet are dear. This does not at all suggest or support the idea of writing the client software from scratch for each application. /// It's Amiga /// for me: why Kent, the man from xanth. \\\/// settle for \XX/ anything less? -- Convener, comp.sys.amiga grand reorganization.