Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!tut.cis.ohio-state.edu!ucbvax!pasteur!dent.Berkeley.EDU!davidh From: davidh@dent.Berkeley.EDU (David S. Harrison) Newsgroups: comp.windows.news Subject: Re: obsolete arguments against NeWS Keywords: NeWS, X, Toolkits Message-ID: <20973@pasteur.Berkeley.EDU> Date: 3 Jan 90 00:01:35 GMT References: <9001022135.AA05473@brillig.UMD.EDU> Sender: news@pasteur.Berkeley.EDU Reply-To: davidh@dent.Berkeley.EDU (David S. Harrison) Followup-To: comp.windows.news Organization: UC Berkeley CAD Lab Lines: 117 Some of you may receive this posting twice due to my error. My apologies. David Harrison>The solution is to have programs agree on a toolkit. Don Hopkins>How can you get programs to agree on a toolkit if you can get the Don Hopkins>people who write and use the them to agree on one? Right now, Don Hopkins>I'd rather have a *GOOD* toolkit, than a *STANDARD* toolkit. Once Don Hopkins>there is such a thing as a good toolkit, then we can start talking Don Hopkins>about standards. Here we agree. I too would prefer a good toolkit over a standard one. However, the problem of orthogonal UI development libraries and the resulting large applications and servers will not go away until a standard toolkit is adopted. Besides, I will stick by my argument that the underlying system (either NeWS or X) make very little difference when developing a good toolkit (or a standard toolkit). In the final analysis, I think the underlying system will make little difference in general to application programmers once a successful toolkit appears on the scence. Most application programming will be done at the toolkit level and not at the window system level. dk>NeWS applications share more than just the toolkit code. They share dk>lots of runtime data, and even event managers (light weight NeWS dk>processes). Perhaps I am missing something but it seems to me that the code and resources applications share is the definition of a UI toolkit. Even under X, toolkit applications share resources other than code. dsh>- Under X, applications will link against a shared library for most dsh> toolkit functionality and may use server extensions (if present). dk>And if the extensions are not present, you lose. I refer you to the dk>thread in comp.windows.x about the impossibility of running anything dk>that depends on Display PostScript on an X terminal or other dk>workstation not supporting DPS. dk> dk>Under X, extensions are linked into the server during the entire dk>session, even if you don't need them, but if you don't have a needed dk>extension, you lose. Under NeWS, you don't have to load an extension dk>until it's needed, and when you need it, you only have to load it if dk>it's not already there. (For example, UniPress Emacs comes up much dk>faster the second time you run it since it doesn't have to load its dk>NeWS driver again.) It's even possible to un-load extensions you dk>don't need any more. I agree NeWS has a better model for incremental extensibility than X. However, it is a two-edged sword and there are definite tradeoffs. Extensions downloaded into NeWS incrementally are interpreted. A 3-d enhancement package like PEX downloaded in this fashion would be much too slow to be useful. Of course this kind of extension could be "built in" to the server. This is exactly the problem X addresses with its extension mechanism. Not all enhancements to a server lend themselves to interpretation or the restrictions imposed by the Postscript imaging model. dsh>In both cases, applications will share the toolkit code. The sum dsh>of server size and client size should be roughly equivalent. dk>What about the sum of server size plus the size of *each* client? I mentioned this in a followup article in comp.windows.news. There is indeed a savings for NeWS applications that is proportional to the number of different machines used. This number is fairly small under most conditions and thus the savings are minimal. Don continues by mentioning some of the problems I have found with NeWS and how they are fixed in the new OpenWindows server. I am pleased these problems have been addressed. Personally, had they been addressed two years ago and had NeWS been more widely available, I might have chosen it for our application. One in particular requires some comment: dsh> I am not convinced that the raw drawing speed of Postscript dsh> based graphics interfaces is sufficient. Postscript was designed dsh> as a page description language. Unfortunately, CAD of ICs dsh> does not fit into this view of the world very well. Most dsh> implementations of Postscript (and I assume NeWS) are very dsh> good at rendering fonts and line drawings. Views of a large dsh> integrated circuit have very little text but thousands of filled dsh> boxes, polygons, and circles. So far, I have seen little dsh> indication that any emphasis is being placed on this type dsh> of graphics in Postscript or NeWS. dk>You should see NeWS running on a Sparcstation with a GX accelerator, dk>or the Silicon Graphics with its special graphics hardware. NeWS dk>programs can take advantage of graphics accelerators like the GX board dk>that speed up PostScript graphics, without any modification [modulo dk>problems caused by the use of antisocial, device dependant operators dk>like setrasteropcode, as described above]. The merged server has promise simply because it allows you to use X for graphics intensive work. I don't want an interpreter in the way when I dump fifty thousand stippled rectangles into a window. As far as machines go, I find the performance of my color DECstation 3100 running X very satisfying (especially when compared to any color Sun with or without accelerator). dsh>The X team has put a lot of time into input dsh>handling and event generation. I have a bad feeling that certain dsh>interfaces may not be realizable in NeWS. dk>It's been almost two years since you said that. Has your bad feeling dk>been confirmed? The lack of serious NeWS applications still makes this point an open question. It may now remain open since the two models have been merged. In my own development, I have found the X model sufficient for the tasks at hand with no major blocks to forward progress. When I looked at NeWS (and many of these points have been addressed), I could not say the same thing. David Harrison UC Berkeley Electronics Research Lab (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh)