組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：邵二東（sherd  erdong_shao@hotmail.com）
譯文發布時間：2002-05-28
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須保留本文檔的翻譯及版權信息。

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

網絡圖形
(RFC285----Network Graphics)
在NIC收藏專欄關于在ARPANET上的圖形的文章并不多。在大約8000個題目中關于圖形學的只有20多個。原因可能與L. G. Roberts 在 A FORWARD LOOK (NIC 7542)中所說的原因差不多，那就是，數據庫共享或軟件共享今后幾年不會成為重要的題目。ARPANE還沒有發展足夠長時間使那些關心它的人了解它是否可行且富有創意。
因此此文目的是介紹圖形學在ARPANET上的現有情況和涉及到的更遠的一些情況。我將以概況介紹開始，之后簡要介紹過去的工作，最后加入一些我的新想法。
因為ARPANET上有大量的數據處理。其中一些或全部可能在同一時間使用。我們不只局限于在個人安裝的系統構架：一個主處理器和一些低端的機器（甚至沒有）作為顯示處理器。在NET的實際應用中可能有比執行主要任務的機器功能更強的機器作顯示處理器。NET上的圖形并不是我們現在所知道的那樣。
當設計標準圖形語言和處理器時當然應該考慮各種各樣的圖形設備的組合。如果我們想驅動從程序的來的顯示，這樣的輸出語言必須相當通用。但是構建最終顯示列表的處理器沒有必要實際上也不可能做到通用。它的工作僅僅是轉換定義好的通用語言來滿足某一確定圖形終端的需要。命令處理，今后將討論和非常值得關心的題目，將是一個完全不同的問題。這一次可能會帶來壞處而不是好處，因為現在可能有幾個（不是一個或沒有）映射。這些映射用來定義從主工作處理器產生的最初顯示列表到如光筆等交互設備等最終設備產生的最終顯示列表的指向。這是必須面對的問題，許多公司已經通過不同的途徑解決了這個問題。最終他將給我們帶來困難。
如果顯示終端是智能的，甚至擁有自己的中間或大規模除了刷新顯示沒有其他功能的處理器，本地處理是一件非常簡單的事情。這些事情可能是在圖片上簡單的增加或刪除這樣的不需要主要任務處理器完成的工作。本地處理器只需要向顯示列表通報所有變化以使主拷貝更新。功能的分配帶來的后一個問題。如果當地處理器只是保持圖片顯示，那么它達到了最低要求，如果它比主處理器功能更強并能自己處理所有命令便達到了更高的要求。現在諸如哪個顯示列表拷貝是主拷貝，誰負責監視所有拷貝是否有相同內容，列表間需要什么樣的映射等問題成為有待解決的重要問題。
網絡標準圖形建議的初衷是只包括命令的簡單可解釋語言，這些命令包括擦除屏幕，顯示文本字符串，移動光標，在虛框的顯示范圍內畫線或點，執行預定好的子程序用命令流中的下一個命令覆蓋上一個子程序的顯示內容等。在屏幕范圍內的移動是用屏幕的坐標變化來定義的而不是實際長度。這個建議符合圖形標準不能過于限制而應能廣為接受的建議。這個建議對復雜圖形該如何處理不夠明確。很多人都認為一個標準必須能夠充分利用圖形硬件資源，并能夠體現和預測將來。數據結構應能夠體現邏輯結構和圖示結構。允許定義和修改子圖，將顯示屏幕分為幾個邏輯單元。現在建議的標準已經成為一個普遍的高級語言而不是低級語言。需要指出的是沒有必要所有的站點都具備對圖形語言解釋能力。但由于NET中其他部分的存在，其他的一臺機器應有這種解釋能力，就好像數據重構服務。諸如強度，亮度，虛線，顏色或立體化等畫圖模式應也能夠通過命令模式來進行設置。必須規范的定義字符串，因為每個人都有自己的文本顯示方式，而且其中大部分都不相同。最好應有的Osanna, J., Sahzer, J.的 Multics遠程終端字符流處理（ Proceedings SJCC, 1970,  p. 671.）
如果要另外顯示簡單的圖形信息，希望與圖片直接進行交互，協議必須包括在反饋與命令處理被調用時的標準。然而命令可能并不總是直接指向圖片，比如鍵盤輸入可以作為NET上的其他標準信息被處理這種情況下就是如此。有的圖形處理器能夠在本地處理命令的能力而只是向主處理器報告最終結果。考慮到主拷貝的問題和個處理模塊如何同步，大部分的數據結構應該更新，這是一個問題。我們也發現，圖形應用程序和主處理模塊通過網絡標準語言與圖形設備處理流程進行通信，系統框架就應該比較武斷，所有的終端都應附屬于主處理模塊。命令處理當然也應該如此：關于當更新時由某一設備產生的所有命令的傳輸的標準應被所有的其他圖形處理終端的主處理器所理解。大部分的輸入設備與標準輸出設備相同，同樣建議每一個命令都標明產生命令的設備，提供的數據，當然還有數據本身。
建議的圖形協議已經有了較豐富的顯示類型。點，線，向量，字符串，視口和窗口，流程的傳送，硬件字節流，事件命令等是基本的顯示類型。還需另外考慮灰度設備，四種不同的模式在NIC 7128中有所討論。
NIC 7130中有一個關于硬件共享的例子。它是為在網中(ARPANET中)有LDS-1程序的用戶使用M.I.T.的LDS-1處理器所用的協議。正如其所稱，圖形讀取器提供發向M.I.T 的PDP-10 程序的執行，執行完后便送回執行的結果。圖片便能在顯示器上畫出來，但由于LDS-1處理器能夠根據協處理器產生的結果執行，圖形讀取器命令將（結果）寫回顯示協處理部分的核心部分。這些協處理部分被送回起初的站點顯示或用來編譯。
由于協議中非交互式圖形不能與交互式的圖形要求相混雜，(NIC 7151)， 現在已經有了一種專門針對句柄輸入數據處理的方法。現在已經有幾種句柄數據類型能作為圖形處理的輸入了，其中有單間斷（single shot），簡單同步，簡單異步，和預處理的數據。預處理數據可通過各種技術分塊，過濾，簡化使數據更簡化和易于處理。在數據解釋過程中可加入用來加速的部分。
NETCRT (NIC 7172)是第一個針對本地處理（的協議），或沒有。NETCRT是關于中央處理器和字符顯示（之間）的協議。字符顯示完全服從于中央處理器而自己沒有處理能力。然而它（字符顯示）可以對處理器提出中斷以說明用戶已經輸入完畢或要開始輸入。NETCRT通過控制終端的狀態以保持良好的人機交互。
我在關于對各種不同協議的評論中多次總結，因為我認為這些協議并不符合我在本文中所說的。我們有必要重新考慮圖形系統的整體模型。以前的建議沒有考慮整體模型就刪除了一些細節，對于具體的應用確實有一些新想法，但沒有整體考慮到整個系統怎樣很好的結合在一起。所以我想建議一個圖形系統的模型。它包括許多協議，并有許多地方以后大家深入討論。它以可提供簡單工作標準為起點，但也不排除以后加入更高級的功能。
圖1是一模塊信息流的圖示。PROCESS表示在網絡中運行的圖形應用程序。相關的INPUT和OUTPUT流程可認為是與PROCES一同讀取的子程序或為其他用戶服務的獨立的子程序。在循環的另一端是一些供顯示圖形信息的DISPLAY使用的 INPUT和OUTPUT驅動。從PROCESS流向PROCESS的信息流是建立和處理圖形的畫圖信息。從DISPLAY流向PROCESS的信息流是命令信息。當圖形由PROCESS畫出或圖形由本地處理并將已完成的圖形命令信息通知PROCESS時，才建立與主PROCESS相關的圖形數據庫。數據庫沒有必要保存多余的PROCESS處理的信息，事實上也沒有必要保存沒有交互活動的圖片。與DISPLAY驅動相關的數據庫由DISPLAY自己建立，這樣DISPLAY驅動沒有必要請求主PROCESS就可以處理來自DISPLAY的命令，并根據實際顯示的圖片的調用INPUT驅動更新圖片。主PROCESS的進出信息是一些過程所發出和接收的參數。INPUT 和OUTPUT 顯示驅動將標準信息翻譯成合適的字節流給DISPLAY或者將從DISPLAY傳來的命令翻譯成網絡標準信息。INPUT和 OUTPUT 流程相應將標準圖形協議翻譯給INPUT驅動或將OUTPUT驅動中的信息翻譯成標準的圖形協議。如果DISPLAY需要刷新則它將自行處理，所以刷新和沒有刷新的形式并沒有明顯的區別。此模型既適合于簡單的應用也適合于復雜的交互式的圖形。通過設置運行條件可以使其發揮最大作用或最小作用，如沒有交互式的圖片或與交互式圖片相關的全部跳過，但與此同時其他PROCESS在原情況下仍能高效圖像處理。
由于有兩個彼此保持同步更新的數據庫，所以有兩種運行此模型的方式。沒有其他的好名字，我們叫它程序（PROGRAM）圖形和本地（LOCAL）圖形。前者指顯示的圖片是有主PROCESS創建的并且圖片中所有的用戶輸入都已提交。因此DISPLAY數據庫只作為主PROCESS動作的結果在其后更新。后者指顯示端的用戶通過功能按鈕或畫圖工具直接創建圖片，DISPLAY數據庫立即更新，并通知主PROCESS使其更新，但只有在DISPLAY OUTPUT驅動提出請求后才能執行對圖形的處理；后者還可作為由DISPLAY INPUT/OUTPUT驅動自己執行的函數或由主PROCESS在圖形上執行的非標準的函數的結果。
此設計的主要目的是實現圖形配置的最大通用性而不是最小的響應時間。此設計最好有更明確的硬件配置和所期待的應用的規范說明。由于所有參數都是未知的而且我們所期望的通用性使我們不能對其深入，所以我們應該提供能夠對INPUT/OUTPUT和主PROCESS之間的說明驅動哪種DISPLAY的處理任務進行分割的能力，而不是設計合適的斷點。
圖形協議應該定義INPUT和OUTPUT流程和驅動間的傳遞的消息的格式。 消息可按如前所述根據傳遞方向和內容分類，如畫圖信息，指令信息。因為圖形和文本經常混雜所以圖形消息必須有可區分的頭消息頭部。因此用一個字節指定消息主體的信息類型，一段字節表示消息主體，最后是主體本身。事實上需要的消息類型已經在以前的RFC中提到，我在此就不重復了。需要指出的是現在命令包括驅動不能實現的處理請求。
總之，我認為一個簡單的模型便可滿足復雜的交互圖形和非交互圖形的設計要求，主要原因是我們最感興趣的不是最短響應時間而是最大的構造復雜性。當建立INPUT/OUTPUT流程時可以應用軟件共享和數據重組技術。還有好多具體工作要作，但在當前最基本的模型的基礎上要想實現預想的思想，還需要不斷的努力。
         +---------+                  +--------+
         ! INPUT   !                  ! OUTPUT !
      +--! routine !<------||---------! driver !<--+
      !  +---------+                  +--------+   !
      !                                   ^        !
      V                                   !        !
 +---------+---------+      +---------+   !   +---------+
 !         ! Graphic !      ! Graphic !   !   !         !
 ! PROCESS ! Data    !      ! Data    !<->!   ! DISPLAY !
 !         ! Base    !      ! Base    !   !   !         !
 +---------+---------+      +---------+   !   +---------+
      !                                   !        ^
      !                                   V        !
      !  +---------+                  +--------+   !
      !  ! OUTPUT  !                  ! INPUT  !   !
      +->! routine !-------||-------->! driver !---+
         +---------+                  +--------+

圖1
[ This RFC was put into machine readable form for entry into the online RFC archives by Ian Redfern 4/99 ]
RFC285----Network Graphics                                                          網絡圖形




1
RFC文檔中文翻譯計劃