Path: utzoo!attcan!uunet!lll-winken!brutus.cs.uiuc.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ASC.SLB.COM!rxb
From: rxb@ASC.SLB.COM (Rafael Bracho)
Newsgroups: comp.windows.news
Subject: Re: NeWS => X11/NeWS
Message-ID: <8910182021.AA00296.rxb@plutonium.ASC.SLB.COM>
Date: 19 Oct 89 04:31:04 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 62

I just finished porting a fairly complex NeWS application (close to 75K
lines of PostScript) to the merged server, taking me about two weeks of
work.  These are a few of the issues I found:

1.  Input has changed somewhat; in particular, the function keys no
longer work with the litewindow toolkit -- we implement a window system
that is a descendant of litewindows.

2.  The focus (re: the Extended Input System chapter of NeWS 1.1) is no longer
and array of canvas and process but rather just a canvas.  Some of our
code broke because of that.

3.  The merged server has the concept of "packed arrays".  The command
setpacking may be used so the server packs all executable arrays.
Unfortunately, the buildimage operator doesn't work with packed arrays.

4.  X11/NeWS follows the red book a lot more closely so there were a
number of bugs we uncover in our code.  For example, erasepage now
blanks out the whole canvas, irrespectively of any clipping path that
may be in effect.

5.  A host of bugs were related to the fact that canvases are,
internally, kept in the X11 coordinate system (upper-left corner is the
origin) and not in the PostScript one (the origin being the lower-left
one).  Normally this shouldn't affect anyone since the defaultmatrix is
set properly everytime the canvas is reshaped -- previously it was
always the identity matrix.  In NeWS 1.0, however, the default matrix
contained very small translation factors that would become significant
with large scaling.  We got in the habit of doing "matrix setmatrix"
instead of "initmatrix" and in NeWS 1.1, these two were identical.  This
is obviously no longer the case.

6.  Imagecanvas is much more consistent to the PostScript image
operator.  Under NeWS 1.1, to "imagecanvas" a regular canvas -- i.e.,
obtained via newcanvas -- the receiving canvas had to be scaled by the
size of the source canvas; even though the source canvas' coordinate
system was not the unit square.  Doing this in X11/NeWS results in
double scaling so you'll probably won't get anything on the screen --
the server refuses to "imagecanvas" anything that results in more than
32767 pixels in either dimension.  Either make the source canvas be
mapped to the unit square, or the receiving canvas have pixel units.

7.  Readcanvas returns a canvas with its default coordinate system being
the unit square (more consistent with buildimage, and better for
imagecanvas, see above).  Thus to "imagecanvas" it, one must scale the
receiving canvas by the size of the rasterfile read -- this was also
true in NeWS 1.1.  Previously, however, one could "setcanvas" to the
result of readcanvas knowing that the default matrix was in pixels (like
a canvas obtained via newcanvas).

In general the X11/NeWS server is much nicer than NeWS 1.1.  There are a
few rough edges, particularly with the CG6 (GX or LEGO) board, and I
don't think performance is quite up to par with NeWS 1.1.  In our case,
we had some bound-checking code in our inner loops to avoid crashing the
1.1 server that is no longer needed so we don't really see *drawing*
performance degradation.  Interactions, particularly dragging, seem a
bit slower, though.

					Rafael Bracho
					Schlumberger
					Austin Systems Center
					rxb@asc.slb.com