RFC 472

Illinois' Reply to Maxwell's Request for Graphics Information ✨

okay bestie, so the title block first 🎀 this is RFC 472 (NIC 14801), written by Steve Bunch from ILL-ANTS in March 1973. It's a reply to Craig Maxwell's (UCLA-NMC) "Request for graphics information" of 3/7/73, which was NIC Document 14925. The doc doesn't say anything about obsoleting or updating other RFCs, so we're good there 💅 If you want more details, Steve says to contact him directly.

Okay so graphics has mostly been about supporting a bunch of applications groups 🦋 To make beam-oriented graphics painless for them, Illinois copies the CALCOMP plotter support package on the host machine as closely as possible, but the output is NGP0 instead. Some of their peripherals (like the Gould 4800) need the NGP converted to device specifics first, so it's not perfect yet. Once ANTS MARK II and a PDP-11/45 show up, all the conversions will happen locally, and every graphics flow into their system will be NGP. Steve says it's super labor-saving even at the slightly kludgey stage, and honestly that's giving efficiency 🧚

They also have some grey-scale work going on with the GOULD and the IMLAC 🌈 One group is processing satellite pictures on the Illiac and will need grey-scale output soon, another is making natural-resource maps, and a third is generating holograms. No standardization plans exist for grey scale yet, but if an acceptable standard shows up, they'll most likely use it.

A small group, Steve included, is planning an interactive graphics system 👑 It'll use multiple hosts, possibly with a remote E&S machine doing rotation, scaling, and so on. There are a bunch of big hurdles first, and some aren't even graphics-specific, like process-controlled FTP and inter-process coordination among hosts. They originally planned to let efficiency decide the format of intermediate results shipped over the Net, with standardization only where it helps cut down on effort. But since the system will be super interactive and handle grey-scale data too, they'll need a higher level of graphics protocol for the user interface 😭

Right now there's a "proto-prototype" doing simple manipulations of meteorological data (contouring, 3-D plotting). It passively displays the NGP0 pictures on an IMLAC. Steve hopes to finish an IMLAC program soon that handles interaction with the mouse/keyset. He's decided on these outgoing commands:

MOVE  beam to mouse position

DRAW  from last to present beam position.

TEXT  at present beam position.

UNDO  the last command (to facilitate freehand drawing and
      backspacing in TEXT).

More commands may be added as people need them, at least until a proper interaction standard shows up 🍓

Heads up: the UNDO command quietly assumes the other end of the line has a certain amount of memory and intelligence. 🙈

Steve describes two philosophies for standardizing interaction. In (1), all "nodes" ("generators" or "users" of data) understand some set of commands and have at least a certain amount of intelligence. In (2), there's a distinction between "displays" and "computers" (the quotes are there because the line is fuzzy). He favors (1) for its generality, but suggests the lowest level of interactive graphics might want (2) for ease of implementation with unintelligent devices, like the COMPUTEK 400's. He also clarifies that in (1), the actual "computer" wouldn't have to have a smaller vocabulary than the actual "display." That's inevitable once you get higher-level capabilities in the protocol, and it's a very real point 💜

Since they have almost no local computing power for applications, all graphics computation happens remotely. Their work is spread across UCSD (B6700), USC-ISI (TENEX), and UCLA-CCN (360). Because they work at scattered sites and are basically economic of labor (pronounced "lazy"), they have a lot to gain from standards, and they're happy to cooperate as much as possible with standardization efforts 🫶

Steve Bunch 💖

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alex McKenzie with ] [ support from GTE, formerly BBN Corp. 9/99 ]