🚀 go-pugleaf

It would be a shame if NeWS gets canned. It can solve so many
problems that X will eventually face. Dave Rosenthal discussed some of
these issues at the 1990 SUG:


X Frame Buffer assumptions:
	a rectangular array
	square pixels
	32-bit color, RGB Encoded
	15 bit coordinate system
	Read/Write on each pixel
	a pixel is assumed to be visible
	a one-pixel line is assumed visible

Impact:
	X won't look well on HDTV (non-square pixels)
	Solid State (Flat Panel) Screens may have defects and single
		pixels should be small. (e.g. 200 DPI) 
		However - this exceeds the coordinate system of X
	Hardware accelerators will be hard to pipeline or parallelize
		(because pixels are read AND write instead of write only)

Plus the multi-threaded, object oriented light weight dynamically
extensible nature of NeWS, suitability over a WAN, device
independance, as well as the flexibility (Changing the cursor from a
bitmap to a procedure that dynamically changes colors, icons that can
contain any image, scaling and rotation, paths that can be text, fill
areas, holes, outlines, buttons, windows, cursors, etc.)

Heavy sigh...... Some people have a vision. Apparently Sun Marketing doesn't.
Just think what would have happened if the energy that was put into X
was put into NeWS.

If Sun sends out the message that NeWS has no future, then it will
become a self-fulfilling prophecy. :-(

I agree with Frank that the only hope is if Sun gives away the sources
of NeWS for a reasonable price. Maybe free to research institutes and
universities.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

barnett@grymoire.crd.ge.com (Bruce Barnett) writes:

>Heavy sigh...... Some people have a vision. Apparently Sun Marketing doesn't.
>Just think what would have happened if the energy that was put into X
>was put into NeWS.

I really don't think it is their fault. Sure everybody agrees
that NeWS (with a little work) was far superior to X. But then
you had every other Unix vendor jumping on the X11 band wagon
just because Sun was working on NeWS, X11 was it's only
competitor.

The same applies to OpenLook, all the rest of the lemmings did not
choose Motif until Sun went OpenLook.

>I agree with Frank that the only hope is if Sun gives away the sources
>of NeWS for a reasonable price. Maybe free to research institutes and
>universities.

I like NeWS to but Sun had to go with X, what choice did they have.
As for the future of NeWS, release the source to the world, it is
the only way it will have a future.
-- 
Craig Bishop			Information Systems Division
Email: csb@gdwb.OZ.AU		Geelong & District Water Board
Phone: +61 52 262506		61-67 Ryrie St Geelong
Fax:   +61 52 218236		Victoria 3220 Australia

In article <3201@peking.gdwb.oz.au> csb@gdwb.oz.au (Craig Bishop) writes:

>   I really don't think it is their fault. Sure everybody agrees
>   that NeWS (with a little work) was far superior to X. But then
>   you had every other Unix vendor jumping on the X11 band wagon
>   just because Sun was working on NeWS, X11 was it's only
>   competitor.

I think the fault was that there were very few programs that showed the
power of NeWS, and the "official" development environment was real
bad. Yes, Sun had to do X. Yes, NeWS was on a back burner for a while
(but TNT 3.0 did come out). NeWS is still a bastard child that no-one
wants to recognize. Without the developers, there are no applications.
Without the applications, there isn't a need for development tools.
Without the tools, there are no developers. 

NeWS can still be a very strong advantage for special applications. If
Sun continues to support it, NeWS can gain popularity by sheer mass.
Many of us are designing applications to run over a wide area network.
This is the time to go from group-ware to Enterprise-ware. Think of
all of those PC's running Solaris 2.0 and having a X/NeWS server.
Imagine a system that could dynamically download the necessary pieces
to improve performance over a serial line. Consider how much easier it
is to do this than to wait for X11R[6789] to come out.

Many people, including me, have complained about the development
environment of NeWS. Funny thing is, the Mac and PC had (have) HORRID
environments. A lot of applications still get developed. If enough
copies of something exist in the world, it will be used. I can see the
future - NeWS finally becomes "fashionable" and Sun announces they will
discontinue support. Heavy sigh.....
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

barnett@grymoire.crd.ge.com (Bruce Barnett) writes:

>	Hardware accelerators will be hard to pipeline or parallelize
>		(because pixels are read AND write instead of write only)
>

Since when has Sun's implementation of NeWS ever used a write-only
framebuffer???!?  They even use XOR for doing *overlays*, for God's
sake!

-- 
Ian D. Kemmish                    Tel. +44 767 601 361
18 Durham Close                   uad1077@dircon.co.uk
Biggleswade                       uknet!dircon!uad1077
Beds SG18 8HZ United Kingdom

I wrote:

|>	Hardware accelerators will be hard to pipeline or parallelize
|>		(because pixels are read AND write instead of write only)


In article <1992Aug22.150017.1614@dircon.co.uk> uad1077@dircon.co.uk (Ian Kemmish) writes:
|
|Since when has Sun's implementation of NeWS ever used a write-only
|framebuffer???!?  They even use XOR for doing *overlays*, for God's
|sake!

Who was talking about Sun's implementation? I thought I said it is
difficult to design a hardware accelerator for a X based system that
can handle parallel/pipelined constructs. If you had a stencil based
model, it is theoretically possible.

uad1077@dircon.co.uk (Ian Kemmish) writes:

   barnett@grymoire.crd.ge.com (Bruce Barnett) writes:

   >	Hardware accelerators will be hard to pipeline or parallelize
   >		(because pixels are read AND write instead of write only)
   >

   Since when has Sun's implementation of NeWS ever used a write-only
   framebuffer???!?  They even use XOR for doing *overlays*, for God's
   sake!

SGI's implementation of NeWS (4Sight) ran on a practically write-only
framebuffer.  The xor operation was very slow (as it was with the X
server at the time).  It used real hardware overlay planes to
implement the NeWS overlay plane.  In fact the pop-up menus were
subclassed (the SGIMenu subclass) to draw in the overlay plane, so
they popped down instantly without causing repainting (they didn't use
savebehinds, which were slow for the same reason xor was slow).

You were allowed three colors on the overlay (since it used 2
bitplanes to implement the overlay): black, white, and one other
color.  When you drew with a gray color, it would simply use a stipple
pattern.  When you drew with a non-gray color it would set the
colormap slot for the color overlay pixel to that color and use that.
The 4Sight user interface displayed red bounding boxes on the overlay
when you dragged windows around, and the menus had nice 50% gray drop
shadows stippled over the (appearently darkened) screen image
underneath.

	-Don