acsgjjp@sunybcs.UUCP (Jim Poltrone) (04/03/84)
[the IRS always takes their cut from the top ('nuff said!)]
I have my copy of the GKS proposal. I haven't sat down and read it yet
(I'm too busy reading articles on the Net). What I'd like to know is why
the 1979 ACM SIGGRAPH CORE proposal is not being accepted as the standard.
(See NCGA Computer Graphics News, Nov./Dec. 1983.)
I have no experience with any Graphical Kernel System (GKS), but I am
quite familiar with the CORE proposal. Here at SUNY/Buffalo, we have a
package called DI-3000, a device-independent graphics system written by
Precision Visuals, Inc. of Boulder, Colorado, and modeled after the CORE
proposal. DI-3000 allows you to write a graphics program (using FORTRAN-
callable subroutines) and run it on any output device, be it a lineprinter,
direct-view storage tube graphics terminal (e.g. the Tektronix 4010), a
standard, unmodified terminal (e.g. a stock VT100), a raster display, or
any other output device you have, provided you have the device drivers.
(Most are available from Precision Visuals.) For those familiar with
DIGRAF (based on the 1977 CORE proposal), DI-3000 has certain advantages:
colors, a "pause" subroutine, and built-in graphic-arts-quality text fonts,
to name a few.
[The above paragraph is geared toward new graphics users; seasoned veterans
can treat it as review.]
What I am really looking for is:
1) A description of the GKS system (in easy-to-understand terms)
2) An open debate regarding the pros and cons of the two proposals.
3) A chance to communicate with other DI-3000 users (how well does
it work under Unix or Unix-type operating systems?)
I'm hoping that this debate does not erupt into a shouting match (such
was the case for the now-infamous creation and abortion "debates"--oh, you
'n'-ed them all? Good!). I'll be awaiting your responses.
The SIGGRAPH/Buffalo focal point:
--
From the polyphonic, pitch-bending keyboard of
nfqstuwxy; James J. Poltrone
(a/k/a "Poltr1: The Last of the Raster Blasters")
UUCP: {hao,harpo}!seismo!rochester!rocksvax!sunybcs!acsgjjp
ARPA, CSnet: acsgjjp.buffalo@rand-relaybarmar@mit-eddie.UUCP (Barry Margolin) (04/05/84)
GKS and CORE have much in common, have been around for about the same amount of time, and both of them contributed to the design of the draft standard GKS. They had to pick one to be the major base; I'm not sure why you are so miffed that they picked GKS (or am I misreading your tone?). It just happened not to be the one you use, and there was a fifty percent chance you would lose; if you had won, then a bunch of existing GKS users would be voicing your complaint. GKS is device-independent, just like Core. It should not be difficult to convert Core applications to run under GKS. They probably have about the same set of primitive operations. Names, calling sequences, and constants will be different, but the organization of the applications will probably not have to change; most of the translations will be pretty mechanical. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
wm@tekchips.UUCP (Wm Leler) (04/09/84)
My understanding of the Siggraph Core standard was that it was
more of a compromise than a standard. Even some of the people
who helped draft it aren't that happy with it. GKS seems to
be a much more harmonious standard. I also understand that
some of the people who worked on the Siggraph Core standard
are the same people who are now drafting the GKS standard.
And that speaks for itself.
To people who ask what was wrong with the "original" standard,
meaning the Siggraph Core one, I ask, what was wrong with the
real original standard -- Plot-10? :-) If you think I am
defending Plot-10, think again.
Standards come and go.
None of them get better with age.
Wm Leler 503/627-5151
wm.Tektronix@csnet-relay
{ucbvax|allegra|decvax|ihnp4}!tektronix!wmnoel@cubsvax.UUCP (04/09/84)
The main reason for being upset that GKS was picked over CORE
is that CORE is 3D and GKS is only 2D. For some of us that means
that GKS currently is NOT USABLE for our application. I understand
the process and have a fair idea why GKS won out. No sour grapes,
just a desire to get GKS upgraded to 3D as soon as possible.
--
-- Noel Kropf {philabs,cmcl2!rocky2}!cubsvax!noel.UUCP 212-280-5517
-- 1002 Fairchild; Columbia University; New York NY 10027jons@shark.UUCP (Jon Steinhart) (04/12/84)
A few notes on the GKS vs CORE discussion: 1. GKS is a major improvement over CORE in the area of language-bindings. CORE standardized the functionality but did not standardize the access to that functionality. As a result packages such as DI-3000 were necessary in order to allow portable graphics code to be generated. GKS language binding efforts are currently underway for: FORTRAN, C, PASCAL, ADA, PL/1 and BASIC. 2. GKS is an international standard. It makes sense to adopt it as an American standard in order to be compatible with the rest of the world. 3. GKS has additional functionality in the area of output primitives and attributes, and segments. 4. Work is currently underway on 3D extensions for GKS. 5. Proposals have been submitted to extend GKS in the areas of segment hierarchy and editing. 6. Two GKS books are in print. The first is by Hopgood, the second by Enderle and Pfaff. The first book was published before work on GKS was completed. Enderle and Pfaff also helped author GKS itself. 7. There are some differences between ANSI and ISO GKS. Among other things, ANSI has defined a new level of GKS which provides the equivalent functionality of the now defunct PMIG (programmers minimal interface to graphics) project. Jon Steinhart Tektronix, Inc. and (I'd use small print if I could) ANSI X3H3