JP2004102343A - 画面表示処理装置及び画面表示処理方法、並びにコンピュータ・プログラム - Google Patents

Abstract

【課題】不必要なオブジェクトの描画を抑制して効率的なＧＵＩ画面の表示処理を効率的に行なう。
【解決手段】まず、Ｒｅｖｅｒｓｅ　Ｐａｉｎｔｅｒ’ｓ　Ａｌｇｏｒｉｔｈｍに従って、描画処理のためにｚ−ｏｒｄｅｒを追跡しながら、前方から後方に向かってオブジェクトを探索する。但し、オブジェクトを描画する代わりに、この段階では描画の必要上のフラグを立てる程度でよく、ｚ−ｂｕｆｆｅｒを備える必要がない。オブジェクトを実際に描画する際、Ｐａｉｎｔｅｒ’ｓ　Ａｌｇｏｒｉｔｈｍに従って、後方から前方に向かってオブジェクトを描画する。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、コンピュータ上のディスプレイ画面の表示を処理する画面表示処理装置及び画面表示処理方法、並びにコンピュータ・プログラムに係り、特に、複数のオブジェクトで構成されるコンピュータ画面の表示を処理する画面表示処理装置及び画面表示処理方法、並びにコンピュータ・プログラムに関する。
【０００２】
さらに詳しくは、本発明は、複数のオブジェクトで構成されユーザ・インタラクションとともに画面表示が逐次更新されるＧＵＩ画面の表示を処理する画面表示処理装置及び画面表示処理方法、並びにコンピュータ・プログラムに係り、特に、不必要なオブジェクトの描画を抑制して効率的なＧＵＩ画面の表示処理を行なう画面表示処理装置及び画面表示処理方法、並びにコンピュータ・プログラム関する。
【０００３】
【従来の技術】
昨今の技術革新に伴い、ワークステーション（ＷＳ）やパーソナル・コンピュータ（ＰＣ）と呼ばれる、比較的小型且つ低価格で、高付加価値化・高機能化された汎用タイプのコンピュータ・システムが開発・市販され、大学その他の研究機関や企業その他のオフィス、さらには一般家庭内の日常生活にも深く浸透している。いまや、日常業務の大部分がコンピュータとの関わりを持っており、多くの人々は、キーボードやマウスを触れながら１日を過ごす。
【０００４】
コンピュータ・システムは、一般に、ユーザ入力コマンドに応答して駆動し、処理結果をディスプレイ・スクリーン上に表示することによって、「インタラクティブ」、すなわち対話的な処理環境を提供している。最近では、ＤＯＳ（ＤｉｓｋＯｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）シェル画面を代表とする旧来のキーボードを介したキャラクタ・ベースのユーザ入力環境すなわち「ＣＵＩ（Ｃｈａｒａｃｔｅｒ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）」から、グラフィック・ベースのユーザ入力を実現した「ＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）」への移行が挙げられる。ＧＵＩ環境下では、コンピュータ・システムがシミュレートされたデスクトップと無数のアイコンがディスプレイ・スクリーンに用意される。
【０００５】
ＧＵＩが提供されたデスクトップ上では、ファイルなどのコンピュータ・システム上で取り扱われる全ての資源オブジェクトはアイコンとして表現されている。ユーザは、ディスプレイ・スクリーン上のプログラム、データ、フォルダ、デバイスなどを象徴するアイコンなど画面上の表示オブジェクトに対してマウスなどのユーザ入力装置を用いて直接操作を印加する（例えば、クリックやドラッグ・アンド・ドロップ）ことで、直感的に且つ判り易くコンピュータ操作を行なうことができる。また、デスクトップ上には、メニュー・バーやツール・ボックスなど、各種の機能すなわちコンピュータ処理を瞬時に呼び出すためのボタンが用意されており、コンピュータへのコマンド入力の様式はますます直感的で分かり易いものとなってきている。
【０００６】
ＧＵＩ環境の導入により、もはやユーザは、特定のコマンドの名称やコマンド操作方法等を特に習得したり、煩雑なキー入力を行なったりしなくとも、コンピュータを充分に操作することができる。また、コンピュータは、ユーザの意思に忠実なユーザ入力をシステムに取り込むことができる。
【０００７】
【発明が解決しようとする課題】
ＧＵＩ環境下では、デスクトップ画面の表示内容（ａｐｐｅａｒａｎｃｅ）は常に更新される。例えば、メニュー・ウィンドウがオープンしたりクローズしたり、ボタンが押下されたり解放されたり、チェック・ボックスが選択されたり排除されたり、ラベル・テキストやカウンタ値が更新されたり等などである。
【０００８】
このようなＧＵＩ画面の変更は、一般に画面表示上のダメージとみなされ、修復すなわち再描画が必要である。例えば、ドロップ−ダウン・メニューをクローズしたとき、メニューが表示されていた領域をメニューが覆っていた通りに表示するように再び回復する必要がある。あるいは、ユーザが選択しなかったチェック・ボックス上でクリック操作を行なった場合、選択しなかった画面表示から選択した画面表示へと表示内容を更新する必要がある。
【０００９】
２次元ＧＵＩ画面における上述したようなダメージを修復するために、後方から前方に向かって、ダメージ領域内のすべてのオブジェクトを修復すなわち再描画する方法が広く用いられている。すなわち、背景イメージのような後方の最も遠くに配置されているオブジェクトがまず描画され、次いでこれに最も近いより前方のオブジェクトが順次描画されていき、最終的には最前方のオブジェクトが描画される。この方法は、絵描きがキャンバス上に絵を描くのと同様の形態でＧＵＩ画面を描画処理することから、”Ｐａｉｎｔｅｒ’ｓ　Ａｌｇｏｒｉｔｈｍ”としても知られる。絵描きは、まず最初に空や後方の山を描き、次いで木や家を描き、最終的には最前方の人のポートレートを描く。この方法によれば、ダメージ領域内のダメージを確実に修復することはできるが、実際にダメージを受けた領域の数倍の領域を再描画しなければならないため、計算コストが高い。
【００１０】
例えば、あるイメージの前方に配置されているボタンの表示色を変更した場合、このボタンで閉められている領域がダメージ領域となり、修復する必要がある。この場合、ダメージ領域と交差しているイメージの部分がまず再描画され、次いで、その領域上のボタンが再描画される。
【００１１】
ここで、もしボタンがダメージ領域を完全に塗り潰しているような場合には、画面表示を修復するにはボタンだけを再描画すれば充分である。このようなオーバーヘッドは、変更内容が膨大ではなく重なり合うオブジェクトが少数で済む２次元ＧＵＩにおいては、受容し得るものである。しかしながら、２次元表示にズームやアニメーション機能が加わった２．５次元ＧＵＩにおいては、相当量のダメージやオブジェクト同士の重なり合いが表示されるので、オーバーヘッドは即座にシステムのパフォーマンスの問題へと波及する。
【００１２】
ここで、アニメーションＧＵＩの画面修復について、図１０を参照しながら考察してみる。同図に示す例では、あるＧＵＩオブジェクトが、１つのアニメーション・ステップにおいて、当該オブジェクトを囲う前回（ｐｒｅｖｉｏｕｓ）のオブジェクト境界ボックスから現在（ｃｕｒｒｅｎｔ）のオブジェクト境界ボックスへと移動している。
【００１３】
移動するオブジェクトについての修復処理は、基本的には２つの簡単なアニメーションのステップで構成される。すなわち、移動先の新しい場所（ｎｅｗ　ｐｏｓｉｔｉｏｎ）において描画処理を行なうとともに、元の場所（ｉｎｉｔｉａｌ　ｐｏｓｉｔｉｏｎ）を背景イメージで塗り潰す必要がある（図１１を参照のこと）。このようなダメージ修復の処理が各ステップ毎に実行される。
【００１４】
”Ｐａｉｎｔｅｒ‘ｓ　Ａｌｇｏｒｉｔｈｍ”に置き換わる一般的な方法として、”ｚ−ｂｕｆｆｅｒ　Ａｌｇｏｒｉｔｈｍ”を挙げることができる。このアルゴリズムでは、前回の描画処理におけるｚ−ｏｒｄｅｒすなわちオブジェクトの前後の順序を保持するために、いわゆるｚ−ｂｕｆｆｅｒが管理されている。すなわち、ある位置において描画処理が実行されるときにはいつでも、まずｚ−ｂｕｆｆｅｒがチェックされ、当該位置において描画処理が既に完了しているかどかが判断される。現在の描画処理よりも前回の描画処理の方がｚ−ｏｒｄｅｒ上では前方に存在する場合には、現在の描画処理の内容は破棄される。このアルゴリズムでは、付加的なチェック処理が必要になるが、描画処理を省略することができることから、それでもなおｐａｉｎｔｅｒ’ｓ　Ａｌｇｏｒｉｔｈｍよりもパフォーマンスがよい。ｚ−Ｂｕｆｆｅｒ　Ａｌｇｏｒｉｔｈｍでは、ある領域が既に手前で塗られたかやｚ−ｏｒｄｅｒが何であるかが常に判断されるので、特定の順番でオブジェクトを描画するという必要がない。
【００１５】
一方、Ｐａｉｎｔｅｒ‘ｓ　Ａｌｇｏｒｉｔｈｍとの比較において、ｚ−Ｂｕｆｆｅｒ　Ａｌｇｏｒｉｔｈｍの短所は、ｚ−ｂｕｆｆｅｒのための付加的なメモリが必要となる点である。このため、メモリの制約を受ける装置にとっては、このアプリケーションは非現実的である。また、このアルゴリズムは、通常、ピクセル単位で描画処理を行なうような高いパフォーマンスを持つシステム上で動作する３次元ＧＵＩに適用される。すなわち、ｚ−ｂｕｆｆｅｒは、最近の描画処理に関しては、ｚ−ｏｒｄｅｒに関する情報を各ピクセル毎に含んでいる。このような精細な解像度の描画処理を行なう場合、計算能力が比較的非力のシステム上では、ｚ−ｂｕｆｆｅｒチェックは不可能に等しい。さらに、ＧＵＩオブジェクトの描画には何ら特定の順番が規定されていないので、上述したような不必要な描画が行なわれる可能性が依然としてある。
【００１６】
ＧＵＩ画面の表示を更新する他の方法として、Ｐａｉｎｔｅｒ‘ｓ　Ａｌｇｏｒｉｔｈｍとｚ−Ｂｕｆｆｅｒ　Ａｌｇｏｒｉｔｈｍを組み合わせて構成されるＲｅｖｅｒｓｅ　Ｐａｉｎｔｅｒ’ｓ　Ａｌｇｏｒｉｔｈｍを挙げることができる。一般に、この方法は、ｚ−Ｂｕｆｆｅｒ　Ａｌｇｏｒｉｔｈｍと同様であるが、ＧＵＩオブジェクトをｚ−ｏｒｄｅｒとは逆の順番すなわち前方から公報に向かって描画する必要がある。このようにすることで、不必要な描画処理を回避することができるが、ｚ−ｂｕｆｆｅｒのメモリ・オーバーヘッドの負担はなお大きい。
【００１７】
本発明は、上述したような技術的課題を鑑みたものであり、その目的は、複数のオブジェクトで構成されユーザ・インタラクションとともに画面表示が逐次更新されるＧＵＩ画面の表示を好適に処理することができる、優れた画面表示処理装置及び画面表示処理方法、並びにコンピュータ・プログラムを提供することにある。
【００１８】
本発明のさらなる目的は、不必要なオブジェクトの描画を抑制して効率的なＧＵＩ画面の表示処理を効率的に行なうことができる、優れた画面表示処理装置及び画面表示処理方法、並びにコンピュータ・プログラムを提供することにある。
【００１９】
【課題を解決するための手段及び作用】
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、複数のオブジェクトで構成される画面の表示を画面表示出力用の画面イメージを書き込むフロント・バッファと画面表示されるイメージを構築するために使用されるバック・バッファを利用して処理する画面表示処理装置又は画面表示処理方法であって、
画面の変更に伴い、修復する必要があるダメージ領域を決定するチェック手段又はステップと、
前記チェック手段又はステップにより発見されたダメージ領域に基づいて、再描画を必要とするオブジェクトを決定する生成手段又はステップと、
前記生成手段又はステップにより決定された再描画するとオブジェクトを前記バック・バッファ上で後方から前方に向かって描画する描画手段又はステップと、
前記生成手段又はステップにおいて破棄された領域を除くすべてのダメージ領域をバック・バッファからフロント・バッファへ複製してダメージの修復を行なう画面更新手段又はステップと、
を具備することを特徴とする画面表示処理装置又は画面表示処理方法である。
【００２０】
ここで、前記チェック手段又はステップは、ｚ−ｏｒｄｅｒに従って、前方から後方に向かってオブジェクトのチェックを行ない、変化を来たしたオブジェクトを完全に含む最小の矩形をダメージ領域として抽出するようにすればよい。
【００２１】
また、前記チェック手段又はステップは、ダメージ領域の統合処理を行なうようにしてもよい。ダメージ領域の統合処理により、不必要な描画や画面表示の更新処理を削減することができる。
【００２２】
例えば、前記チェック手段又はステップは、交差する２つのダメージ領域が重なり合う領域が、統合することによって付加される領域よりも大きくなる場合に当該ダメージ領域同士を統合することができる。
【００２３】
ダメージ領域同士が重なり合う領域よりも、結合により付加される領域の方が大きくなるような場合には、これらを結合することにより得られるダメージ領域はほぼ２倍の大きさとなる。この結果、当該画像修復アルゴリズムの完了に伴いダメージ領域を更新するときに、バック・バッファからフロント・バッファへ転送するデータがより大きくなってしまうからである。さらにこの統合されたダメージ領域に第３のオブジェクトの境界ボックスが交差するような場合には、これも描画処理しなければならなくなってしまう。
【００２４】
また、前記生成手段又はステップは、手前のオブジェクトと交差しているダメージ領域のオブジェクトに対して描画処理が必要であることを示すフラグを設定するようにしてもよい。このような場合、前記描画手段又はステップは、前記生成手段又はステップにより描画処理が必要であることを示すフラグが設定されたすべてのＧＵＩオブジェクトをバック・バッファ上で用いて描画するようにすればよい。
【００２５】
また、前記生成手段又はステップは、手前のオブジェクトによって完全に覆われていないダメージ領域のオブジェクトに対して描画処理が必要であることを示すフラグを設定してもよい。このような場合、前記描画手段又はステップは、前記生成手段又はステップにより描画処理が必要であることを示すフラグが設定されたすべてのＧＵＩオブジェクトをバック・バッファ上で用いて描画するようにすればよい。
【００２６】
また、前記生成手段又はステップは、オブジェクトが完全に不透明でその境界ボックスがダメージ領域を完全に含んでいる場合には、さらにオブジェクトがダメージ領域を覆っていることを確認した上で、このダメージ領域に対して塗り潰されていることを示すフラグを設定するようにしてもよい。
【００２７】
塗り潰されているダメージ領域では、残りのオブジェクトに関して交差しているかどうかをチェックする必要はない。前方から後方に向かってオブジェクトをチェックするので、塗り潰されているとフラグが設定された後にダメージ領域と交差していることが判明したオブジェクトは、当該ダメージ領域を塗り潰すオブジェクトによって必然的に覆われることになる。この描画処理を省略することによって、画面全体における描画処理の総量を削減することができる。
【００２８】
また、前記生成手段又はステップは、オブジェクトが処理対象となっているダメージ領域よりも手前に配置されていてさらに変化がない場合には、オブジェクトとダメージ領域をともに破棄するようにしてもよい。
【００２９】
ダメージ領域が変化したオブジェクトで構成されるとしても、変化しないオブジェクトによって完全に隠れてしまい、その変化は画面上では現れないので、その描画処理を省略することができる。
【００３０】
また、本発明の第２の側面は、複数のオブジェクトで構成される画面の表示を画面表示出力用の画面イメージを書き込むフロント・バッファと画面表示されるイメージを構築するために使用されるバック・バッファを利用して行なう処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
画面の変更に伴い、修復する必要があるダメージ領域を決定するチェック・ステップと、
前記チェック・ステップにおいて発見されたダメージ領域に基づいて、再描画を必要とするオブジェクトを決定する生成ステップと、
前記生成ステップにおいて決定された再描画するとオブジェクトを前記バック・バッファ上で後方から前方に向かって描画する描画ステップと、
前記生成ステップにおいて破棄された領域を除くすべてのダメージ領域をバック・バッファからフロント・バッファへ複製してダメージの修復を行なう画面更新ステップと、
を具備することを特徴とするコンピュータ・プログラムである。
【００３１】
本発明の第２の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係る画面表示処理装置又は画面表示処理方法と同様の作用効果を得ることができる。
【００３２】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【００３３】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施形態について詳解する。
【００３４】
本発明に係る画面表示処理方法は、２次元又は２．５次元のＧＵＩ環境を提供するコンピュータ画面の描画処理に好適に適用することができる。ここで言う２．５時限のＧＵＩ画面は、２次元ＧＵＩ画面にズームやアニメーション機能が備わったものを意味する。
【００３５】
図１には、本発明が適用された画面表示処理装置１００が備える最低限のハードウェア構成を模式的に示している。
【００３６】
同図に示すように、画面表示処理装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ　ＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）１０１と、プログラムＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）１０２と、グラフィック・ハードウェア１０３とを備えている。ＣＰＵ１０１は、共通信号伝送路としてのバス（図示しない）を介して、当該装置１００を構成する各ハードウェア構成要素に相互接続されている。
【００３７】
メイン・コントローラであるＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１０１は、オペレーティング・システム（ＯＳ）の制御下で、各種のアプリケーションを実行する。本実施形態では、オペレーティング・システムは、ビットマップ表示機能を備え、２次元若しくは２．５次元のＧＵＩ環境を提供している。
【００３８】
プログラムＲＡＭ１０２は、例えば複数個のＤＲＡＭ（Ｄｙｎａｍｉｃ　ＲＡＭ）で構成され、ＣＰＵ１０１において実行されるプログラム・コードをロードしたり、実行プログラムの作業データを一時保管したりするために使用される。
【００３９】
グラフィック・ハードウェア１０３は、ＣＰＵ１０１が発行する描画命令を実際に処理するための専用コントローラであり、例えばアダプタ・カードという形態で当該装置１００に装備される。グラフィック・ハードウェア１０３には、表示出力のターゲットとして、ＣＲＴ（Ｃａｔｈｏｄｅ　Ｒａｙ　Ｔｕｂｅ）やＬＣＤ（Ｌｉｑｕｉｄ　Ｃｒｙｓｔａｌ　Ｄｉｓｐｌａｙ）などのディスプレイ（図示しない）が接続されている。本実施形態では、ディスプレイはビットマップ表示機能をサポートしているものとする。
【００４０】
図示の通り、グラフィック・ハードウェア１０３上には、画面の表示内容を一時的に書き込むフレーム・バッファとして使用されるビデオＲＡＭ１０３Ａが搭載されている。勿論、ビデオＲＡＭ１０３Ａは、図示のように独立したハードウェアではなく、プログラムＲＡＭ１０２のメモリ空間上にマッピングされたシェア・メモリの形態であってもよい。
【００４１】
なお、図示しないが、画面表示処理装置１００は、上述した以外にも、キーボードやマウスなどのユーザ入力装置や、ハード・ディスク装置やＣＤ／ＤＶＤ読み書き装置などの外部記憶装置、当該装置１００をネットワーク接続するためのネットワーク・インターフェース（ＮＩＣ）などを装備していてもよい。
【００４２】
画面表示処理装置１００の典型的な例は、パーソナル・コンピュータ（ＰＣ）などのＧＵＩ環境を提供する計算機システムである。
【００４３】
ＧＵＩ環境下では、コンピュータ・システムがシミュレートされたデスクトップと無数のアイコンがディスプレイ・スクリーンに用意される。ＧＵＩが提供されたデスクトップ上では、ファイルなどのコンピュータ・システム上のすべての資源オブジェクトはアイコンとして表現されている。ユーザは、ディスプレイ・スクリーン上のプログラム、データ、フォルダ、デバイスなどを象徴するアイコンなど画面上の表示オブジェクトに対してマウスなどのユーザ入力装置を用いて直接操作を印加する（例えば、クリックやドラッグ・アンド・ドロップ）ことで、直感的に且つ判り易くコンピュータ操作を行なうことができる。また、デスクトップ上には、メニュー・バーやツール・ボックスなど、各種の機能すなわちコンピュータ処理を瞬時に呼び出すためのボタンが用意されている。
【００４４】
ＧＵＩオブジェクトは、階層化ツリー構造を構成して、プログラムＲＡＭ１０２上で格納されている。ＣＰＵ１０１は、プログラムＲＡＭ１０２に読み書きアクセスすることができる。
【００４５】
本実施形態では、フレーム・バッファは、「フロント・バッファ」と「バック・バッファ」で構成され、これらを用いてＧＵＩオブジェクトのレンダリング処理が行なわれる。
【００４６】
フロント・バッファは、ディスプレイ上でユーザに画面表示するために使用されるＧＵＩイメージを常に保持している。これに対し、バック・バッファは、このように画面表示されるイメージを構築するために使用される。すなわち、ＧＵＩオブジェクトをレンダリングする間、それらのグラフィック表示は、まずバック・バッファ上で構築され、その完成を待って、フロント・バッファに複製される。
【００４７】
フロント・バッファは、画面出力用のデータそのものであり、ビデオＲＡＭ１０３Ａ上に存在する。また、バック・バッファは、ビデオＲＡＭ１０３Ａ又はプログラムＲＡＭ１０２のいずれに割り当ててもよい。図１に示すハードウェア構成例では、ＣＰＵ１０１は、ビデオＲＡＭ１０３Ａに対して、少なくとも書き込みアクセスを行なうことができるようになっている。
【００４８】
図２には、本発明の実施形態に係る画面表示処理アルゴリズムの構成を模式的に示している。
【００４９】
この画面表示処理は、レンダリング・サイクルにおいてＧＵＩ画面上でダメージが発生したとき、すなわち、修復（再描画）を必要とするようなＧＵＩイメージの変更が生じたことに応答して起動する。例えば、ドロップ−ダウン・メニューをクローズしたとき、メニューが表示されていた領域をメニューが覆っていた通りに表示するように再び回復する必要があるときなどである。
【００５０】
第１の処理フェーズでは、修復する必要があるＧＵＩ領域、すなわち「ダメージ領域」と呼ばれる領域を決定する。この処理フェーズのことを以下では「チェック・フェーズ」と呼び、その詳細な処理手順を図３に示している。
【００５１】
続く第２の処理フェーズでは、チェック・フェーズにおいて発見されたダメージ領域を基に、修復を必要とするオブジェクトを決定して、これらにフラグを設定する。この処理フェーズのことを以下では「生成（Ｇｅｎｅｒａｔｅ）フェーズ」と呼び、その詳細な処理手順を図４に示している。
【００５２】
続く第３の処理フェーズでは、生成フェーズにおいてフラグが設定されたすべてのＧＵＩオブジェクトをバック・バッファ上で用いて描画する。このとき、各オブジェクトを後方から前方に向かって描画する。この処理フェーズのことを「描画（Ｐａｉｎｔ）フェーズ」と呼ぶ。
【００５３】
続く第４の処理フェーズでは、すべてのダメージ領域をバック・バッファからフロント・バッファへ複製することによって、ダメージの修復を完成する。このとき、生成フェーズにおいて破棄された領域を排除して、ダメージ領域の複製が行なわれる。この処理フェーズのことを「更新（Ｕｐｄａｔｅ）フェーズ」と呼ぶ。
【００５４】
第２の処理フェーズでは、すべてのＧＵＩオブジェクトに関して、発見されたすべてのダメージ領域と交差するかどうかをチェックする。そして、ｚ−ｏｒｄｅｒに従って、ＧＵＩオブジェクトを前方から後方に向かって再度チェックする。
【００５５】
図３には、第２の処理フェーズであるチェック・フェーズにおける詳細な処理手順を示している。
【００５６】
変化を来たしたすべてのＧＵＩオブジェクトをチェックすることによって、ダメージ領域が決定される。但し、ｚ−ｏｒｄｅｒに従って、前方から後方に向かってオブジェクトのチェックが行なわれる。
【００５７】
変化があったオブジェクトが発見された場合（判断ブロックａ）、変化前（ｐｒｅｖｉｏｕｓ）及び変化後（ｃｕｒｒｅｎｔ）の境界ボックスがダメージ領域となる（図１１を参照のこと）。ここで、変化後の境界ボックスはいま現在のオブジェクトの境界ボックスであり、変化前の境界ボックスは最後に描画されたオブジェクトの境界ボックスである（図１０を参照のこと）。境界ボックスは、当該オブジェクトを完全に含み水平方向に位置調整（ａｌｉｇｎ）された最も小さな矩形がダメージ領域となる。図５には、さまざまの形状のＧＵＩオブジェクトに関する境界ボックスを示している。各々のダメージは、そのダメージ領域内で処理される。
【００５８】
次いで、すべてのダメージ領域について統合処理を行なう。もし２つのダメージ領域が所定以上交差しているならば、１つのダメージ領域に結合される（判断ブロックｂ）。すなわち、オブジェクトの前回又は現在の境界ボックスがダメージ領域と交差しているかどうかを判断し、交差している場合には、当該オブジェクトの前回又は現在の境界ボックスをダメージ領域に統合する。そして、ダメージ領域を取り除いて、統合した領域として再スタートする。このようなダメージ領域の統合処理により、不必要な描画や画面表示の更新処理を削減することができる。
【００５９】
例えば図６に示すように、ダメージ領域同士が重なり合う領域よりも、結合により付加される領域の方が大きくなるような場合には、これらを結合することにより得られるダメージ領域はほぼ２倍の大きさとなる。この結果、当該画像修復アルゴリズムの完了に伴いダメージ領域を更新するときに、バック・バッファからフロント・バッファへ転送するデータがより大きくなってしまう。さらにこの統合されたダメージ領域に第３のオブジェクトの境界ボックスが交差するような場合には、これも描画処理しなければならなくなってしまう。したがって、このような場合には、２つのダメージ領域を個別に処理することが効率的であることから、ダメージ領域の統合は行なわない。
【００６０】
一方、２つのダメージ領域の合計が統合したダメージ領域よりも大きいとき、交差する２つのダメージ領域が重なり合う領域が、統合することによって付加される領域よりも大きくなるとき（図７を参照のこと）には、既に統合されているダメージ領域を２つの個別のダメージ領域として取り扱うことがむしろ不利である。交差するダメージ領域を統合するかどうかを判断する閾値は、このアルゴリズムにおけるパラメータである。
【００６１】
ダメージ領域を決定するとき、ｚ−ｏｒｄｅｒに従い、ＧＵＩオブジェクトを前方から後方に向かってチェックする。最前方のオブジェクトは、ｚ−ｏｒｄｅｒ上ではレベル０である。レベル番号は、後方に向かうに従って各オブジェクト毎に１ずつ増分する。ダメージ領域が発見された場合、関連するＧＵＩオブジェクトのｚ−ｏｒｄｅｒ上のレベルがダメージ領域に割り当てられる。例えば、最前方から３番目のオブジェクトに変化があった場合、この結果として取り出されるダメージ領域にはｚ−ｏｒｄｅｒ上のレベル２が割り当てられる。また、２つのダメージ領域を統合した場合、これら２つのダメージ領域のうち低い方のｚ−ｏｒｄｅｒレベルが統合した結果のダメージ領域に割り当てられる。割り当てられる。
【００６２】
このようにして、すべてのダメージ領域についてチェックが終了したならば、オブジェクトの前回及び現在の境界ボックスをダメージ領域のリストに追加する。
【００６３】
さらに未処理のオブジェクトが残っている場合には、次のオブジェクトを取り出して、変化の有無をチェックして、上述と同様の処理を繰り返し実行する。
【００６４】
また、図４には、第３の処理フェーズである生成フェーズの詳細な処理手順を示している。
【００６５】
この生成フェーズでは、すべてのＧＵＩオブジェクトについて、上述したチェック・フェーズにて発見されたすべてのダメージ領域と交差するかどうかをチェックする。但し、ｚ−ｏｒｄｅｒに従って、前方から後方に向かってオブジェクトのチェックが行なわれる。そして、オブジェクトがあるダメージ領域と交差していることが判明したときには、そのオブジェクトに対して描画処理が必要であることを示すフラグを設定する。
【００６６】
すべてのＧＵＩオブジェクトについて、前方から後方に向かって、画面上で見えている（ｖｉｓｉｂｌｅ）かどうかをチェックする（判断ブロックａ）。
【００６７】
そして、視覚可能なオブジェクトについて、すべてのダメージ領域との関係をチェックする。まず、オブジェクトがダメージ領域を塗り潰していないかどうかをチェックする（判断ブロックｂ）。オブジェクトがダメージ領域を満たしていないときには、次いで、オブジェクトの境界ボックスがダメージ領域を交差しているかどうかをチェックする（判断ブロックｃ）。オブジェクトの境界ボックスがダメージ領域を交差していないときには、オブジェクトが完全に不透明でその境界ボックスがダメージ領域を完全に含んでいるかどうかをチェックする。
【００６８】
オブジェクトが完全に不可視（ｏｐａｑｕｅ）でその境界ボックスがダメージ領域を完全に含んでいる場合には（判断ブロックｄ）、さらにオブジェクトがダメージ領域を覆っている（すなわち、ｚ−ｏｒｄｅｒ上で手前にあり、オブジェクトに変化がない）ことを確認した上で（判断ブロックｅ）、このダメージ領域に対して塗り潰されている（ｆｉｌｌｅｄ）ことを示すフラグを設定する。塗り潰されているダメージ領域では、残りのオブジェクトに関して交差しているかどうかをチェックする必要はない。図８には、不可視のオブジェクトと完全に不可視ではないオブジェクトを例示している。
【００６９】
前方から後方に向かってオブジェクトをチェックするので、塗り潰されているとフラグが設定された後にダメージ領域と交差していることが判明したオブジェクトは、当該ダメージ領域を塗り潰すオブジェクトによって必然的に覆われることになる。この描画処理を省略することによって、画面全体における描画処理の総量を削減することができる。
【００７０】
また、オブジェクトが処理対象となっているダメージ領域よりも低いｚ−ｏｒｄｅｒレベルを持っている、すなわち手前に配置されている場合であって、さらに変化がない場合には、オブジェクトとダメージ領域をともに破棄することができる。何故ならば、ダメージ領域が変化したオブジェクトで構成されるとしても、変化しないオブジェクトによって完全に隠れてしまうからである。このような場合、ダメージ領域内のオブジェクトの変化は隠されてしまうので、その描画処理を省略することができる。
【００７１】
一方、判断ブロックｄにおいて、境界ボックスがダメージ領域を完全に含んでいないと判断された場合には、ダメージ領域内のオブジェクトに対して描画処理が必要であることを示すフラグを設定する。
【００７２】
図９には、ダメージ領域を描画処理すべきか又は破棄してもよいかどうかを判断するための基準を図解している。ダメージ領域の手前のオブジェクトがダメージ領域を完全には覆っていない場合には、ダメージ領域を描画処理する必要がある。また、ダメージ領域が不可視（ｏｐａｑｕｅ）のオブジェクトで覆われているダメージ領域は描画処理する必要がある。また、手前のオブジェクトによって完全に覆われているダメージ領域は、描画処理を省略することができるので、処理対象から外す（ｄｉｓｃａｒｄ）ことができる。
【００７３】
［追補］
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【００７４】
【発明の効果】
以上詳記したように、本発明によれば、複数のオブジェクトで構成されユーザ・インタラクションとともに画面表示が逐次更新されるＧＵＩ画面の表示を好適に処理することができる、優れた画面表示処理装置及び画面表示処理方法、並びにコンピュータ・プログラムを提供することができる。
【００７５】
また、本発明によれば、不必要なオブジェクトの描画を抑制して効率的なＧＵＩ画面の表示処理を行なうことができる、優れた画面表示処理装置及び画面表示処理方法、並びにコンピュータ・プログラムを提供することができる。
【００７６】
本発明に係る画像表示処理装置又は画像表示処理方法によれば、ＧＵＩ画面を再描画する際の描画処理数を削減することができる。
【００７７】
また、本発明に係る画像表示処理装置又は画像表示処理方法によれば、ＧＵＩ画面を再描画する際の、バック・バッファからフロント・バッファへ転送するデータの総量を削減することができる。
【００７８】
また、本発明に係る画像表示処理装置又は画像表示処理方法によれば、ＧＵＩ環境を提供するコンピュータ処理において必要とされるメモリ容量を削減することができる。
【図面の簡単な説明】
【図１】本発明が適用された画面表示処理装置１００が備える最低限のハードウェア構成を模式的に示した図である。
【図２】本発明の実施形態に係る画面表示処理アルゴリズムの構成を模式的に示した図である。
【図３】本発明の実施形態に係る画面表示処理アルゴリズムのチェック・フェーズにおける詳細な処理手順を示した図である。
【図４】本発明の実施形態に係る画面表示処理アルゴリズムの生成フェーズにおける詳細な処理手順を示した図である。
【図５】さまざまの形状のＧＵＩオブジェクトに関する境界ボックスの例を示した図である。
【図６】ダメージ領域同士を統合する処理を説明するための図である。
【図７】ダメージ領域同士を統合する処理を説明するための図である。
【図８】不可視のオブジェクトと完全に不可視ではないオブジェクトを例示した図である。
【図９】ダメージ領域を描画処理すべきか又は破棄してもよいかどうかを判断するための基準を示した図である。
【図１０】アニメーションＧＵＩにおいて画面を修復するための処理手順（従来例）を説明するための図である。
【図１１】アニメーションＧＵＩにおいて画面を修復するための処理手順（従来例）を説明するための図である。
【符号の説明】
１００…画面表示処理装置
１０１…ＣＰＵ
１０２…プログラムＲＡＭ
１０３…グラフィック・ハードウェア
１０３Ａ…ビデオＲＡＭ

Claims (17)

1. 複数のオブジェクトで構成される画面の表示を処理する画面表示処理装置であって、
   画面表示出力用の画面イメージを書き込むフロント・バッファと、
   画面表示されるイメージを構築するために使用されるバック・バッファと、
   画面の変更に伴い、修復する必要があるダメージ領域を決定するチェック手段と、
   前記チェック手段により発見されたダメージ領域に基づいて、再描画を必要とするオブジェクトを決定する生成手段と、
   前記生成手段により決定された再描画するとオブジェクトを前記バック・バッファ上で後方から前方に向かって描画する描画手段と、
   前記生成手段において破棄された領域を除くすべてのダメージ領域をバック・バッファからフロント・バッファへ複製してダメージの修復を行なう画面更新手段と、
   を具備することを特徴とする画面表示処理装置。
2. 前記チェック手段は、ｚ−ｏｒｄｅｒに従って、前方から後方に向かってオブジェクトのチェックを行ない、変化を来たしたオブジェクトを完全に含む最小の矩形をダメージ領域として抽出する、
   ことを特徴とする請求項１に記載の画面表示処理装置。
3. 前記チェック手段は、ダメージ領域の統合処理を行なう、
   ことを特徴とする請求項１に記載の画面表示処理装置。
4. 前記チェック手段は、交差する２つのダメージ領域が重なり合う領域が統合することによって付加される領域よりも大きくなる場合に当該ダメージ領域同士を統合する、
   ことを特徴とする請求項３に記載の画面表示処理装置。
5. 前記生成手段は、手前のオブジェクトと交差しているダメージ領域のオブジェクトに対して描画処理が必要であることを示すフラグを設定し、
   前記描画手段は、前記生成手段により描画処理が必要であることを示すフラグが設定されたすべてのＧＵＩオブジェクトをバック・バッファ上で用いて描画する、
   ことを特徴とする請求項１に記載の画面表示処理装置。
6. 前記生成手段は、手前のオブジェクトによって完全に覆われていないダメージ領域のオブジェクトに対して描画処理が必要であることを示すフラグを設定し、前記描画手段は、前記生成手段により描画処理が必要であることを示すフラグが設定されたすべてのＧＵＩオブジェクトをバック・バッファ上で用いて描画する、
   ことを特徴とする請求項１に記載の画面表示処理装置。
7. 前記生成手段は、オブジェクトが完全に不透明でその境界ボックスがダメージ領域を完全に含んでいる場合には、さらにオブジェクトがダメージ領域を覆っていることを確認した上で、このダメージ領域に対して塗り潰されていることを示すフラグを設定する、
   ことを特徴とする請求項１に記載の画面表示処理装置。
8. 前記生成手段は、オブジェクトが処理対象となっているダメージ領域よりも手前に配置されていてさらに変化がない場合には、オブジェクトとダメージ領域をともに破棄する、
   ことを特徴とする請求項１に記載の画面表示処理装置。
9. 複数のオブジェクトで構成される画面の表示を画面表示出力用の画面イメージを書き込むフロント・バッファと画面表示されるイメージを構築するために使用されるバック・バッファを利用して処理する画面表示処理方法であって、
   画面の変更に伴い、修復する必要があるダメージ領域を決定するチェック・ステップと、
   前記チェック・ステップにおいて発見されたダメージ領域に基づいて、再描画を必要とするオブジェクトを決定する生成ステップと、
   前記生成ステップにおいて決定された再描画するとオブジェクトを前記バック・バッファ上で後方から前方に向かって描画する描画ステップと、
   前記生成ステップにおいて破棄された領域を除くすべてのダメージ領域をバック・バッファからフロント・バッファへ複製してダメージの修復を行なう画面更新ステップと、
   を具備することを特徴とする画面表示処理方法。
10. 前記チェック・ステップでは、ｚ−ｏｒｄｅｒに従って、前方から後方に向かってオブジェクトのチェックを行ない、変化を来たしたオブジェクトを完全に含む最小の矩形をダメージ領域として抽出する、
    ことを特徴とする請求項９に記載の画面表示処理方法。
11. 前記チェック・ステップでは、ダメージ領域の統合処理を行なう、
    ことを特徴とする請求項９に記載の画面表示処理方法。
12. 前記チェック・ステップでは、交差する２つのダメージ領域が重なり合う領域が統合することによって付加される領域よりも大きくなる場合に当該ダメージ領域同士を統合する、
    ことを特徴とする請求項９に記載の画面表示処理方法。
13. 前記生成ステップでは、手前のオブジェクトと交差しているダメージ領域のオブジェクトに対して描画処理が必要であることを示すフラグを設定し、
    前記描画ステップでは、前記生成ステップにおいて描画処理が必要であることを示すフラグが設定されたすべてのＧＵＩオブジェクトをバック・バッファ上で用いて描画する、
    ことを特徴とする請求項９に記載の画面表示処理方法。
14. 前記生成ステップでは、手前のオブジェクトによって完全に覆われていないダメージ領域のオブジェクトに対して描画処理が必要であることを示すフラグを設定し、
    前記描画ステップでは、前記生成ステップにおいて描画処理が必要であることを示すフラグが設定されたすべてのＧＵＩオブジェクトをバック・バッファ上で用いて描画する、
    ことを特徴とする請求項９に記載の画面表示処理方法。
15. 前記生成ステップでは、オブジェクトが完全に不透明でその境界ボックスがダメージ領域を完全に含んでいる場合には、さらにオブジェクトがダメージ領域を覆っていることを確認した上で、このダメージ領域に対して塗り潰されていることを示すフラグを設定する、
    ことを特徴とする請求項９に記載の画面表示処理方法。
16. 前記生成ステップでは、オブジェクトが処理対象となっているダメージ領域よりも手前に配置されていてさらに変化がない場合には、オブジェクトとダメージ領域をともに破棄する、
    ことを特徴とする請求項９に記載の画面表示処理方法。
17. 複数のオブジェクトで構成される画面の表示を画面表示出力用の画面イメージを書き込むフロント・バッファと画面表示されるイメージを構築するために使用されるバック・バッファを利用して行なう処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
    画面の変更に伴い、修復する必要があるダメージ領域を決定するチェック・ステップと、
    前記チェック・ステップにおいて発見されたダメージ領域に基づいて、再描画を必要とするオブジェクトを決定する生成ステップと、
    前記生成ステップにおいて決定された再描画するとオブジェクトを前記バック・バッファ上で後方から前方に向かって描画する描画ステップと、
    前記生成ステップにおいて破棄された領域を除くすべてのダメージ領域をバック・バッファからフロント・バッファへ複製してダメージの修復を行なう画面更新ステップと、
    を具備することを特徴とするコンピュータ・プログラム。

Images