Newsgroups: comp.windows.news
Path: utzoo!utgpu!watserv1!watcgl!watcgl!bmacinty
From: bmacinty@mud.uwaterloo.ca (Blair MacIntyre)
Subject: Re: NeWS "open" / "standard"?
In-Reply-To: erik@westworld.esd.sgi.com's message of 24 Jun 91 21: 48:36 GMT
Message-ID: <1991Jun25.210259.19555@watcgl.waterloo.edu>
Sender: news@watcgl.waterloo.edu (USENET News System)
Organization: University of Waterloo
References: <1991Jun21.165649@aquarius.sfu.ca>
	<1991Jun24.214836.27386@zola.esd.sgi.com>
Date: Tue, 25 Jun 1991 21:02:59 GMT
Lines: 109

>>>>> On 24 Jun 91 21:48:36 GMT,
>>>>> In message <1991Jun24.214836.27386@zola.esd.sgi.com>,
>>>>> erik@westworld.esd.sgi.com (Erik Fortune) wrote:

>1) The PostScript model is far "better" than X.  For example, if I
>   want my X application to display grey scale on a monochrome
>   display I have to encode all the dither maps and then manage
>   all the stipple switching myself.  In PostScript I just set the
>   grey level and draw.
Erik> Better for some things, worse for others.   Rasterops and
Erik> colormaps are real useful things for a lot of applictions.

I think many people are arguing about NeWS based on old versions of it.

NeWS has colormaps and allows them to be used in the obvious ways
(see createcolormap, createcolorsegment).

NeWS allows you to specify rasterops for it's graphics operations
(see setrasteropcode)
ie.  Yes, it is possible to do XOR drawing (in response to some mail I
     received pertaining to this discussion, but have since lost)

Erik> This argument ignores the added complexity
Erik> of doing the event handling in the server (in terms of server size
Erik> and performance) 

Which, on todays workstations, is not a real issue.  IMO.

Erik> and the hassle of debugging a program that is split across
Erik> multiple machines and languages.  

Hastle?  Hmmmm ... when there is a clear split of functionality between
the interface and the rest of the application, it should _help_ with
debugging. 

Erik> I still remember the arguments from (some) NeWS folks in the early
Erik> days of X that it was absolutely impossible to get good
Erik> interactive performance for things like rubber-banding and outline
Erik> dragging without handling events in the server.  On more than one
Erik> occasion we'd go and demostrate perfectly acceptable tracking to
Erik> these people only to hear them make the same claim in a different
Erik> forum a week later.

Absolutely impossible would be a stupid thing to say.  However, I would
agree that you would get better performance, IN GENERAL, by having
things like rubber-banding in the server.  Of course, I usually get
satisfactory performance from my X stations.  Then again, we have fast
hardware and a fairly unloaded network.

>3) The architecure of X is very primative from a systems aspect.
>   It's crazy the amount of low level issues you have to worry
>   about writing X applications (like if you don't handle your
>   events fast enough you make the server very upset).
Erik> I've never run into this problem.   Are your clients runnning on
Erik> a particularly slow host?   Xlib is low level -- it's supposed
Erik> to be.   Try one of the many toolkits available for X (InterViews,
Erik> Andrew, etc).

The fact remains that there is an enormous amount of activity happening
in the server, and as a user I am often forced to use the toolkit that
the application writer used.

For example, the interface for a program I am writing using tk and tcl
is forever fixed using the widget set of tk.  I don't have to worry
about the low level stuff, but it is still tucked inside that program. 

Now, by writing the same thing in NeWS, I can easily switch the toolkit,
assuming that they are "compatible" ... ie.  I switched from TNT2.0 to
Tabwindows without having to change my application at all.

All of my applications now have that same look and feel.  The interface
is consistent.  Not so with my X applications.

Erik> I'll steal a line from your posting: "If PostScript is so great,
Erik> why is there now an OOPS extension."  

... you answered your own question ...

Erik> PostScript is a great page description language.  As a general
Erik> purpose programming language, I'll pass.

So, there is an OOPS extension.  

Erik> Postscript is great for some things (generally for things that
Erik> overlap with printers).  For those things, you have Display
Erik> Postscript.  I wouldn't want to write a flight simulator in
Erik> postscript, though.

Well, I wouldn't either.  But, I would have no objection to implementing
the actually drawing in postscript ... you know, the interface, the part
of a NeWS program that should be written in postscript.  The number
crunching stuff would be in C ... what's the big deal?

Ever played acm (the X flight simulator) over a network?  It's not
exactly zippy, and I don't see how having the drawing done in postscript
would be any worse.  In fact, I can even imagine in being faster.  The
number crunching would be done on my server, and the drawing would be
done on the various workstations (for each user).  Multiprocessing is a
great thing, after all.

Erik> Because PostScript is good for some things, while X rendering
Erik> is good for others.   I'm not sure what a NeWS extension to
Erik> X would be.

Hmmm ... I have yet to see anything that X can do that NeWS can't.
--
Blair MacIntyre, Computer Graphics Lab
Dept. of Computer Science, University of Waterloo, Waterloo, ON, Canada, N2L3G1
{bmacintyre@{watcgl|violet|watdragon}}.{waterloo.edu|uwaterloo.ca}