don@CS.UMD.EDU (Don Hopkins) (01/03/90)
>Date: 2 Jan 90 03:00:24 GMT >From: pasteur!ic.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) >[...] >I am afraid I disagree with the arguments expressed here. The problem >truely lies in toolkits and policy. In order for memory savings to >take place, programs *must agree* to use the same features. Otherwise, >using the NeWS paradigm, each program will download its own features >into the server and you will have a gigantic server where little or >no sharing occurs. > >Furthermore, the problem is *identical* for both NeWS and X. Both >systems provide fairly low-level user interface programming facilities. >Both systems require higher level facilities in order to quickly build >real-world user interfaces. The solution is to have programs agree >on a toolkit. How can you get programs to agree on a toolkit if you can get the people who write and use the them to agree on one? Right now, I'd rather have a *GOOD* toolkit, than a *STANDARD* toolkit. Once there is such a thing as a good toolkit, then we can start talking about standards. >The memory savings will be the same under both systems: >- Under NeWS, toolkit facilities will be downloaded to the server where > possible and applications will link against a shared library for > client side facilities. NeWS applications share more than just the toolkit code. They share lots of runtime data, and even event managers (light weight NeWS processes). >- Under X, applications will link against a shared library for most > toolkit functionality and may use server extensions (if present). > And if the extensions are not present, you lose. I refer you to the thread in comp.windows.x about the impossibility of running anything that depends on Display PostScript on an X terminal or other workstation not supporting DPS. Under X, extensions are linked into the server during the entire session, even if you don't need them, but if you don't have a needed extension, you lose. Under NeWS, you don't have to load an extension until it's needed, and when you need it, you only have to load it if it's not already there. (For example, UniPress Emacs comes up much faster the second time you run it since it doesn't have to load its NeWS driver again.) It's even possible to un-load extensions you don't need any more. >In both cases, applications will share the toolkit code. The sum >of server size and client size should be roughly equivalent. What about the sum of server size plus the size of *each* client? As a contrived example, it would take less resources to run 10 NeWS performance monitors on 10 different machines than to run 10 X performance monitors on 10 different machines, especially if each X performance monitor had to link against the X toolkit to provide a "QUIT" button (with all the un-shared run time client side toolkit data structures that involves). >My point is that there is nothing fundamental about NeWS that makes >this problem any easier. Furthermore, in my opinion, there are some >problems in the NeWS model that make it harder to develop a general >purpose toolkit that meets the needs of a wide range of application >developers. I have posted these problems before in this newsgroup so >I won't repeat them here. > > David Harrison > UC Berkeley Electronics Research Lab > (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh) Besides the fact that some of your arguments are obsolete with the introduction of X11/NeWS, I disagree that your objections have anything to do with the difficulty of developing a general purpose toolkit. In fact there are a lot of fundamental differences between NeWS and X that make toolkit development in NeWS easier, that have been discussed before on this mailing list. I will repeat your points myself. >Date: Wed, 7 Sep 88 10:14:09 EDT >From: pasteur!dent.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) >[...] >1. No primitives for modifying colormaps. Fixed in the merge. (visual, colormap, and colormapentry data types) >2. No support for plane masks on multi-plane devices. Fixed in the merge. (setplanemask operator) >3. No support for interlocked tiling of filled regions. >[...] I don't know if this problem has been or will be addressed. Anybody who knows care to comment? >Date: Sat, 16 Apr 88 00:39:57 EDT >From: pasteur!dent.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) >[...] >1. Raster operations other than copy or xor. >[...] That's been in NeWS since 1.0. (setrasteropcode) Its use is considered poor form. (I learned that the hard way when porting the UniPress Emacs NeWS interface to the Silicon Graphics 4D -- It was trying to blink, using exclusive-or for the visual bell, and since such rasterops require reading pixels back from the screen, and the CPU couldn't access the graphics memory directly but had to go through the graphics processor, it took a couple seconds to blink the window! Yes, this is the same machine that runs that excellent flight simulator in real time. If you depend on reading pixels back off the screen, then you are going to lose big time on certain types of hardware. {the fix was to use the NeWS overlay plane abstraction, but then it blinked much too fast, so I had to put in a short sleep.}) >Date: Mon, 15 Feb 88 10:55:17 EST >From: pasteur!dent.Berkeley.EDU!davidh@ucbvax.Berkeley.EDU (David S. Harrison) >[...] >Raw Rendering Speed > > I am not convinced that the raw drawing speed of Postscript > based graphics interfaces is sufficient. Postscript was designed > as a page description language. Unfortunately, CAD of ICs > does not fit into this view of the world very well. Most > implementations of Postscript (and I assume NeWS) are very > good at rendering fonts and line drawings. Views of a large > integrated circuit have very little text but thousands of filled > boxes, polygons, and circles. So far, I have seen little > indication that any emphasis is being placed on this type > of graphics in Postscript or NeWS. You should see NeWS running on a Sparcstation with a GX accelerator, or the Silicon Graphics with its special graphics hardware. NeWS programs can take advantage of graphics accelerators like the GX board that speed up PostScript graphics, without any modification [modulo problems caused by the use of antisocial, device dependant operators like setrasteropcode, as described above]. >On a more personal note, I tend to like the amount of control given >by X. And I tend to like the ammount of power given by NeWS. It's because of people like you and people like me that Sun merged X11 and NeWS. Now I can play my games with the PostScript interpreter in one window, and still experience psychodellic colormap flashes whenever I move my cursor into a window running one of your X applications. >Until we understand more about modeling device independent >graphics, I feel we must have enough control over the device to try >out new approaches. As so many East European dictators have learned, total control is *not* necessarily a good thing. (Although one thing we have learned from the reign of X is what happens when you mix window systems and politics!) There are good reasons for window system application writers to give up direct control of their hardware. (Have you ever tried to port a program from an IBM-PC to a real computer?) >Finally, I have a nasty feeling about developing highly >interactive applications in a graphics environment based on an output >only graphics standard. There's nothing "output only" about NeWS. Adobe's non-cooperation certainly hasn't stopped Sun from coming up with well designed interactive extensions to PostScript. >The X team has put a lot of time into input >handling and event generation. I have a bad feeling that certain >interfaces may not be realizable in NeWS. > > David Harrison > (davidh@ic.Berkeley.EDU) > UC Berkeley Electronics Research Lab It's been almost two years since you said that. Has your bad feeling been confirmed? I think the NeWS input model is more general than the X input model, since PostScript processes can respond to events locally in the server, and there are no restrictions on the format of the data they send over the wire. There are certain types of interfaces that X is horrible at (like interfaces to remote applications at less than ethernet speeds, that provide responsive feedback.) -Don
davidh@dent.Berkeley.EDU (David S. Harrison) (01/03/90)
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)
bob@MorningStar.Com (Bob Sutterfield) (01/06/90)
In article <20973@pasteur.Berkeley.EDU> davidh@dent.Berkeley.EDU (David S. Harrison) writes:
The merged server has promise [for applications that need raw
drawing speed] 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.
It's my understanding that you'll still have an interpreter in the way
when using the merged server. There are two interpretive language
frontends on the same internal data structures driving the same
display backend. One interprets PostScript and manipulates the
internals appropriately, the other interprets the X11 protocol as a
simple language (single threaded, no loops or branches, etc.) and also
manipulates the internals appropriately.
So if your task requires a lot of work of the PostScript interpreter,
then indeed it may get in the way. But if the task is characterized
more by fondling internals or squirting bits on a screen, the
bottleneck moves further back in the pipeline. In that case, requests
of both the X interpreter and the NeWS interpreter would experience
the same performance.
I suspect that your example (50K stippled rectangles) would be
interpreted once by NeWS and then handed to the guys in the back room.
(But then again, how would I know? We're still waiting for our xnews
shipment.) Other tasks are probably better suited to illustrate your
point.