Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!dprg-330.GOVt.shearson.COM!fgreco From: fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) Newsgroups: comp.windows.x Subject: Re: A tirade about inefficient software & systems Message-ID: <9011150026.AA10815@islanders.> Date: 15 Nov 90 00:26:25 GMT Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 99 > > X11 is not significantly more expensive than NeWS as far a CPU is related. > However the load may be distributed rather differently: some computations > that are done on the client side (eg. user coordinate/screen coordinate > transformations) may be done on the server side. Note that this implies > that a NeWS terminal, should such a beast exist, would have to be more > powerful than an equivalent X terminal. > Well...if you said that an X/NeWS terminal (its only a matter of time...) had to be more "powerful" because it swaps more than the vanilla MIT X, I would tend to agree with you, because OW is larger. NeWS, unlike X, offers you the choice of a client *or* a server-side toolkit; X only gives you the client-side. In any event, using the X/NeWS server, you get both. > The only area mentioned above where NeWS wins over X is in the > interprocess communications overhead: since clients download PostScript > code to the server no client-server transfers are necessary to repair > windows after expose events. How about dedicating a lightweight task *in* the server to efficiently track the mouse? This greatly minimizes the net traffic...there isn't any. (To all those out there who say, "networks are getting faster so who cares?" should hang your software engineering heads in shame.). Reliable double clicks? Its a given. How about a dynamically extensible class mechanism *in* the NeWS server? How about running windowed applications over a 2400 modem? A proof of concept was demoed at a recent Usenix (during a WIP session) with an email application. > > I also believe that NeWS is rather better at handling exceptions (eg. servers > running out of memory) than X, but there is no fundamental reason why X > should not improve in this regard in future releases. Yes, I agree. Both X and NeWS are relatively young and evolving. So why are groups like AFIPS standardizing on Xt as *the* way to program for X? > > Working against NeWS (and presumably Display PostScript) is the fact that > they impose the PostScript imaging model on their clients, which may not > be appropriate for some applications. X11 uses a very low-level raster > graphics model which may act as the foundation for any of a number of > higher level models (including PostScript --- see GhostScript as an example). I don't understand. If you use X/NeWS, you get both. You choose the model that's best for the app. > Furthermore, I suspect that many programmers are not comfortable with the > though of writing PostScript code; certainly the idea of maintaining a > few hundred lines of someone elses PostScript code would give *me* night- > mares. > Gees, on the net we have some of the brightest programmers in the world, yet, most people on it say its a bear to learn something new to solve a problem. These are the same people that know C, C++, Smalltalk, the innards of the Unix kernal, the intricicies of awk/lex/yacc...yet, a simple, simple little language like Postscript scares everyone. The programmers that are typically afraid of Postscript are those people whose first exposure to Postscript was looking at the output of a mechanized, poorly-formatted XXX-to-PS filter. Heck, there is no need for formatting if you're just going to have another program, or printer, read it. I'm sure if your first exposure to C was looking at a multi-pager that didn't have too many newlines or tabs or comments, you'd be saying the same about C (...many have....). > > The fact that I hear people from Sun tell me ``Our implementation of > > Open Look is great --- but you need 16 Meg in your SPARCstation'' alarms > > me. > > This just ain't so. I'm running OpenWindows 2.0 on a SPARCstation 1 with > only 8 Mbytes of memory and, as long as I don't start doing silly things > like grabbing hold of huge globs of shared memory, it hums along very > nicely thank you (not that that stopped me from asking for more memory). Well...lets be fair. Unless you run most of your X/NeWS clients remotely (which is not a bad idea if you can), think about a minimum of 12 MB for doing development on a SS1 with OW. Of course, in this case the more the better. I'm like Chris, I only have 8 MB, but only my console runs locally. I borrow cycles from other SPARCS on the network (isn't that what networks are for?). > Now OpenWindows 1.0.1 really dragged. That turns out to have been due > to the window manager being written in PostScript and, consequently, being > a real memory pig (I rest my case). > In a computer languages class that I taught, I had a student who wrote a video game (so it was a *fun* assignment...so sue me) in interpreted BASIC that ran rings around another students' 80X86 assembler version of the same game. Its not the language. I rest *my* case. Frank G.