JPH08115413A - グラフィカルプログラミング言語の解釈方法 - Google Patents

Abstract

(57)【要約】 【課題】グラフィカルプログラミング言語で定義された
プログラムの解釈を通して、画像生成のより進歩した形
態を提供する。 【解決手段】グラフィカルプログラミング言語で定義さ
れるプログラムは以下のようにして解釈される。即ち、
グラフィック要素の組合わせ又は描画を含む記述列が分
析され、実行される。ここで、該組合わせ又は描画の効
果は遅延される。そして、グラフィック要素の組合わせ
又は表現は、エクスプレッションツリー６７のノードへ
変換される。ここで、各ノードの子孫は遅延されたグラ
フィック要素の組合わせ又は描画のオペランドであり、
ノード６９はクリッピングリスト７０に格納された境界
でクリップされるようにマークされる。このようなクリ
ップリスト７０の利用により、７２に示すようなコンパ
イル結果が得られ、通常のOUT,IN命令を用いた場合に比
べて実行時間を短縮できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、静止画像とビデオ
画像の両方の形態をしたコンピュータ生成画像の作成に
関し、更に詳しくは、多数のサブコンポーネントから作
られた画像の作成における合成方法に関する。

【０００２】

【従来の技術】コンピュータ生成画像は、典型的には多
数の異なる構成要素、つまり、「合成」、即ち最終画像
を作成するために寄せ集めて描画されたグラフィック要
素により構成されている。画像は、構成要素が独立して
描画されるように、構成要素に分けられているため、小
さい画像部分を使用することによって潜在的にかなりの
時間が節約されている。それぞれの成分やオブジェクト
は、特有のマット（matte）情報、つまり、一般的には
成分の形状や透明性を示すカバレージ情報を含む「アル
ファチャンネル」情報に関係してきた。マット情報、つ
まりアルファチャンネル情報は、通常、それぞれの画素
について別々に記憶されている。更に、それぞれの画素
は、それぞれの画素の色成分（たとえば、赤、緑、青
（RGB））を記憶する。従って、成分のそれぞれの画素
は（R, G, B, α）の４成分によって表すことができ
る。ここで、αは成分の透明度を表しており、一般に
「アルファ」、つまり不透明チャンネルとして知られて
いる。例えば、黒が、RGB色成分（０，０，０）により
表現されるとすると、黒色は（０，０，０，１）の４成
分によって表現することができ、また、透明、つまり完
全に透けてみえる色は（０，０，０，０）の４成分で表
現することができる。

【０００３】また、色成分をその不透明度で「前もって
掛けておく」ことも、場合によっては効果がある。この
場合、色（R,G,B）は（R,G,B）によって表現される。

【０００４】図１から図３に画像合成の簡単な例を示
す。図１は、円の端として定義される輪郭を持つ円形の
グラフィック要素１の例を示す。円の内側は特定の色又
はバリエーションで定義される。円の境界線の外側部分
３は無限に続いているものとし、０アルファ値を取る
（つまり、見えない）ものと定義する。図２は、図１の
円１の色と異なる色５をした第２の円４を示す。図３
は、図１及び図２の円１及び円４をそれぞれ１ページ上
にコピーして合成して作られた、より複雑な画像６の例
を示す。円が重なる部分７は、２つの円１と円４が組合
わさった部分と定義し、より複雑な画像６を作成するた
めに２つの円を組合わせる合成演算子によって決まる色
値を取る。

【０００５】トーマス・ポーターとトム・ダフは、１９
８４年７月刊行のComputer graphicsのVol.１８、 No.
３の２５３〜２５９ページに掲載された「デジタル画像
の合成（Compositing Digital Images）」と題する記事
において、「超要素（super-elements）」を形成するた
めの要素を取りまとめて合成する方法を発表している。
ポーターとダフは、「α」チャンネルを持つ２つの画像
を合成する方法についての検討もしている。単一画像の
２つの部分を組合わせるには、主に１３の合成演算があ
る。これらの合成演算は下記の表１に示されている。こ
の表において、Dcは予め掛けられた目的色、つまり結果
として生じる色であり、Doは目的値、つまり結果として
生じるαチャンネル値であり、Acは第１のソースAの第
１部分の予め掛けられた画素色であり、Aoは色がAcであ
る画素に対応するα値であり、Bcは第２のソースBの部
分画像の予め掛けられた画素色値であり、そして、Boは
ソースBの、Bcに対応する画素のαチャンネル値であ
る。

【０００６】

【表１】

【０００７】異なる演算子を利用して２つの異なる画像
を組合わせる多種類の方法が表１に示されている。上記
以外の演算子を利用することも可能である。上記以外の
演算子は主に特殊効果を実行するために使用することも
できる。

【０００８】「pulsW」演算子の「包み込む」性質と
は、例えばAc + Bcの和が色成分の最大値より大きい場
合に、その色空間で最小値を参照しながら始めからやり
直すように値が「包み込まれる」ものである。また、
「plusC」演算子に使用される「クランピング」処理
は、例えばAc + Bcの和が色成分最大値より大きい場合
に、その和を色成分最大値にクランプする動作を含む。

【０００９】図４は、２つの完全に不透明な円Aと円Bを
表１に示す様々な演算子を用いて合成して得られた、様
々な最終画像の例を示している。なお、演算子「rove
r」と、「rin」と、「rout」と、「ratop」とはオペラ
ンドを交換して「r」（逆（reverse））演算子にしたも
ので、それぞれ対応する「over」と、「in」と、「ou
t」と、「atop」演算子に対して行われたものである。

【００１０】近年、POSTSCRIPT（商標）等のページ記述
言語の形式によるグラフィックス言語が開発されてい
る。これらの言語は比較的複雑なプログラミング言語に
完全な機能性を提供するものであるため、反復概念や、
制御の流れや、画像成分の一連の処理の定義を用いるこ
とによって、複雑な画像をコンパクトに表現することを
可能にした。これらのページ記述言語は、アプリケーシ
ョンの作者がプリンターの機種に付随するどのような詳
細な制約にも束縛されないようにするために開発された
もので、プログラムの移植性向上に役立っている。ま
た、これらの言語により、テキストや、スプラインを基
本としたグラフィカルオブジェクトや、サンプルされた
画像の拡張補助を行なうことができる。従って、この言
語のインタープリタを製造し、例えば印刷機器に備える
こともでき、そうすることによって簡潔に複雑な画像を
表示することができる。言語の解釈は機器に従属するた
めに、このようにページ記述言語は１つの出力機器から
他の出力機器への移植性を助長する。POSTSCRIPTなどの
言語は元来、ビットマップページまたはスクリーンの見
え方を表し、ビットマップ画像上に不透明な画材で作画
する概念に基づくグラフィックの原点を利用するために
創られたものであった。

【００１１】ほとんどのプログラミング言語に見られる
ように、ページ記述言語はしばしばオペランドと、新し
い結果や効果を産み出すためにオペランドに作用する演
算子とによって構成されている。オペランドは、線や、
弧や、曲線や、線やスプラインの集合や、テキスト列
や、サンプルされた画像などの基本的でグラフィカルな
ものを含むこともあり、演算子によって操作されるよう
に設計されている。演算子は下記を含む数多くの異なる
カテゴリーに分類されている。

【００１２】１． 多種のオペランドやグローバルステ
ータス（gloval status）の変数の現在の属性を決定す
る演算子、 ２． 基本的存在物が定義される様々な座標系を変更す
る演算子、 ３． 多種の経路を定義するためにある基本的存在物を
更新することによって、複雑なオブジェクトの構成を可
能にする経路演算子、 ４． 出力されたページに現れる個々のドットの色を最
終的に決定する画像データを生成する、多種の「描画」
演算子、 ５． 特殊クラスの演算子は、通常、テキストやフォン
トを特定したり、更新したり、選択したりするために使
用される。これは、準備されて定常的に使用される文字
フォントの特殊な性質によるものである、 ６． プリンタやスクリーンなどの表示装置への画像の
出力を制御する為に使用される、様々な機器セットアッ
プ及び出力演算子。

【００１３】

【発明が解決しようとする課題】残念ながら、POSTSCRI
PT等の言語は、フレームバッファ等の上に不透明な画材
で描画を行う「機器のモデル」に左右される。フレーム
バッファの利用は膨大な記憶量を必要とし、また、現代
における画像技術は高画質の出力を要求するため、画像
を作成するためには膨大な記憶量と計算量とを必要とす
ることになる。更に、作画技術を利用するに当たっての
不効率性は、出力解像度の向上に伴い一層悪化してい
る。

【００１４】本発明は上記従来例に鑑みてなされたもの
で、グラフィカルプログラミング言語で定義されたプロ
グラムの解釈を通して、画像生成のより進歩した形態を
提供することを目的とする。

【００１５】

【課題を解決するための手段】上記目的を達成するため
に本発明のグラフィカルプログラミング言語で定義され
たプログラムの解釈方法は、以下の様な構成からなる。
即ち、グラフィカルプログラミング言語で定義されるプ
ログラムを解釈する方法であって、グラフィック要素の
組合わせ又は描画を含む記述列を分析し、実行する工程
と、該組合わせ又は描画の効果は遅延され、前記グラフ
ィック要素の組合わせ又は表現をエクスプレッションツ
リーのノードへ変換する工程とを備え、該ノードの子孫
は遅延されたグラフィック要素の組合わせ又は描画のオ
ペランドであり、また、ノードは遅延された演算を持つ
ものとしてマークされることを特徴とする。

【００１６】

【発明の実施の形態】以下添付図面を参照して本発明の
実施の形態を詳細に説明する。

【００１７】発明の実施の形態において、基本となるグ
ラフィック要素は下記の「基本的なタイプ」から構成さ
れる。即ち、 １． 様々なサイズで詳細に記された、様々なフォント
を含むテキスト、 ２． 経路としても知られるスプラインデータにより定
義される輪郭を持つオブジェクト、 ３． 走査された画像、またはグラフィック要素を形成
する過去に作られた画像などの画素データ、 ４． ページの背景として使用され、少なくとも生成さ
れる画像と同じ大きさである「オール（all）」として
知られるグラフィック要素、である。

【００１８】また、色及びテキストグラフィック要素は
下記項目を含む属性を持つ。即ち、（a） 色、濃淡の
ない色であるか、２色の混合色であるか、または画素単
位を繰り返したタイルであるか、（b） 色データと同
じくバリエーションの選択が可能である透明度、つま
り、αチャンネルデータ、（c） 経路又はテキストグ
ラフィック要素の描画を制御する塗りつぶし及び／又は
ストロークデータ。「グラフィカルコンテキスト」はそ
れぞれのグラフィック要素に関係する属性値を与える。
新しい要素が作成されたとき、作成時のグラフィカルコ
ンテキストにおける属性値は、新しいグラフィック要素
に適用される。

【００１９】従って、プログラミング言語自身は、下記
のデータ形式を含む。即ち、 １． フォントと、大きさと、位置と、他の望ましい特
徴を定義するテキストオブジェクトで、テキストの色
や、透明度や、塗りつぶし又はストロークパラメーター
は定義しない、 ２． 特定のオブジェクト形状の輪郭を定義する経路オ
ブジェクトであって、その色や、透明度や、塗りつぶし
又はストロークパラメーターは定義しない、 ３． 画素データや、「オール」グラフィック要素や、
グラフィック要素や、グラフィック要素を生産する為に
いくつかの合成演算子による多数の他のグラフィック要
素を集めた合成処理を表現するグラフィック要素、又は
テキストオブジェクト、又は対応する画素形式で描画さ
れる経路オブジェクト。

【００２０】画像合成は、画像をオペランドとして取
り、画像を結果として生成する二項演算子１組を提供す
る。グラフィック要素の色情報は時折使用されない場合
もあるが、画像は、それぞれすべての画素毎に色及び
α、つまり透明度チャンネル情報を持つように定義され
る。全てのタイプのグラフィック要素を組合わせ又は合
成できるようにするために、テキストと、経路と、「オ
ール」のグラフィック要素とを含む全てのグラフィック
要素が、それらが合成される前に画素画像へと走査変換
されたように扱われる。加えて、グラフィック要素は、
オペランドを形成するときに通常概念的に無限に広がる
ものとして取り扱われる。グラフィック要素の境界の外
側の画素は完全に透明であるものとして扱われる。それ
ぞれのグラフィック要素の拡張は、一画素が一オペラン
ドの通常の拡張範囲内にあって、他のオペランドの範囲
にない場合に、結果を定義することができるように実行
される。更に、いくつかの特殊な演算子は色がいつも定
義されていることを要件とするため、完全に透明な画素
は描画色空間において０成分として表現される色を取
る。

【００２１】発明の実施の形態における描画言語は、通
常のコンピューター言語と同様に多数の異なる方法で
「実行」される。コンピュータ言語は通常、対応するコ
ンピュータによって「解釈」又は「コンパイル」手段を
介して「実行」され、これらの手段はコンピュータ言語
コンパイラライティングの技術の当業者にとって公知で
ある。

【００２２】インタープリタ及びコンパイラは通常言語
を定義し、コンテクストの無い、文法から構成されてい
る言語記述の為の分析木、つまりエクスプレッションツ
リーを構成する。インタープリタ及びコンパイラの更な
る説明については、標準的テキストである１９８６年に
Addison-Wesley Publishing Company, Reading, massac
husettsから出版されているアホ、セシ、及びウルマン
の共著の「Compilers Principles, Techniques, and To
ols」を参照するとよい。

【００２３】本実施の形態においては、プログラミング
言語で書かれたプログラムの実行は、実行速度、大き
さ、実行し易さのためにインタープリタにより行われ
る。

【００２４】プログラミング言語のそれぞれの文につい
ては、インタープリタは文を分析し、実行可能な形式の
文に変換する。そして、この実行可能な形式のものが実
行される。この実行可能な形式の文が実行されている間
に、グラフィック要素に対して演算が実行される。これ
らを行うために、即時実行や遅延実行等を含む多数の異
なる技術を利用することが可能である。

【００２５】［即時実行］グラフィック要素に応用され
るそれぞれの演算については、結果として得られる画素
画像を保存するのに充分なラスター記憶が作られ、その
演算は、オペランドを合成して出力ラスター画像領域の
画素データを生成するために使用される。このラスター
画像領域は演算の結果であるグラフィック要素となる。
描画演算が実行されると、望ましいグラフィック要素の
ラスター画素が出力装置に送信される。

【００２６】この技術は、多くの中間グラフィック要素
がプログラムの実行中に使用された場合に、大容量の記
憶装置を必要とするという欠点がある。また、グラフィ
ック要素の次の使用に関する情報がその計算時又は生成
時に提供されないため、以降の最適化が殆どできないと
いう欠点がある。

【００２７】図４から図６を参照しながら、即時実行モ
デルに関わるインタープリタの演算例を示す。下記の様
な命令列の例を仮定する。即ち、

【００２８】

【表２】

【００２９】発明の実施の形態にかかるプログラミング
言語において、上記の「A = B」の表現はAの値にBの値
を割り当てることを示す。また、「A: = B」の表現は
「A =A rover B」の表現を短縮したもので、「A rover
B」は「B over A」と同じ結果を導く。

【００３０】「text」関数は、発明の実施の形態におい
て上記に示すように、色情報や透明度情報を持たず、文
字情報と、フォント情報と、サイズ情報と、位置情報の
みを持つテキストオブジェクトを生成する。しかし、A:
= text ("a") の文は「A =A rover text ("a")」と同
じである。演算子「rover」をテキストオペランドに対
して実施するときは、テキストオペランドは先ずグラフ
ィック要素に変換される。この変換は、属性を決定する
ようにテキストを観念的に描画することによって行われ
る。「text」を呼び出す関数を実行するに当たり、現在
点は、描画されたグラフィック要素のテキスト列の結果
として得られる幅だけ動かされる。図５は第１命令完了
後の対応するエクスプレッションツリーである。

【００３１】表２の第１命令（１）は、文字「a」に対
応するグラフィック要素をAの値として割り当てること
である。この割り当て結果は図１０に示されている。

【００３２】インタープリタによって実行される第２命
令は文字「a」の隣の文字「b」に対応するグラフィック
要素の描画を意味する。この命令の実行後の結果のエク
スプレッションツリーは図６に示すとおりであり、Aの
値の状態は図１１に示すとおりである。

【００３３】命令３は既に描画された文字のとなりの文
字「c」に対応するグラフィック要素の描画を意味す
る。一連の命令（１）から（３）に対応するエクスプレ
ッションツリーを図７に示し、Aの値の状態は図１２に
示す。

【００３４】命令４は円を含むグラフィック要素を作成
し、値Bによって定義されるグラフィック要素に生成し
たグラフィック要素を割り当てる。この命令に対応する
エクスプレッションツリーを図８に示し、値Bの状態を
図１３に示す。

【００３５】命令５はグラフィック要素Bをグラフィッ
ク要素Aで定義されるグラフィック要素の上に合成する
動作を含む。図９は、命令５を実行した後のグラフィッ
ク要素Aの結果として得られるエクスプレッションツリ
ーを表している。部分１０はAの過去のエクスプレッシ
ョンツリーである図７のエクスプレッションツリーを表
し、命令５の右辺に現われている。図１４は、即時実行
方法が使用されたときの値Aに対応する状態を示す図で
ある。

【００３６】［遅延実行］コンパイラの実行に対する第
２のアプローチは、遅延実行モデルである。このモデル
において、プログラム文形態であるグラフィック要素に
対して行うそれぞれの演算について、その演算を表すエ
クスプレッションツリーのノードが作成される。作成さ
れたエクスプレッションツリーのノードは演算、または
演算子を記録し、そのエクスプレッションツリーのノー
ドの子は演算のオペランドである。そして、エクスプレ
ッションツリーのノードは演算の結果であるグラフィッ
ク要素となる。１つ以上の命令が実行されると、前の演
算によって作られたエクスプレッションツリーは、時
折、図５から図９に示されるような方法で更に複雑なエ
クスプレッションツリーを創る演算と更に組み合わされ
る。

【００３７】続いて描画演算が実行されると、希望する
エクスプレッションツリーは、繰返して横断（travers
e）され、希望する画像を作るために希望する演算が実
行され、得られた画像は出力機器に送られる。

【００３８】この技術は、グラフィック要素の後の使用
についての情報が分かるまで、描画演算が延期され、生
成されるという点において有効である。従って、プログ
ラムの実行が終了するまでグラフィック要素のラスタ画
素を記憶するメモリを割り当てる必要がなく、グラフィ
ック要素の後の使用を考慮した最適化を行なうことがで
きる。

【００３９】次の２つのアプローチが、インタープリタ
の実施で使用することができる。

【００４０】１．「ポストフィックス（postfix）」、
つまり「スタックベース」のアプローチであって、グラ
フィック要素はスタック上の成分に対して実行されるオ
ペランド及び演算子として、合成スタック上にプッシュ
される。従って、二項演算子は先頭から２つのスタック
登録項目を合成して、得られた結果を元のスタックへ戻
すことによって、それらを削除することができる。入力
されたページ記述の全ての命令が終了すると、スタック
の先頭が出力機器で描画される。

【００４１】２．「挿入辞（infix）」、つまり「表現
ベース」のアプローチであって、元来のグラフィック要
素は直接演算されるか、変数中に記憶される。演算子は
この元来のグラフィック要素、既に変数中に記憶されて
いるグラフィック要素、あるいは準表現（subexpressio
ns）を組合わせることによって、変数中に記憶される
か、更に他の演算子によって組合わせることのできる新
しいグラフィック要素が作成される。「ページ」等のあ
らかじめ決められた変数を割り当てられたグラフィック
要素は、出力機器にて描画され得る。

【００４２】上記２つのアプローチの違いはプッシュダ
ウンオートマトンとチューリングマシンのそれぞれのパ
ワーの違いに類似している。

【００４３】インタープリタの好適な実行として、第２
の遅延実行モデルが利用される。そして、 １． グラフィカル演算が延期されて、エクスプレッシ
ョンツリーが作られる、 ２． 「挿入辞」アプローチがエクスプレッションツリ
ーの実行のために使用される、 ３． 経路輪郭をもつ全てのオブジェクトと、文字と、
画像とが、無限に続く画素画像によって構成される基礎
グラフィック要素へと先ず概念的に変換される。 そして、二項及び単項演算子の両方を含む表１で定義さ
れる演算子を利用して、合成が行われる。

【００４４】一旦画像のためのエクスプレッションツリ
ーが生成されると、画像は適切な出力機器で「描画」さ
れる準備が整う。出力機器のグラフィック要素を表す
「ページ」などの予め定められた変数を利用し、この変
数に対応するエクスプレッションツリーを描画すること
によって、出力画像が描画される。出力機器が１走査線
毎に出力画像を受け付けるとすると、以下のような多数
の異なる描画技術が可能である。

【００４５】１． それぞれの走査線毎に、出力された
変数の為のエクスプレッションツリーは横断され、それ
ぞれのグラフィック要素の描画と演算子の合成はその走
査線について適切であるように行われる。

【００４６】２． 走査線毎の二分木横断はコンピュー
タ時間の観点からすると時間のかかる工程であることを
認知することによって、線形描画リストがエクスプレッ
ションツリーから先ず生成される。続いて、それぞれの
走査線について、それぞれのグラフィック要素は要求通
りに描画され、それぞれの合成演算子はその走査線につ
いて適切であるように実行される。この実行形態は、エ
クスプレッションツリーの評価された準部分に相当する
中間結果をスタックが保持することを必要とする。

【００４７】３． 走査線毎の線形描画リストを全て走
査することは非効率であることを認知することで、ある
特定のグラフィック要素の走査線から線形描画リストの
ソートが始められる。それぞれの走査線を描画する時
に、現在描画されるべき走査線に影響を与える線形描画
リストのグラフィック要素全てを含むように、アクティ
ブリストがメインテナンスされる。それぞれの走査線の
始めでは、その走査線を開始する命令はアクティブリス
ト中に併合され、既に適切でない命令はアクティブリス
トから除かれる。これは当業者にとって公知の表示リス
ト命令のアクティブリストのメインテナンス技術と類似
している。

【００４８】上記第３のアプローチの概念が一度理解さ
れると、この概念の解釈を助けるために、ページ記述プ
ログラミング言語文の解釈はコンパイラによって行われ
る演算に擬せられる。元々のエクスプレッションツリー
はコンパイラの分類木に擬することができ、描画リスト
の生成はコンパイラのコード生成フェーズに擬すること
ができ、分類木から作成される線形描画リストは組立命
令又はいくつかのコンパイラで利用される中間コードに
擬することができ、そして線形描画リスト描画はコンピ
ュータによる組立言語命令の実行に擬することができ
る。

【００４９】ページ記述言語命令のある特定の集合に対
するエクスプレッションツリーは、ページ記述中に含ま
れる文を実行することによりインタープリタによって構
築される。このページ記述中に含まれる文は、Ｃ、Pasc
al、Algol等の現代のプログラミング言語に於て提供さ
れる、「while」ループや、条件文や、他の通常の構造
を含み、これらはプログラミング言語の一部を形成する
と見做される。ある特定の変数に記憶されたどのエクス
プレッションツリーも、ページ記述内又はページ記述言
語プログラム中の後続のページのページ記述内で再利用
することができ、どのエクスプレッションツリーも外部
又はユーザーの視点から更新されていない状態で残して
おくのが非常に望ましい。しかし、一度インタープリタ
がエクスプレッションツリーの構成を終了すると、エク
スプレッションツリーの構成を並べ変える可能性のある
コンパイラ形態の最適化が可能である。従って、表現処
理の一端としてこれらの最適化を可能にするためにツリ
ー中で２組のポインタが使用される。これらのポインタ
は、ユーザーポインタと、ワーキングポインタと呼ばれ
る。インタープリタが初めにページレイアウトプログラ
ム記述からエクスプレッションツリーを構成するとき、
ユーザーポインタが利用される。ページレイアウトを表
現するエクスプレッションツリーが描画の為に後で処理
されるとき、ワーキングポインタが使用され、ユーザー
セットポインタはそのまま残される。

【００５０】エクスプレッションツリーの構成が完成す
ると、描画リスト生成処理が開始される。この描画処理
は、エクスプレッションツリーに対して多数の最適化工
程を実施することによって開始される。これらの工程
は、描画リスト生成処理を説明した後に説明する。

【００５１】描画リスト生成処理は、通常のコンパイラ
によって実行される組立コード又は中間コード生成に類
似している。描画リストの項目は、グラフィック要素を
合成する命令や、又はその他の行動を実行させる命令と
考えることができる。

【００５２】描画リスト生成へのアプローチは２通りあ
る。１つはハードウエア補助の描画装置に、より適する
ものであり、他方は「ソフトウエアのみ」による実施に
適している。これらのアプローチは共に、将来実施する
合成のために最新の合成演算結果を保存するための描画
スタックを使用しなければならない。このソフトウエア
指向のアプローチは、グラフィック要素をスタックへプ
ッシュする命令か、またはスタック上のオペランドに対
して演算を行う命令のどちらかに従って、描画スタック
を用いるとうまく作動する。ハードウエア補助のアプロ
ーチは「アキュムレータ」の利用を前提とする。命令
は、アキュムレータへグラフィック要素をロードする
か、またはグラフィック要素を合成し、アキュムレータ
の内容を描画スタックへプッシュするか、スタックから
ポップした成分をアキュムレータへ合成する。

【００５３】勿論、もし指示された非周期的なグラフが
許可されるとすると、描画スタック自身では不十分であ
り、共通の準表現を記憶するために一時記憶空間を追加
することが必要となる。

【００５４】ハードウエア補助の「アキュムレータ」ア
プローチについては、「命令集合」が表３に示すとおり
に実施される。

【００５５】

【表３】

【００５６】表３において、「acc」はアキュムレータ
（accumulator）を指し、「M」は希望する色変換関数を
指す。

【００５７】変数Aはあらかじめ定義されたどのグラフ
ィック要素または、スタックの先頭にあるグラフィック
要素をポップさせるオペランド「pop」でもよく、それ
を命令のオペランドとして使用してもよい。

【００５８】上記全ての命令は、バウンディングボック
スを与えられ、その内部で演算が行われる。

【００５９】ハードウエアのために設計された累算ベー
スのアプローチとソフトウエアのために設計されたスタ
ックベースのアプローチの対応は、下記のとおりであ
る。 １． 「clear」及び「load」命令は、「clear」命令が
最適化されたとき以外は、片方が他方の後に実施され
る。それらは不透明度０の領域に囲まれたスタック上に
オペランドをプッシュすることに対応する。従って、
「clear」命令は続けてロードするものがないときはそ
れだけを送る。 ２． 「push」命令は飛ばしてもよい。 ３． 「over」命令などの命令に対して行われるオペラ
ンド「pop」は、スタックの先頭から２つの成分を合成
し、結果の合成成分をスタックに残すことを意味する。 ４． グラフィック要素であるオペランド「A」は、グ
ラフィック要素Aをスタックへプッシュし、スタックの
先頭から２つの成分を合成し、結果の合成成分をスタッ
クの先頭に残すことを意味する。

【００６０】エクスプレッションシンタックスツリーが
描画リストへ変換されるとき、エクスプレッションシン
タックスツリーを介していくつかのパス（passes）が作
られる。これらのパスは以下の仕事を行う。 １． 描画ハードウエア（又はソフトウエア）によって
補佐されない基本事項を表現に拡張する。 ２． 単項最適化を行う。 ３． エクスプレッションツリーのリーフノードと内部
ノードのバウンディングボックスを決定する。 ４． バウンディングボックスの最小化を行う。 ５． クリッピング経路を検出し、クリップノードにラ
ベルをつける。 ６． 最適化を行う。 ７． エクスプレッションツリーを対応する描画命令集
合リストへ変換する。 ８． ソートされた表現命令リストを作成する。

【００６１】上記のパスは分割された見出し毎に、詳し
く説明される。

【００６２】＜１．描画ハードウエア（又はソフトウエ
ア）によって補佐されない基本事項の拡張＞多種類の基
本関数はハードウエア又はソフトウエアの実行によって
補佐されないことが多い。一例として、２つの独立画素
列が１つのオペランドを形成するために組合わせられな
ければいけない、というようなことがある。例えば、も
し色及び不透明さが共に画像の一部を形成し、しかしな
がらそれらが２つの異なる変数からきている場合、ハー
ドウエアは色を表す１つの画素列を、不透明さを表す第
２の画素列として同時に組合わせることができないこと
もある。こういう場合、この状況を表現する基本事項
は、 「色＝A、不透明さ＝B」 である。

【００６３】この基本事項は、この時点で、 「（色＝A、不透明さ＝完全に不透明）in（色＝０、不
透明さ＝B）」 によって置き換えらることができる。

【００６４】＜７．エクスプレッションツリーの、対応
する描画命令集合リストへの変換＞エクスプレッション
ツリーを、対応する描画リスト（パート７）へ変換する
処理は、下記の疑似コードによって記述することができ
る。即ち、 do_node(n) if n is a leaf then produce instruction "load n.operand" else if n is a unary operator then begin do_node(n.operand) produce instruction "cmap n.map" end else begin do_node(n.right) if n.left is a leaf then produce instruction "n.operation n.left.operand" else begin produce instrction "push n.left.bounding-box" produce instruction "clear n.left.bounding-box" do_node(n.left) produce instruction "reverse(n.operation)pop" end end となる。

【００６５】上記の翻訳処理において、 関数「reverse
(n.operation)pop」はパラメータ「n.operation」の逆
の演算を作る。例えば、「rover」は「over」の代わり
に創られ、「over」は「rover」の代わりに作られる。
更に正式には、演算子「op」が与えられているとする
と、「revop」で定義される逆の演算子はA op B = B re
vop Aのような演算子である。

【００６６】上記の翻訳処理はルートノードを飛ばし
て、命令「clear root.bounding-box」を先ず発行する
動作へと移ることによって開始され、そして、ルートノ
ードを主題とするdo_node(root)を呼び出す動作を行
う。

【００６７】更なる最適化の実行として、クリップされ
る形状の「クリッピングスタック」を利用することもで
きる。描画スタック上の中間結果ではないグラフィック
要素の組合わせ動作は、クリッピングスタックの全ての
クリッピング形状の共通部分にクリップされる。これは
描画演算の効率を向上させる。従って、例えば「loadn.
operand」 又は「n.operation n.left-operand」等のグ
ラフィック要素にかかる命令が生成されたときはいつで
も、オペランドがクリップされるべき状態に対応する状
態にクリッピングスタックを置く必要のある「push cli
p」又は「popclip」命令によって行うのがよい。

【００６８】＜３＆４．バウンディングボックスの決定
と、バウンディングボックスの最小化＞上記に於ては、
それぞれのグラフィック要素が観念的に無限に広がるも
のと仮定した。明らかに、２つの無限のグラフィック要
素を合成するためには、無限の時間でないとしても、膨
大な時間がかかる。バウンディングボックスを使用する
技術は、それぞれの合成処理の対象となる画素数を大幅
に減らす為に利用される。バウンディングボックス最小
化処理は、最終画像を作るために必要なそれぞれのグラ
フィック要素の最小領域部分を探すために設計されたも
のである。バウンディングボックス最小化は、合成する
画素数を更に最小化するために、エクスプレッションシ
ンタックスツリーのそれぞれの内部ノードの最小領域を
探す役割をも果たす。更に、バウンディングボックス最
小化は、最終画像に対して寄与しないエクスプレッショ
ンシンタックスツリーのリーフ、または、全ての部分木
を検知する。エクスプレッションツリーによって表現さ
れる、完全にクリップアウトされたピクチャー表現成分
を削除する処理は、「カリング（culling）」と呼ばれ
る。バウンディングボックス最小化処理の結果は、それ
ぞれのノードに、そのノードに対応する画像を作成して
いるときに作画者が必ず塗潰さなければならないバウン
ディングボックスを与える為のものである。反対に、バ
ウンディングボックスは描画スタックへ記憶したり読み
出したりできる唯一の領域であるため、作画者は画像を
作成しているときに、決してバウンディングボックスの
外側を塗ってはならない。

【００６９】つぎに、図１５から図１８を参照にして、
ボックス最小化処理の簡単な例を説明する。図１５は、
例えば下記の文から形成される画像を示す図である。

【００７０】

【表４】

【００７１】この文の集合のエクスプレッションツリー
を図１６に示す。

【００７２】バウンディングボックス最小化は、２つの
パス上で行われる。第１のパスはエクスプレッションツ
リーの深さ優先ポスト順横断である。この第１のパスに
おいて、それぞれのノードの「自然な」バウンディング
ボックスが決定される。リーフでは、これがグラフィッ
ク要素のバウンディングボックスとなる。内部ノードで
は、左右の部分木のバウンディングボックスは現ノード
の合成演算に対応する方法で組合わせられる。この組合
わせを表５に示す。

【００７３】

【表５】

【００７４】つぎに図１７を参照にして、上記の文と図
１６のエクスプレッションツリーに関連させながらこの
処理の例を示す。上記の文で描画される画像の第１の部
分は文字T２０に対応するグラフィック要素である。こ
の描画はページ２１で起こり、あらかじめ定義された空
間、つまりページ２１に置かれる走査変換された部分T
の唯一の部分である「バウンディングボックス」２２の
内部でしか起こらない。つぎの文（７）は、現在のペー
ジ画像を文字E２４に対応するグラフィック要素と組合
わせる。この場合も、この文字はあらかじめ決められた
バウンディングボックス２５を持つ。この２つの文字E
とTはover演算子２６を使用して組合わせられる。従っ
て、over演算子２６のノードと共に記憶されるバウンデ
ィングボックス２７は、２つのバウンディングボックス
２２と２５の組合わせである。バウンディングボックス
最小化ルーチンが深度優先ポスト順のエクスプレッショ
ンツリー横断をするので、与えられたノードの子孫ノー
ドは、現在のノードがビジットされるまえにビジットさ
れ、全てのリーフノードを先にビジットする。それぞれ
のリーフノード２８から３２にとって、描画されるべき
グラフィック要素のバウンディングボックスは図示のと
おりに、先ず計算される。リーフノードのバウンディン
グボックスの計算に続いて、内部ノードのバウンディン
グボックスが計算される。

【００７５】内部ノード２６のバウンディングボックス
２７を計算した後、バウンディングボックス２７と２８
がover演算子を再度用いて組合わせられて３４となる。
同様に、バウンディングボックス３５は、バウンディン
グボックス２９と３４をover演算子３７を用いて組合わ
せて作られたものである。

【００７６】図４に示されるように、２つのグラフィカ
ルオブジェクトAとBがover演算子を用いて組合わせられ
た場合、結果として得られる画像はAがBの上位にあるA
とBの組合わせである。従って、バウンディングボック
スはAとBの組合わせ領域上にまで広がることが要求され
る。「in」演算子を用いたAとBの組合わせは、画像のA
とBがオーバーラップする部分に対してのみ定義され
る。よって、その組み合わせ領域のバウンディングボッ
クスは、AとBの２つのバウンディングボックスの共通部
分である。

【００７７】ノード３９で２つのバウンディングボック
ス３０と３５はin演算子を用いて組合わせられ、その結
果、バウンディングボックス４０は２つの領域３０と３
５の共通部分となる。

【００７８】ノード４１では、２つのバウンディングボ
ックス３１と３２がout演算子を使用して組合わせられ
る。図１７に示すとおり、ノード４１におけるバウンデ
ィングボックス４２はバウンディングボックス３２と同
じものとなる。最後にノード４３において、バウンディ
ングボックス４０と４２がover演算子を用いて組合わせ
られる。ノード４３におけるバウンディングボックス４
４は、２つのバウンディングボックス４０と４２を一体
にしたものである。こうして、バウンディングボックス
判定の第１段階を完了する。図１７から分かるように、
バウンディングボックス処理は、演算子を利用して複合
した結果の領域によって決定される合成されたバウンデ
ィングボックスの大きさを持つ、組合わされた２つのグ
ラフィック要素のバウンディングボックスを決定する処
理を含む。

【００７９】バウンディングボックス最小化の第２段階
つまりパスは、深さ優先プリオーダーのシンタックスエ
クスプレッションツリーの横断を含む。第２のパスで
は、それぞれの内部ノードの子孫のバウンディングボッ
クスが親のバウンディングボックスによって重ねられ
る。新しい子のバウンディングボックスがその子孫のバ
ウンディングボックスへ重ねたり、最小化に使用するこ
とができるように、この処理は繰り返し行われる。つぎ
に図１８を参照して、この処理の例を説明する。図１８
において、図１６と図１７と同じエクスプレッションシ
ンタックスツリーを示す。プレオーダーな横断は、先ず
現在のノード、そしてその左右の子へのビジットを行
う。従って、ノード４３から始めると、バウンディング
ボックス４４はバウンディングボックス４０はノード３
９で重なり、変化は起こらない。バウンディングボック
ス４４はまた、バウンディングボックス４２と重なる
が、変化は起こらない。そして、バウンディングボック
ス４０はリーフノード４５に記憶されているバウンディ
ングボックス３０と重なる。この重なりの結果がバウン
ディングボックス４７である。

【００８０】従って、最終画像で必要とされる画像又は
グラフィック要素の唯一の部分は、古いバウンディング
ボックス３０ではなく、バウンディングボックス４７に
よって定義される部分である。これは、画像４７の部分
が合成処理で必ず使用されなければならない全てのもの
あるであるために、合成時間を実質的に削減することに
なる。同様に、ノード３７では、バウンディングボック
ス４０はバウンディングボックス３５（図１７）と組合
わせられ、削減された大きさのバウンディングボックス
４８となり、結果として実質的な削減となる。そしてバ
ウンディングボックス４８は、ノード５０でバウンディ
ングボックス２９（図１７）と重なる。バウンディング
ボックス領域４８と２９の共通部分は空となり、ノード
５０が最終画像を形成しないことを示す。従って、この
ノード（及び、もしあれば子ノード）はすべてのエクス
プレッションシンタックスツリーから削除することがで
き、結果的に、ツリーを簡素な形態にすることができ
る。

【００８１】そしてバウンディングボックス３４（図１
７）はノード３６でバウンディングボックス４８で区切
られ、削減された大きさのバウンディングボックス５１
を創る。

【００８２】バウンディングボックス４２はノード５２
でバウンディングボックス３２（図１７）と組合わせら
れ、削減は行われない。そして、このバウンディングボ
ックス４２はノード５３でバウンディングボックス３１
（図１７）と重ねられ、以前のバウンディングボックス
３１と比べて削減された大きさのバウンディングボック
ス５４を創る。

【００８３】この処理は最終画像の部分を形成するため
に描画されるべき領域において、できれば実質的な削減
が行われるように、エクスプレッションシンタックスツ
リーのそれぞれのノードについて行われる。更に、バウ
ンディングボックスが空領域に削減された場所は、エク
スプレッションシンタックスツリーのこれらの部分は最
終画像部分を形成しないので、全ての部分木を削除する
ことができる。

【００８４】バウンディングボックスの大きさを更に縮
小するために利用される更なる最適化は、オペランドの
１つが不透明なオブジェクトの下にある時を検知するこ
とである。例えば、そのオペランドが「over」オペラン
ドで、右側のオペランドのバウンディングボックスが完
全又は部分的に左側の不透明なオペランドのバウンディ
ングボックスに覆い隠されているならば、右側オペラン
ドのバウンディングボックスを削減又は削除することが
できる。例として、図３０にバウンディングボックス１
０２を持つオブジェクトA１００とバウンディングボッ
クス１０３を持つオブジェクトB１０１の２つオブジェ
クトを示す。また、図３１にオブジェクトBが部分的に
オブジェクトAの不透明部分に覆われていることを示すA
overBの演算を示す。オブジェクトBの相当の部分はオブ
ジェクトAの不透明部分の影に隠されているので、これ
に対応するバウンディングボックスのオブジェクトAに
よって完全に覆われる部分を削減することができる。こ
のことを図３２に視覚的に示す。図３２において、オブ
ジェクトBの為のバウンディングボックスの一辺１０５
は１０６となり、バウンディングボックスが削減され
る。

【００８５】この処理の実行の簡易な１つの形態は、不
透明で、バウンディングボックス内が完全に塗りつぶさ
れたグラフィック要素Aの為のエクスプレッションツリ
ーのそれぞれのリーフノードを確認することである。こ
の場合、バウンディングボックスBはバウンディングボ
ックスAによって完全に覆い隠されるかどうかによって
削減もしくは削除することができる。

【００８６】＜５．クリップ経路の検出、及びクリップ
ノードのラベリング＞図４から分かるとおり、もし「i
n」又は「out」演算が完全に不透明な右オペランドによ
って行われたとすると、その効果は左のオペランドが右
オペランドの境界線にクリップされた物と同じ効果であ
る。「in」演算では、効果は右オペランドの内側にある
左オペランドの部分を示すことだけであり、「out」オ
ペランドでは、その効果は右オペランドの外側にある左
オペランドの経路を示すことだけである。右オペランド
の境界線が分かっているとすると、これら「in」及び
「out」演算は組合わせではなく、クリッピングによっ
て行われる。

【００８７】この処理の簡単な例を図１９から図２２に
示す。先ず図１９において、実行したい演算は「円中の
四角形」である。ここで、「四角形」とはグラフィック
要素６０を指し、「円」はグラフィック要素６１を指
す。

【００８８】この処理を実行するための通常の組合わせ
方法を図２０に示す。図２０において、円６１に対応す
るグラフィック要素はロードされ画像平面６２上に表さ
れる。続いて、図２１に示すように、画像６２（図２
０）は、グラフィック要素６０からの色データ情報を持
つ円６３を創るための、四角形グラフィック要素に対す
る台紙として使用される。

【００８９】図２２に、図１９の動作を行う更に効果的
な方法を示す。この場合、グラフィック要素６０は、最
終出力６４を作成するために、グラフィック要素６１の
境界線に対してすぐにクリップされる。

【００９０】合成とクリッピングのどちらがコンピュー
タ時間と必要メモリ空間の面でより効果的な方法である
かということは、いつも明らかなわけではない。しかし
ながら、下記の観察は注目するに値するものである。 １． 不透明のグラフィック要素が右オペランドである
ときに、グラフィック要素が「in」演算の左オペランド
として使用されるならば、クリッピングは左側のオペラ
ンドの可視部分の選択と、それらを合成することのみを
含む。反対に合成は、現在の絵を保存したり、右側オペ
ランドのグラフィック要素全体を描画したり、左側オペ
ランド全体を合成したり、記憶された絵を最終的に合成
し直す動作を含む。 ２． 画像をクリッピングすることにより、合成される
べき画素データの量を大幅に削減すると共に、合成処理
以前に生成される画素データの量を減らすことができる
ので、多大な節約がなされる。 ３． クリッピングオブジェクトが非常に複雑であるた
め、クリップされるべきオブジェクトをクリッピングオ
ブジェクトに重ねるための総計算が、削減した合成処理
の利益に値しないときがある。クリッピングオブジェク
トが、小サイズのテキストや、非常に複雑な経路で構成
されているときに、このようなことが起こる。

【００９１】なお、上記の任意のエクスプレッションツ
リーにおけるクリッピングによる最適化の実施におい
て、クリッピング、つまり、完全に不透明な右オペラン
ドの「in」又は「out」、又は、完全に不透明な左オペ
ランドの「rin」又は「rout」は全ての二項合成演算子
に分配される（つまり、これらの演算子が２つの題目を
持っている。）従って、完全に不透明なグラフィック要
素Cが与えられているとすると、全ての二項合成演算子o
pについて、下記の関係が成り立つ。 (a op b) in c = (a in c) op (b in c) 式１ このクリッピング処理は、全ての単成分演算子にも分配
されており、不可視領域を、可視領域にマッピングす
る。この後者の場合が考慮されることはまれで、特殊ケ
ースとして扱われる。

【００９２】クリッピングの例を、図２３と図２４を参
照にして説明する。図２３はエクスプレッションツリー
６５の部分の合成処理の例を示す図である。このエクス
プレッションツリー６５の部分は、対応する機械命令リ
スト６６にコンパイルされる。このリスト６６は現在の
画像をスタック上へプッシュする動作（push）と、不透
明な右側オペランドをアキュムレータへ描画する動作
（load P）と、左側のオペランドを「in」演算子を使用
して合成する動作（in B）と、保存された絵を合成しな
おす動作（rover pop）とを含む。

【００９３】図２４は、右側のオペランドが不透明なオ
ブジェクトである場合に、合成ではなくクリッピングを
する処理を説明する図である。この場合、図２３のエク
スプレッションツリー６５は、例えば６８のような（図
２３）「in」又は「out」演算子を用いて、グラフィッ
ク要素を不透明なグラフィック要素にクリップする場合
を全てロケートするために先ず実施される。それぞれの
場合、これは特殊ノードインディケーター６９によって
置き換えられ、クリッピングオブジェクトの境界線はば
らばらのクリップリスト７０に置かれる。新しいエクス
プレッションツリー６７が完成すると、コード列７２が
結果としてできる。このコード列に於て、クリップリス
ト７０に要素１として記憶された境界Ｐに対応するクリ
ップオブジェクトは、Ｐへのクリッピングを含むその他
の命令の前に、描画リストにおける「クリップ」命令と
して配置される（clip P, 1）。その他の命令のすぐ前
に、境界Ｐに対応するクリップリストの要素１はクリッ
ピングスタックへとプッシュされる（pushclip 1）。そ
して、Bはクリッピングスタック中の全ての境界の共通
部分を通してで描画され（over B）、クリッピングスタ
ックの先頭のオブジェクトはポップされ、命令列は図２
３に示されているように続けられる。

【００９４】従って、下記の実施構想が考えられる。

【００９５】１． エクスプレッションツリーのポイン
タのワーキングセットは、上記の方法で変換することの
できる経路のために検索される。経路又はオブジェクト
が見つかると、それはワーキングツリーポインタの集合
から除かれ、クリップリストと呼ばれる配列に入れられ
る。この配列へのインデックス（クリップID）は、最適
化がinまたはout演算の結果であるかどうかの記録に加
えて、現在のノードへ記録される。

【００９６】２． エクスプレッションツリーを繰り返
すとき、クリップIDによるクリップを必要とするエクス
プレッションツリーの後続する部分のリーフノードを付
加することができるように、クリップリスト上でクリッ
プオブジェクトに変換された全てのグラフィック要素の
クリップIDの動きを追うことが必要である。始めにクリ
ップされた部分木はどれでもクリッピングの輪郭へ変換
するのに適する部分を含むため、クリップIDのスタック
を保存する必要がある。クリッピングの輪郭に変換すべ
きグラフィック要素を見つける時はいつでもそのクリッ
プIDをスタックへプッシュすることができ、そしてクリ
ップされた部分木は横断され、これに応じて、スタック
の先頭のクリップIDをポップすることができる。横断中
にリーフノードに当たったときは、その時にスタックに
存在する全てのクリップIDをそれに付加する。

【００９７】３． 描画リストが生成されたときは、ク
リップへ変換されてクリップリストに記憶されたそれぞ
れのグラフィック要素が使用される前に（例えばプログ
ラムの始めなど）、そのグラフィック要素の生成の為に
必要な「clip」命令が生成される。

【００９８】４． 描画時間「clip stack」は、様々な
合成命令を取り囲む「push clip」と「pop clip」命令
によって操作される。グラフィカルオブジェクトが合成
されるときは、同時にクリップスタック中の全てのクリ
ップオブジェクトへクリップする。従って、命令の描画
リストの生成に当たっては、グラフィック要素が合成さ
れるときのクリップスタックの状態を追わなければなら
ない。もし、このクリップスタック状態がグラフィカル
オブジェクトによって要求される状態になければ、クリ
ップスタックを要求される状態にするために、命令を生
成しなければならない。不可視画素を可視画素へ変換す
る単項演算子については、それらが利用されるときに追
加のクリッピングが必要となる。つまり、演算子をグラ
フィック要素の可視部のみに応用し、不可視のクリップ
された領域の状態をそのまま残すことが必要である。

【００９９】上記のクリッピング処理に加えて、グラフ
ィック要素はそれらのバウンディングボックスが最小化
されたことに起因する、更なるクリッピングを要求する
ことができることは言うまでもない。

【０１００】＜２．単項最適化の実施＞命令集合は、M
によって定義されるマッピングに対応して、特定のグラ
フィック要素の色を変化させるための命令（cmap M）を
供給する。

【０１０１】時々、ページ記述言語において利用できる
色マップ演算は、描画中ではなく、エクスプレッション
ツリー段階で実施することができる。例えば、色マップ
を用いてグラフィック要素の色を変えることを要求され
たとすると、描画処理が行われる前に要素の色を変える
ことが可能になり、従って、色マップ演算をエクスプレ
ッションツリーから除くことを可能にする。しかし、時
折、色マップ演算中にグラフィック要素の色がその透明
度、つまりαチャンネル値と反応することがある。色マ
ップ演算をエクスプレッションツリー段階で適用するこ
とができる否かを決定するために、この色マップ演算を
慎重に分析しなければならない。

【０１０２】また、グラフィック要素の色を考慮する
と、どのグラフィック要素も簡略化することができる。
例えば、図３３を参照にすると、普通は１０８で示され
るグラフィカルオブジェクトは、色が混ざり合った複雑
な形態を持つ領域１０９と、一定の色混合である第２領
域１１０とを含んでもよい。上記で概略説明したバウン
ディングボックス最適化処理は、領域１０９を囲むこと
のない境界を持つ最適化されたバウンディングボックス
１１１を作るかも知れない。従って、対応するエクスプ
レッションツリーを評価するときに、オブジェクト１０
８の色を領域１１０の一定色に相当する色へ変えること
ができる。

【０１０３】＜６．最適化＞エクスプレッションツリー
において、異なる形態の最適化が可能である。まず、上
述したとおり、空ボックスに最小化されたバウンディン
グボックスを持つエクスプレッションツリー部分は、エ
クスプレッションツリーから削除することができる。

【０１０４】演算子合成の数学的性質は、可能であれば
いつでもより無駄の多い演算をより効果的な演算に置き
換えるように、エクスプレッションツリーを配置し直す
ために利用することができる。これらの代数学的性質
は、結合性、可換性、及び様々な演算子の逆化を含む本
質である。最適化処理はあらかじめ決められた順序どお
りにツリーを横断し、それぞれのノードにおいて、最適
化装置は数学的特徴から導きだされた規則のそれぞれの
集合が現在のノードに適合するか否かをテストする。ど
の規則を応用すべきかを決定するに当たって、数学的特
徴に応じてエクスプレッションツリーを更新することに
より、エクスプレッションツリーの描画のコストのおお
まかな進歩が評価される。与えられたノードのコスト
は、左部分木のバウンディングボックスの高さ（h）と
領域（h × w）の線形の組合わせとして評価される。更
に詳しくは、結合性の性質は、描画処理中に要求される
スタック深度を大幅に削減するために、エクスプレッシ
ョンツリーを右へ傾けることに使用することもできる。
可換又は逆演算子を応用してのノードの部分木の取り替
えは、合成されるべき領域に関するコストが減少する場
合に限り、応用するとよい。これはスタック深度を上昇
させることになるが、これに対応して実行時間が減少す
る。

【０１０５】エクスプレッションシンタックスツリーの
それぞれのノードは、バウンディングボックスの走査線
数hと領域hwとを記憶する。これらは画素を単位とし表
される。従って、「A over B」などの共通の演算子のコ
ストを決定するためには、下記の要素を評価する必要が
ある。 ・ C1overは、単純なグラフィック要素に対して「ove
r」を実行するための、一走査線当たりのコストであ
る、 ・ C2overは、単純なグラフィック要素に対して「ove
r」を実行するための、一画素当たりのコストである、 ・ C3overは、単純なグラフィック要素の組合わせによ
って構成される複雑なグラフィック要素に対して「ove
r」を実行するための、一画素当たりのコストである、 ・ C4overは、複雑なグラフィック要素に対して「ove
r」を実行するための、一走査線当たりのコストであ
る、 ・ hは、境界A内の走査線数である、 ・ hwは、境界A内の画素数である。

【０１０６】従って、総コストは下記のとおりである。
即ち、 if グラフィック要素が単純 then cost = C1over・h +C2over・hw else グラフィック要素が複雑 cost = C3over・h + C4over・hw 式２ となる。

【０１０７】結合性質は、エクスプレッションツリーを
傾けるために利用することができる。傾いたエクスプレ
ッションツリーは、しばしば実行のための時間とメモリ
を削減する描画命令の対応する集合となる。図２５に、
対応する右に傾いた部分７６を形成するためにエクスプ
レッションツリーの部分７５を右に傾ける例を示す。図
２５に示される演算を実行するか否かを計算する式は下
記のとおりである。

【０１０８】 fover(A) + fover (Y) > fover(A) + fover(B) 即ち、fover(Y) > fover(B) 式３ となる。ここで、fover(Z)は、グラフィック要素Zの「o
ver」合成を行うコストである。

【０１０９】Bのバウンディングボックスがいつも部分
７５においてY以下であり、ほとんどの場合、複雑なグ
ラフィック要素を合成することは単純なグラフィック要
素を合成することよりも難しいため、この結合性の演算
はほとんどの場合は、今までよりも速いか、同じ速さで
描画するシンタックスエクスプレッションツリーを提供
する。ツリーはポインタを７５から７６へ変えるだけで
変更することができる。

【０１１０】可換性のこれらの演算子に関して、可換性
演算子のオペランドのいくつかを互換させることも有利
である。例えば、図２６に示すように、「xor」演算子
のオペランドは図では互換されている。互換するかどう
かは左ツリーのコストと、右ツリーのコストによって決
まる。従って、もし、 fxor(A) > fxor (B) 式３ ならば、オペランドは交換される。これは大抵は２つの
領域AとBを描画するのに要求される記憶装置の大きさに
関係し、ポインタを図２６に示すように変更するだけで
簡単に実施することができる。

【０１１１】時々、いくつかの演算子をその逆演算子に
交換しても便利である。例えば、図２７は「in」演算子
を、対応するポインタの交換動作によりその逆演算子
「rin」に変換する処理を示す。２つの方法の提案され
たコストの計算は、交換が行われるべきかどうかを決定
する。下記の変換について、多数の他の最適化が可能で
ある。

【０１１２】

【表６】

【０１１３】また、特に、含まれる部分木が「in」又は
「out」演算子の右オペランド（又は同等の「rin」又は
「rout」演算子の左オペランド）である場合は、応用可
能な様々な他の変換がある。

【０１１４】エクスプレッションツリーに対する上記全
ての最適化及び変更は、ユーザーのポインタセットが代
わることがないように使用中のポインタのセットに対し
て行われるため、エクスプレッションツリーを変更する
必要のないときには、変化は検知されない。

【０１１５】一度エクスプレッションツリーが最適化さ
れると、既に説明したように、描画リスト命令を生成す
るためにそれを利用することができる。

【０１１６】つぎに、図２８と図２９を参照して、エク
スプレッションツリーの操作の更に複雑な例を開示す
る。エクスプレッションツリー８０の元の部分は、一連
の中間コード命令に変換される。変換の第１の方法は、
エクスプレッションツリー８１の対応する最適化された
部分を形成するために図２８のエクスプレッションツリ
ー８０の部分を最適化することだけである。ツリーに対
して行われた最適化は、「in」であるオペランド８３を
「rin」８４へ変更する動作を含む。この演算子の変更
はそのオペランドの結果的な順列を持ち、オペランドP
がルートが「over」演算子８６である部分木オペランド
より実質的に小さい場合の結果として起こるものであ
る。そして、最適化されたエクスプレッションシンタッ
クスツリー８１は、中間コード命令８７へと変換され
る。この最適化の論理的根拠は、ツリー８０は２つのプ
ッシュと、ポップを必要とするのに対して、ツリー８１
は１つづつしか必要としないことである。従って、ツリ
ー８１に起因するより単純な命令集合は、実行速度が速
く、また必要なメモリを少なくするようである。

【０１１７】図２９は、クリッピングが利用されたとき
のエクスプレッションツリー８０の部分変形形式を示
す。これは、図２８のグラフィック要素P８５が不透明
なオブジェクトであって、その結果として、「over」演
算子８６によって生成されたグラフィック要素が不透明
なグラフィック要素８５と「in」演算子８３を使って組
合わせられることとする。図１９から図２２を参照して
説明したとおり、不透明なオブジェクトP８５に対する
クリッピングを「in」演算子の代わりに使用することが
できる。従って、Pの輪郭はクリップリストに８９とし
て、オペランド８５に関連して使用される図２８の演算
子８３と共に記憶される。

【０１１８】クリッピング処理は、全てのほかの二項合
成演算子（式１参照）に分配されるため、P８５へのク
リッピングは図２８の演算子８６と９１へ分配すること
ができる。その結果、リーフノード９２から９４のそれ
ぞれが、クリップリストに記憶された輪郭８９に対して
クリップする為にマークされることになる。

【０１１９】結果として得られるエクスプレッションツ
リー９６は、最適化されたエクスプレッションツリー９
７を形成するために最適化される。最適化されたエクス
プレッションツリー９７は、(A over B) over C = A ov
er (B over C)の形態を持つ「over」演算子（表４に示
す）のための結合規則の繰り返し実施によって、エクス
プレッションツリー９６から形成される。

【０１２０】そして、最適化されたエクスプレッション
ツリー９７は、中間命令９８を生成するために利用され
る。命令リスト８７（図２８）を命令リスト９８（図２
９）と比べると、リスト８７は、Pをオペランドとする
「rin」命令を対象とする前に、B1,B2,B3の全てのロー
ドや合成に加えて、アキュムレータの現在の内容をスタ
ックへプッシュするプッシュ命令を含んでいることが分
かる。そして、この演算結果はスタックの先頭と（「ro
ver pop」命令により）合成される。第２の命令集９８
において、クリップリストは最初に輪郭Pと共にロード
され、そして、Aは現在のアキュムレータの内容と合成
され、輪郭Pをクリップスタックへプッシュし、続い
て、クリップスタックの先頭にある輪郭Pを通してB1,B
2,B3の合成を行う。そして、クリップスタックの先頭
は、Cがアキュムレータの残りの内容に合成される前に
ポップされる（「popclip」命令）。命令列９８は命令
列８７よりも実際的にはより効果的なようであり、結合
性演算子の使用を合成する代わりにクリッピングするこ
とによって実行速度が早められる。

【０１２１】上述の通り、エクスプレッションシンタッ
クスツリーから作られる命令列は、ソフトウエア又はハ
ードウエアベースの機器での実行に用いられる。例とし
て、ハードウエアベースのアプローチを、図３４を参照
にして説明する。図３４に、例えば表３にあるような命
令列を実行することのできる、一例であるハードウエア
構造物１２０を示す。ハードウエア構造物１２０は、例
えば、Morgan Kaufmann Publishers Inc.から１９９０
年に出版されているJohn Hennessy とDavid Patterson
共著の「Computer Architecture - A Quantitative App
roach」の第３章から第８章のような、標準的テキスト
に示されている標準的なコンピュータ構造技術を用いる
ことにより実現することができる。

【０１２２】ハードウエア構造物１２０は、標準タイプ
の入力／出力インターフェイス１２３を使ってハードウ
エア構造物１２０とインターフェイスする、標準的な外
部コンピュータシステム１２５の制御下において作動す
るように設計されている。

【０１２３】上記のとおり、命令列は通常、走査線順に
ソートされ、アクティブリストは現走査線について外部
コンピュータシステム１２５によって維持される。ハー
ドウエア構造物１２０において、ある特定の現在アクテ
ィブな走査線の為の命令列は入力／出力インターフェイ
ス１２３を介して外部コンピュータシステム１２５から
命令記憶器１２１へロードされ、命令列に要求されるグ
ラフィック要素はメモリ記憶器１２２へクリップリスト
に加えてロードされる。制御部１２６は活発化され、命
令記憶器１２１から命令を読み始め、そして、再び標準
技術を使用して、制御部１２６内に記憶されたマイクロ
プログラムされたメモリによって、命令列の実行を開始
する。

【０１２４】アキュムレータ１２８は一走査線分の色情
報及び透明度情報を記憶するのに充分な記憶空間を持
つ。スタック記憶空間１３０は、ある一行でスタックが
成長できる最高深度を表わす、あらかじめ決められた最
高数の走査線を記憶するだけの充分な空間を持つ。

【０１２５】命令列中の「pushclip」命令に制御部１２
６が当たる度に、メモリ記憶器１２２中のクリッピング
リスト内に記憶された適切なクリッピングオブジェクト
がその時のクリッピングスタック１３２の先頭の内容に
重ねられ、その結果が新しいクリッピングスタック１３
２の先頭の構成要素として記憶される。「popclip」命
令に当たると、クリッピングスタック１３２のその時の
先頭がポップされる。

【０１２６】それぞれの合成命令については、制御部１
２６は、２つの画素色及び不透明さ情報列に対して表１
の合成演算を実施する合成部１２７の演算を制御する。
２つの情報列のうち、第１の列はアキュムレータ１２８
からのもので、第２の列はスタック記憶空間１３０から
のものである（必要時）。制御部１２６は、クリッピン
グスタック１３２のその時の先頭要素からの画素列を合
成する境界線を決定する。合成部１２７の結果の色と透
明度の出力は１３１を介してアキュムレータ１２８へフ
ィードバックされる。

【０１２７】一旦命令列が完了すると、制御部１２６
は、現在の走査線のためにアキュムレータ１２８から結
果を読みだすコンピュータシステム１２５に通知し、そ
の結果を望むとおりに出力又は記憶する。

【０１２８】上記の発明の実施の形態は、コンピュータ
グラフィックスや、アルゴリズムや、データ構成や、コ
ンピュータ構成や、コンパイラ記述の技術者にとって最
大限に明確に理解しやすいような形態で表現されたもの
である。また、種々の最適化が可能であることは言うま
でもない。例えば、ツリー横断の繰り返しの使用は、テ
ール繰り返し、又は維持バックポインタなどの公知の方
法を用いることにより削除することができる。

【０１２９】更に、ページ記述言語などの標準プログラ
ミング言語において、多様な設備を手に入れることが可
能である。これらの設備は通常、言語によって異なるた
め、特定の言語の実際的な詳細については仮定していな
い。当業者はページ記述言語による上記の実施の形態を
実施することが可能であることは言うまでもない。

【０１３０】上記の説明は好適な実施例の動作の説明を
含んでなされたがこれは発明の範囲を限定するものでは
ない。発明の範囲は以下の請求項によってのみ限定され
る。関係分野の当業者には、発明の精神と範囲を越えな
い程度で、上記の説明から多数の変形例が可能であるこ
とが明らかとなるであろう。

【０１３１】以上述べた様に上記実施の形態によれば、
以下に示すような効果が得られる。即ち、 １． グラフィック要素とそれらの組合わせは言語のデ
ータタイプであり、グラフィック要素の任意の組合わせ
が可能である、 ２． グラフィック演算子はグラフィック要素をそのオ
ペランドとして取り、２つの新しいグラフィック要素ま
たはそれらの組合わせを評価する、 ３． グラフィカルオブジェクトが関わる演算子のタイ
プ制限を条件として、グラフィカルオブジェクトは、他
の標準的言語データタイプと同じ方法で使用される（例
えば、除算演算子は数学的なオペランドのみを演算する
が、課題演算子はどの種類のオペランドにも使用するこ
とができる）、 ４． 全てのグラフィック要素と、グラフィック演算子
を利用したグラフィック要素の組合わせ結果は、更なる
グラフィック演算に適したオペランドである、 ５． ページ記述言語の実行によって生成されたある特
定のグラフィック要素の描画による出力のために、画像
を生成することができる。

【０１３２】なお、本発明は、複数の機器から構成され
るシステムに適用しても、１つの機器からなる装置に適
用してもよい。また、本発明はシステム或は装置にプロ
グラムを供給することによって達成される場合にも適用
できることは言うまでもない。この場合、本発明に係る
プログラムを格納した記憶媒体が、本発明を構成するこ
とになる。そして、該記憶媒体からそのプログラムをシ
ステム或は装置に読み出すことによって、そのシステム
或は装置が、予め定められた仕方で動作する。

【０１３３】

【発明の効果】以上説明したように本発明によれば、グ
ラフィカルプログラミング言語で定義されたプログラム
の解釈において、画像生成のより進歩した形態を提供す
ることができる。この結果、必要とするメモリの減少、
処理速度の向上が達成される。

【０１３４】

【図面の簡単な説明】

【図１】２つの単純なグラフィック要素を表す図であ
る。

【図２】２つの単純なグラフィック要素を表す図であ
る。

【図３】グラフィック要素の合成を表す図である。

【図４】様々な合成演算子と、最終的に得られる出力を
表す、発明の実施の形態にかかる図である。

【図５】第１の記述のエクスプレッションツリー（expr
ession tree）の構成を示す図である。

【図６】第１の記述のエクスプレッションツリー（expr
ession tree）の構成を示す図である。

【図７】第１の記述のエクスプレッションツリー（expr
ession tree）の構成を示す図である。

【図８】第１の記述のエクスプレッションツリー（expr
ession tree）の構成を示す図である。

【図９】第１の記述のエクスプレッションツリー（expr
ession tree）の構成を示す図である。

【図１０】第１の記述の合成処理を示す図である。

【図１１】第１の記述の合成処理を示す図である。

【図１２】第１の記述の合成処理を示す図である。

【図１３】第１の記述の合成処理を示す図である。

【図１４】第１の記述の合成処理を示す図である。

【図１５】第２の記述の結果として得られる最終画像を
示す図である。

【図１６】第２の記述のエクスプレッションツリーを示
す図である。

【図１７】エクスプレッションツリー上で行われるバウ
ンディングボックス（bounding box）処理を示す図であ
る。

【図１８】更なるバウンディングボックス最小値化を表
現する、発明の実施の形態にかかる図である。

【図１９】「in」演算子を使用して組合わされる２つの
グラフィック要素を示す図である。

【図２０】図１９のグラフィック要素の第１の組合わせ
方法を示す図である。

【図２１】図１９のグラフィック要素の第１の組合わせ
方法を示す図である。

【図２２】図１９のグラフィック要素の第２の組合わせ
方法を示す図である

【図２３】エクスプレッションツリーを対応する「中間
レベル」命令に変換する第１の方法を示す図である。

【図２４】エクスプレッションツリーを対応する命令に
変換する第２の方法を示す図である。

【図２５】エクスプレッションツリー上において実施さ
れる第１の最適化を示す図である。

【図２６】エクスプレッションツリー上において実施さ
れる第２の最適化を示す図である。

【図２７】エクスプレッションツリー上において実施可
能な第３の最適化を示す図である。

【図２８】エクスプレッションツリーの部分の最適化の
第１の方法を示す図である。

【図２９】エクスプレッションツリーの部分の最適化の
第２の方法を示す図である。

【図３０】２つのグラフィック要素と、それらに対応す
るバウンディングボックスを示す図である。

【図３１】図３０の２つのグラフィック要素を合成する
図である。

【図３２】図３０のグラフィック要素の一方の削減され
たバウンディングボックスを示す図である。

【図３３】発明の実施の形態で行われる色最適化を表す
図である。

【図３４】発明の実施の形態にかかる、命令を実施する
コンピュータ構造を示す図である。

フロントページの続き (71)出願人 000001007 キヤノン株式会社 東京都大田区下丸子３丁目30番２号 (72)発明者 ジョージ ポリティス オーストラリア国 2113 ニューサウス ウェールズ州，シドニー，ノースライド, トーマス ホルト ドライブ １ キヤノ ン インフォメーション システムズ リ サーチ オーストラリア プロプライエタ リー リミテツド内 (72)発明者 アンドリュー ティモシー ロバート ニ ューマン オーストラリア国 2113 ニューサウス ウェールズ州，シドニー，ノースライド, トーマス ホルト ドライブ １ キヤノ ン インフォメーション システムズ リ サーチ オーストラリア プロプライエタ リー リミテツド内 (72)発明者 ティモシー マーリック ロング オーストラリア国 2113 ニューサウス ウェールズ州，シドニー，ノースライド, トーマス ホルト ドライブ １ キヤノ ン インフォメーション システムズ リ サーチ オーストラリア プロプライエタ リー リミテツド内

Claims (10)

【特許請求の範囲】
1. 【請求項１】 グラフィカルプログラミング言語で定義
   されるプログラムを解釈する方法であって、 グラフィック要素の組合わせ又は描画を含む記述列を分
   析し、実行する工程と、該組合わせ又は描画の効果は遅
   延され、 前記グラフィック要素の組合わせ又は表現をエクスプレ
   ッションツリーのノードへ変換する工程とを備え、該ノ
   ードの子孫は遅延されたグラフィック要素の組合わせ又
   は描画のオペランドであり、また、ノードは遅延された
   演算を持つものとしてマークされることを特徴とするグ
   ラフィカルプログラミング言語の解釈方法。
2. 【請求項２】 前記エクスプレッションツリーのリーフ
   ノードはグラフィック要素を備えることを特徴とする請
   求項１に記載のグラフィカルプログラミング言語の解釈
   方法。
3. 【請求項３】 前記エクスプレッションツリーの内部ノ
   ードは、前記エクスプレッションツリーの対応する子孫
   ノードを組合わせるための演算子を備えることを特徴と
   する請求項１または２に記載のグラフィカルプログラミ
   ング言語の解釈方法。
4. 【請求項４】 前記エクスプレッションツリーのそれぞ
   れの内部ノードは、該内部ノードの子のグラフィック要
   素の境界を示すバウンディングボックス情報を記憶する
   ことを特徴とする請求項１に記載のグラフィカルプログ
   ラミング言語の解釈方法。
5. 【請求項５】 前記エクスプレッションツリーのそれぞ
   れのリーフノードは、前記プログラムの前記解釈によっ
   て作成される最終画像に現われるリーフノードのグラフ
   ィック要素の部分を示すバウンディングボックス情報を
   記憶することを特徴とする請求項１に記載のグラフィカ
   ルプログラミング言語の解釈方法。
6. 【請求項６】 前記エクスプレッションツリーは二分木
   であることを特徴とする請求項１に記載のグラフィカル
   プログラミング言語の解釈方法。
7. 【請求項７】 前記エクスプレッションツリーを対応す
   る命令列へ変換する工程を更に含むことを特徴とする請
   求項１に記載のグラフィカルプログラミング言語の解釈
   方法。
8. 【請求項８】 前記画像を描画する為に前記命令列を実
   行する工程を更に含むことを特徴とする請求項７に記載
   のグラフィカルプログラミング言語で定義されるプログ
   ラムの解釈方法。
9. 【請求項９】 前記エクスプレッションツリーを対応す
   る命令列へ変換する工程はエクスプレッションツリーの
   ルートノードを現ノードと指定する工程を含み、 （ａ） もし前記現ノードがリーフノードならば、現ノ
   ードのオペランドをロードする命令を生成する工程と、
   そうでなければ （ｂ） もし前記現ノードが単項演算子だけならば、現
   ノードのオペランドを現ノードとして、工程（a）から
   工程（c）を繰り返し呼び出し、前記単項演算子を実行
   するように命令を生成する工程と、そうでなければ （ｃ）（I）現ノードの第１子を現ノードとして工程
   （a）から工程（c）を繰り返し呼び出す工程と、 （II）もし現ノードの第２子がリーフノードならば、第
   ２子のオペランドと、現ノードのオペランドを使用する
   命令を生成する工程と、そうでなければ （III） （１）第２子のオペランドに対応するグラフィ
   ック要素のバウンディングボックスをクリッピングスタ
   ックへプッシュする命令を生成し、（２）第２子のオペ
   ランドを現ノードとして工程（a）から工程（c）を繰り
   返し呼び出し、（３）第２子のオペランドのバウンディ
   ングボックスを空にする命令を生成し、（４）現ノード
   の現演算子の逆をスタックの先頭に対して実行する命令
   を生成する工程と、を実行する工程とを完了することを
   特徴とする請求項７に記載のグラフィカルプログラミン
   グ言語の解釈方法。
10. 【請求項１０】 前記命令は一つの演算子又は演算コー
    ドと、多くとも一つつのオペランドにより構成されてい
    ることを特徴とする請求項１に記載のグラフィカルプロ
    グラミング言語で定義されるプログラムを解釈する方
    法。