tmb@WHEATIES.AI.MIT.EDU (Thomas M. Breuel) (07/03/88)
|From: sgi!daisy!klee@bloom-beacon.mit.edu (Ken Lee) |In article <980@eos.UUCP> al@eos.UUCP (Al Globus) writes: |>From talking to people and reading a bit of the documentation it seems |>that X has two fundimental problems relative to NeWS. Please forgive |>me if the newsgroup has been over this already, I'm new on it. |> |>1. The performance of highly interactive operations with a remote client |>are dependent on network load. | |Yeah, that's a problem and there's no way around it, short of extending |the server (at compile time). The client doesn't even have to be |remote. Inter-process communication on a single machine eats up alot of |cycles. In the case of NeWS, postscript is a horrible choice of extension language for the server. It is slow and semantically unclean. Why should I have to use a programming language whose designers ignored years (decades?) of developments in software design and programming language technology? I could also write my application in FORTH, but I could also eat soup with a fork. With networked windowing systems, the main problem is that of proper partitioning of the application between the client and the server machine. The major constraints are computational resources on the client and the server, and bandwidth of IPC and the network. Let us assume for the moment that our major constraint is network bandwidth. Then we would like to partition our problem such that a minimum amount of information has to flow over the network (subject to distributing the computation to a certain degree). Often, this means that most of the graphic operations ought to happen on the server machine, and the client only sends some data (consider the case of a numerical program that generates a vector that is to be graphed. A "good" partition might be to do the computation on the client, ship the resulting vector over to the server, and do the graphing on the server; in fact, a lot of scientific graphics problems are very similar to this one). NeWS allows you to partition your problem this way by allowing you to write the server side of your code in postscript. The primitives used to communicate with an X server are fixed, however, and IPC on the server is slow enough that it almost doesn't matter whether you run the server code in the above example on the server or on the client. If, however, you assume that your major constraint is not network bandwidth or local IPC, but server resources, the X approach is completely valid and even preferable to NeWS. By specifying in advance what the server can and cannot do, I can build a box whose sole purpose is to be an X server and which doesn't waste any resources on bizarre eventualities (postscript engines are notorious for running out of resources). A solution to this dilemma might be (1) to speed up local communications (for example by having a non-network version of Xlib that writes directly to shared graphics memory or by improving IPC performance), and (2) to write portions of an application that are time critical in 'C' and execute them on the display server. In effect, this makes 'C' the extension language of the server (rather than postscript). Another option you have right now is to add extensions to the server directly. In NeWS' defense, the choice of postscript as an extension language means that the display server need not be able to execute arbitrary 'C' programs or even have any kind of process running other than the NeWS server; the server end of an application is very portable and can be downloaded while an application is executing simply over the network connection to the display server. (The primitivity of postscript and the overhead of downloading, of course, limit the complexity of the server end of applications significantly). |>2. X graphics are pixel based, so if pixel size changes the size of |>things on the screen changes. | |Conversely, if you care about specific pixels or colors, you're screwed |if you use NeWS. You can write a PostScript server for X, solving many |of these types of problems, although you may pay in speed. In NeWS you always pay the overhead of postscript, whether you need it or not. At least X with a postscript server gives you a choice. Altogether, I'm unhappy both with the X and NeWS approach. I believe it would have been preferable to make X a local, highly efficient window system and to encourage people to write network servers for specific applications (e.g. an xtermd/xterm pair). Much of the hair of the current X semantics could have been avoided. Of course, in that case, each window system implementation would have had to deal with IPC and resource sharing more complex than reliable streams, and applications would have to deal with the network themselves. Altogether, X is a standard, whether one likes it or not, so one should try to make the best of it. Thomas. PS: I suppose I should have said "the X window system" instead of "X" in the above.