Organization: China Interactive Publishing Network (http://www.china-pub.com/)
RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: Ouyang@china-pub.com
Translator: Shao Erdong (SHERD ERDONG_SHAO@hotmail.com)
Translation time: 2002-05-28
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but the translation and copyright information of this document must be retained.
Network Working Group D. HUFF
Request for Comments: 285 CWRU (case)
NIC: 8271 December 15, 1971
Updates: None
Obsoletes: None
Network graphics
(RFC285 ---- Network Graphics)
There are not many articles on the NIC Collection Column About graphics on Arpanet. In approximately 8,000 questions about more than 20 of graphics. The reason may be similar to the reasons why the L. G. Roberts is in A Forward Look (NIC 7542), that is, database sharing or software sharing will not become an important topic in the next few years. ARPANE has not developed for a long time to make those who care about it is feasible and creative.
So this paper is to introduce some of the existing situations on the Arpanet and more far-reaching situations involved. I will start with an overview, and then briefly introduce the past work, and finally join some of my new ideas.
Because there is a lot of data processing on the ArpaNet. Some or all of them may be used at the same time. We are not limited to system architecture in personal installation: a master processor and some low-end machines (or even) as a display processor. In the practical application of NET, there may be a machine that is more powerful than the machine function of the main task. The graph on the NET is not what we now know.
A combination of a variety of graphics devices should be considered when designing standard graphical languages and processors. If we want to drive the display from the program, such an output must be quite universal. However, the processor that constructs the final display list is not necessarily universal. It works just to convert a well-defined generic language to meet the needs of a certain graphics terminal. Command processing, will be discussed and very worthy of concern in the future, will be a completely different issue. This time may bring bad things instead of benefits, because there may be several (not one or no) mapping. These mappings are used to define the initial display list of final display lists generated by interactive devices such as interactive devices such as stylus from the main working processor. This is a problem that many companies have solved this problem through different ways. In the end, he will bring us difficulties.
If the terminal is intelligent, the local processing is a very simple thing even if you have your own middle or large-scale processors that do not have other features. These things may be simply added or deleted on the image that does not require work that requires the main task processor. The local processor only needs to notify all changes to the display list to update the primary copy. The latter problem brought by the allocation of the function. If the local processor just keeps the picture display, it has achieved a minimum requirement, and if it is more powerful than the main processor, it has reached a higher requirement. Now which display list copy is a master copy, who is responsible for monitoring all copies have the same content, what kind of mapping needs to be solved in the list, etc. The original intention of the network standard graphics is to include only a simple interpretable language of the command. These commands include the erase screen, display text strings, moving cursors, draw lines or points in the display range of the virtual box, perform a predetermined subroutine command The next command in the stream covers the display of the previous subroutine, and the like. The movement within the screen range is defined by the coordinate change of the screen instead of the actual length. This suggestion that the graphic standard cannot be too limited and the advice should be widely accepted. This recommendation how to handle the complex graphics is not clear enough. Many people think that a standard must be able to make full use of graphical hardware resources, and can be embodied and predictive. The data structure should be able to reflect logical structure and illustration. Allow the definition and modification of the sub-map, divide the display screen into several logical units. Now the recommendations have become a universal high-level language rather than a low-level language. It is to be pointed out that there is no need to have all sites to explain the ability to interpret graphical language. However, due to the existence of other parts in NET, other machines should have such interpretation capabilities, as as data reconstruction services. Picture modes such as intensity, brightness, dashed line, color or stereochemical should also be set by command mode. The definition string must be specified because everyone has their own text display mode, and most of them are different. It is best to have Osanna, J., Sahzer, J., J., J. Proceedings SJCC, 1970, P. 671.)
If you want to display simple graphics information, you want to interact directly with the image, the protocol must include the standard when the feedback and command processing is called. However, the command may not always directly point to the picture, such as the keyboard input can be processed as other standard information on the NET. Some graphics processors can handle the ability of the command locally and only report the final result to the main processor. Considering the problem of the master copy and how the processing module is synchronized, most of the data structures should be updated, this is a problem. We also found that graphics applications and main processing modules communicate with graphics device processing flows through the network standard language. The system framework should be more arbitrary, and all terminals should be attached to the main processing module. The command processing is of course so: About the standard of transmission of all commands generated by a device when updated, should be understood by the main processor of all other graphics processing terminals. Most of the input devices are the same as the standard output device, and it is also recommended that each command indicates the device that generates commands, and the data provided, of course, there is also the data itself.
The proposed graphics protocol has a rich display type. Point, line, vector, string, viewport, and window, process, hardware word stream, event command, etc. are basic display types. It is also necessary to consider grayscale devices, four different modes are discussed in NIC 7128.
There is an example of hardware sharing in NIC 7130. It is a protocol used by users with LDS-1 programs in the network (Arpanet) using the protocol used by the LDS-1 processor of M.i.t. As it is known, the graphic reader provides the execution of the PDP-10 program that swirks M.I.T, and then sends back the result of the execution. The picture can be drawn on the display, but since the LDS-1 processor can execute according to the result generated by the coprocessor, the graphics reader command writes (results) back the core portion of the display coherent portion. These coprocessions are sent back to the first site display or to compile. Since the non-interactive graphics in the protocol cannot be mixed with interactive graphics requirements, (NIC 7151), there is now a method specifically for input data processing for handles. There are now several handle data types as input of graphics processing, with single break, simple synchronization, simple asynchronous, and pre-processed data. Pre-treatment data can be divided into various technical blockages, filtration, and simplify data more simplified and easy to handle. The portion used to accelerate can be added during the data interpretation.
NetCRT (NIC 7172) is the first for local processing (protocol), or not. NetCRT is a protocol for central processors and characters (between). The character display is completely affected by the central processor and there is no processing capability. However, it (character display) can be interrupted to the processor to explain that the user has entered or started. NetCRT interacts a good human machine by controlling the status of the terminal.
I have made many summary on all kinds of different agreements, because I think these agreements are not in line with me in this article. We need to reconsider the overall model of the graphics system. The previous recommendations did not consider the overall model to delete some details. There are still some new ideas for specific applications, but do not take into account how the entire system is well combined. So I want to suggest a model of a graphics system. It includes many protocols and many places in depth. It provides a simple work standard as a starting point, but does not exclude the addition of more advanced features.
Figure 1 is an illustration of a module information stream. Process represents a graphical application running in the network. The associated Input and Output processes can be considered as a subroutine that is read with Proces or a separate subroutine for other user services. On the other end of the loop is some input and Output drivers for Display for display graphics information. The flow of information from Process to Process is the drawing information of establishing and processing graphics. The information stream flowing from Display to Process is command information. The graphical database related to the main Process is created when the graph is drawn by Process or graphics and the completed graphic command information is notified. The database does not have to save the extra process processing information, in fact, there is no need to save pictures without interactive activities. The database related to the Display is built by DISPLAY yourself so that the Display driver is not necessary to request the main process to handle commands from the display, and call the Input Input for the actual display INPUT. The information of the main Process is a parameter issued and received by some processes. Input and Output Display Drivers Translate Standard Information into a suitable byte stream to Display or translate the commands from Display into network standard information. The INPUT and OUTPUT process will translate standard graphical protocols to INPUT or translate the information in the Output drive into a standard graphical protocol. If DISPLAY needs to be refreshed, it will process itself, so it is not a significant difference in the form of refreshing and no refresh. This model is suitable for simple applications and is also suitable for complex interactive graphics. By setting the operating conditions, it can make it maximize or minimally effect, such as images that are not interactive or all skip related to interactive images, but at the same time, other process can still be efficient image processing in the case.
There are two ways to run this model because there are two databases that have been synchronized with each other. Without other good names, we call its program (Program) graphics and local (local) graphics. The former refers to the image displayed is a master process created and all user inputs are submitted. Therefore, the Display database is only updated after the result of the main Process action. The latter refers to the display of the user directly to create a picture through the function button or the drawing tool, and the display database is updated immediately and informs the main process to update it, but only after the Display Output driver is requested, it can perform the processing of graphics; the latter can also act as The result of the DISPLAY INPUT / OUTPUT is driven or the result of the non-standard function executed by the main processs on the graph. The main purpose of this design is to achieve maximum versatility of graphical configuration rather than the minimum response time. This design preferably has a more clear hardware configuration and the specification description of the expected application. Since all parameters are unknown and what we expect so that we can't inverse it, we should provide the ability to drive which Display handles the INPLAY processing task between INPUT / OUTPUT and main Process, and Not a design suitable breakpoint.
The graphical protocol should define the format of the message that the Input and Output processes and the passage of the drive. The message can be based on the transfer direction and content classification, such as draw information, command information, as described above. Because graphics and text are often mixed, the graphic messages must be distinguished. Therefore, the information type of the message body is specified with one byte, and a paragraph is indicated by the message body, and finally the main body itself. In fact, the required message type has been mentioned in the previous RFC, I will not repeat it here. What needs to be pointed out is that the command now includes a process request that is not implemented.
In short, I think a simple model can meet the design requirements of complex interaction graphics and non-mutual graphics, the main reason is that we are most interesting is not the shortest response time but the maximum construction complexity. Software sharing and data reorganization technology can be applied when the Input / Output process is established. There are still many specific work, but on the basis of the current most basic model, I want to achieve the idea of the idea and require constant efforts.
------- --------
! 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 Ian Redfern 4/99]
RFC285 ---- Network Graphics Network Graphics
1
RFC Document Chinese Translation Program
