In the early 1980s, George Kelley and I were working in the Fusion Energy Division of Oak Ridge National Laboratory. He was an experimentalist, and i was a theorist. IBM PCs had just come out, but we felt that their graphics resolution was too low for scientific use. So we both bought "high-resolution" (640 x 480) Corona PCs. Alas, there was no software available to actually use this resolution, so we decided to create our own.
We both used Fortran on the ORNL mainframes, and were heavily influenced by the DISSPLA® graphics package on it. However, there were no good Fortran compilers for these primitive PCs, so we decided to learn C. There were several good C compilers and we decided upon one called DeSmet C. Recall that in those days, 64 kB was a lot of memory, and was in fact the maximum amount that could be loaded into the CPU at a time, so ultra-efficient coding was a must. The DeSmet compiler also exported Assembler code, and we used this to teach ourselves how to program in Assembler. We wrote all of out critical code (e.g., line drawing) in Assembler to speed up computations. There were also no math coprocessors (the 8087), so floating point operations were slow. We used a trick developed by Astronomers in the Forth language to do most of our floating-point arithmetic using integer fractions. In those days, we also had to write code to support every graphics card and printer that we could lay our hands on.
Finally, we borrowed the DISSPLA paradigm of defining a drawing page, specifying the plot region on the page, adding the axes, and finally the data points. Because screen resolutions were still very low, we had no choice but to do vector-based graphics so that small details could be enlarged without loss of resolution. Thus, we had a very high-quality graphics library that shortly could accommodate all the types of plots that we could conceive of. We called it GraphiCTM, and it is available at http://www.sciend.com, along with the full manual so that you can see its capabilities. After my partner George died, his son Steve Kelley took over his place.
I suppose that we are bad businessmen because we have not made any changes to the GraphiC code in decades! It seems to do everything necessary, is very fast, and no bugs have been found for ages.
Why a library?
Nowadays, there are many applications that create decent graphics, for example Excel. But by using a library with plot calls embedded into your code, you can see the data being plotted as it is produced. Many scientific problems take hours, days, or even weeks to fully compute, and it is critical to watch progress either to guide the calculation along, or to abort it if things are going badly.
Also, they say "a good picture is worth a thousand words." I have found that to gain physical insight into a problem, I usually must create plots that no one else has created before, so a canned set of plot types is inadequate.
I used GraphiC in a study of the capacity of the U.S. airspace. As an example of what GraphiC can do, I created the following plot:
At a glance you can see the on-time arrival time of the flights, and if you zoom the plot, you can see the details of individual flights.