JP2007187849A - 画像表示装置及びウインドウ制御プログラム - Google Patents

Abstract

【課題】汎用システムを用いながら、シングル走査型のメモリ性表示デバイス上への画像の表示が不完全になることを防止できる画像表示装置及びウインドウ制御プログラムを得る。
【解決手段】メモリ性表示デバイス10とそれに表示される画像データを記憶するためのフレームバッファと、LCDドライバIC37と、記録部30と、CPU36とを備えた画像表示装置。記録部30には、汎用オペレーティングシステム、該システムで実行されるGUI形式のアプリケーションプログラム、及び、汎用オペレーティングシステム上で動作し表示デバイス10の画面に表示されるウインドウを制御するための制御プログラムがインストールされている。制御プログラムは、アプリケーションプログラムからの描画イベントに従ってフレームバッファを更新し、また、アプリケーションプログラムとの間の通信に基づいて表示デバイス10への描画タイミングを検知して表示デバイス10への描画開始をLCDドライバIC37に指示する。
【選択図】図２

Description

本発明は、画像表示装置及びウインドウ制御プログラム、特に、メモリ性表示デバイスを備えた画像表示装置、及び、メモリ性表示デバイスの画面に表示されるウインドウの制御をコンピュータによって実現させるウインドウ制御プログラムに関する。

近年、低消費電力型の画像ビューワーとして、メモリ性表示デバイスを搭載した電子ブックなどと称する画像表示装置が種々提案／実用化されている。

画像ビューワーの機能として、単純にメモリ性表示デバイスにコンテンツのデータを表示させるだけではなく、表示させるデータを複数のフォーマットに対応させて、複数のビューワーソフトウェアを開いて表示したり、ユーザーインターフェースにＧＵＩ（グラフィカルユーザーインターフェース）形式のアプリケーションを実装して使用するなどの高機能化への要望がある。

そのようなシステムを効率よく実装するには、表示デバイス、ファイル、メモリ、プロセスなどを管理するオペレーティングシステムとＧＵＩのウインドウを管理するウインドウシステムと呼ばれるウインドウ制御プログラムが必要である。特許文献１には、ＧＵＩ形式のアプリケーションを用いてユーザーにとって使いやすいコンピュータ環境を実現することが開示されている。

汎用システムとしては、汎用オペレーティングシステムであるＬｉｎｕｘ（登録商標）とＬｉｎｕｘ上で動作可能なウインドウシステムであるＸｗｉｎｄｏｗ（登録商標）が既に存在し、これらを利用することで効率のよいシステムの構築が可能である。しかしながら、これらの汎用システムには、メモリ性表示デバイスを想定した設計はされておらず、メモリ性表示デバイスへの正常な表示を行うことが実質的にできないという問題点を有していた。

なぜなら、Ｘｗｉｎｄｏｗはフレームバッファへのビットマップデータの更新を行うだけであり、実際の表示は、ＸｗｉｎｄｏｗとＬｉｎｕｘの間で標準出力として割り当てられた表示デバイスのソフトウェアドライバを制御することで行われるためである。

一般に使用されている表示デバイスであるＣＲＴモニタ、ＴＦＴ液晶モニタなどのいわゆるリフレッシュ駆動が必要で画面が連続走査されるタイプの表示デバイス（以下、連続走査型表示デバイスという）では、１秒間に数十フレームの描画が連続に行われており、アプリケーション側での処理が重く、表示に必要なビットマップデータの作成に時間がかかっても、駆動回路であるデバイスドライバによって描画が連続的に行われる。それゆえ、あるフレームの更新タイミングでビットマップデータの生成が間に合わなくても、以降の描画タイミングのいずれかには間に合うため、連続走査による描画を行っている場合、フレームバッファへの更新で数フレーム分、データの欠落が生じても、いずれはデータの欠落が解消され、人間の目では何の違和感もなく表示データを観察することができる。

しかしながら、汎用のオペレーティングシステムと汎用のウインドウシステムとから構成されるシステムを用いて、リフレッシュ駆動が不要で１度の画面走査（シングル走査）で描画を完了し表示を行わせると、画像が不完全な状態で表示されてしまうなどして、良好な表示を行わせることができなかった。このように、汎用のオペレーティングシステムと汎用のウインドウシステムとから構成されるシステムを用いて、メモリ性表示デバイスに良好な表示を行わせることはこれまで提案されていなかった。
特開２００２−２９７２７９号公報

そこで、本発明の目的は、汎用システムを用いながら、シングル走査型のメモリ性表示デバイス上への画像の表示が不完全になることを防止することのできる画像表示装置及びウインドウ制御プログラムを提供することにある。

以上の目的を達成するため、第１の発明に係る画像表示装置は、
メモリ性表示デバイスと、
該メモリ性表示デバイスに表示される画像データを記憶するためのフレームバッファと、
該フレームバッファに記憶された画像データに基づいて前記メモリ性表示デバイスに描画を行うための駆動回路と、
汎用のオペレーティングシステム、該汎用のオペレーティングシステムで実行されるグラフィカルユーザーインターフェース形式のアプリケーションプログラム、及び、前記汎用のオペレーティングシステム上で動作し前記メモリ性表示デバイスの画面に表示されるウインドウを制御するためのウインドウ制御プログラムがインストールされたコンピュータ部と、を備え、
前記ウインドウ制御プログラムは、前記アプリケーションプログラムからの描画イベントに従ってフレームバッファを更新し、また、前記アプリケーションプログラムとの間の通信に基づいて前記メモリ性表示デバイスへの描画タイミングを検知して前記メモリ性表示デバイスへの描画開始を前記駆動回路に指示すること、
を特徴とする。

第２の発明に係るウインドウ制御プログラムは、汎用のオペレーティングシステム及びグラフィカルユーザーインターフェース形式のアプリケーションプログラムがインストールされたコンピュータ環境において、メモリ性表示デバイスの画面に表示されるウインドウの制御をコンピュータによって実現させるウインドウ制御プログラムであって、
前記ウインドウ制御プログラムは、前記アプリケーションプログラムからの描画イベントに従ってフレームバッファを更新し、また、前記アプリケーションプログラムとの間の通信に基づいて前記メモリ性表示デバイスへの描画タイミングを検知して前記メモリ性表示デバイスへの描画開始を指示すること、
を特徴とする。

第１及び第２の発明において、ウインドウ制御プログラムはアプリケーションプログラムからの描画イベントに従ってフレームバッファを更新し、また、アプリケーションプログラムとの間の通信に基づいてメモリ性表示デバイスへの描画タイミングを検知してメモリ性表示デバイスへの描画開始を駆動回路に指示する。その結果、メモリ性表示デバイスを意識する必要なく、グラフィカルユーザーインターフェース形式のアプリケーションプログラムも通常のウインドウシステムに対応してメモリ性表示デバイスへの表示を行うことが可能になり、グラフィカルユーザーインターフェース形式のアプリケーションプログラムで作成途中の画像が表示される不具合を解消できる。また、グラフィカルユーザーインターフェース形式のアプリケーションプログラムはウインドウシステムに対応したアプリケーションプログラムであるので、実装さえ行うことができれば、連続走査型であるＣＲＴモニタやＴＦＴ液晶モニタなどでも全く問題なく表示が可能となる。

第１及び第２の発明において、ウインドウ制御プログラムは、アプリケーションプログラムからの描画イベントから所定時間経過した後にメモリ性表示デバイスへの描画開始を駆動回路に指示するようにしてもよい。また、ウインドウ制御プログラムは、アプリケーションプログラムからのイベント待ちを示すイベントを受け取った場合に、メモリ性表示デバイスへの描画開始を駆動回路に指示するようにしてもよい。あるいは、ウインドウ制御プログラムは、メモリ性表示デバイスへの描画開始を駆動回路に指示した後、画像表示装置をサスペンドモードに移す指示を行うようにしてもよい。

以下、本発明に係る画像表示装置及びウインドウ制御プログラムの実施例について、添付図面を参照して説明する。

（実施例１、図１〜図７参照）
典型的な汎用オペレーティングシステムであるＬｉｎｕｘを実装しているシステムでＧＵＩ形式のアプリケーションを実行させる場合は、Ｘｗｉｎｄｏｗのような汎用ウインドウシステム又はＱＴ、Ｐｏｗｅｒ−ｐａｒｔ、ＰｅｇといったＧＵＩ専用キットと呼ばれる制御プログラムを必要とするが、実施例１では、汎用ＯＳにＬｉｎｕｘ、ウインドウシステムにＸｗｉｎｄｏｗをベースとしたウインドウ制御プログラムを用いることとする。

ここで、ＬｉｎｕｘでＸｗｉｎｄｏｗとＧＵＩアプリケーションを実現するための好適な環境について説明する。Ｘｗｉｎｄｏｗは、ＬｉｎｕｘやＵＮＩＸ（登録商標）での標準的なウインドウシステムであり、ユーザーインターフェイスや外部インターフェースからのイベント処理、ウインドウ管理、アプリケーションから依頼されたグラフィック処理を行うウインドウシステムである。

ＧＴＫ＋は、Ｘｗｉｎｄｏｗの上位に位置するウインドウシステムで、Ｘｗｉｎｄｏｗの機能を利用したＧＵＩ用のツールキットであり、内部に持つライブラリはＸｗｉｎｄｏｗの機能をラッピングして使いやすくしたものである。

ＧＮＯＭＥも、Ｘｗｉｎｄｏｗの上位に位置するウインドウシステムであり、Ｘｗｉｎｄｏｗベースのデスクトップ環境とネットワークを基本としたアプリケーションを開発するためのツール、ライブラリを提供するものである。

ＬｉｎｕｘのＧＵＩアプリケーションは、Ｘｗｉｎｄｏｗ用のライブラリｘｌｉｂを用いて作成することもできるが、ｘｌｉｂは点を打つ、線を引くといった基本的な機能の集まりであるため、ＧＵＩアプリケーション上でボタンなどのウィジットを表示させるなどの複雑なプログラムを作ると大きく複雑なものになってしまう。そこで、いくつかの機能をラッピングして合わせ込んだＧＵＩ用ツールキットとして、ＧＴＫ＋、ＧＮＯＭＥを利用することで容易に多機能なアプリケーションの開発が可能となる。

ところで、汎用のウインドウシステムＸｗｉｎｄｏｗを実装し、ツールキットを利用してＧＵＩアプリケーションを開発しても、メモリ性表示デバイスへの表示を正確に行うことはできない。なぜなら、Ｘｗｉｎｄｏｗはデバイスドライバが表示の際にアクセスに行くフレームバッファへのビットマップデータの更新を行うだけで、ＧＵＩアプリケーションも、実際の表示デバイスの制御には関心を払うことなく、「この点からあの点まで線を描け」、「この文字列を描写せよ、フォントはこれを使って」とかの指示を伝えるだけであり、実際の表示は、ＸｗｉｎｄｏｗとＬｉｎｕｘの間で標準出力として割り当てられた表示デバイスのソフトウェアドライバを制御することで行われるためである。

メモリ性表示デバイスを用いた場合は、ＣＲＴモニタやＴＦＴ液晶モニタのように連続的にフレームバッファを読み込んで表示を行っていたのでは、省電力という利点を活かすことができない。一方、アプリケーションで処理された結果をいつＸｗｉｎｄｏｗがフレームバッファに書き込んで終えたのかを把握せずに、任意のタイミングで表示デバイスへの描画を行っていたのでは、フレームバッファの更新途中の画像が表示されてしまう可能性があり、そのままでの使用は困難である。

そこで、Ｘｗｉｎｄｏｗを実装したシステムにおいて、Ｘｗｉｎｄｏｗ側でＧＵＩアプリケーションの状態を通信により把握してメモリ性表示デバイスへの描画タイミングを検知できる機能を追加し、ウインドウシステム自身で描画タイミングを管理することで、シングル走査でメモリ性表示デバイスの表示を行うことが可能となる。これにて、省電力の利点を活かした状態で、汎用のオペレーティングシステムでのＧＵＩ環境の構築が実現されることになる。

以下に、メモリ性表示デバイスを備えた画像表示装置の実施形態について図面を参照して説明する。図１に示すように、この画像表示装置１は、不揮発性のメモリ性表示デバイス１０を備え、操作スイッチなどを含む操作部１５からの指示により表示デバイス１０へ画像データ（図１（Ａ）参照）や、テキストデータ（図１（Ｂ）参照）などの電子データを画像表示する。

メモリ性表示デバイスとしては、強誘電性液晶表示素子、反強誘電性液晶表示素子、強誘電性高分子液晶表示素子、室温でコレステリック液晶相を示すカイラルネマチック液晶などを用いたコレステリック液晶表示素子、エレクトロクロミック表示素子、電気泳動セルを有する表示素子、乾式粉体を基板内に封入し電界で移動させて表示を行う粒子移動型表示素子、銀の析出と溶解により表示を行う表示素子、ツイストボールを有する表示素子など、従来知られている様々な表示素子が使用できる。要は、一度の走査で描画を完了し、その後は外部からの電界等のエネルギー印加を停止した状態でも実質的に永久的に表示を維持できる表示デバイスであればよい。ここでは、一例として、マトリクス状に複数の画素が配置されたコレステリック液晶表示素子などのメモリ性を有する液晶表示素子を採用している。

図１（Ｃ）は、不揮発性のメモリ性表示デバイス１０に画像データを表示する際に、ウインドウシステムであるＸｗｉｎｄｏｗとＧＵＩアプリケーションの処理の同期をとる手段がなく、不具合な表示がなされた場合を示している。即ち、図１（Ｂ）の画面から図１（Ａ）の画面へ切り換わる途中の両者が混在した画像が表示されている例である。図１（Ａ），（Ｂ）は、本実施形態によってＸｗｉｎｄｏｗとＧＵＩアプリケーションの処理の同期がとれた状態で表示が行われている場合を示している。

図２に画像表示装置１のハードウェア構成を示す。ハードウェアは、前記メモリ性表示デバイス１０やユーザーインターフェース部２０に加えて、外部インターフェース部２５、記録部３０、制御部３５にて構成されている。

ユーザーインターフェース部２０は、キースイッチ、タッチパネルなどが含まれる。外部インターフェース部２５は、ＬＡＮなどのネットワーク、ＰＣＭＣＩＡ規格のＰＣカードなどの拡張カードや外部機器、ＳＤメモリカードやコンパクトフラッシュ（登録商標）などの情報記憶メディアとの接続を確立する。記録部３０は、ＳＤＲＡＭ３１とフラッシュＲＯＭ３２とからなり、ＯＳであるＬｉｎｕｘ、表示デバイスの画面に表示されるウインドウを制御するためのウインドウ制御プログラムであるＸｗｉｎｄｏｗ、ＧＵＩアプリケーションプログラム、表示データを格納している。制御部３５は、ＣＰＵ３６とメモリ性表示デバイス１０を駆動するためのＬＣＤドライバＩＣ３７とからなる。ＣＰＵ３６はユーザーインターフェース部２０からの入力・指示に応じて各部を制御する。ＬＣＤドライバＩＣ３７はメモリ性表示デバイス１０を駆動する。記録部３０及びＣＰＵ３６によって、制御プログラムを実行するためのコンピュータ部が構成される。

図３に画像表示装置１のソフトウェアシステムの構成を示す。デバイス部４２に対してソフトウェア部４１は、全体を管理するＯＳであるＬｉｎｕｘ、ウインドウを管理するウインドウシステムであるＸｗｉｎｄｏｗ、ＧＵＩツールであるＧＴＫ＋、ＧＮＯＭＥ、ＧＵＩアプリケーションプログラム、キー入力デバイス、表示デバイスであるＬＣＤ、タッチパネルやマウスなどのポインティングデバイス等の各デバイス用のソフトウェアドライバからなる。

まず、比較のために、前期ソフトウェアシステムにおいて汎用のウインドウシステムをそのまま使用し、連続走査型表示デバイスに描画する様子を図４に示す。

Ｘｗｉｎｄｏｗは、ＬｉｎｕｘでＧＵＩを構築する際に必要となるウインドウシステムであり、その機能としては、外部インターフェース部２５やユーザーインターフェイス部２０からの入力に対して、アクティブになっているウインドウを判別する。さらに、外部インターフェース部２５から入力されたコードを取得して、アクティブウインドウの対象となるＧＵＩアプリケーションに受信したコードを転送したり、画像のフレームバッファを更新するなどの作業を実行する。

表示デバイス１０への描画を行うフレームバッファのデータの更新は、ＧＵＩアプリケーションからＸｗｉｎｄｏｗにＧＵＩアプリケーションが必要とする描画用パーツである様々なウィジットの作成を依頼することで行われる。しかし、ＧＵＩアプリケーションとＸｗｉｎｄｏｗの間で描画タイミングの作成依頼の受取りや、描画データ作成終了の確認等は行われず、ＧＵＩアプリケーションから必要なウィジットの依頼をバッファリングしてＸｗｉｎｄｏｗが所定のタイミングで順次データの作成を行う。従って、全てのウィジットの作成終了もＧＵＩアプリケーションに知らされることはない。

ＧＵＩアプリケーションは、キー入力を受け取り、そのキーコードに応じた演算処理を行い、ウインドウに表示するための画像データの作成依頼をＸｗｉｎｄｏｗに対して行う。

Ｘｗｉｎｄｏｗは、ＧＵＩアプリケーションから必要なウィジットの依頼をバッファリングして順にデータの作成を行っているため、ＧＵＩアプリケーションが処理をしている間も、フレームバッファへの更新を行うことになり、Ｘｗｉｎｄｏｗで全ての画像データの作成が終了する前に描画を行うと、ＧＵＩアプリケーションで作成途中の画像が表示デバイス１０に表示されてしまう。このように、ＧＵＩアプリケーションが表示用データの作成を依頼することと、Ｘｗｉｎｄｏｗがフレームバッファへの更新を行うことの同期がとれていなくても、ＣＲＴモニタ、ＴＦＴモニタなど連続走査型の表示デバイスは、１秒間に数十フレームといった走査を連続的に行っているため、フレームバッファの更新の遅れが問題になることはない。しかし、シングル走査型のメモリ性表示デバイスでは、アプリケーションから依頼した処理が終了し、フレームバッファの更新を行った後で表示を開始しないと、アプリケーションでの処理途中の画像が表示、書き込まれ、使用者に視認されてしまうことになる。

連続走査では単位時間当たり決められたレートでフレームバッファのデータをモニタへ出力する。しかし、シングル走査では、メモリ性表示デバイスを対象として、表示の際、一度だけフレームバッファのデータを表示デバイスに出力するために前述の不具合を生じることになる。

本実施例１は、ウインドウシステムにＸｗｉｎｄｏｗを搭載してＧＵＩ環境を実現しているシステムにおいて、シングル走査で画像の表示を行うメモリ性表示デバイス１０でもＧＵＩが実現できるように、ウインドウシステムとＧＵＩアプリケーションとの間で、双方の通信に基づいて、描画タイミングを検知するように、ウインドウシステムがプログラムされている。

図５に、シングル走査型のメモリ性表示デバイス１０に、本実施例１の如く、ＧＵＩアプリケーションの状態を通信により把握し、メモリ性表示デバイス１０への描画タイミングを検知できる機能をウインドウシステムに追加した場合の描画の様子を示す。

ＧＵＩアプリケーションとの同期をとりながらメモリ性表示デバイス１０へ書き込むタイミングを把握できることが可能な機能をＸｗｉｎｄｏｗに追加したウインドウシステムは、ＧＵＩアプリケーションが外部インターフェース部２５やユーザーインターフェース部２０からの入力を受信して、入力コードに応じた処理を行う。そして、ウインドウシステムに描画に関するイベントを発行した後、全ての処理が終了したことを意味するイベント待ちを示すイベントを発行する。

ここで、ウインドウシステムは、ＧＵＩアプリケーションから最初の描画イベントを受け取った後、フレームバッファの更新が完了するのに足るような所定時間の経過を計測する。この間、ウインドウシステムは、ＧＵＩアプリケーションからの描画に関する依頼がある度にそれを受け取り、定期的にフレームバッファを更新する。そして前記所定時間が経過すると、ウインドウシステム自らがソフトウェアドライバを介してＬＣＤドライバＩＣに対して、更新されたフレームバッファ情報を描画するように指示を行う。

前記動作は、ＧＵＩアプリケーションからの描画イベントを受け取った後、フレームバッファの更新が完了するのに足るような所定時間が経過してから、ソフトウェアドライバを介してＬＣＤドライバＩＣに書込み要求を行う機能をウインドウシステムに追加することで、Ｘｗｉｎｄｏｗ向けのＧＵＩアプリケーションで作成途中の画像が表示されてしまうことはなく、シングル走査での安定した画像表示が可能となる。

図６に、キー入力により動作するＸｗｉｎｄｏｗに対応したＧＵＩアプリケーションによる描画の処理手順を示す。ステップＳ１で外部インターフェース部２５やユーザーインターフェース部２０からの入力動作（キー入力）がなされたことを確認のうえ、Ｘｗｉｎｄｏｗからキーイベントを受け取る。ステップＳ２では、Ｘｗｉｎｄｏｗから受け取ったキーイベントに応じた処理を行い、ステップＳ３でＸｗｉｎｄｏｗに対してウインドウ内の描画要求を行う。

その後、ステップＳ４でＸｗｉｎｄｏｗに全ての要求が終了し、イベント待ちであることを知らせ、ステップＳ５でアプリケーションが終了か否かを判定し、次のキー入力に備える。

図７に、実施例１の機能を追加したＸｗｉｎｄｏｗの処理手順を示す。まず、ステップＳ１１で、アプリケーションの稼働中、外部インターフェース部２５やユーザーインターフェース部２０からの入力動作（キー入力）がなされたことを確認のうえ、入力されたコードを取得してＧＵＩアプリケーションに処理を渡す。ステップＳ１２では、アプリケーションが入力に応じた処理を行い、描画に関するイベントを発行するのを待つ。そして、ステップＳ１３で描画が完了するまでの時間を設定して計測を開始する。なお、前記設定時間は予め定められたものであってもよいし、表示内容や表示を変更する領域のサイズ等に応じて算出されたものであってもよい。

ステップＳ１４では、アプリケーションからの描画イベントに応じてフレームバッファの更新を行う。ステップＳ１５において、設定時間が経過したと判断されるまで、アプリケーションからの描画に関する依頼に応じて定期的にフレームバッファの更新を行う。設定時間が経過すると描画開始が指示されるのであるが、本実施例１では、設定時間経過後にステップＳ１６で、例えば、アプリケーションからイベント待ちを表すイベントが発行されたことを確認するなどして、フレームバッファの更新が完了していることを確認するようにしている。フレームバッファの更新完了が確認されたら、ステップＳ１７で自らドライバを制御して描画を行う。その後、描画時の温度など環境パラメータから算出した描画時間の間待機するか、ＬＣＤコントローラからの描画処理終了の信号を待って次のキー入力に備える。

（実施例２、図８及び図９参照）
本実施例２は、ウインドウシステムにＸｗｉｎｄｏｗを搭載してＧＵＩ環境を実現するとともに、シングル走査で画像の表示を行うメモリ性表示デバイスでもＧＵＩアプリケーションを支障なく実行可能なように、Ｘｗｉｎｄｏｗ側でＧＵＩアプリケーションの状態を通信によって直接的に把握し、メモリ性表示デバイスへの描画タイミングを検知する処理手順を追加している。なお、ハードウエアの構成は図１〜図３に示したものと同様である。

図８に、シングル走査型のメモリ性表示デバイス１０に、本実施例２の如く、ＧＵＩアプリケーションの状態を通信により把握し、メモリ性表示デバイス１０への描画タイミングを検知できる機能をウインドウシステムに追加した場合の描画の様子を示す。

ＧＵＩアプリケーションとの同期をとりながらメモリ性表示デバイス１０へ書き込むタイミングを把握できることが可能な機能をＸｗｉｎｄｏｗに追加したウインドウシステムは、ＧＵＩアプリケーションが外部インターフェース部２５やユーザーインターフェース部２０からの入力を受信して、入力コードに応じた処理を行う。そして、ウインドウシステムに描画に関するイベントを発行した後、全ての処理が終了したことを意味するイベント待ちを示すイベントを発行する。

ここで、ウインドウシステムは、稼働中の全てのアプリケーションプロセスからのイベント待ちを示すイベントを受け取ると、フレームバッファの更新が行われていることを確認のうえ、ウインドウシステム自らソフトウェアドライバを介してＬＣＤドライバＩＣに対して、更新されたフレームバッファ情報を描画するように指示を行う。

本実施例２では、ＧＵＩアプリケーションからのイベントを全て出し終えたときに発行するイベント待ちを示すイベントを受け取った状態を確認することでソフトウェアドライバを介してＬＣＤドライバＩＣに書込み要求を行う処理手順をウインドウシステムに追加することで、Ｘｗｉｎｄｏｗ向けのＧＵＩアプリケーションで作成途中の画像が表示されてしまうことはなく、シングル走査での安定した画像表示が可能となる。

図９に、実施例２の機能を追加したＸｗｉｎｄｏｗの処理手順を示す。まず、ステップＳ２１で、アプリケーションの稼働中、外部インターフェース部２５やユーザーインターフェース部２０からの入力動作（キー入力）がなされたことを確認のうえ、入力されたコードを取得してＧＵＩアプリケーションに処理を渡す。ステップＳ２２では、アプリケーションが入力に応じた処理を行い、イベントを発行するのを待ち、描画依頼などのイベントの発行があれば、ステップＳ２３でそれに応じてフレームバッファを更新する処理を行う。そして、ステップＳ２４でイベントがイベント待ちを示すものであることが確認されるまで、イベントに応じてフレームバッファの更新を定期的に行う。

そして、イベント待ちを示すイベントを受けると、ＧＵＩアプリケーションに依頼した処理は終了したと判断し、ステップＳ２５でフレームバッファの更新が完了していることを確認して、ステップＳ２６で自らドライバを制御して描画を行う。フレームバッファの更新完了は、例えば、イベント待ちを示すイベントの受取りから予め定められた所定時間が経過したか否かで判断すればよい。描画時の温度など環境パラメータから算出した描画時間の間待機するか、ＬＣＤドライバＩＣからの描画処理終了の信号を待って次のキー入力に備える。

イベントを利用してウインドウシステムとＧＵＩアプリケーションとの間で通信を行いながら同期をとってメモリ性表示デバイス１０への描画を行う機能を追加したＸｗｉｎｄｏｗとＧＵＩアプリケーションは、互いに独立しており、連続走査型の表示デバイスに接続されたターゲットで起動させる際は、ＧＵＩアプリケーションはそのままでウインドウシステムを汎用のＸｗｉｎｄｏｗにするだけで、連続走査型の表示デバイスにも対応させることができる。

（実施例３、図１０及び図１１参照）
本実施例３は、前記実施例２のウインドウシステムに省電力制御のためのサスペンドモード制御を追加したものである。

図１０に、シングル走査型のメモリ性表示デバイス１０に、本実施例３の如く、ＧＵＩアプリケーションの状態を通信により把握し、メモリ性表示デバイス１０への描画タイミングを検知できる機能及び前記サスペンドモード制御をウインドウシステムに追加した場合の描画の様子を示す。

システムの稼働中、ウインドウシステムは、描画に関する一連の作業を終了すると、省電力化のためのサスペンドモードに入り、ＣＰＵのクロックを低速にしたり、ＣＰＵの内部回路の一部を不作動状態にしたり、昇圧回路などの電源回路の一部をオフしたりして装置全体を低消費電力状態に移行させる。そして、外部インターフェース部２５やユーザーインターフェース部２０からの入力待ちとなる。

ＧＵＩアプリケーションへ外部インターフェース部２５やユーザーインターフェース部２０からの入力を行うと、最初にサスペンドモードを管理するパワーマネージメントドライバが稼働してシステムの復帰処理、即ち、サスペンドモードに入る前の状態までの復帰処理を行う。

前記復帰処理が終了し、入力コードに応じた処理を行ったＧＵＩアプリケーションは、表示のため、ウインドウシステムに描画に関するイベントを発行し、次に全ての処理が終了すると、イベント待ちを示すイベントを発行する。

ここで、ウインドウシステムは、稼働中の全てのアプリケーションプロセスからのイベント待ちを示すイベントを受け取ると、フレームバッファの更新が行われていることを確認のうえ、ＬＣＤドライバＩＣに対してフレームバッファの画像データの描画を指示し、描画が終了すると、省電力化のためのサスペンドモードに入り、外部インターフェース部２５やユーザーインターフェース部２０からの次の入力に備える。

本実施例３では、前記実施例２のウインドウシステムに省電力化のためのサスペンドモードを追加することで、シングル走査での安定した画像表示と省電力制御が可能となる。また、前記実施例１のウインドウシステムにサスペンドモードを追加しても同様の効果を発揮する。

図１１に、実施例３の機能を追加したＸｗｉｎｄｏｗの処理手順を示す。まず、ステップＳ３１で、アプリケーションの稼働中、外部インターフェース部２５やユーザーインターフェース部２０からの入力動作（キー入力）がなされたことを確認のうえ、サスペンドモードから復帰するとともに、入力されたコードを取得してＧＵＩアプリケーションに処理を渡す。ステップＳ３２では、アプリケーションが入力に応じた処理を行い、イベントを発行するのを待ち、描画依頼などのイベントの発行があれば、ステップＳ３３でそれに応じてフレームバッファを更新する処理を行う。そして、ステップＳ３４でイベントがイベント待ちを示すものであることが確認されるまで、イベントに応じてフレームバッファの更新を定期的に行う。

そして、イベント待ちを示すイベントを受けると、ＧＵＩアプリケーションに依頼した処理は終了したと判断し、ステップＳ３５でフレームバッファの更新が完了していることを確認して、ステップＳ３６で自らドライバを制御して描画を行う。フレームバッファの更新完了は、例えば、イベント待ちを示すイベントの受取りから予め定められた所定時間が経過したか否かで判断すればよい。描画時の温度など環境パラメータから算出した描画時間の間待機するか、ＬＣＤコントローラからの描画処理終了の信号を待って、ステップＳ３７でシステム全体の省電力動作のためにサスペンドモードに移行し、次のキー入力に備える。

イベントを利用してウインドウシステムとＧＵＩアプリケーションとの間で通信を行いながら同期をとってメモリ性表示デバイス１０への描画を行う機能に、さらに省電力化のための機能を追加したＸｗｉｎｄｏｗとＧＵＩアプリケーションは、互いに独立しており、連続走査型の表示デバイスに接続されたターゲットで起動させる際は、ＧＵＩアプリケーションはそのままでウインドウシステムを汎用のＸｗｉｎｄｏｗにするだけで、連続走査型の表示デバイスにも対応させることができる。

（他の実施例）
なお、本発明に係る画像表示装置及びウインドウ制御プログラムは前記実施例に限定するものではなく、その要旨の範囲内で種々に変更できることは勿論である。

本発明の一実施例である画像表示装置の表示デバイスへの画像表示状態を示し、（Ａ）は画像データを正常に表示している状態、（Ｂ）はテキストデータを正常に表示している状態、（Ｃ）は比較のため制御の一部を省略し、不具合な表示がなされた状態の説明図である。 前記画像表示装置のハードウェア構成を示すブロック図である。 前記画像表示装置のソフトウェアシステムを示すブロック図である。 比較のため、前記ソフトウェアシステムにおいて汎用のウインドウシステムをそのまま使用して連続走査にて画像を描画する様子を示す説明図である。 本発明の実施例１でシングル走査にて画像を描画する様子を示す説明図である。 ＧＵＩアプリケーションでの描画の処理手順を示すフローチャート図である。 実施例１での処理手順を示すフローチャート図である。 実施例２で画像を描画する様子を示す説明図である。 実施例２での処理手順を示すフローチャート図である。 実施例３で画像を描画する様子を示す説明図である。 実施例３での処理手順を示すフローチャート図である。

符号の説明

１…画像表示装置
１０…メモリ性表示デバイス
２０…ユーザーインターフェース部
２５…外部インターフェース部
３０…記録部
３５…制御部
３６…ＣＰＵ
３７…ＬＣＤドライバＩＣ

Claims (5)

1. メモリ性表示デバイスと、
   該メモリ性表示デバイスに表示される画像データを記憶するためのフレームバッファと、
   該フレームバッファに記憶された画像データに基づいて前記メモリ性表示デバイスに描画を行うための駆動回路と、
   汎用のオペレーティングシステム、該汎用のオペレーティングシステムで実行されるグラフィカルユーザーインターフェース形式のアプリケーションプログラム、及び、前記汎用のオペレーティングシステム上で動作し前記メモリ性表示デバイスの画面に表示されるウインドウを制御するためのウインドウ制御プログラムがインストールされたコンピュータ部と、を備え、
   前記ウインドウ制御プログラムは、前記アプリケーションプログラムからの描画イベントに従ってフレームバッファを更新し、また、前記アプリケーションプログラムとの間の通信に基づいて前記メモリ性表示デバイスへの描画タイミングを検知して前記メモリ性表示デバイスへの描画開始を前記駆動回路に指示すること、
   を特徴とする画像表示装置。
2. 前記ウインドウ制御プログラムは、前記アプリケーションプログラムからの描画イベントから所定時間経過した後に前記メモリ性表示デバイスへの描画開始を前記駆動回路に指示することを特徴とする請求項１に記載の画像表示装置。
3. 前記ウインドウ制御プログラムは、前記アプリケーションプログラムからのイベント待ちを示すイベントを受け取った場合に、前記メモリ性表示デバイスへの描画開始を前記駆動回路に指示することを特徴とする請求項１に記載の画像表示装置。
4. 前記ウインドウ制御プログラムは、前記メモリ性表示デバイスへの描画開始を前記駆動回路に指示した後、画像表示装置をサスペンドモードに移す指示を行うことを特徴とする請求項１ないし請求項３のいずれかに記載の画像表示装置。
5. 汎用のオペレーティングシステム及びグラフィカルユーザーインターフェース形式のアプリケーションプログラムがインストールされたコンピュータ環境において、メモリ性表示デバイスの画面に表示されるウインドウの制御をコンピュータによって実現させるウインドウ制御プログラムであって、
   前記ウインドウ制御プログラムは、前記アプリケーションプログラムからの描画イベントに従ってフレームバッファを更新し、また、前記アプリケーションプログラムとの間の通信に基づいて前記メモリ性表示デバイスへの描画タイミングを検知して前記メモリ性表示デバイスへの描画開始を指示すること、
   を特徴とするウインドウ制御プログラム。

Images