Browse Prior Art Database

Network graphics (RFC0285) Disclosure Number: IPCOM000003448D
Original Publication Date: 1971-Dec-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 7 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People


Related Documents

10.17487/RFC0285: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 18% of the total text.

Network Working Group D. Huff Request for Comments: 285 CWRU (Case) NIC: 8271 December 15, 1971 Updates: None Obsoletes: None

Network Graphics

Not much has been written about graphics on the ARPANET when the volume of the NIC collection is considered. Presently it contains some 8000 entries of which only about 20 are on the subject of graphics. The reason is probably similar to that given by L. G. Roberts in A FORWARD LOOK (NIC 7542) as the reason that data base sharing or software sharing will not be important topics for several more years: the NET hasn’t been up long enough for interested people to have enough of the facts to know if it is feasible and to think creatively.

This paper is therefore aimed at bringing together the present state of graphics on the NET for the newcomer and attempting to add a little more distance to the ground covered so far. I will start with an overview, then proceed to briefly describe past work, and finally add some of my own thoughts.

Since the NET represents a wealth of data processors, any or all of which may be used at one time, we are not restricted to the configurations most generally found in private installations where there is a main processor and a somewhat less capable machine or perhaps none at all doing the honors as display processor. Indeed when using the NET it might occur that one has a more powerful machine as the display processor than the machine which is running the main job. Graphics on the NET need not be anything like what we know it as now.

There is of course a greater more diversified mix of graphics equipment that must be considered when designing a standard graphics language and its processor. If we wish to drive an aribitrary display from a program such an output language must be quite general, but the processor which constructs the actual display list for the target display need not and in fact will not be general, rather its only job will be to translate a well defined general language to meet the requirements of one specific graphics terminal.

Attention handling, a lately discussed and much worried about topic, presents an entirely different problem. This time the NET may cause more harm than good for the simple reason that now there may be several, instead of one (in some cases none at all), mappings defined to get from the initial display list that the main job process is creating


RFC 285 NIC 8271

to the final display list which interactive devices such as the light

pen actually refer to. This is a problem which has to be faced and has been solved at many different sites in as many different ways. It is likely to give as much trouble as the final concept.

Local processing is in many cases a very simple thing to accomplish when the display terminal is "intelligent" or even has its own medium or large scale processor which has little or nothing else to do aside from refreshing the display. Such processing can be simple additions or deletions to the picture which certainly do...