xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (10/25/90)
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 <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> \XX/ anything less? -- Convener, comp.sys.amiga grand reorganization.
jmeissen@oregon.oacis.org ( Staff OACIS) (10/26/90)
In article <1990Oct24.221622.3575@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: ->peter@sugar.hackercorp.com (Peter da Silva) writes: ->> 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. But that's EXACTLY the problem with X. Instead of having the device which actually performs the display function (the server) handle clip regions and window refreshing, the application is responsible for these things,\ which puts the burden back on the central system running multitudinous X applications for users at distributed locations. PLUS it has to push all this data back and forth over the local net, adding to the net load. Don't confuse window manager with server. In most cases, the X user has a box configured as a server, tied in to a central system. This distributes the SERVER's function, while centralizing CLIENT activity. Obviously you want to off-load as much as possible onto the server! -- John Meissen .............................. Oregon Advanced Computing Institute jmeissen@oacis.org (Internet) | "That's the remarkable thing about life; ..!sequent!oacis!jmeissen (UUCP) | things are never so bad that they can't jmeissen (BIX) | get worse." - Calvin & Hobbes
dlt@locus.com (Dan Taylor) (10/30/90)
jmeissen@oregon.oacis.org ( Staff OACIS) writes: >In article <1990Oct24.221622.3575@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >->peter@sugar.hackercorp.com (Peter da Silva) writes: >->> 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. >But that's EXACTLY the problem with X. Instead of having the device which >actually performs the display function (the server) handle clip regions >and window refreshing, the application is responsible for these things,\ >which puts the burden back on the central system running multitudinous >X applications for users at distributed locations. PLUS it has to push >all this data back and forth over the local net, adding to the net load. >-- >John Meissen .............................. Oregon Advanced Computing Institute >jmeissen@oacis.org (Internet) | "That's the remarkable thing about life; >..!sequent!oacis!jmeissen (UUCP) | things are never so bad that they can't >jmeissen (BIX) | get worse." - Calvin & Hobbes NONSENSE!!!!! Even cheap X-Terminals have at least SOME "backing-store". This allows the server to "hide" windows and then redisplay them WITHOUT sending events to client processes. Given the Amiga's windowing power, unless the X implementations are REALLY screwed up, there should be excellent performance up to the point that CHIP memory is consumed. Even then, FAST RAM, even disk files, could be used as backing store, ELIMINATING window refresh, unless the client has changed some data. No client or network overhead. RT_M. -- * Dan Taylor * The opinions expressed are my own, and in no way * * dlt@locus.com * reflect those of Locus Computing Corporation. *