RFC 192

Some Factors which a Network Graphics Protocol must Consider ✨

Okay so this RFC is from way back in the day 🕰️💜, and the title block is giving old-school vibes:

• Network Working Group 🌸
• Request for Comments: 192 📜
• NIC: 7137
• Author: R. Watson, SRI-ARC 👩‍💻
• Date: 12 July 1971 📅
• Category / status: not stated in this header
• Obsoletes / Updates: neither is listed in this header

Okay so the big idea is that a bunch of the existing RFCs about a network graphics protocol weren't general enough 🥺. They didn't handle attention handling, picture structure, or the other higher level processes that interactive graphics needs. Rude, honestly 💅.

So for what it's worth 🎀, the author is sending out these rough intro notes. They're about ideas that any network graphics protocol has to come to grips with 🫶.

The protocol should let you run the most sophisticated system with more general data structures and concepts than these notes cover, and it should also let really simple systems work too ✨. That's the energy we want 🦋.

Introduction 🌸

It's the author's position that if computer graphics is going to be widely useful, graphics terminals need to be just another kind of terminal on a timesharing system, with minimal special privileges 💖. These notes lay out the basic features that a graphics support package needs so that interactive graphics application programming is easy 🧚.

If you look at the kinds of tasks in industry, government, and universities that could use timesharing support from graphics consoles, the author estimates that most of them can get by with quite simple terminals, like the ones using storage tubes 🍓. They guess about 75% of the needed terminals fall into this group. Another 15-20% of terminals may need higher response and a bit of simple realtime picture movement, so they need simple refresh displays 🔥. The rest are for high payout tasks that need all the picture processing power you can get 👑. These notes aren't about supporting that last group, so we're skipping it for now 🙈.

MAIN ASSUMPTIONS AND REQUIREMENTS FOR SYSTEM DESIGN 👑

The main assumptions and requirements behind the interactive graphics work are these:

1. The user of the graphics terminal should be just another timesharing system user. 🫶
2. The graphics software support should interface with existing timesharing programs. 🔌
3. The software support should let technicians, engineers, scientists, and business analysts, as well as professional programmers, easily create applications on a graphic terminal. 💅
4. The software support should easily allow use of new terminals and new types of terminals as they hit the market. 🛍️
5. The software support should be expandable as experience shows that new facilities are needed. 🌱
6. The software support should be portable from one timesharing service to another. 🦋
7. Some form of hardcopy should be available. 🖨️

MULTILEVEL MODULAR APPROACH TO SYSTEM DESIGN 🧚

Okay so if you want a system that inexperienced programmers (and eventually non-programmers) can actually use, you need to give them powerful problem-oriented tools for writing programs 🥹. You start at the bottom with the primitive machine language that commands the graphics system hardware, and then you build upward 🪜. The design philosophy here is one that's getting more common in the computer industry: design increasingly powerful levels of programming support, where each level plugs into the levels around it and builds on the ones below 💜.

Here's the important part. You want to design these levels more or less at the same time 🙌. That way, what you learn from each level feeds back into the designs of the others before they get frozen and become really hard to change 🧊. Lowkey a big deal.

The author recognizes five basic levels 🎀:

1. The basic system level: this level gives assembly language programmers a way to use the terminal. 🛠️
2. The problem programming language level: this level gives powerful facilities for interactive graphics programming from the commonly used higher level programming languages 💻.
3. The picture editor or drawing system: this level lets you draw pictures and link those pictures to application programs 🖍️.

Data management support for interactive programming: this level gives you facilities to help create and manipulate data structures that relate the data attached to the pictures and the application 📊.

5. The application program level 🌈.

A REVIEW OF TERMINAL HARDWARE CHARACTERISTICS OF CONCERN TO THE USERS 💜

There are two basic kinds of general purpose cathode ray tube display systems on the market right now 📺. Each class has different forms and implementation techniques, but the author doesn't go into those here ✨. The first type is called a "refresh display". The second is called a "storage tube display".

A refresh display has to keep repainting the picture on the screen at rates of 20-60 times per second 🔁. The commands that tell the system how to draw the picture get stored in a memory 🧠. A storage tube display, on the other hand, is built in a way that lets it keep a picture on the face of the display, for practical purposes, indefinitely once it's drawn 🫧. Iconic.

REFRESHED DISPLAYS 🔥

Refreshed displays have limits. If you draw too much on the face, the time it takes to paint it drags the refresh rate below a critical value, and the picture starts to flicker 😭. How much information fits depends on the type of phosphor on the tube face, how fast the display system draws lines and characters, and the ambient light level in the room 💡. Refresh display systems cost anywhere from $10,000 to several hundred thousand dollars 💸.

The good news is that refresh displays can change the picture every few milliseconds just by altering its command list (often called a display file or display buffer) ⚡. That means picture parts can be moved around the screen, either by the operator or by the computer 🕹️. You can also erase objects on the screen selectively, without messing with the other objects 🧹. Main character energy 👑.

These characteristics make refreshed displays suitable for a wide range of applications 🌟.

STORAGE TUBE DISPLAYS 🍓

Storage tube displays can show a lot of information without flickering, and they generally cost under $20,000 💅. But they have some limitations, not gonna lie 😬. They can't be selectively erased. If you want to move or delete something on the screen, you have to erase the entire screen and then redraw the new picture 🙃. Because this kind of display usually works over a communication line, the speed of that line can seriously limit how much you can interact with it if you need a lot of erasing and redrawing 🐌.

The graphics software concepts described here can be used with both storage tube and refreshed displays, though some features only make sense for the refreshed type 🔁. The big takeaway is that new storage tube technologies ensure this class of terminal is going to stick around for a long time 🥰.

INPUT DEVICES 🎀

A console user needs a way to talk to the graphics system 💬. They do that through a keyboard, plus some specialized graphic input devices: the Light Pen, the Tablet, the SRI "Mouse", and the "Joy Stick" 🖱️. These input devices let a console user point at vectors and characters shown on the CRT, and feed position information into the graphics system 📍.

Comparison of the Graphics Input Devices -- Analog Comparitors 🔍

The Joy Stick, Mouse, and Tablet are alike in that each one generates a two dimensional position address without help from the display processor 🧭. The catch is that they can't be used directly to identify displayed objects 🙅. The light pen and display processor hardware, plus its software, is the opposite: it can easily sense and identify displayed vectors and characters, but it doesn't generate any position data itself 🎯. To get position data for the light pen, a "tracking cross" program is used 🎯✨.

To give the Joy Stick, Mouse, and Tablet pointing capability, the author suggests using a pair of analog comparitors on the x and y axis drive voltages of the display analog bus 🔌. These comparitors generate interrupts when the beam drawn on the CRT lands inside a rectangular "viewing window". It's kind of like how the light pen generates interrupts when a beam is drawn under its circular viewing area 💖.

A comparator gives an output signal when the drive voltage sits between two limits, and those limits can be set using special display processor commands 🔧. When both comparators signal at the same time, the output voltages on the analog buss correspond to a beam position inside the rectangular viewing window 🪟. The viewing window's position is set based on where the pen, Mouse, or Joy Stick is 📌.

Software can also simulate what the hardware comparators do 💻. You can't use hardware comparators with storage tube displays, so a software simulation is required for those 🍓. The author says this simulation gets discussed later in these notes 👀.

The light pen can only be used with a refreshed display 🔥. The other devices work with both storage tube displays and refreshed displays 🫶. With storage tube displays, they rely on hardware that puts a dot, cross, or other cursor on the screen to show the device's x, y position 🎯. You can move that cursor around because it's created with special techniques that keep it from being stored on the screen 🪄. Honestly, so clever 🥹✨.

USER SOFTWARE REQUIREMENTS 💅✨

Okay so, here's what users actually need from a timesharing-based interactive graphics system 🫶:

1. The user should have available a language for creating a computer representation of the picture to be displayed. This language should allow more complex pictures to be built up from simpler structures. 🧱
2. The computer representation of the picture must allow easy identification of picture parts when pointed at or "picked" or "hit" with graphical input devices such as light pen, electronic pen-tablet, Joy Stick, SRI mouse, or other supplying x, y information. 👆
3. The computer representation of the picture must allow linking of picture parts with data about these parts appropriate to the application using the terminal. There should be an appropriate data management system for use with interactive application programming. 🗂️
4. There must be some way of communicating events taking place at the terminal in real-time, such as picking objects with the light pen, with the application program running in the timesharing system. ⚡
5. The user should be able to save and restore pictures from one console session to the next. 💾
6. If possible, the user should be able to use the display as a stand-alone terminal or in conjunction with a teletype or other typewriter terminal. 🖥️
7. The user should be able to do some graphic programming by drawing directly at the console. 🎨

The choice of an appropriate data structure for picture representation simplifies the handling of requirements one to five. It is this data structure that we consider now in more detail. 🤓

Picture-Related Structures 🖼️

Okay, if a picture on the console only meant something because of where its lines and characters physically sat, the system would be basically a piece of paper that you can erase, and nobody wants that 💀. To really level up, we have to be able to express relations between displayed entities. A line is so much more than just a line when it represents a boundary or a part of some bigger unit! And those units can be related in a similar way to higher level units. ✨ We may also want to make picture elements that get used over and over, so that a change to the one master copy shows up in every single use of that copy. 🔁

To see why this picture-subpicture relationship is so useful, let's look at the three houses of Figure 1 🏠🏠🏠. The two types of houses look different, but it's obvious they have picture elements a designer of prefabricated houses could draw, and that the designer wanted to put a new standard window unit into all of the houses. With conventional pencil and paper, they'd have to redraw or overlay every single window on the diagram to reflect the changed component, which is so much work 😭. But if the window were drawn by the graphics system inside a common subroutine, only that one master copy would need to be modified to change the appearance of every reference to that kind of window on the diagram. Iconic, honestly 👑.

Nodes and Branches 🌳

To make the discussion easier, we're going to introduce the terms "node" and "branch" 🧚. A node is a form of picture subroutine that may cause the display of lines and characters and may also call other nodes. The subroutine call is called a "branch". Nodes may also be thought of as representing PICTURES or SUBPICTURES, and the branches to these nodes as uses or instances of these subpictures. 🦋

Directed Graph Structure 🕸️

The nodes and branches form a directed graph. The branches contain positioning information indicating the beam location to be used by the called node. This location is relative to the position of the node in which the branch is made. This use of relative beam positions lets the user of the system create subroutine structures that make multiple branches to common nodes, which is giving main character energy 💖. Branches may also set other display parameters such as intensity and character size. A subroutine calling structure that fits the needs of our hypothetical designer is shown schematically in Figure 2 🌸. Nodes are shown as circles and branches are shown as connecting lines. The picture of the house is composed of wall unit and roof SUBPICTURES. The wall unit is, in turn, composed of subpictures. 🏡

Node and Branch Display Parameters 🎀

Branches may contain the setting of parameters that will be in effect when the called node is executed. The parameters that may be set are: the beam position to be used (relative to the current beam position, i.e., a displacement value), intensity, character size, line type, visibility (the display of vectors and characters may be suppressed), "hitablility" (whether or not vectors and text may be "viewed" by devices such as the light pen), and blinking. 💡

Coding within nodes may modify only the parameters controlling position, intensity, character size, and line type to be used by subsequent display coding or branches. It is not necessary that a node or branch specify every parameter. For those parameters other than position, the system allows a "don't care" option. The parameter setting in effect when the node or branch is executed will be retained and used in this case. 🙌

Identification of Graphic Entities with Graphic Input Devices 🔍

Structural Hits 🎯

A console operator or application program may modify, add, or delete branches to any of the nodes, as well as add new nodes. So that a console operator can manipulate any branch in such a structure, we've implemented a "structural hit identification" scheme. To follow the discussion below, check out Figures 1 and 2 📸.

A viewing device, such as a light pen, can only respond to the individual vectors or characters displayed on the screen. At the time a vector is drawn under the viewing area of the light pen, an interrupt is generated and, if enabled, will be sent to the central computer. Even though the same node is used to display the eight windows in the diagram of Figure 1, we can tell which window and house is being pointed to by examining the sequence of branches taken to arrive at the window displayed at the time of interrupt. If the console user points to the right hand window of the middle house of Figure 1 (marked with an asterisk *), an examination of the subroutine return addresses in the push down stack would show that the current "window" node had been arrived at via the dotted line path shown on the network of Figure 2. 🕵️‍♀️

There's still the question of "Are we pointing at a window, at a wall, at the house, or at all three houses?" 🤔 The location of the structural hit depends on how many branches are counted while examining the return addresses, before one stops to consider which branch that return jump points to. This is kind of like counting a fixed number of levels from the ends of the graph structure. This number of jumps is set using reserved keys on the keyboard, one incrementing and the other decrementing the limit. By manipulating these keys and pointing at various displayed objects with the light pen, it's possible to point to any branch in the network of subroutine calls. 🔑

All information about the path in the node-branch network taken to arrive at any displayable coding is contained in a push down stack. Return jumps are stored in the stack by the subroutine calls to nodes. These jumps, when executed, will return the processor to the next instruction after the call. 📚

A greatly simplified version of the display coding used to generate the picture and tree of Figures 1 and 2 is shown in Figure 3 🧾. The labels a through d on the diagram represent the addresses of the subroutine calls that cause the display of the subpicture hit by the viewing device, which in this case is the right hand window of the second house. The returns from the called subroutines are stored in the push down stack as jumps to the location following the calls. The routine RETURN would merely execute POP instructions, which will ultimately cause the execution of a jump instruction previously placed in the stack by the calling branch, thus returning control to the calling routine. The stack is shown in the condition at the time of the hit on the right hand window of the middle house. Note that by counting 3 jumps upward (downward in the diagram) in the memory containing the stack, we arrive at the jump pointing to a structural hit at (b) in Figure 3, the call to model 120. 🎯💅

Console Operator Feedback 💬

The console operator has to know where they're pointing in the network of nodes and branches! 🙋‍♀️ So all displayable coding below the structurally hit branch flashes when a vector or character is viewed. This flashing is a doubling of the intensity at 2 to 8 cycles per second ✨. On top of that, a list of the names of all nodes and branches taken to arrive at the vector or character viewed is displayed in a corner of the screen. The name of the selected branch is intensified a bit brighter than the other names. 🌈

Generating an Attention 🔔

Once the operator has confirmed their choice, all they have to do is terminate the view to generate an attention on the desired branch. This is done by releasing the button on the light pen or lifting the pen from the Tablet. A button on the mouse performs the same function 🖱️. If the structural hit isn't correct, the operator can move the viewing device to a new area. 🙅‍♀️

A termination of the view on a blank area of the screen results in the generation of a "null" attention. This attention returns only position data; no structural data is generated. The significance of this attention is determined by the application program 🫠.

The above discussion assumed a refreshed display and the use of a light pen, but it greatly simplifies interactive graphics programming if these concepts can be implemented no matter what type of display or graphical input device is being used. This, in fact, can be accomplished, as discussed later 🦄💜.

THE GRAPHICS LANGUAGE 🎀

okay so for the sake of discussion we're gonna assume the graphics language statements are a set of subroutine calls 💅 (a fancier syntax could totally be embedded in the host programming language tho, and that would be iconic 🦋). The statements needed are:

1. Subroutine calls for creating and manipulating the picture-subpicture data structure 🌸
2. Subroutine calls to generate displayed pictures and picture parts, like lines and characters ✨
3. Subroutine calls to take in info about events or "attentions" that happen in real time at the console 👀
4. Subroutine calls to tweak picture parameters like line type (solid, dashed, dotted, etc.), brightness, character size, and so forth 💖
5. Subroutine calls for utility stuff, like saving and restoring pictures from disk files, starting the display, and so forth 🧚

NAMING 🏷️

okay bestie, a bunch of different naming conventions are required to meet what system and application programmers need 🫶

The Display Pointer 👑

so nodes and branches in the system get their names by assigning an integer or array location as an argument in the call that creates them. The system drops a number into those variables, and that number points to the physical location of the branch or node position in the picture-subpicture data structure. We call this name the DISPLAY POINTER 💜. As long as the user doesn't change what's inside these variables, they can refer to particular nodes or branches in various subroutines by using those integer variables as arguments. Basically, to the user, the name of a picture or subpicture is just the variable that got used when it was created 🌈. This kind of naming scheme is clearly needed if the programmer is going to manipulate pictures or subpictures at all 💅.

The Light Button Code 🔘

extra identification is useful to the application programmer because it makes their life way easier 🙈. A user has zero control over the number the system assigns to a Display Pointer, but there are situations where the user would love to link a known number to a branch. One super common example is "light buttons" 🍓. A light button is a displayed object that the user wants to be able to point at in order to command the controlling application program to do something. It's usually a string of characters forming an English word or words, but it could be any picture at all ✨. When the user picks or hits the light button, info identifying the object has to be sent to the timesharing application program. The program then has to branch to an appropriate statement or subroutine to carry out the operations needed to execute the command.

Here's the tea ☕: the Display Pointer uniquely identifies the object that got hit, but since its value isn't under the programmer's control, writing the code to test it against all the various Display Pointers that are considered legit to be hit at that point in the program is tedious 😭. If, however, the application programmer knew that at this point only objects with identification numbers 20-28 were legitimate to be hit, then testing to see that one was in that range and branching with a computed GOTO would simplify the flow of control. Often you don't need a unique ID for an object at all, and you just want to do a certain action if any object in a class of objects gets hit 🦋.

So the above need for identification is handled by letting the application programmer assign a number to a branch, and this number doesn't have to be unique 💖. This number is called the Light Button Code. The programmer can use it however they want, but it's most commonly used, as the name suggests, as a code identifying light buttons 🔥. This number gets sent to the application program along with the Display Pointer of the object that was hit on the screen with a graphical input device.

The Back Pointer 🧚‍♀️

we mentioned earlier that interactive graphic programming needs to be able to associate application-oriented data with picture and subpicture objects on the screen 🫶. That data can be stored in lots of different kinds of data structures depending on the app, like arrays, lists, trees, etc. The way we meet that need is by associating each branch with one word, which could contain a pointer to the right spot in the application data structure holding the data for that branch. We call this word the Back Pointer 🌸. The application programmer can actually store any code they want in this word and use it however they like, but its common use as a pointer back into a database in the application program is where the name came from 💅.

Let's say there's an app that lets a chemical engineer draw a chemical flow sheet on the screen and then feed that flow sheet into a process calculation system 🧪. There will be various symbol-pictures on the screen representing basic process units, like heat exchangers, mixers, columns, and so forth, that can be copied and positioned on the screen 🎀. These units have to be connected together by streams ✨. The units and the streams will have names and data associated with them that describe their contents and properties. Also, the node-branch structure visually shows the user which units are connected to each other and how, but it doesn't necessarily store that connecting info in a form the application program can easily handle 😭.

The best way to represent that connectivity is with a data structure that uses simple list processing, where each unit and stream has a block of cells associated with it. Those cells hold the data for that unit or stream, plus pointers that carry the connectivity info 🔗. When a branch is created to position and display a unit, it will hold a pointer in its Back Pointer to the block of data associated with that unit. The data block will probably contain the Display Pointer for the associated branch too, so you can go from the picture to the data block, or from the data block back to the picture 🦋. Say you point at a unit to delete it: given the Back Pointer of the unit that got hit, you can find its associated block and return that block to free space. Then you can follow the right chain of pointers to the blocks for the streams connected to that unit. Inside those blocks you'll find the Display Pointers for the branches displaying each stream, so you can delete the stream from the node-branch structure and make it vanish from the screen 💀.

An additional form of name is letting the programmer store an alphanumeric string with each branch or node 💜. This form of name isn't required for most applications, but it can be useful with the picture editor 🌈.

To recap, each node and branch has a unique identifier that the user names, called the Display Pointer, and its value is assigned by the system 👑. Each branch also has two additional pieces of info that the programmer can assign to it, called the Light Button Code and the Back Pointer 🍓.

Given a Display Pointer for a branch, the programmer can get the Light Button Code or the Back Pointer for that branch ✨. Given a Light Button Code or a Back Pointer, the programmer can get a Display Pointer for a branch that has that code. That Display Pointer might not be unique if several branches share the same Light Button Code or Back Pointer 🙈. The naming and identification ideas above have proven to be easy to understand and yet completely general and easy to use 🫶🎀

COORDINATE SYSTEMS 🗺️

Okay so, we need a coordinate system to describe where pictures go 💅. The actual display hardware in a terminal already has a fixed one (commonly 1024 by 1024 units on a fixed size screen, with the origin 0,0 in the left hand corner or center of the screen) 🖥️. But the user really wants a virtual screen way bigger than the hardware screen, and they want to treat the hardware screen like a window they can slide around to peek at it 👀. Pictures should also be built out of subpictures, like in Figures 1 and 2 🧩. To handle the second thing now and leave room for the first later, we use these coordinate system conventions ✨.

Each node has its own coordinate system 🌸. When node A is created, the programmer assumes the picture-drawing CRT beam is sitting at the origin of that node's coordinate system 🎯. When node A gets used inside node B through a branch, A's position is relative to the beam position in B's coordinate system 💖. All nodes get positioned relative to each other by x, y positioners in the corresponding branches 📍. When a picture is actually displayed, one node is named to the system as the initial or Universe Node 🌌. That initial node gets positioned absolutely on the screen, and every other node shows up relative to it, as set out in the branches pointing to them 🔗. This setup is required to give the flexibility and generality that the picture-subpicture tree needs 👑.

---

Logical Completeness of Operation Set 🎀

Throughout the whole system design, we should follow the philosophy of having a logically complete and consistent set of operations 🧠. Specifically, for every call that sets a value, there should be another call that fetches it 🔄. Basically, every operation gets an inverse operation whenever that makes sense 💫. We see a need for a basic system built on the calls as primitives. Calls that a programmer could build out of other calls can be added when usage seems to warrant it 🛠️. We'd expect a library of higher level routines in the language 📚.

It's beyond these notes to go through every call that's needed, so we'll just point out a few basic ones 🫶. For structure creation, you need to be able to create a node or branch, delete a branch, and add a new branch to a node at run time 🌳.

You need to be able to specify beam movements in nodes, and place text in nodes with the normal write-format statements of the host programming language 🖊️. This last point is super important for easy programming 😭.

You need to be able to set and test parameters, and convert one form of name into others 🧪.

We talk about Attention handling in more detail because it matters so much for making interactive programming easy 🔥.

---

Attention Handling 🔔

The user at the console is operating in real time, but the application program is running in timesharing time ⏰. So at any point where the user might do something at the console, the application program might not even be running 🙈. A mechanism has to be built to let the user and the application program talk to each other, and designing it is a big deal, so it needs real careful thought 🧐. There are lots of different operations you might want to offer the user at the console. This section covers one basic mechanism that lets others be added later 🧩. When the application reaches a point where it's expecting input from the terminal, it makes a call and passes an array as an argument 📦. The Attention handling mechanism puts the program to sleep until an event is reported from the console 😴. What gets sent back to the application is the type of event that occurred, plus other relevant information for that event 💌.

On refreshed displays, a common input device is the light pen 🖋️. Its physical field of view is about a 1/8-1/4 inch circle ⭕. Its most common use is pointing at an object to be hit or picked 🎯. The user's logical field of view is a branch in the node-branch structure 🌿. The picture drawn by the structure below that branch blinks to give the user feedback about which object they're about to hit or operate on ✨. The level in the structure where the logical view is given can be set under program control, or adjusted by the user from the keyboard ⌨️. When the user sees feedback showing the right object is in view, they press a button on the light pen to generate an Attention 👆. They're said to obtain a "structural bit" at a branch, at the level in the node-branch structure set by the application program or by themselves 💫. When the hit occurs, the right info gets entered into the Attention queue, as described below 📥.

The other type of graphical input device, common on both refreshed and non-refreshed displays, includes electronic pen-tablets, Joy Sticks, the SRI Mouse, and so on 🕹️. These produce x, y position information that gets fed back to the screen as some sort of cursor, like a dot or a cross ➕. Without special hardware it's difficult, if not impossible, to give the kind of feedback the light pen can, but structural hits can still be generated using special hardware or software 🛠️. These devices require the application programmer to set the appropriate level for an expected hit 🎚️.

The level of a structural hit is counted up from the bottom of the node-branch structure 🪜. A hit at level 1 is the lowest branch currently in view 🌱. A hit at level 0 is a hit on an individual vector or group of characters 🔍. Only special programs, like a picture editor, are likely to obtain hits at level 0 ✏️.

The Attention type you get from a structural hit on a branch returns the following info: the information the application program requires in the array, the Display Pointer, the Light Button Code, and x, y information 📋. The x, y information returned is not the absolute x,y pen position, since that wouldn't be of any use for this type of hit 🙅. Instead, it's the physical beam position just before execution of the branch that was hit 📍. If you want the physical location of the node origin the hit branch is connected to, make another call to get the branch positioner, then add those values to the corresponding values from the hit 🧮. Given the Display Pointer, you can get the Back Pointer or other parameter values associated with that branch call 🔗.

Next up is the Attention type you get when a hit is generated but no object is in view 👻. This is called a null attention, and it gets used a lot for positioning objects on the screen 📌. The only information returned in the array is the absolute screen coordinates of the position of the graphic input device or cursor 🗺️. This can be converted into relative information for placement in a branch positioner, or used for incrementing a branch position when an object is being moved 🚚.

Other calls are required to obtain information about other branches related to the one that was hit, and to perform other functions 💜.

STRUCTURAL HITS FOR STORAGE TUBE DISPLAYS 🦋

Okay bestie, last topic 🫶 How do we get structural hit info when a storage tube display only gives you absolute x, y screen coords? It's giving detective energy 🧚

The problem: take an x, y pair and figure out whether the user is pointing at an object on the screen, and if they are, which object 👀 When a light pen hit happens, the display processor halts, and the controlling computer can get into the return addresses in the push down stack and the instruction location that made the line or character causing the hit 💅 Joy Stick, Mouse, or tablet use is totally asynchronous with the display for refresh displays. For storage tube systems, the hit happens after the drawing has taken place ✨

The brute force approach would be to simulate running the Display Buffer and calculate some measure of distance between every line and the hit's x, y. That's way too time consuming and not feasible 💀

The second approach, which is commonly used, is to have the programmer define a rectangle around each object on the screen. Then you figure out which rectangle the cursor was in, and that tells you the object hit 🎀 But this takes extra effort from the programmer, and it only works well if the node-branch structure is one level deep, there are no diagonal lines as nodes, and no objects have overlapping rectangles. Those are severe restrictions, so this approach is out ngl 🙈

The third approach is to break the screen into small squares or rectangles, sized so a line from more than one picture object is unlikely to pass through the same one. For each square, you'd record the Display Pointer of the lowest level object branch passing through it. The catch is that this needs considerable system space and takes a lot of time to figure out which rectangles each line passes through 😭

The fourth approach, the one we recommend 👑, is to split the screen into horizontal and vertical strips. When the call to DISPLAY is given, the system makes one pass through the node-branch structure and makes a list of the Display Pointers for the lowest branch having a node with a line or character passing through or in each horizontal or vertical strip.

This calculation is quick because the system can easily get the start and end points of a line. You can then determine which strips the end points fall in, plus the intermediate strips crossed. When a hit is generated, the x, y information is converted to horizontal and vertical strip numbers. The Display Pointers for each of these strips are intersected to see if a common Display Pointer exists. If yes, that's the Display Pointer for the object hit. If not, a null hit is generated. Choosing the strip width decreases the probability of multiple hits resulting 🌸

The process above yields the Display Pointer of the lowest branch in the tree in view, but you might want info about other, higher branches in view too 🌳 That's handled by creating not only the strip lists, but also parsing the node-branch structure at the same time into a table containing an abbreviated representation of the tree and the screen x, y coordinates existing at each branch. The strip lists don't actually contain Display Pointers. Instead, they point back into the parsed representations, which have the Display Pointer, x, y coordinates, and the structure level for each of the branches. The parsed representation is a linear list of the branches encountered as the program walks through the node-branch graph. Given the hit at the lowest level, you can determine all branches passed through from the top node to the hit branch by searching upward through the graph representation 🧠

Every time a branch is deleted or a new branch is added, you need to modify the screen, modify the representations, and modify the strip lists. For refresh displays, the picture can be changed immediately, and the strip lists and representations can be modified at the time of an attention call. For a storage display, erasing and redrawing the picture on each deletion can be slow if lots of deletions are going on, and it may be unnecessary 🙃

There are three approaches to performing these functions in storage tube systems:

1. Erase the screen on each deletion and recompute the picture, strip lists and graph representations on each deletion and addition.
2. Keep a list of each Display Buffer change, perform an erase if necessary, and redraw or make an addition when an attention call is encountered. This is a feasible approach because it's only at this point that the screen and structural hit information need to be up to date ✨
3. Allow control of screen changes and other updating by special subroutine call. The recommended approach uses a combination of the above. Adding information to the screen should occur at the time of the new branch call. Deletions and modifications of the representation and the strip lists occur only at the time of an attention call. Routines should also be provided to give the programmer control over this redraw mechanism.

Experience with the above mechanism has shown it to be quite fast and not to noticeably degrade response time. One minor difficulty has been encountered when a horizontal or vertical line of an object is on the borderline of a strip. Sometimes this results in a null hit being generated if the cursor is on the wrong side of the borderline. A check can be made for this condition, and audio feedback can be given to the user with the bell in the terminal to indicate a correct or erroneous hit 🔔

---

INTERFACE TO THE TIMESHARING SYSTEM OF A REMOTE MINICOMPUTER DRIVEN DISPLAY 💜

Although the graphic system is locally controlled by a minicomputer, the user doesn't have to worry about the mini 🙌 Application programs are written for the timesharing computer only. The graphic system as a whole behaves as a terminal of the timesharing computer. This feature is super important, because no matter how powerful the graphic system is, it has to be easy to program and use before useful applications can be implemented 💖

Because nobody wants to operate over a communication line, you need to compress the information sent to the remote system. This is done by compiling a central node-branch structure in the central computer and only sending minimal character strings to the remote computer. Those strings represent the subroutine calls that need to be compiled into a Display Buffer in the remote computer for display refresh. In other words, a smaller remote version of the graphics system lives in the remote minicomputer 🧚 Simple schemes for coordinating the Display Pointer in the remote and central machines have to be devised.

CONCLUSION 🎀

We feel that the above concepts are central to creating an interactive graphics support system for use with a timesharing system 💅 The key concepts are the ones associated with the node-branch structure and the structured hit. The topics of a picture editor, data management system, and basic level support are also very important, but they're beyond the scope of this lecture 🌈

Figures 1, 2. and 3, are available in both .PS and .PDF versions.

---

[This RFC was put into machine readable form for entry] [into the online RFC archives by Lorrie Shiota, 10/01]