🚀 go-pugleaf

In article <50851@bbn.COM> cosell@BBN.COM (Bernie Cosell) writes:
] My problem is that I need to draw a LOT of filled-in squares.
] like  >100,000 of 'em.  ... [(x,y), (x+1,y+1) are the corners of every box]
]     /box
]     {
] 	setgray
] 	moveto
] 	0 1 rlineto
] 	1 0 rlineto
] 	0 -1 rlineto
] 	closepath
] 	fill
]     } def
] and then the file has zillions of lines of the form:
]     33 42 .35 box
]     34 42  1  box

Well, I have only epsilon experience with Postscript programming, so
these ideas mostly will be about programming techniques,
and any syntax presented below will be incorrect :-)
1) use "bind def", not just "def" - you're always using the same
	basic routines, and you're not redefining them - so do the
	parsing and dictionary lookups for the routine once up front.
2) The important trick:
] About the only thing I can't change is the order that the boxes are drawn
	Not true - this is UNIX!  You're generating an ascii text file,
	with a simple structure on every line, so you can do
	standard UNIXy things like running it through sort and then
	through an awk/shell/C filter:  I assume your program generates
	boxes for almost the entire screen, and they're all the same size?
	Define a routine "nbox", which draws a box next to the
	previous one, using the syntax "grayness nbox" -
	it's the same program as box, only you do
		0 1 rmoveto
	instead of the "moveto" you had.  This means you won't have
	to transmit, parse, and evaluate the x and y parameters most
	of the time.  Make a filter like this pseudocode
		while read x y gray box ; do
			if ( x == oldx && y == oldy + 1 )
			then print "gray nbox"
			else print "x y gray box" ; fi
			oldx = x ; oldy = y
			done
	This means you almost always need only one parameter, the
	gray level.  It also makes it easy to do your run length encoding: 
	either define a "ngbox" to do the next box in the same gray,
	or have your program further crunch the output to do rectangles.

3) Cut down your transmission times and parsing a little more by
	naming your routines "b" and "n" instead of "box" and "nbox";
	it probably matters more if you're on an RS232 line than if
	you're on parallel or Appletalk.  Use >9600 baud if possible.
-- 
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs

# ho95c has gone the way of all VAX/785s, so I'm now on erebus.att.com