JPH07129357A - マルチディスプレイシステム - Google Patents

Abstract

(57)【要約】 【目的】 コンテキストの異なる複数のディスプレイを
目的によって使い分けることができ、ディスプレイ資源
とＣＰＵ資源とを分散配置したマルチディスプレイシス
テムを提供する。 【構成】 グラフィックス出力機能を有するＣＰＵに対
して仮想記憶空間を設け、前記仮想記憶空間にディスプ
レイユニットを接続する場合、前記デイスプレイユニッ
トに対応する表示空間を、前記仮想記憶空間の論理的な
出力空間に配置して管理するモジュールを設けている。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、グラフィックスユーザ
インタフェースを提供するシステムソフトウェアのグラ
フィックス表示管理機能に関するものであり、特に表現
力の異なった複数のディスプレイユニットに対応する表
示空間を、仮想記憶空間の論理的な出力空間に配置して
統合的に管理するようにしたマルチディスプレイシステ
ムに関する。

【０００２】

【従来の技術】従来のグラフィックスディスプレイは図
１３に示す如く、全体の制御を行なうＣＰＵ１に対して
プログラム内蔵のＲＯＭ２及びデータ格納用のＶＲＡＭ
３が接続され、キーボード４等から入力される処理情
報、指示に従ってＣＲＴ等のディスプレイ５に種々の情
報、画像が表示されるようになっている。このように、
従来は１つのＣＰＵ１に対して１つのディスプレイ５と
いった利用形態を仮定しているため、追加投資により表
現力の高い、つまり解像度や色表現力の高いディスプレ
イを追加した場合には、それまでのディスプレイを破棄
するような非効率的な拡張しかできなかった。又、ＣＰ
Ｕ１とディスプレイ５との間の接続形態が限定されてい
るため、遠隔地にあるディスプレイへの表示を実現する
ことができなかった。

【０００３】

【発明が解決しようとする課題】上述のように従来のグ
ラフィックスディスプレイでは、１ＣＰＵに対して１デ
ィスプレイといった利用形態になっているため、表現力
の異なるディスプレイを増設して利用することが不可能
であると共に、遠隔地のディスプレイへの表示が不可能
であった。

【０００４】本発明は上述のような事情よりなされたも
のであり、本発明の目的は、解像度や色表現力といった
コンテキストの異なる複数のディスプレイを目的によっ
て、効率良く使い分けできると共に、ディスプレイ資源
とＣＰＵ資源とを分散配置したマルチディスプレイシス
テムを提供することにある。

【０００５】

【課題を解決するための手段】本発明はマルチディスプ
レイシステムに関するもので、本発明の上記目的は、グ
ラフィックス出力機能を有するＣＰＵに対して仮想記憶
空間を設け、前記仮想記憶空間にディスプレイユニット
を接続する場合、前記ディスプレイユニットを通信手段
に依存しないで制御するために、前記ディスプレイユニ
ットに対応する表示空間を、前記仮想記憶空間の論理的
な出力空間に配置して管理するモジュールを設け、前記
ＣＰＵと前記ディスプレイユニットとの間の制約を解消
するようにすることによって達成される。

【０００６】

【作用】本発明では、ソフトウェアのモジュール構成
を、仮想記憶空間による仮想的なグラフィックス出力空
間の管理部と、その空間にマッピングされる個々のハー
ドウェアデバイス（ディスプレイ）を制御する部分とに
完全に分離し、このモジュール間のプロトコルを通信手
段に依存しないメタピクチャーフォーマットとしてい
る。これにより、ＣＰＵとディスプレイの間の制約はほ
とんど解消された。即ち、仮想記憶空間の適宜領域を各
ディスプレイに割当てることによって、コンテキストの
異なる複数のディスプレイをその目的によって使い分け
でき、ディスプレイ資源とＣＰＵ資源とを分散配置する
ことができる。

【０００７】

【実施例】以下に本発明の実施例を説明する。図１は本
発明の概要を示すブロック図であり、ＣＰＵ１０にはデ
ータ格納用のＶＲＡＭ１１及びプログラム格納用のＲＯ
Ｍ１２が接続され、例えば解像度１０２４×７６４画素
のＣＲＴ１３が接続されている。ＣＰＵ１０にはアプリ
ケーションプログラム３０（ＡＰ１〜ＡＰｎ）から情報
が入力され、キーボード１４から指示情報等が入力さ
れ、更に、例えば３２，０００×３２，０００画素の領
域を有する仮想記憶空間２０が用意されている。仮想記
憶空間２０の領域はＣＲＴ１３が利用できると共に、モ
ジュール４０を介して表示装置４１〜４３のＣＲＴ１〜
ＣＲＴ３が利用できるようになっている。ＣＲＴ１〜Ｃ
ＲＴ３はそれぞれ表現力が異なっていても良く、例えば
仮想記憶空間２０内の領域２１〜２３がインストールし
て割当てられ、各領域２１〜２３はモジュール４０を介
して、ラスタイメージではないベクトル情報のメタピク
チャープロトコルで各表示装置４１〜４３に供給され
る。インストール時に割当てられた領域２１〜２３は、
その位置やサイズについて修正可能である。

【０００８】ウィンドウオペレーティング環境に要求さ
れるグラフィックス機能には、ウィンドウ枠、スクロー
ルバー、ボタンといった比較的簡単なオーナメントか
ら、連続したスプライン曲線やカラービットマップの描
画までの広範な要求が存在する。しかし、これら全ての
要求をディスプレイドライバーが単独で処理しサポート
することは、メモリ効率や開発効率の面からも不合理で
非現実的なことである。本発明のディスプレイドライバ
は、上位モジュールに高度な座標系管理やグラフィック
スデータベース管理を持つグラフィックスライブラリの
存在を仮定して設計することにより、基本的な座標変換
やプリミティブに関しては非常にシンプルな構造とし、
高速なパフォーマンスを提供するようにしている。プリ
ミティブとしては矩形や円等の図形、ブロックコピー、
ビットマップ、塗りつぶし（Ｒｅｇｉｏｎ）等を用意し
ている。

【０００９】ディスプレイドライバのレンダリング機能
としては、フォトリアステイクなコンピュータグラフィ
ックスのためのカラー表現（例えば３２ビットフルカラ
ー），２５６種のラスタオペレーション（３次元論理演
算に対応）とラスタオペレーションのユーザ定義をサポ
ート、任意の線幅、線種、接続、端線形状を有する高品
位レンダリングモジュールの機能がある。又、ストロー
クスプリミティブのレンダリングモードの切り替え機
能、マルチフォントテキスト表示機能、塗りつぶし機
能、パス作成プリミティブを用意しており、マルチメデ
ィアプラットフォームを見据えた高品位なグラフィック
スを実現している。

【００１０】更に、ディスプレイドライバでは、アプリ
ケーションの要求レベルに応じた色々なカスタマイズの
ためのインタフェースとディスプレイサブドライバを用
意している。ディスプレイドライバのアプリケーション
インタフェースは、機能レベルに応じて、システムイン
タフェース、サブドライバインタフェース、アプリケー
ションインタフェース（低レベル）、アプリケーション
インタフェースの４階層に整理分類される。単にウィン
ドウ内のオーナメントとして、矩形のハッチングと枠線
の描画を行なうのであれば、アプリケーションインタフ
ェースの項目のみを参照すれば良く、独自のカラーパレ
ットテーブルを用意するアプリケーションでは、アプリ
ケーションインタフェース（低レベル）を利用する必要
がある。更に、描画プリミティブの変更や追加、パレッ
ト変換アルゴリズムのカスタマイズ等を要求するアプリ
ケーションでは、システムインタフェースの利用やサブ
ドライバインタフェースを利用した独自のディスプレイ
サブドライバを用意することにより、アプリケーション
独自の表現力を実現することが可能である。

【００１１】ディスプレイドライバに必要なもう一つの
重要な機能は、ハードウェアからの独立性である。ハー
ドウェア独立性には２つの側面があり、１つは、アプリ
ケーションインタフェース（Ａｐｐｌｉｃａｔｉｏｎ
Ｉｎｔｅｒｆａｃｅ）が特定のハードウェアに依存しな
いことであり、もう１つは、作成したグラフィックスオ
ブジェクト（メタピクチャー、ビットマップ）の可搬性
が保証されることである。ディスプレイドライバでは、
この２つのハードウェア独立性を、ＤＩＧ［Ｄｅｖｉｃ
ｅ Ｉｎｄｅｐｅｎｄｅｎｔ Ｇｒａｐｈ］データ構
造、ＧＰＣ［Ｇｒａｐｈ Ｐｏｒｔ Ｃｏｎｔｅｘｔ
（ワールド座標系）］，ＧＤＳ［ＧｒａｐｈＤｅｖｉｃ
ｅ Ｓｐａｃｅ］，ＧＤＣ［Ｇｒａｐｈ Ｄｅｖｉｃｅ
Ｃｏｎｔｅｘｔ（デバイス座標系）］の３階層の座標
空間とコンテキストの提供、及びディスプレイサブドラ
イバ（ハードウェアデバイスの記述）の分離の手法を用
いることにより実現している。ディスプレイドライバで
は、ＧＤＳと呼ばれる論理空間でハードウェアデバイス
との柔軟な連結を実現し、マルチディスプレイのサポー
トや異なるデバイスへの同時出力を実現している。この
ようなマルチディスプレイシステムの場合にも、アプリ
ケーションはそれを意識する必要は全く無い。座標変換
は上述のように上位モジュールでの管理を前提とした簡
易な設計となっており、デバイス座標系までに必要な２
回の変換は平行移動のみであり、変換に要するオーバー
ヘッドはほとんど無視できる。しかし、スケーリングや
回転といった座標変換要求は、高度なグラフィックス機
能を必要としないアプリケーションでもしばしば起こり
得る。このため、物体座標系（Ｏｂｊｅｃｔ Ｃｏｏｒ
ｄｉｎａｔｅ）を用意し、これに対するアフィン変換
（Ａｆｆｉｎｅ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ）とし
て、平行移動、スケーリング、回転を用意している。本
発明のディスプレイドライバでは、この他、カーソル、
キャレット管理（マルチディスプレイ対応），高速クリ
ッピング機能（オーバラップウィンドウ用）、マルチフ
ォントドライバインタフェースの機能を持つ。

【００１２】ディスプレイドライバはドライバのインス
トールを行ない、サブドライバのロード後にデイフォル
トのＧＰＣを作成し、又ドライバの解除（終了処理）を
行ない、更にスクリーンデバイスタイプとして登録され
たＧＤＣの数を通知する。ディスプレイドライバはＧＤ
Ｃをディスプレイデバイス管理に登録し、このサービス
は、サブドライバが固有のハードウェアデバイスに関す
るコンテキストとサービスをディスプレイデバイス管理
に登録するために使用する。通常登録されるデバイスコ
ンテキストはリソースとして宣言されており、ネームド
ポインタとして参照可能である。ディスプレイドライバ
のプリミティブ描画要求はＧＤＳに出力され、システム
によってディスプレイやプリンタデバイス空間は予約さ
れているが、ユーザが独自のデバイス空間を用意したい
場合には、システムでユニークなデバイススペースを確
保する必要がある。このような場合、ＧＤＳの作成関数
で取得したデバイススペースを使用する。又、ＧＤＳを
破棄する機能もある。更に、サブドライバによって登録
されているＧＤＣをカスタマイズして、等価なデバイス
コンテキストを作成する機能を有し、ＧＤＣを指定した
デバイス原点に移動する機能も有する。デバイス位置は
仮想デバイス空間の座標系であり、複数のＧＤＣを有す
るグラフスペースにおいて、個々のＧＤＣの位置関係を
設定するために使用される。ＧＰＣの作成ではオリジナ
ルのＧＰＣを作成する。即ち、カラー属性をパレットシ
ステムと設定した場合、パレットテーブルが必要であ
り、そのメモリ領域はグラフポートを解放するまで呼出
側で保証する必要がある。パレットシステム指定で、パ
レットテーブルのポインタをＮＵＬＬで呼び出した場合
には、ディフォルトのパレットテーブルをデュープリケ
ートしたものが自動的に用意される。

【００１３】ディスプレイドライバは表示可能な矩形領
域を問い合わせるが、表示可能な矩形領域は、図２に示
す如くビューポート領域、クリッピング領域、デバイス
領域、そして可視レクタングルリストの論理積領域であ
る。そして、カレントのＧＰＣのビューポート領域を設
定する。この設定後、ディスプレイドライバのプリミテ
ィブは、設定されたビューポート相対座標系に出力され
る。また、ビューポートのクリッピング情報は、この設
定により全てキャンセルされる。通常、ビューポート領
域のシステム・ディフォルト値は、グラフデバイス空間
全体の領域である。クリッピング矩形の設定では、カレ
ントのＧＰＣにビューポートのクリッピング領域を設定
する。これ以降、ディスプレイドライバのプリミティブ
は、図３に示す如く、ビューポート領域とクリッピング
領域のＡＮＤ領域にのみ出力される。通常、クリッピン
グ領域のシステム・ディフォルト値は、ビューポート領
域と同様、グラフデバイス空間全体の領域に設定されて
いる。

【００１４】カレントのＧＰＣにクリッピング情報を設
定する。このクリッピング情報は、オーバーラップウィ
ンドウシステム等の複雑なクリッピング操作をサポート
するために使用する。図４のように表示したい領域（破
線）内に幾つかの非表示矩形が存在する場合、図３のよ
うな３つの矩形情報リストを作成し、本関数によりその
情報をディスプレイドライバに通知する。実際の表示可
能領域としては、このクリッピング情報とビューポート
領域、ビューポートクリッピング領域の全てのＡＮＤ領
域が選択される。クリッピング情報のシステムディフォ
ルト値は、無効（−１）となっている。

【００１５】本発明のディスプレイドライバでは図５に
示すように、グラフポートコンテキスト（ＧＰＣ）／ワ
ールド座標系、グラフデバイススペース（ＧＤＳ）、グ
ラフデバイスコンテキスト（ＧＤＳ）／デバイス座標系
の３つの座標空間を用意している。即ち、アプリケーシ
ョンからのグラフィックスプリミティブの出力は、ウィ
ンドウサーバが用意したＧＰＣに出力される。このプリ
ミティブはウィンドウウィング変換によりＧＤＳ上のビ
ューポート領域に投影される（図５の変換Ｔ１）。この
変換はウィンドウを原点位置に固定し、しかもビューポ
ートと同じサイズにすることにより、アフィン変換成分
の平行移動のみが有効となっている。このため、変換操
作についてはほとんどオーバーヘッドはないが、スケー
リングや回転といったアフィン変換はサポートされな
い。このようにＧＤＳに投影された描画要求は、適切な
物理デバイスに連結される必要がある。ＧＤＳは、ＧＰ
ＣとＧＤＣ間の連結のための論理空間となっており、複
数のＧＤＣを同一空間上に配置し管理することができる
ため、アプリケーションからの描画要求を同時に複数の
物理デバイスに出力したり、複数のディスプレイデバイ
スを２次元空間で連動させたりすることが可能である。
ＧＰＣからビューイングされたプリミティブは、ＧＤＳ
で連結されたハードウェアデバイス空間であるＧＤＣに
変換され実際のレンダリングが行なわれる（図５の変換
Ｔ２）。この変換も座標変換操作については平行移動の
みであるが、ＤＩＧと呼ばれるデバイス独立なグラフ情
報が異なる場合には、カラーパレットやメモリレイアウ
トの変換が行われる。

【００１６】このようなスクリーンへの標準的な座標変
換以外に、ＧＰＣ固有のローカルな出力デバイスが用意
される。ＧＰＣへの描画要求は、このローカルデバイス
とＧＤＳの双方か、ローカルデバイスのみの何れかに出
力される。通常、ローカルデバイスとして仮想メモリデ
バイスを定義しておいて、表示のバッファリングに利用
されることが多い。本発明のウィンドウ環境におけるス
クリーン出力は、当然ウィンドウの重なり状況に応じた
適切なクリッピング情報（矩形リストで表現される）
と、ウィンドウの位置に応じたＧＤＳ座標系でのビュー
ポート情報とが必要となる。このような情報は、ウィン
ドウの拡大、縮小、移動といったウィンドウリストの変
化の度に更新する必要があり、アプリケーションからの
描画要求のタイミングで、ウィンドウを描画するための
ビューポートとクリッピング情報から計算され、該当す
るＧＰＣにその情報が設定される。出力デバイスによっ
ては、ビューボートとクリッピング矩形リスト情報は無
視されるが、スクリーンデバイスでは、この情報により
図６のようにウィンドウのオーバラップ状態が保持され
る。

【００１７】ＧＤＳは、ワールド座標系（ＧＰＣ）とデ
バイス座標系（ＧＤＣ）の連結関係を管理するための論
理空間である。ＧＰＣからの出力は選択されているＧＤ
Ｓに投影され、投影されたビューポートとオーバーラッ
プする全てのＧＤＣへ変換されて描画される（図５参
照）。ＧＤＳにマッピングできるＧＤＣの数や位置関係
には何の制約もない。このため、スクリーン上への出力
そのままを、ＧＤＳにマッピングした仮想メモリデバイ
スに出力させたり、プリンタデバイスに出力させること
が可能である。しかし、スクリーン用ＧＤＳのようなリ
アルタイム描画が要求される空間に対して、バッファリ
ング機能の無いプリンタデバイスをマッピングすること
は、システムのパフォーマンスを著しく阻害してしま
う。このような問題を回避するため、通常はアプリケー
ションによる標準グラフデバイススペースの操作は禁止
されている。標準グラフデバイススペースとしては、 ｇｄｓＳＣＲＥＥＮ スクリーンへの表示（標準出
力） ｇｄｓＰＲＩＮＴＥＲ プリンターへの出力 が用意される。標準出力であるスクリーンＧＤＳには、
ディフォルトでハードウェア標準のＶＲＡＭ用ＧＤＣが
マッピングされる。これ以外にハードウエア構成にフレ
ームバッファや、他の表示デバイスが用意され、対応す
るディスプレイサブドライバが組み込まれている場合に
は、スクリーンＧＤＳにこれらのＧＤＣが自動的にマッ
ピングされる。図５のスクリーンＧＤＳは、標準ＶＲＡ
Ｍ以外にフレームバッファが組み込まれた例である。

【００１８】次に、本発明の動作例を具体的に説明す
る。図７は本発明の動作フローを示しており、先ずグラ
フィックスリクエスト（ステップＳ１）及び属性情報リ
クエスト（ステップＳ２）が入力される。グラフィック
スリクエストは例えば図８に示すような直線Ｌであり、
始点Ｐｓ（ｓｘ，ｓｙ）と終点Ｐｅ（ｅｘ，ｅｙ）とを
仮想記憶空間２０上に与える。属性情報としては、線
種、カラー、バックグランド、接続情報、塗りつぶしパ
ターン等があり、これら属性情報は適宜与えられる。グ
ラフィックスの情報（必要に応じて属性情報）が入力さ
れると、ＣＰＵ１０は必要に応じてボックスイングテス
ト（Ｂｏｘｉｎｇ Ｔｅｓｔ）を実行する。即ち、図８
に示すように各々異なった表現力のＣＲＴ１〜３に領域
２１〜２３が設定されているとすると、入力されたグラ
フィックス（直線Ｌ）がこれら領域２１〜２３に重なる
か否かを判定する。本例の場合、直線Ｌは領域２１及び
２２に重なっているので、その領域２１及び２２に対応
した表示装置４１及び４２のサブドライバに座標変換を
指示する（ステップＳ１０）。

【００１９】座標変換は仮想記憶空間２０の座標から、
各領域２１及び２２固有の座標に変換するものであり、
ラスタ情報ではないメタピクチャー情報で処理される。
サブドライバは座標変換されたメタピクチャー情報に従
ってクリッピングを行ない（ステップＳ１１）、領域２
１に関しては図９に示すように領域２１の端部と直線Ｌ
との交点Ｐ１及びＰ２を求めることによって行なわれ、
このクリッピングの結果がレンダリングされる（ステッ
プＳ１２）。その後、全ての入力されたグラフィックス
について上記動作を繰り返す（ステップＳ１３）。

【００２０】ここで、上述ではグラフィックスとして直
線の入力を説明したが、ベジェ３次曲線の描画では図１
０に示すように、始点座標（ｓｘ，ｓｙ）及び終点座標
（ｅｘ，ｅｙ）と、２つの制御点（ｘ１，ｙ１）及び
（ｘ２，ｙ２）とでベジェ３次曲線を描画する。又、ビ
ットマップデータの表示では図１１に示すように、オリ
ジナルのビットマップデータを各デバイス先へ描画す
る。この場合、図１２に示すようにデータの拡大／縮小
も可能である。

【００２１】

【発明の効果】以上のように本発明によれば、ソフトウ
エアのモジュール構成を仮想的なグラフィックス出力空
間の管理部と、その空間にマッピングされる個々のハー
ドウエアデバイスを制御する部分とに完全に分離し、こ
のモジュール間のフロトコルを通信手段に依存しないメ
タピクチャーフォーマットとしているので、解像度や色
表現力といったコンテキストの異なった複数のディスプ
レイを目的によって使い分けることができ、更にディス
プレイ資源とＣＰＵ資源とを分散配置することができ
る。

【図面の簡単な説明】

【図１】本発明の基本的構成例を示すブロック図であ
る。

【図２】表示可能な矩形領域を説明するための図であ
る。

【図３】クリッピング矩形の設定を説明するための図で
ある。

【図４】可視領域情報の設定を説明するための図であ
る。

【図５】本発明で用いる座標変換の例を示す図である。

【図６】ウインドウオペレーティング環境における座標
変換とクリッピングを説明するための図である。

【図７】本発明の動作例を示すフローチャートである。

【図８】ボックスイングテストを説明するための図であ
る。

【図９】クリッピングを説明するための図である。

【図１０】ベジェ３次曲線の描画を説明するための図で
ある。

【図１１】ビットマップデータの表示を説明するための
図である。

【図１２】ビットマップデータの表示を説明するための
図である。

【図１３】従来の技術を説明するためのブロック構成図
である。

【符号の説明】

１，１０ ＣＰＵ ２，１２ ＲＯＭ ３，１１ ＶＲＡＭ ４，１４ キーボード ５，１３ ＣＲＴ ２０ 仮想記憶空間 ４０ モジュール

Claims (3)

【特許請求の範囲】
1. 【請求項１】 グラフィックス出力機能を有するＣＰＵ
   に対して仮想記憶空間を設け、前記仮想記憶空間にディ
   スプレイユニットを接続する場合、前記ディスプレイユ
   ニットを通信手段に依存しないで制御するために、前記
   ディスプレイユニットに対応する表示空間を、前記仮想
   記憶空間の論理的な出力空間に配置して管理するモジュ
   ールを設け、前記ＣＰＵと前記ディスプレイユニットと
   の間の制約を解消するようにしたことを特徴とするマル
   チディスプレイシステム。
2. 【請求項２】 前記ディスプレイユニットが複数個であ
   り、それぞれが異なった表現力である請求項１に記載の
   マルチディスプレイシステム。
3. 【請求項３】 前記モジュールがメタピクチャープロト
   コルで動作する請求項１に記載のマルチディスプレイシ
   ステム。