RFC 285

Network graphics

📅 published December 1971, from ietf

Network Graphics ✨

okay bestie, let's get into it 🎀 This is RFC 285 (also known as NIC 8271), titled "Network Graphics." It was written by D. Huff from CWRU (Case) and dated December 15, 1971. It doesn't update anything and doesn't obsolete anything, so it's totally standalone 💅

Not much has been written about graphics on the ARPANET, and that's kind of wild when you look at the NIC collection. It has around 8000 entries, and only about 20 are about graphics 😭 L. G. Roberts basically explained why in A FORWARD LOOK (NIC 7542). He said data base sharing and software sharing won't matter for several more years, because the NET hasn't been up long enough for people to have the facts to know if it's feasible and to get creative 🧚

This paper is trying to pull together where graphics on the NET is at right now, so newcomers can catch up, and to add a little more distance to the ground covered so far. I'll start with an overview, then briefly go over past work, and then share some of my own thoughts 🌸

The NET is basically a huge pile of data processors, and any or all of them might be in use at the same time. So we aren't stuck with the setups you usually see in private installations, where there's a main processor plus a less capable machine, or sometimes nothing at all, handling display duties. It can actually happen that the machine doing the display is more powerful than the machine running the main job 🤯 Graphics on the NET doesn't have to look anything like what we know today ✨

There's also a much bigger, more varied mix of graphics equipment to think about when you design a standard graphics language and its processor. If we want to drive any arbitrary display from a program, the output language has to be pretty general. The processor that builds the actual display list for the target display doesn't need to be general, and in fact it won't be. Its only job is to translate a well-defined general language into what one specific graphics terminal needs 💅

Attention handling is the topic everyone's been stressing about lately, and it's a totally different problem 💀 This time the NET might do more harm than good. The reason is that there could be several mappings (or none at all) between the initial display list the main job creates and the final display list that interactive devices like the light pen actually point at. This problem has to be faced, and it's been solved at lots of different sites in lots of different ways. It'll probably cause as much trouble as the final concept itself 🙈

Local processing is pretty simple to do when the display terminal is "intelligent," or even has its own medium or large scale processor that doesn't have much else to do besides refreshing the display. Stuff like simple additions or deletions to the picture definitely doesn't need the main job process. The local processor only has to tell the main process what changes it made to the display list so the main copy can be updated 🦋 Then there's the allocation of abilities, which is the last problem. The lower limit is when the local processor can't do anything except keep the picture on screen. The upper limit is when the local processor is more powerful than the main processor and handles every attention itself. At that point, the big questions are: which copy of the display list is the master copy, who makes sure all the copies have the same information, and what kinds of mappings between display lists are needed? Those are the important ones we all want to answer 👑

Proposals for Network Standard Graphics started out with the idea of a simple, interpretable language. It only had commands to erase the screen, display a string of text, move the beam or draw a line or point inside a virtual rectangle (which stands in for the generalized display screen), execute a previously defined subroutine, and replace the contents of a subroutine with whatever follows in the command stream. Movements inside the screen area were defined as fractions of the screen dimensions instead of absolute lengths 📐

People responded that a graphics standard couldn't be that restrictive and still get wide acceptance. The proposal also wasn't expressive enough for sophisticated picture manipulations. It was recognized that a standard has to be able to use all graphics hardware, both present and foreseeable. The data structure should represent both logical and pictorial structure, allow for defining and manipulating subpictures, and let the display screen be divided into logical units. The proposed standard ended up becoming a general high-level language instead of a low-level one, which is a whole glow-up 🌈

It was also pointed out that not every site needs to be able to interpret this graphics language. Because the rest of the NET exists, one of the other machines could run the interpreter, which is basically the same as a data reconfiguration service 🫶 Drawing modes like intensity, blinking, dashed, color, or stereo should also be expressible through a command that sets the mode. A canonical definition of a character string should be defined too, since everyone has their own way of displaying text and most of those ways are different 😭 The suggestion was to use the Multics convention, as described in Osanna, J., Sahzer, J., Remote Terminal Character Stream Processing of Multics, Proceedings SJCC, 1970, p. 671.

RFC 285 NIC 8271 1

RFC 285 NIC 8271

If you also want to interact with the picture directly, and not just display it, the protocol has to include a standard for feedback, which is called attention handling. Attentions don't always refer directly to the picture, though. Keyboard input is one example, and it can be handled as any other standard message on the NET 💜 Some graphics processors can handle attentions locally and only need to report the final result to the main process. That raises the question of which data structure is most up to date, which one counts as the master copy, and how the processes can be kept in sync 🔥 Here's the thing that makes it click: as long as the graphics application program (the main process) talks to a pair of graphic device handling routines in a network standard language, the system configuration can be arbitrary. That means any terminal can be attached to any main process ✨ The same goes for attention handling. If there's a set of standards for sending an attention generated by a particular device, then any graphics terminal can be understood by any main process. A summary of input devices was given, along with typical outputs, and the suggestion was that each attention message should identify the device that caused it, the data being supplied, and of course, the data itself 🎀

The proposed graphic protocol has gotten way richer in display types. The following list was suggested as the basics: points, lines, vectors, character strings, viewport and window, transformations of instances, hardware-dependent byte streams, and attention commands 🦋 It was also said that grey-scale devices need special considerations, and four alternate display modes are discussed in NIC 7128 👀

There's an example of hardware sharing in NIC 7130, and it's giving very "share the toys" energy 🧸 It's a protocol for using the LDS-1 processor at M.I.T. by anyone on the net who has a program for the LDS-1. It's called the Graphics Loader, and it runs programs that have been sent to the PDP-10 at M.I.T. and then returns the data generated when the program runs. The picture never actually gets drawn on a display. Since the LDS-1 processor can be told what to do with the coordinates it generates, the Graphics Loader sets it up to write the computed display coordinates back into core. Those coordinates can then be sent back to the originating site, either to display or as a debugging aid 🌸

RFC 285 NIC 8271 2

RFC 285 NIC 8271

NIC 7137 brings back a lot of these earlier points, but this time it's working under the idea that a graphics terminal should just be another terminal, with minimal special privileges 💅 It also made suggestions about designing a graphics protocol, with a particular focus on display structure, attention handling, coordinate systems, and the difference between storage tube and refreshed display requirements 🫧

There's a specific solution for handling tablet input data in NIC 7151, and it also says that non-interactive graphics shouldn't get tangled up with the requirements of the protocol's interactive parts 🙈 Tablet data can come in several types, and four are described: single-shot, raw asynchronous, raw synchronous, and preprocessed. Preprocessed data can be smoothed, filtered, or thinned with various techniques to make it more uniform and workable. Velocities can also be calculated for each point to help interpret the data ✨

NETCRT (NIC 7172) is the first time local processing, or the lack of it, shows up 👑 NETCRT is a protocol between a central processor and a character display. The character display is completely slaved to the central processor and can't do any local processing. It can, however, interrupt the processor to signal that the user is done typing or wants to start typing. NETCRT tries to keep the man-machine interaction good by controlling the state of the terminal 🧚

I didn't comment on the various proposals while summarizing them, because that wouldn't fit what I'm trying to do in this paper 🌈 I think we need to consider an overall model of the graphic system we're trying to design. Earlier proposals dealt with a set of details without tying them to a general model. That gave us good ideas for implementing details, but nobody really thought about how the whole thing fits together 😭 So I'd like to propose a model for our graphics system. It contains many protocols and leaves plenty of areas open for further discussion, but it gives us a starting point to build on along simple lines, without ruling out adding more sophisticated abilities later 💖

Figure 1 shows a block diagram of information flow. PROCESS is a graphics application program running on a computer in the net. Its associated INPUT and OUTPUT routines can be thought of as a set of subroutines loaded with the main PROCESS, or as separate routines running somewhere else and serving many users 🫶 At the other end of the loop are a set of INPUT and OUTPUT drivers for the DISPLAY, which is what shows the graphics information. The information flowing from the PROCESS to the DISPLAY is drawing information for building and manipulating pictures 🦋 The information flowing from the DISPLAY back to the PROCESS is attention information 💜 The Graphic Data Base associated with the main PROCESS is the one that gets built up when the picture is being drawn by the PROCESS, or when the picture is being drawn

RFC 285 NIC 8271 3

(part 2 picks up right here 👀✨)

Okay so, picking up right where we left off 💅 the local processing and attention messages are how the PROCESS finds out what's been done to the picture 👀 This data base doesn't need to hold any more info than the PROCESS is willing to work with, and honestly it doesn't need anything at all if there's no picture interaction happening 🙈 The Graphic Data Base linked to the DISPLAY drivers gets built by the drivers themselves 🎀 That way the OUTPUT driver can handle attentions from the DISPLAY without the main PROCESS needing to be able to do that, and the INPUT driver can use it when it changes the picture based on what's actually on screen ✨

The information going to and from the main PROCESS is the same kind that gets passed or received as parameters to procedures 💜 The INPUT and OUTPUT routines translate to and from a network standard graphics protocol, which gets sent over the net to the INPUT and OUTPUT display drivers 🦋 The drivers then translate that standard message into the right byte stream to drive the DISPLAY, or turn an attention from the DISPLAY into a network standard message 🌈 The DISPLAY is assumed to handle its own refreshing, if it needs any, so refreshed and non-refreshed displays look as similar as possible 🫶

This model is giving both simplicity and power 👑 People doing simple things can use it with minimal effort and overhead, just by setting runtime conditions that say no interactive graphics will happen so all the associated processing gets skipped ✨ Meanwhile, other PROCESSes can still do high powered interactive graphics without switching to a totally different set of routines and rules 🧚

Because there are two separate data bases that have to stay up-to-date with each other, there are two modes for running this model 💖 For lack of better names, let's call them PROGRAM graphics and LOCAL graphics 🌸

  • PROGRAM graphics: the picture being displayed is constructed by the main PROCESS, and all input from the user at the display is solicited. So the DISPLAY data base only gets updated after, and as a result of, action by the main PROCESS.
  • LOCAL graphics: the user at the display is directing the construction of the picture using function buttons and drawing tools. The DISPLAY data base is updated immediately, and the main PROCESS is notified of the change so it can keep up. The main PROCESS does not perform manipulations of the picture unless the DISPLAY OUTPUT driver asks it to. That request can be for a function the DISPLAY INPUT/OUTPUT drivers can do by themselves, or the user can ask the main PROCESS to perform a non-standard function on the picture 🍓

The main goal of this design is greatest generality of graphic configurations, rather than minimum response time 💅 An optimum design would need a more exact spec of the hardware configuration and the proposed usage. Neither of those can be known, and our attempt at generality stops us from even guessing closely at them 🙈 So instead we have to provide intelligent INPUT/OUTPUT drivers that know how to split the processing load between themselves and the main PROCESS, depending on what kind of DISPLAY they're driving 👑 That's better than trying to design in one optimum breakpoint ✨

The Graphics Protocol should specify the format of the messages sent between the INPUT and OUTPUT routines and drivers 💖 As mentioned before, these messages split up by direction and content, so you get drawing messages and attention messages 🦋 Since people often want to mix graphics and text, every graphics message needs a distinguishing message header 🎀 After that comes one byte saying what type of information is in the body, then a count of the bytes in the body, and finally the body itself 🌈 Basically all of the message types you need were already covered in the previous RFCs, so I won't list them again 💜 The one thing to note is that attentions now include requests for processing the drivers couldn't do themselves 🔥

To sum up, I think a simple model is enough to design both sophisticated interactive graphics and low effort non-interactive graphics 🫶 The main reason is that our big interest isn't minimum response, it's maximum configuration mixes 🌸 There are chances to use software sharing and data reconfiguration services when building the INPUT/OUTPUT routines and drivers ⭐ There's still a lot of detailed work to do, but with a basic model in sight, we've got a framework to hang proposed ideas on for evaluation, so work should move along more smoothly 😭✨

         +---------+                  +--------+
         ! INPUT   !                  ! OUTPUT !
      +--! routine !<------||---------! driver !<--+
      !  +---------+                  +--------+   !
      !                                   ^        !
      V                                   !        !
 +---------+---------+      +---------+   !   +---------+
 !         ! Graphic !      ! Graphic !   !   !         !
 ! PROCESS ! Data    !      ! Data    !<->!   ! DISPLAY !
 !         ! Base    !      ! Base    !   !   !         !
 +---------+---------+      +---------+   !   +---------+
      !                                   !        ^
      !                                   V        !
      !  +---------+                  +--------+   !
      !  ! OUTPUT  !                  ! INPUT  !   !
      +->! routine !-------||-------->! driver !---+
         +---------+                  +--------+

Figure 1 🦋

[ This RFC was put into machine readable form for entry into the online RFC archives by Ian Redfern 4/99 ] 🌷

📦 where this page comes from