Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!CS.UMD.EDU!don
From: don@CS.UMD.EDU (Don Hopkins)
Newsgroups: comp.windows.news
Subject: obsolete arguments against NeWS
Message-ID: <9001022135.AA05473@brillig.UMD.EDU>
Date: 2 Jan 90 21:49:27 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 190

>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