RFC285 网络图形_成都软件开发公司

RFC285 网络图形

作者：zhaozj
发表时间：2020-12-23 10:53
来源：未知

组织：中国互动出版网（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文档中文翻译计划