RFC285 日本語訳

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

コメントを求めるワーキンググループD.立腹要求をネットワークでつないでください: 285 CWRU(ケース)NIC: 8271の1971年12月15日アップデート: なにも以下を時代遅れにしません。 なし

                            Network Graphics

ネットワークグラフィックス

        Not much has been written about graphics on the ARPANET when the
volume of the NIC collection is considered. Presently it contains some
8000 entries of which only about 20 are on the subject of graphics. The
reason is probably similar to that given by L. G. Roberts in A FORWARD
LOOK (NIC 7542) as the reason that data base sharing or software sharing
will not be important topics for several more years: the NET hasn't been
up long enough for interested people to have enough of the facts to know
if it is feasible and to think creatively.

NIC収集のボリュームが考えられるとき、多くがアルパネットにグラフィックスに関して書かれるというわけではありません。 現在の、それはそれに関するおよそ20だけがグラフィックスの問題を扱っているおよそ8000のエントリーを含んでいます。 理由はたぶんより多くの数年間データが共有かソフトウェア共有を基礎づける理由がならない重要な話題によってA FORWARD LOOK(NIC7542)でL.G.ロバーツによって与えられたそれと同様です: NETは関心がある人々には事実がそれが可能であるかどうかを知って、創造的に思うことができるくらいあるくらいの長い間、上がっていません。

        This paper is therefore aimed at bringing together the present
state of graphics on the NET for the newcomer and attempting to add a
little more distance to the ground covered so far. I will start with an
overview, then proceed to briefly describe past work, and finally add
some of my own thoughts.

したがって、新来者のためにNETにグラフィックスの現状を集めて、今までのところカバーされている地面に距離をもう少し加えるのを試みるのをこの紙は目的とされます。 私は、概観から始まって、簡潔に過去の仕事について説明して、次に、最終的に私自身の考えのいくつかを加えかけるでしょう。

        Since the NET represents a wealth of data processors, any or all
of which may be used at one time, we are not restricted to the
configurations most generally found in private installations where there
is a main processor and a somewhat less capable machine or perhaps none
at all doing the honors as display processor. Indeed when using the NET
it might occur that one has a more powerful machine as the display
processor than the machine which is running the main job. Graphics on
the NET need not be anything like what we know it as now.

NETが豊富なデータ処理装置(それのいずれかすべてがひところ、使用されるかもしれない)を表すので、私たちはディスプレイ・プロセッサとして主人役を務めながら、メインプロセッサといくらかできないマシンか恐らく全くなにもないところで個人的なインストールで最も一般に、見つけられた構成に制限されません。 NETを使用するとき、本当に、1つにはディスプレイ・プロセッサとして主な仕事を走らせているマシンより強力なマシンがあるのは起こるかもしれません。 現在、私たちが何としてそれを知っているようにNETの上のグラフィックスが少しでもある必要はないか。

        There is of course a greater more diversified mix of graphics
equipment that must be considered when designing a standard graphics
language and its processor. If we wish to drive an aribitrary display
from a program such an output language must be quite general, but the
processor which constructs the actual display list for the target
display need not and in fact will not be general, rather its only job
will be to translate a well defined general language to meet the
requirements of one specific graphics terminal.

もちろん、標準のグラフィックス言語とそのプロセッサを設計するとき考えなければならないグラフィックス設備の、より大きいより様々なミックスがあります。 プログラムからaribitrary表示を追い立てたいと思うなら、そのような出力言語がしかし、一般、全く表示がそうする必要はない目標のための実際の表示リストを構成するプロセッサでなければならなく、事実上、一般的にならない、むしろ唯一の仕事は1台の特定のグラフィックス端末に関する必要条件を満たすためによく定義された一般的な言語を翻訳することでしょう。

        Attention handling, a lately discussed and much worried about
topic, presents an entirely different problem. This time the NET may
cause more harm than good for the simple reason that now there may be
several, instead of one (in some cases none at all), mappings defined to
get from the initial display list that the main job process is creating

注意取り扱い(最近、議論して、話題を非常に心配するa)は完全に異なった問題を提示します。 今回、NETは1の代わりに数個が現在あるかもしれない簡単な理由による利益より多くの害を引き起こすかもしれません(いくつかの場合皆無な)、主な仕事の過程が作成している初期の表示リストから得るために定義されたマッピング

                                   1

1

RFC 285  NIC 8271

RFC285NIC8271

to the final display list which interactive devices such as the light
pen actually refer to. This is a problem which has to be faced and has
been solved at many different sites in as many different ways. It is
likely to give as much trouble as the final concept.

決勝に、ライトペンなどの対話的な装置が実際に示すリストを表示してください。 これは同じくらい多くの異なった方法で直面されなければならなくて、多くの異なったサイトで解決された問題です。 それは最終的な概念と同じくらい多くの問題を与えそうです。

        Local processing is in many cases a very simple thing to
accomplish when the display terminal is "intelligent" or even has its
own medium or large scale processor which has little or nothing else to
do aside from refreshing the display. Such processing can be simple
additions or deletions to the picture which certainly do not require the
main job process to accomplish. The local processor need only notify the
main process of what changes have been made to the display list so that
the main copy may be updated. The allocation of abilities poses the last
problem. The lower limit is reached when the local processor is unable
to do anything beyond keeping the picture displayed, and the upper limit
applies to the case when the local processor is more powerful than the
main processor and handles all attentions itself. Now such questions as,
just which copy of the display list is the master copy, who is
responsible for seeing that all copies of the list contain the same
information, and what kind of mappings between display lists are
required, become the important ones we all seek to answer.

ローカル処理には、ディスプレー装置が「知的であり」多くの場合実行するのが非常に簡単であるものであるか画面の内容を更新することは別としてする少しか他に何もを持っているそれ自身の媒体か大規模プロセッサがありさえします。 そのような処理は絵への確かに、主な仕事を必要としなかった簡単な追加か削除が達成する過程であったならそうすることができます。 地方のプロセッサは主なコピーをアップデートできるようにどんな変更を表示リストにしたかに関する主な過程に通知するだけでよいです。 能力の配分は最後の問題を引き起こします。 絵を表示しておくことを超えて地方のプロセッサが何もできないとき、下限に達していて、地方のプロセッサ自体がメインプロセッサより強力であり、すべてのこころづくしを扱うとき、上限はケースに適用されます。 そのようなものが質問する現在と、まさしく表示リストのどのコピーがマスターコピーであるか、そして、リストのすべてのコピーが同じ情報を含むのがわかるのにだれが責任があるか、そして、表示リストの間のマッピングの種類が何であるかということであることが必要であることで、私たちが皆、答えようとする重要なものになってください。

        Proposals for Network Standard Graphics started with the idea of
a simple interpretable language containing only commands to erase the
screen, display a string of text, move the beam or draw a line or point
within a virtual rectangle which is the generalized display screen,
execute a previously defined subroutine, and replace the contents of a
subroutine with what follows in the command stream. Movements within the
screen area were defined in terms of fractions of the screen dimensions
instead of absolute lengths. This proposal was responded to with the
suggestion that a graphics standard could not be so restrictive and find
wide acceptance. The proposal was not expressive enough to handle
sophisticated picture manipulations. It was recognized that a standard
must be able to make use of all graphics hardware, present and within
the forseeable future. The data structure should represent both logical
and pictorial structure, allow for the definition and manipulation of
subpictures, and division of the display screen into logical units. The
proposed standard has now become a general high-level language rather
than a low-level language. It was pointed out that all sites need not be
able to handle the interpretation of this graphic language, but because
of the existence of the rest of the NET, one of the other machines could
run the interpreter, this is equivalent to a data reconfiguration
service. Such drawing modes as intensity, blinking, dashed, color, or
stereo should also be expressable by means of a command to set the mode.
The canonical definition of a character string should be defined since
everyone has their own way of displaying text and most of them are

Network Standard Graphicsのための提案は簡単な解明できる言語が一般化されたディスプレイの画面である仮想の長方形の中にスクリーンを消すか、テキストのストリングを表示するか、ビームを動かすか、または線かポイントを描いて、以前に定義されたサブルーチンを実行して、サブルーチンのコンテンツをコマンドの流れで続くことに取り替えるコマンドだけを含むという考えから始まりました。 画面領域の中の動きは絶対長さの代わりにスクリーン寸法の部分で定義されました。 グラフィックス規格がとても制限していて、広い承認を見つけることができなかったという提案でこの提案に応じました。 提案は洗練された絵の操作を扱うくらいには表現していませんでした。 現在のすべてのグラフィックスハードウェアを利用して、規格がforseeable未来中にそうすることができなければならないと認められました。 データ構造は論理的で絵の両方の構造を表すべきであり、「副-絵」の定義と操作、およびディスプレイの画面の分裂を論理装置に考慮してください。 現在、提案された標準は低級言語よりむしろ一般的な高位言語になりました。 NETの残りの存在のために、他のマシンの1つはインタプリタを車で送るかもしれません、そして、サイトが必要とするすべてがこのグラフィック言語の解釈を扱うことができるというわけではないと指摘されましたが、これはデータ再構成サービスに同等です。 また、明滅している強度を突進されたときモードを描くそのようなもの、色、またはステレオもモードを設定するコマンドによる「言い表-可能」であるはずです。 皆にはそれら自身の表示の方法があるので、文字列の正準な定義は定義されるべきです。

                                   2

2

RFC 285  NIC 8271

RFC285NIC8271

different. It is suggested that the Multics convention be used as
described by Osanna, J., Sahzer, J., Remote Terminal Character Stream
Processing of Multics, Proceedings SJCC, 1970,  p. 671.

異なる。 Osanna、J.、Sahzer、J.、Multics、Proceedings SJCC、1970年のRemote TerminalキャラクターStream Processingによって説明されるようにMulticsコンベンションが使用されることが提案されます、p。 671.

        If in addition to simply displaying graphic information, if one
wishes to to interact with the picture directly, the protocol must
include a standard for feedback, attention handling as it is being
called. Attentions may not always refer directly to the picture however,
as in the case of keyboard input which can be handled as any other
standard message on the NET. Some graphics processors may also have the
capability of handling attentions locally and only need to report the
end result to the main process. This is the problem of which data
structure is most up to date, which is considered the master copy, and
how can the processes be kept in sync? The observation is also made that
as long as the graphics application program, the main process,
communicates with a pair of graphic device handling routines in a
network standard language, the system configuration can be arbitrary and
any terminal may be attached to any main process. The same is of course
true of attention handling, a set of standards for the transmission of
an attention generated by a particular device when developed will allow
any graphics terminal to be understood by any other main process. A
summary of input devices has been given along with typical outputs and
the suggestion that each attention message identify the device causing
the attention, the data which is being supplied, and of course, the data
itself.

単にグラフィック情報を表示することに加えて人がそうしたいなら、直接絵と対話するために、プロトコルはフィードバック(それが呼ばれているような注意取り扱い)のために規格を含まなければなりません。 しかしながら、こころづくしはいつも直接絵を示すかもしれないというわけではありません、NETに関するいかなる他の標準のメッセージとしても扱うことができるキーボード入力に関するケースのように。 また、いくつかのグラフィックスプロセッサで、取り扱いこころづくしの能力は、主な過程に結末を報告する必要があるだけであるかもしれません。 これはどのデータ構造が最も最新であるかに関する問題です、そして、マスターコピーであるとどれを考えるか、そして、同時性でどうしたら過程は保つことができますか? また、グラフィックスアプリケーション・プログラム(主な過程)がネットワーク標準語でグラフィック装置取り扱いルーチンの1組とコミュニケートする限り、システム構成が任意である場合があるという観測をします、そして、どんな主な過程にもどんな端末も取り付けるかもしれません。 同じくらいがもちろん注意取り扱いに関して本当である、開発されると特定の装置で発生する注意の送信のための1セットの規格はどんなグラフィックス端末もいかなる他の主な過程にも解釈されるのを許容するでしょう。 典型的な出力とそれぞれの注意メッセージが注意を引き起こす装置を特定するという提案と共に入力装置の概要をしました、提供されているデータ、もちろん、データ自体。

        The proposed graphic protocol has become much richer in display
types. The following list was suggested as basic: points, lines,
vectors, character strings, viewport and window, transformations of
instances, hardware-dependent byte streams, attention commands. The
point was also made that special considerations for grey-scale devices
are needed and four alternate display modes are discussed (NIC 7128).

提案されたグラフィックプロトコルは表示タイプがはるかに豊かになりました。 以下のリストは基本的であるとして示されました: 注意は、ポイントと線とベクトルと文字列とビューポートと窓、例の変化、ハードウェア依存するバイトが流れると命令します。 また、灰色のスケール装置のための特別な問題が必要であり、4つの交互の表示モードについて議論するという(NIC7128)ポイントは、指摘されました。

        An example of hardware sharing is described in NIC 7130. It is a
protocol for the use of the LDS-1 processor at M.I.T. by anyone on the
net who has a program for the LDS-1. This Graphics Loader, as it is
called, provides for the execution of programs that have been sent to
the PDP-10 at M.I.T. and the return of the data generated when the
program is executed. The picture is not drawn on a display, but since
the LDS-1 processor can be instructed as to what to do with the
coordinates that it generates, the Graphics Loader sets up the processor
to write back into core the computed display coordinates. These
coordinates may now be sent back to the originating site for display or
as a debugging aid.

ハードウェア共有に関する例はNIC7130で説明されます。 それはネットのLDS-1のためのプログラムを持っているだれによるもマサチューセッツ工科大学のLDS-1プロセッサの使用のためのプロトコルです。 このGraphics Loaderはいわゆるマサチューセッツ工科大学でPDP-10に送られたプログラムの実行とプログラムが実行されるとき発生するデータの復帰に備えます。 絵は表示のときに描かれませんが、それが発生させる座標でするべきことに関してLDS-1プロセッサを命令できるので、Graphics Loaderは計算された表示座標のコアに返事を書くためにプロセッサをセットアップします。 送信側サイトはもう、表示かデバッギング・エイドとしてこれらの座標に送り返されるかもしれません。

                                   3

3

RFC 285  NIC 8271

RFC285NIC8271

        In NIC 7137 many of these previously discussed points are again
brought up, but this time under the supposition that a graphics terminal
should be just another terminal with minimal special privileges.
Suggestions were also made pertaining to the design of a graphics
protocol with particular emphasis on display structure, attention
handling, coordinate systems, and the difference between storage tube
and refreshed display requirements.

しかし、NIC7137年に、これらの以前に議論されたポイントの多くが今回、再びグラフィックス端末が最小量の特権があるただの端末であるべきであるという仮定の下で持って来られます。 また、蓄積管と壮快な表示要件の間には、特定の強調ディスプレーされた構造、注意取り扱い、座標系、および違いがある状態でグラフィックスプロトコルのデザインに関しながら、提案をしました。

        A specific solution for the handling of tablet input data has
been presented, (NIC 7151), along with the expression that the graphics
protocol should be designed so that non-interactive graphics should not
be complicated with the requirements imposed by the interactive aspects
of the protocol. It is pointed out that there are several types of
tablet data that can be sent as input to a graphics process. Four types
of data are described. They are single-shot, raw asynchronous, raw
synchronous, and preprocessed data. Preprocessed data can be smoothed or
filtered or thinned using various techniques to make the data more
uniform and workable. Velocities can also be calculated for each point
to aid in the interpretation of the data.

入力データが提示されたタブレットの取り扱いの特定の解決策、(NIC7151)、表現と共に、グラフィックスが議定書を作るのは、要件がプロトコルの対話的な局面によって課されている状態で非対話的なグラフィックスが複雑であるべきでないように、設計されるべきです。 グラフィック処理に入力されるように送ることができるいくつかのタイプに関するタブレットデータがあると指摘されます。 4つのタイプに関するデータは説明されます。 それらはただ一つのショットの、そして、生の非同期で、生の同時の、そして、前処理されたデータです。 データをより一定で実行可能にするのに様々なテクニックを使用することで前処理されたデータを整えるか、フィルターにかけられるか、または薄くすることができます。 また、データの解釈で支援するために各ポイントに速度について計算できます。

        The description of NETCRT (NIC 7172) is the first encounter with
local processing, or lack of it. NETCRT is a protocol between a central
processor and a character display. The character display is completely
slaved to the central processor and can do no local processing, however
it can interrupt the processor thus signalling that the user is done
typing or wishes to begin typing. NETCRT tries to maintain good man-
machine interaction by controlling the state of the terminal.

NETCRT(NIC7172)の記述は、ローカル処理との最初の遭遇、またはそれの不足です。 NETCRTは中央のプロセッサとキャラクタディスプレイの間のプロトコルです。 キャラクタディスプレイは、しかしながら、中央のプロセッサに完全に身を粉にして働いて、ローカル処理が全くできないで、その結果ユーザがタイプし終わっていると合図するプロセッサは中断できるということであるかタイプし始めたがっています。 NETCRTは、端末の状態を制御することによって、良い男性マシン相互作用を維持しようとします。

        I have refrained from commenting on the various proposals as I
summarized them because I don't think that it would have been in line
with what I am trying to do in this paper. I think that there is a need
to consider an overall model of the graphic system we are trying to
design. Previous proposals have dealt with some set of details without
identifying with a general model, producing good ideas for
implementation of details but not considering how the whole will fit
together. Thus I would like to propose a model for our graphics system.
It will contain many protocols and leave many areas to be discussed
further, but it will provide a starting point from which work can be
done along simple lines, and yet not exclude the later inclusion of more
sophisticated abilities.

私がこの紙でしようとしていることに沿ってそれがあったと思わないのでそれらをまとめたとき、私は様々な提案のときにコメントを控えていました。 私は、私たちが設計しようとしているグラフィック・システムの総合的なモデルを考える必要があると思います。 一般的なモデルを同一視しないで、前の提案は何らかのセットの細部に対処しました、詳細の実現のために名案を生産しますが、全体がどのように一緒に合うかを考えない場合。 したがって、私たちのグラフィックスシステムのためにモデルを提案したいと思います。 多くのプロトコルを含んでいて、さらに議論するために多くの領域を出ますが、それは、簡単な線に沿って仕事をできる出発点を提供しますが、より洗練された能力の後の包含を除かないでしょう。

        Figure 1 shows a block diagram of information flow. The PROCESS
indicates a graphics application program which is running on a computer
in the net. Its associated INPUT and OUTPUT routines can be thought of
as being a set of subroutines loaded with the main PROCESS or as
separate and running elsewhere serving many users. At the other end of
the loop are a set of INPUT and OUTPUT drivers for the DISPLAY which is
being used to display the graphics information. The information flowing

図1は情報流動のブロック図を示しています。 PROCESSはネットでコンピュータで動いているグラフィックスアプリケーション・プログラムを示します。 主なPROCESSか別々で走りとしてほかの場所で多くのユーザに役立ちながらロードされた1セットのサブルーチンであるとしてその関連INPUTとOUTPUTルーチンを考えることができます。 輪のもう一方の端に、グラフィックス情報を表示するのに使用されているDISPLAYのための1セットのINPUTとOUTPUTドライバーはいます。 情報流動

                                   4

4

RFC 285  NIC 8271

RFC285NIC8271

from the PROCESS to the DISPLAY is drawing information for the building
and manipulation of pictures. The information flowing from the DISPLAY
to the PROCESS is attention information. The Graphic Data Base
associated with the main PROCESS is that which is constructed when the
picture is being drawn by the PROCESS or when the picture is being drawn
by local processing and attention messages tell the PROCESS what has
been done to the picture. This data base need not contain more
information that the PROCESS is willing to work with, and in fact need
not contain anything if no picture interaction is to be done. The
Graphic Data Base associated with the DISPLAY drivers is built by
themselves so that the OUTPUT driver can handle attentions from the
DISPLAY without requiring the main PROCESS to be able to do this and for
the INPUT driver to use when modifying the picture based on what is
actually being displayed. The information flowing to and from the main
PROCESS is the sort which is passed or received as parameters to
procedures. The INPUT and OUTPUT routines translate to and from
respectively a network standard graphics protocol which is sent out over
the net to the INPUT and OUTPUT display drivers whose responsibility it
is to translate the standard message into the appropriate byte stream to
drive the DISPLAY or translate the attention from the DISPLAY into a
network standard message. The DISPLAY is assumed to handle its own
refreshing if it requires any, so that there will be as little apparent
difference between refreshed and non-refreshed displays as is possible.

PROCESSからDISPLAYまで絵のビルと操作のための情報を描いています。 DISPLAYからPROCESSまで流れる情報は注意情報です。 主なPROCESSに関連しているGraphic Data基地は絵がPROCESSによって描くことにされるのであるか、または絵がローカル処理で描くことにされるのであるとき組み立てられるそれです、そして、注意メッセージは絵に何をしたかをPROCESSに言います。 このデータベースは、PROCESSが望んでいるという働いている詳しい情報を含む必要はなくて、絵の相互作用が全く完了していないつもりであるなら、事実上、何でも含む必要はありません。 DISPLAYドライバーに関連しているGraphic Data基地は、OUTPUTドライバーが主なPROCESSがこれができるのが必要であることのないDISPLAYと何が実際に表示されているかに基づく絵を変更するとき使用するINPUTドライバーのためにこころづくしを扱うことができるように、自分たちで造られます。 PROCESSと、そして、主なPROCESSから流れる情報はパラメタとして手順に通過されるか、または受け取られる種類です。 INPUTとOUTPUTルーチンはネットワークとそれぞれ標準のグラフィックスが議定書の中で述べるネットワークから翻訳されます(それがある責任がDISPLAYからネットワークの標準のメッセージにDISPLAYを運転するか、または注意を翻訳するために標準のメッセージを適切なバイト・ストリームに翻訳するINPUTとOUTPUTディスプレイドライバへのネットの上に出されます)。 DISPLAYは壮快で非壮快な表示の間には、見かけの違いが同じくらいほとんどないようにいずれかも必要とするならそれ自身が可能であるようにリフレッシュするハンドルに想定されます。

        This model provides for both simplicity of use for those doing
simple things and power which is needed for those doing sophisticated
interactive graphics. It can be used with a minimum of effort and
overhead by setting runtime conditions to indicate that no interactive
graphics will be done and all associated processing should be skipped,
while still enabling other PROCESSes to do high powered graphics without
going to a completely different set of routines and rules.

このモデルは簡単なことをするそれらにおいて、役に立つ簡単さと精巧な対話的なグラフィックスをするそれらに必要であるパワーの両方に備えます。 最小努力とオーバーヘッドと共にインタラクティブグラフィックスを全くしないのを示すランタイム条件を出すことによって、それを使用できます、そして、他のPROCESSesが完全に異なったセットのルーチンと規則に行かないで高い動力付きのグラフィックスをするのをまだ可能にしている間、すべての関連処理がサボられるべきです。

        Due to the existence of two separate data bases, which must be
kept up-to-date with each other there are two modes of operating this
model. For lack of better names let us call them PROGRAM graphics and
LOCAL graphics. The former indicates that the picture being displayed is
constructed by the main PROCESS and all input from the user at the
display is solicited, thus the DISPLAY data base is only updated after
and as a result of action by the main PROCESS. The latter indicates that
the user at the display is directing the construction of a picture by
means of function buttons and drawing tools, the DISPLAY data base is
updated immediately and the main PROCESS is notified of the change so
that it may keep up, but it does not perform manipulations of the
picture unless requested to do so by the DISPLAY OUTPUT driver; this can
be as a result of a request to perform some function that the DISPLAY
INPUT/OUTPUT drivers can do by themselves or a request by the user to
have the main PROCESS perform a non-standard function on the picture.

2つの別々のデータベースの存在のために、このモデルを手術する2つのモードがあります。(互いに最新にデータベースを保たなければなりません)。 より良い名前の不足によって、それらをPROGRAMグラフィックスとLOCALグラフィックスと呼びましょう。 前者は動作の後と主なPROCESSによる動作の結果、主なPROCESSが表示される絵を構成して、表示におけるユーザからのすべての入力に請求して、その結果、DISPLAYデータベースをアップデートするだけであるのを示します。 後者が、表示におけるユーザがファンクション・ボタンと描画ツールによって絵の工事を指示しているのを示して、すぐに、DISPLAYデータベースをアップデートして、変化について主なPROCESSに通知するので、維持するかもしれませんが、DISPLAY OUTPUTドライバーでそうするよう要求されない場合、絵の操作を実行しません。 これはDISPLAY INPUT/OUTPUTドライバーが自分たちでできる何らかの機能が実行するという要求かユーザによる主なPROCESSに標準的でない機能を絵に実行させるという要求の結果、あることができます。

                                   5

5

RFC 285  NIC 8271

RFC285NIC8271

        The main purpose of this design is to allow greatest generality
of graphic configurations rather than minimum response time. The design
for an optimum requires more exact specification of the hardware
configuration and the proposed usage. Since neither of these variables
can be known, and in fact our attempt at generality keeps us from even
guessing very closely at them, we must provide intelligent INPUT/OUTPUT
drivers that will know how to split the processing load between
themselves and the main PROCESS as a function of what kind of DISPLAY
they are driving, rather than attempting to design in an optimum
breakpoint.

このデザインの主な目的は最小の応答時間よりむしろグラフィック構成の最大級の一般性を許容することです。 最適条件のためのデザインはハードウェア・コンフィギュレーションと提案された用法の、より正確な仕様を必要とします。 これらの変数のどちらも知ることができないで、事実上、一般性への私たちの試みによって非常に密接にそれらを推測さえできないので、私たちは最適な区切り点で設計する試みよりむしろ彼らがどういうDISPLAYを運転するかに関する機能として処理負荷を分ける方法を知っている知的なINPUT/OUTPUTドライバーを自分たちと主なPROCESSの間に供給しなければなりません。

        The Graphics Protocol should specify the format of the messages
which are transmitted between the INPUT and OUTPUT routines and drivers.
These messages can be divided as previously mentioned according to their
direction and content, i.e. drawing messages and attention messages.
Since it is often desired to intermix graphics and text there should be
a distinguishing message header for all graphics messages. Then a byte
to specify the type of information contained in the body of the message,
a count of the bytes in the body, and finally the body itself. Virtually
all of the necessary message types have been indicated in the previous
RFCs and I will not list them here, except to note that attentions now
include requests for processing that the drivers could not do.

GraphicsプロトコルはINPUTと、OUTPUTルーチンとドライバーの間に送られるメッセージの形式を指定するべきです。 それらの指示、満足していて、すなわち、描いているメッセージ、および注意メッセージに従って以前に言及されるようにこれらのメッセージを分割できます。 以来、グラフィックスを混ぜるのがしばしば必要であり、そこのテキストはすべてのグラフィックスメッセージのための区別しているメッセージヘッダーであるべきです。 次に、メッセージ欄に含まれた情報の種類を指定するバイト、ボディーでのバイトのカウント、および最終的にボディー自体。 必要なメッセージタイプのほとんどすべてが前のRFCsで示されました、そして、私はここに彼らを記載するつもりではありません、こころづくしが現在ドライバーができなかった処理が要求を含んでいることに注意するのを除いて。

        To summarize, I believe that a simple model is enough to enable
the design of both sophisticated interactive graphics and low effort
non-interactive graphics. The primary reason for this is that our major
interest is not minimum response, but rather maximum configuration
mixes. There are opportunities to use software sharing and data
reconfiguration services when building INPUT/OUTPUT routines and
drivers. Much detailed work remains to be done, but with a basic model
in sight providing a framework to hang proposed ideas on for evaluation,
work should be able to proceed more smoothly.

まとめるために信じている、私は、単純モデルが精巧な対話的なグラフィックスと低い努力非対話的なグラフィックスの両方のデザインを可能にするために十分であると信じています。 この第一の理由は私たちの主要な利益のためが最小の応答ではなく、かなり最大の構成ミックスであるということです。 INPUT/OUTPUTルーチンとドライバーを組み込むとき、ソフトウェア共有を使用する機会とデータ再構成サービスがあります。 多くの詳細な仕事がするために残っていますが、評価のために提案された考えに掛かるように枠組みを提供する基本型が見えていて、仕事は、よりスムーズに続くことができるべきです。

                                   6

6

RFC 285  NIC 8271

RFC285NIC8271

         +---------+                  +--------+
         ! INPUT   !                  ! OUTPUT !
      +--! routine !<------||---------! driver !<--+
      !  +---------+                  +--------+   !
      !                                   ^        !
      V                                   !        !
 +---------+---------+      +---------+   !   +---------+
 !         ! Graphic !      ! Graphic !   !   !         !
 ! PROCESS ! Data    !      ! Data    !<->!   ! DISPLAY !
 !         ! Base    !      ! Base    !   !   !         !
 +---------+---------+      +---------+   !   +---------+
      !                                   !        ^
      !                                   V        !
      !  +---------+                  +--------+   !
      !  ! OUTPUT  !                  ! INPUT  !   !
      +->! routine !-------||-------->! driver !---+
         +---------+                  +--------+

+---------+ +--------+! INPUT!OUTPUT+!--ルーチン!<。------||---------! ドライバー!<--+ +---------+ +--------+ ^!V+!---------+---------+ +---------+ ! +---------+! グラフィック!グラフィック!過程!データ!データ!<->!基地!の基地+!を表示してください。---------+---------+ +---------+ ! +---------+ ^!V+!---------+ +--------+ OUTPUT!INPUT!+->!ルーチン!-------||-------->! ドライバー!---+ +---------+ +--------+

                         Figure 1

図1

       [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Ian Redfern 4/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][イアンRedfern4/99によるオンラインRFCアーカイブへの]

                                   7

7