[net.unix-wizards] UNIX Graphics Summary

larry@RAND-UNIX (02/04/83)

Many thanks for the response to our quest for UNIX graphics leads.  Special
thanks to Sean D. True for sharing similar information that he has gathered.
My impression as a result is that while there is not a whole lot out there in
the way of general-purpose graphics for UNIX, there do seem to be a number of
encouraging efforts to achieve this capability.  Our decision to go with
Precision Visuals' DI-3000 is based on its availability, completeness, cost-
effectiveness, documentation, and support.  Had we not been so pressed for
time, we might have opted for one of the many efforts still under development
but which could have better suited our needs in the long run.  Some of the
more interesting possibilities are listed below.

					Larry Painter
					Rand Corporation

------------------------------------------------------------------------------

From: Steve Rubin <Strubin at SRI-KL>
Subject: Re: Graphics Software for VAX/UNIX

I have a C-language version of the SIGGRAPH Core at a basic level (2-D only,
no segmentation, some input primitives).  The program runs under 4.1bsd UNIX
and supports about nine different devices with more to come:  AED-512 frame
buffer, Ikonas frame buffer, Raster Technologies model one frame buffer,
ID100-V graphics terminal, Versatec V-80 plotter, Ramtek color printer,
Symbolics laser printer, CIF (for putting graphics on your VLSI chips), and
normal video terminals with TERMCAP cursor control.  Release status is not
known yet, but further information will be available soon.  Documentation is
available now.

		-Steve Rubin
		 Fairchild

------------------------------------------------------------------------------

From: cbosgd!djb
Subject: 2D Graphics - me too!

        I'm currently putting together a graphics system very similar to what
you've described.  Unfortunately, it's internal and propriatery at this point,
so I can't let you have it.  Hopefully at some time in the future I'll be able
to give it away, or have the UN*X folks buy it back for inclusion (extremely
unlikely, given their buy-back philosophy).  I would be interested to hear
about anything you turn up.  I do know that some folks at Berkeley were
working on something called MFBCAP, which is a termcap-like system for
graphics terminals and frame buffers.  It looked pretty good (based on the
draft manual pages) but I don't think it's been cleared for release yet.  If
you'd like more information on it, I can see what I can dig up.

                                         Good Luck,
                                        David Bryant
                                         cbosg!djb

------------------------------------------------------------------------------

From: Greg.Glass at CMU-CS-CAD at CMU-CS-A
Subject: graphics package

I have a graphics package that I wrote generally along the lines of what is
outlined in Newman & Sproull.  It is written in pascal.  I use it for
interactive programs in 3-D mostly although it will support 2-D drawing.  At
this time it works with 4 diff. terminals and new ones are not hard to add.
Preview of information may be done on regular CPT terminals also.  If you are
interested you may ftp over the file: /usr/gjg/proc.lpt@cmu-cs-cad this has a
list of the procedure calls and short explanations of what they do.

						Greg

------------------------------------------------------------------------------

From: Randy.Pausch at CMU-CS-G at CMU-CS-A
Subject: gen. purpose graphics software

Contact Joe Pato at Brown University -- they distribute (or did, anyway) a 2D
subset of the CORE standard, I believe available in both C and Pascal.

------------------------------------------------------------------------------

From: Michael Wayne Young <Michael.Young at CMU-CS-A>
Subject: Re: Graphics Software for VAX

I have such a package in the works for 4.1BSD; it's a SIGGRAPH "Core" system
written for any version 7 or better system (which of course includes System
III or 4.1BSD running on Vaxen).  It currently supports level 1 input and
level 1 output; that is, full 3D viewing, no segmentation, no input.  It
supports the definition of various attributes (such as color, which is what
you're interested in); it's up to the device driver to decide how much to
actually implement though, and the devices I've had are primarily monochrome
(4010 series, hp2648, Tek 4025), but some support color (an AED 512, a Dec
Gigi terminal, and an hp7221 plotter [4 pens]).

Maybe I should tell you a bit about the status of my project:

	Currently, all of level 1 i/o is complete; it is currently
	in use in part of a larger graphics system (only in size,
	not complexity...) at the University of Delaware.

	A fairly sophisticated device assignment feature is provided
	(but not mandated); it allows various device types to
	be handled on any output file (discriminated at runtime),
	with various device options (like screen window, startup color,
	device defaults).  It also allows output to be piped
	to a command, if that's your interest.  [I've used
	that a lot to build device drivers without having a
	device available.]

	It's fully device-independent; the effort involved
	in building an additional device driver is minimal
	(for me, at least, as nobody else has had to try yet).
	It relies heavily on standard device driver parts,
	to maintain continuity among drivers.

	It's all C code, but is barely accessible from Pascal.
	[I have an include file for Pascal use, but it's
	been minimally tested.]  Fortran (IV or -77)
	support is not even conjectured yet, as most parameters
	are passed by value now, and I see no need to change
	that either.  [It'd be a matter of writing a F77-C
	interface.]

	What I plan to be doing in the next 1-2 months is
	finishing up level 2 (and maybe 3) output; this
	would add segmentation and the associated visibility
	handling.  Batching of updates would become more
	important.  I am currently part-way through this
	section, but it's not available yet.

	I have no current timetable for the inclusion of
	graphical input; aside from simple "locator"
	input (joystick or cross-hair cursor), none of my
	devices could do anything anyway, so it's not
	that important.  A possible intermediate
	stage is an "escape" function to read this joystick
	position.

I think what I have is probably sufficient for what you want to do...
moderately tough vector graphics, primarily for plots, in a device-independent
way.  If you have any questions/doubts/whatever, don't hesitate to let me
know.

Now, as for the "distribution" of the package:  I'll give it out for free, but
I want to retain copyrights on it. [I.e. not public domain, but free to use.]
What I'd need is a statement from you saying that you were to use the package
for yourselves only, and not to distribute it, plus I guess to pass back
changes to me (although I'm not sticky on that point).  Let me know if this is
the only problem; I'm sure we can arrange something if you're still
interested.

			Michael

------------------------------------------------------------------------------

From: johnston at LBL-UNIX (Bill & [csam])
Subject: unix graphics

David Rosenthal has written an implementation of GKS (one of the proposed ISO
and US graphics standards) for UNIX.  GKS is functionally similar to a 2-D
SIGGRAPH core system, with several groups working on the 3-D version.  It is
also the case that SUN Microsystems (Jerry Evans, if my memory serves me,
though Bill Joy would know also) is writing a UNIX version of GKS.  You should
also contact Precision Visuals (if you are interested in commercial software),
as I believe they have DI-3000 (SIGGRAPH CORE system) running under UNIX.

    David Rosenthal
    Strichting Mathematicsh Centrum
    Kruislaan 413 1098 SJ Amsterdam
    Postbus 4079 1009 AB Amsterdam
    THE NETHERLANDS
        Phone: (020) 592-9333  (Don't try this unless you speak Dutch.)
        Telex: NETHERLANDS 12571 (this should be checked)
        Uucp: ucbvax!decvax!mcvax!david (sometimes this works)

    Bill Joy
    SUN Microsystems Inc
    2310 Walsh Ave
    Santa Clara, CA  95051

------------------------------------------------------------------------------

From: decvax!mcvax!david@Berkeley
Subject: Graphics for 4.1BSD

Here at The Mathematical Centre, Amsterdam, an implementation of GKS, the
draft International (and ANSI) standard for 2D graphics software, is underway.
It is being made available, but to find out the terms you will have to mail
..decvax!mcvax!paulh (Paul ten Hagen).

I did some of the design, but am not involved in the implementation.  GKS
defines a 3*3 matrix of capabilities, viz:

Output		Input
	None	Synch	Asynch
Basic	Works	Works	Wait 4.2BSD
Segment	Works	Works	Wait 4.2BSD
Full	Untest	Untest	Wait 4.2BSD

Some work is still needed even on the bits that work to make them
fully distributable  (e.g.  clean up makefiles,  translate comments
from Dutch).  At present the interface between the Device Independent
parts and the Device Dependent bits (drivers) is very low-level and
does not exploit the capabilities of advanced devices.  Most testing
uses an AED512.

For information on GKS,  contact the ANSI committee:
	ANSI X3H3
	c/o Dr. Peter R. Bono
	Athena Systems Inc.
	206 South Broad St.
	Pawcatuck,  CT 06379
	203-599-3061

	David Rosenthal

------------------------------------------------------------------------------

From: UCBARPA.wnj@Berkeley (Bill Joy)
Subject: Re:  UNIX Graphics

Sun has a device-independent CORE implementation, done by Michael Shantz.  GKS
is still being finalized as a standard, and Jerry Evans at Sun will implement
it, for release as a product late in 1983.  If you come to the UNICOM show in
San Diego in January you will be able to get information on Sun's graphics
state and plans.  Mike Shantz will be talking about graphics at the show.

	Bill Joy

------------------------------------------------------------------------------

From: alt@UTEXAS-11
Subject: device independent graphics.

We have a package called AMPEX at the astronomy dept.  It currently has
filters for 3 terminals, but I gather they are not hard to write.  It seems to
be very nice, and it is written in C of course.  The way you use it is you
make calls to vplot (a library of graphics routines) then you pipe the output
of the program through the given filter.  If you want a copy, send me a tape
with a SASE and I'll ship you a copy.  I would use the arpanet, but the
astronomy machine is hooked to our gateway by a 2400 baud line, and it's a big
program.

				Howard Alt
				alt@utexas-11

Howard Alt
c/o Fritz Benidict
Dept of Astronomy 
Univ. of Texas
Austin, Texas
78712

------------------------------------------------------------------------------

From: decvax!ittvax!swatt
Subject: Graphics software under 4.1BSD

We have Megatek Template running.  I don't know if it fits your (functional)
needs.  It is device independent after a fashion (link with a different
library of device-specific routines).  It is written in Fortrash.  It is
*LARGE* (typical load image ~.5 Mbytes; "full-blown" system ~1 Mbyte).

The basic routines are written in Fortran66; I don't think we had to do too
much to get them running.  Mostly throw away their SFM (Source File Mangaer)
package and replace it with a few makefiles, awk and shell scripts.  I think
we sent back to Megatek the changes involved (esentially a tar tape).

If you're willing to pay $$, give Megatek a call and see if they will admit to
selling to UNIX sites.

	- Alan S. Watt

------------------------------------------------------------------------------

From: roediger at ANL-MCS (Gary &)
Subject: Re:  Graphics Software for VAX/UNIX

Regarding DISSPLA for VAX UNIX.  I put up version 8.2 for ISSCO in August
1981.  Last week ISSCO contacted me again and they began working on getting
version 9.0 up.

				Gary Roediger