网络图形( 二 )


假如要另外显示简单的图形信息 , 希望与图片直接进行交互 , 协议必须包括在反馈与命令处理被调用时的标准 。然而命令可能并不总是直接指向图片 , 比如键盘输入可以作为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在原情况下仍能高效图像处理 。

推荐阅读