jon@cit-vax.Caltech.Edu (Jonathan P. Leech) (05/02/86)
Summary:
Expires:
Sender:
Followup-To:
Organization : California Institute of Technology
Keywords:
We are starting to accumulate a wide variety of graphics devices
(Sun, HP Bobcat, Symbolics, Rastertech, plotters, printers, etc) and
are interested in a common low-level graphics library. The CGI spec
appears ideal, since both HP and Sun support at least parts of it,
but upon reading the manuals I find completely different C bindings.
My questions:
1) Is the CGI definition indeed standardized, or still undergoing
revision?
2) Is the lack of a common C binding due to
i) stupidity on HP's part
ii) stupidity on Sun's part
iii) both
iv) C standard doesn't exist so there cannot be a standardized
language binding
v) CGI is not yet a standard
vi) CGI is a purely functonal description, there are no
language bindings
vii) ???
3) Does anyone make CGI drivers for Rastertechs, Imagens, and
other such graphics peripherals? If so, who are they? Are
they available with source? (Not interested otherwise, we
have too many machines to port software to).
Any informative answers will be appreciated, but please don't
bother to post unless you have HARD information. As is obvious from
the above I can speculate as well as anyone else.
Thanks,
--
Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon)
Caltech Computer Science Graphics Group
__@/greg@vecpyr.UUCP (Greg Millar) (05/04/86)
CGI/VDI is not a finalized standard yet. I have seen a proposed C binding
but it is only proposed.
The real problem though is that CGI/VDI, GKS and any other graphics
standard like these does not address the issue of device independence.
There is no such thing as a CGI standard device driver, or a GKS device
driver. It is totally up to the implementor of CGI, GKS, etc to determine
how devices are handled.
We have approached the problem differently with graphcap. Once you have
our GKS (with our vdi) and you want to add a new device driver, all you
have to do is add a new graphcap entry (sort of like a termcap entry)
and now your applications can use this new device. You don't need the
source to the GKS or VDI since you get the graphcap database in its
source form so you can change the device at will.
This seems to be the right approach to device independence, since none
of the currently proposed graphics standards really address the issue.
All the do is provide a standard programmer interface to the functions
of GKS, etc, not a standard device interface.
Greg Millar
...{ucbvax,decwrl}!dual!vecpyr!greg
Visual Engineering, Inc.
2680 N. First
San Jose, CA 95134
(408) 945-9055miner@ulowell.UUCP (Richard Miner) (05/06/86)
In article <277@vecpyr.UUCP> greg@vecpyr.UUCP (Greg Millar) writes: > >CGI/VDI is not a finalized standard yet. This is correct, there is a currently only one aproved ANSI graphics standard, that is GKS. Next to follow will be the standard for the Computer Graphics MetaFile CGM in Jan-87, I think Phigs and then CGI. This is according to informations I received from Peter Bono the ANSI X3H3 Chairman. CGI is only in the draft proposal stage now. > >our GKS (with our vdi) and you want to add a new device driver, all you >have to do is add a new graphcap entry (sort of like a termcap entry) This sounds like it will work nice for devices that you can just send ESC sequences or that have ASCII stream bindings, but what about parallel devices, or devices that have there own graphics libraries? The solution to the problem of being able to create your own device drivers is to have a GKS and or VDI/CGI WITH SOURCE! We needed to have a GKS running on many systems with easy to modify device drivers. No one could supply us with one so we engineered our own. We will distribute to non-profit organizations with source at a minimal price to cover cost of distribution and the few students keeping the code up to date. Profit organizations must pay a little more. Please no flames about being commercial, with the cost of most GKS packages and give the fact we give source; this is more like charity. UUCP: !wanginst!ulowell!miner Rich Miner ARPA: miner@ulowell.CSNET University of Lowell, Comp Sci Dept TALK: (617) 452-5000 x2693 Lowell MA 01854 USA Home of a cheap portable 2b/2c GKS w/source -
andrea@hp-sdd.UUCP (05/08/86)
[feed the paisley horsey some sugar cubes...]
I'm the [ISO WG2/ANSC X3H3] CGI Document Editor, so this information is
about as hard as you can get:
CGI is now up to "Working Draft" stage in the official milestones, with
a new improved version coming out later this month; we expect it to be
registered as a Draft Proposed International Standard this fall. From
there, it gets one or two rounds of technical balloting worldwide (plus
a U.S. public review), and should be a real, blessed, official ISO and
ANSI standard in (are you sitting down?) late 1988 to mid 1989.
Of course, we are all anxiously hoping for (and working hard towards)
getting it to converge on major points, so we can implement an "almost
standard" version long in advance of that. As you've noticed, several
companies (including ours) have implemented something "like" CGI,
"based on" CGI, "in the spirit of" CGI (you get the picture). I
honestly don't know when it will be "solid enough" - that's a decision
each company, product group, or project makes on their own.
As far as bindings go, and C bindings in particular: we deliberately
put all binding work on the shelf for a while, so we could get somewhere
on the substantive technical issues and nail the functionality.
Meanwhile, the work that the Language Bindings group has done for
the C binding of GKS will carry over - there is a "Generic Language
Binding Issues" log, a "C Language Binding Issues Log", an approved
abbreviations list (with algorithm for generating names), and the
example of the C GKS binding. Once the work begins on the C binding
of CGI, it should be straightforward and go fairly quickly. There was
a "strawman" C binding submitted a year or two ago, but it has no
standing. I expect that some interested parties on X3H33 (particularly
Sun and System One) may generate a draft C binding from the CGI
Working Draft this summer if there is interest, as the CGI is now
far enough along to consider one again.
You are right in guessing that the non-standard status of C is holding
up having an official C binding of anything - there is alot of tracking
back and forth between the J committee (C language) and X3H3 to ensure
that the GKS C binding doesn't come out before the C standard, but that
it comes out as soon as possible afterwards (and not in conflict with
it!). There is a ratified principle that the X language binding of
graphics standard Y cannot precede either the X standard or the
Y functional standard (we can be sensible at times, if we try).
So...any company producing a "CGI-like" product has to invent their
own C binding (for now). Not a matter of stupidity, but one of
necessity. Once there IS a standard C binding of a standard CGI,
then each company will have to evaluate whether to overhaul their
product, build a standard shell on top of it, or whatever. Meanwhile,
if anyone is about to create yet another C binding of yet another
"CGI-like" product, I hope they'll look at the CGI Working Draft
and the C GKS Binding for guidance.
Hope this helps!
Andrea Frankel, Hewlett-Packard (San Diego Division) (619) 592-4664
...searchlights casting for faults in the clouds of delusion
______________________________________________________________________________
UUCP : {hplabs|hp-pcd|hpfcla|hpda|noscvax|gould9|sdcsvax}!hp-sdd!andrea
UUCP : {ihnp4|cbosgd|allegra|decvax|gatech|sun|tektronix}!hplabs!hp-sdd!andrea
ARPA : hp-sdd!andrea@nosc.arpa
CSNET : hp-sdd!andrea@hplabs.csnet
USnail: 16399 W. Bernardo Drive, San Diego CA 92127-1899 USAgreg@vecpyr.UUCP (Greg Millar) (05/11/86)
miner@ulowell.UUCP (Richard Miner) wrote in response to my posting... Greg then: >>our GKS (with our vdi) and you want to add a new device driver, all you >>have to do is add a new graphcap entry (sort of like a termcap entry) Richard: >This sounds like it will work nice for devices that you can just send >ESC sequences or that have ASCII stream bindings, but what about parallel >devices, or devices that have there [SIC] own graphics library? >... the solution is to have a GKS or VDI/CGI WITH SOURCE! Greg now: Not true. Many users can not afford source licences for COMMERCIAL, SUPPORTED, DOCUMENTED, ETC software. Not only that, users of applications using a GKS most likely will not have source and may not even have a library to relink to. Here are some good reasons to do it this way: - No source needed (the GraphCap file is the driver source) - No libraries needed to add new drivers to applications - No need to re-port driver code from system to system - No need to relink all of the applications (on all of the systems you are supporting) using graphics, everytime a new device is added to the library - You may have any number of devices available to your applications at ANY time without your application getting bigger and bigger. (Consider just 20 device drivers on line at 10-20Kb each = 200-400kb extra code to haul around) - You may want several instances of a particular device driver on line. For example (Imagen portrait, Imagen landscape, Imagen 240 dpi, Imagen 300 dpi, Imagen Black & White, Imagen Gray scale, and all combinations!) With coded device drivers this usually means that many seperate device drivers to link in, with GraphCap it means just changes a couple of fields and referencing a parent entry, like termcap's "tc=". - Don't need to know C or FORTRAN or whatever - Very fast device support turnaround and debugging (make the entry and run) - etc, etc, etc GraphCap does indeed support parallel devices, and devices that have library interfaces (like most workstations). A full explanation was not given in the original posting because (1) GraphCap is a large and complicated software system that would take a very large article to fully describe its functionality and use, (2) it was not intended to be an advertisement. If any of you would like more information from a source that has all of the particulars, please respond to Greg Millar ...{ucbvax,decwrl}!dual!vecpyr!greg Visual Engineering, Inc. 2680 N. First San Jose, CA 95134 (408) 945-9055