(57)【要約】【課題】  汎用システムを用いながら、シングル走査型のメモリ性表示デバイス上への画像の表示が不完全になることを防止できる画像表示装置及び制御プログラムを得る。【解決手段】  汎用のオペレーションシステムと汎用のウインドウシステムとから構成されたシステムに、ＧＵＩ形式のアプリケーションにてメモリ性表示デバイスへの表示が行われるように描画タイミングを管理するための管理プロセスを備えた画像表示装置。【選択図】  図３
2006323313.tif 000002
【特許請求の範囲】
【請求項１】
汎用のオペレーションシステムと汎用のウインドウシステムとから構成されたシステムに、グラフィカル・ユーザー・インターフェース形式のアプリケーションにてメモリ性表示デバイスへの表示が行われるように描画タイミングを管理するための管理プロセスを備えたことを特徴とする画像表示装置。
【請求項２】
前記グラフィカル・ユーザー・インターフェース形式のアプリケーションは、インターフェースを介して外部から与えられる指示に対して、前記管理プロセスと同期がとれるシグナルを発信することを特徴とする請求項１に記載の画像表示装置。
【請求項３】
前記管理プロセスは、前記ウインドウシステムに対応したアプリケーションと同期をとりながら、前記メモリ性表示デバイスへの表示がなされ、該デバイスでの一の表示完了までは次の表示が実行されないように描画タイミングを制御することを特徴とする請求項１又は請求項２に記載の画像表示装置。
【請求項４】
前記管理プロセスは、前記ウインドウシステムに対応したアプリケーションと同期をとりながら、前記メモリ性表示デバイスへの表示がなされ、該デバイスでの一の表示完了の後に省電力モードに移行するように描画タイミング及び動作モードを制御することを特徴とする請求項１又は請求項２に記載の画像表示装置。
【請求項５】
前記管理プロセスは、前記ウインドウシステムに対応したアプリケーションと同期をとりながら、キー入力を受け付けると、前記メモリ性表示デバイスへの一の表示完了までは次のキー入力を制限することを特徴とする請求項１又は請求項２に記載の画像表示装置。
【請求項６】
前記管理プロセスが有効である状態と無効である状態とを選択するための切換え手段を備えたことを特徴とする請求項１ないし請求項５のいずれかに記載の画像表示装置。
【請求項７】
汎用のオペレーションシステムと汎用のウインドウシステムとから構成されたシステムに、グラフィカル・ユーザー・インターフェース形式のアプリケーションにてメモリ表示デバイスへの表示が行われるように描画タイミングを管理するための管理プロセスを備えたことを特徴とするコンピュータを機能させるための制御プログラム。
【請求項８】
前記グラフィカル・ユーザー・インターフェース形式のアプリケーションは、インターフェースを介して外部から与えられる指示に対して、前記管理プロセスと同期がとれるシグナルを発信することを特徴とする請求項７に記載の制御プログラム。
【請求項９】
前記管理プロセスは、前記ウインドウシステムに対応したアプリケーションと同期をとりながら、前記メモリ性表示デバイスへの表示がなされ、該デバイスでの一の表示完了までは次の表示が実行されないように描画タイミングを制御することを特徴とする請求項７又は請求項８に記載の制御プログラム。
【請求項１０】
前記管理プロセスは、前記ウインドウシステムに対応したアプリケーションと同期をとりながら、前記メモリ性表示デバイスへの表示がなされ、該デバイスでの一の表示完了の後に省電力モードに移行するように描画タイミング及び動作モードを制御することを特徴とする請求項７又は請求項８に記載の制御プログラム。
【請求項１１】
前記管理プロセスは、前記ウインドウシステムに対応したアプリケーションと同期をとりながら、キー入力を受け付けると、前記メモリ性表示デバイスへの一の表示完了までは次のキー入力を制限することを特徴とする請求項７又は請求項８に記載の制御プログラム。
【請求項１２】
前記管理プロセスが有効である状態と無効である状態とを選択可能としたことを特徴とする請求項７ないし請求項１１のいずれかに記載の制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像表示装置及び制御プログラム、特に、メモリ性表示デバイスを備えた画像表示装置、及び、画像表示のためにコンピュータを機能させる制御プログラムに関する。
【背景技術】
【０００２】
近年、低消費電力型の画像ビューワーとして、メモリ性表示デバイスを搭載した電子ブックなどと称する画像表示装置が種々提案／実用化されている。
【０００３】
画像ビューワーの機能として、単純にメモリ性表示デバイスにコンテンツのデータを表示させるだけではなく、表示させるデータを複数のフォーマットに対応させて、複数のビューワーを開いて表示したり、ユーザーインターフェースにＧＵＩ（グラフィカル・ユーザー・インターフェース）形式のアプリケーションを実装して使用するなどの高機能化への要望がある。
【０００４】
そのようなシステムを効率よく実装するには、表示デバイス、ファイル、メモリ、プロセスなどを管理するオペレーションシステムとＧＵＩのウインドウを管理するウインドウシステムが必要である。特許文献１には、ＧＵＩ形式のアプリケーションを用いてユーザーにとって使いやすいコンピュータ環境を実現することが開示されている。
【０００５】
汎用システムとしては、汎用オペレーションシステムであるＬｉｎｕｘ（登録商標）とＬｉｎｕｘ上で動作可能なウインドウシステムであるＸｗｉｎｄｏｗ（登録商標）が既に存在し、これらを利用することで効率のよいシステムの構築が可能である。しかしながら、これらの汎用システムには、メモリ性表示デバイスを想定した設計はされておらず、メモリ性表示デバイスへの表示を行うことは実質的にできないといった問題点を有していた。
【０００６】
なぜなら、Ｘｗｉｎｄｏｗはフレームバッファへのビットマップデータの更新を行うだけであり、実際の表示は、ＸｗｉｎｄｏｗとＬｉｎｕｘの間で標準出力として割り当てられた表示デバイスのドライバを制御することで行われるためである。
【０００７】
一般に使用されている表示デバイスであるＣＲＴモニタ、ＴＦＴ液晶モニタなどのいわゆるリフレッシュ駆動が必要で画面が連続走査されるタイプの表示デバイス（以下、連続走査型表示デバイスという）では、１秒間に数十フレームの描画が連続に行われており、アプリケーション側での処理が重く、表示に必要なビットマップデータの作成に時間がかかっても、デバイスドライバからの描画が連続的に行われる。それゆえ、あるフレームの更新タイミングでビットマップデータの生成が間に合わなくても、以降の描画タイミングのいずれかには間に合うため、連続走査による描画を行っている場合、フレームバッファへの更新で数フレーム分、データの欠落が生じても、いずれはデータの欠落が解消され、人間の目では何の違和感もなく表示データを観察することができる。
【０００８】
しかしながら、汎用のオペレーティングシステムと汎用のウインドウシステムとから構成されるシステムを用いて、リフレッシュ駆動が不要で１度の画面走査（シングル走査）で表示を維持しつづけられるメモリ性表示デバイスに良好な表示を行わせることはこれまで提案されていなかった。
【特許文献１】特開２００２−２９７２７９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
そこで、本発明の目的は、汎用システムを用いながら、メモリ性表示デバイス上への画像の表示が不完全になることを防止することのできる画像表示装置及び制御プログラムを提供することにある。
【課題を解決するための手段】
【００１０】
以上の目的を達成するため、第１の発明は、汎用のオペレーションシステムと汎用のウインドウシステムとから構成されたシステムに、グラフィカル・ユーザー・インターフェース（ＧＵＩ）形式のアプリケーションにてメモリ性表示デバイスへの表示が行われるように描画タイミングを管理するための管理プロセスを備えたことを特徴とする。
【００１１】
第２の発明に係るコンピュータを機能させるための制御プログラムは、汎用のオペレーションシステムと汎用のウインドウシステムとから構成されたシステムに、グラフィカル・ユーザー・インターフェース形式のアプリケーションにてメモリ性表示デバイスへの表示が行われるように描画タイミングを管理するための管理プロセスを備えたことを特徴とする。
【００１２】
第１及び第２の発明においては、汎用のオペレーションシステムと汎用のウインドウシステムとから構成されたシステムに、ウインドウシステムとＧＵＩアプリケーションの同期をとり、描画タイミングを管理する管理プロセスを追加することにより、メモリ性デバイスであっても、ＧＵＩアプリケーションはほぼ通常の汎用のウインドウシステムに対応したＧＵＩアプリケーションでメモリ性表示デバイスへの表示を行うことが可能になる。
【００１３】
第１及び第２の発明において、前記ＧＵＩ形式のアプリケーションは、インターフェースを介して外部から与えられる指示に対して、前記管理プロセスと同期がとれるシグナルを発信するものであってもよい。
【００１４】
また、前記管理プロセスは、前記ウインドウシステムに対応したアプリケーションと同期をとりながら、メモリ性表示デバイスへの表示がなされ、該デバイスでの一の表示完了までは次の表示が実行されないように描画タイミングを制御するものであってもよい。あるいは、管理プロセスは、ウインドウシステムに対応したアプリケーションと同期をとりながら、メモリ性表示デバイスへの表示がなされ、該デバイスでの一の表示完了の後に省電力モードに移行するように描画タイミング及び動作タイミングを制御するものであってもよい。さらに、管理プロセスは、ウインドウシステムに対応したアプリケーションと同期をとりながら、キー入力を受け付けると、メモリ性表示デバイスへの一の表示完了までは次のキー入力を制限するものであってもよい。
【００１５】
さらに、前記管理プロセスが有効である状態と無効である状態とを選択するための切換え手段を備えてもよい。これにて、ＣＲＴモニタやＴＦＴ液晶モニタなどでの表示が可能になる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明に係る画像表示装置及び制御プログラムの実施例について、添付図面を参照して説明する。
【００１７】
（実施例１、図１〜図１０参照）
典型的な汎用オペレーティングシステムであるＬｉｎｕｘをＯＳとして実装しているシステムでＧＵＩ形式のアプリケーションを実行させる場合は、Ｘｗｉｎｄｏｗのような汎用ウインドウシステム又はＱＴ、Ｐｏｗｅｒ−ｐａｒｔ、ＰｅｇといったＧＵＩ専用キットを必要とするが、実施例１では、汎用ＯＳにＬｉｎｕｘ、ウインドウシステムにＸｗｉｎｄｏｗを用いることとする。
【００１８】
ここで、ＬｉｎｕｘでＸｗｉｎｄｏｗとＧＵＩアプリケーションの実現に必要な環境について説明する。Ｘｗｉｎｄｏｗは、ＬｉｎｕｘやＵＮＩＸ（登録商標）での標準的なウインドウシステムであり、ユーザーインターフェイスや外部インターフェースからのイベント処理、ウインドウ管理、アプリケーションから依頼されたグラフィック処理を行うウインドウシステムである。
【００１９】
ＧＴＫ＋は、Ｘｗｉｎｄｏｗの上位に位置するウインドウシステムで、Ｘｗｉｎｄｏｗの機能を利用したＧＵＩ用のツールキットであり、内部に持つライブラリはＸｗｉｎｄｏｗの機能をラッピングして使いやすくしたものである。
【００２０】
ＧＮＯＭＥも、Ｘｗｉｎｄｏｗの上位に位置するウインドウシステムであり、Ｘｗｉｎｄｏｗベースのデスクトップ環境とネットワークを基本としたアプリケーションを開発するためのツール、ライブラリを提供するものである。
【００２１】
ＬｉｎｕｘのＧＵＩアプリケーションは、Ｘｗｉｎｄｏｗ用のライブラリｘｌｉｂを用いて作成することもできるが、ｘｌｉｂは点を打つ、線を引くといった基本的な機能の集まりであるため、ＧＵＩ上でボタンなどのウィジェットを表示させるなどの複雑なプログラムを作ると大きく複雑なものになってしまう。そこで、いくつかの機能をラッピングして合わせ込んだＧＵＩ用ツールキットとして、ＧＴＫ＋、ＧＮＯＭＥを利用することで容易に多機能なアプリケーションの開発が可能となる。
【００２２】
ところで、前記ウインドウシステムＸｗｉｎｄｏｗを実装し、ツールキットを利用してＧＵＩアプリケーションを開発しても、メモリ性表示デバイスへの表示を行うことはできない。なぜなら、Ｘｗｉｎｄｏｗはデバイスドライバが表示の際にアクセスに行くフレームバッファへのビットマップデータの更新を行うだけで、ＧＵＩアプリケーションも、実際の表示デバイスの制御には関心を払うことなく、「この点からあの点まで線を描け」、「この文字列を描写せよ、フォントはこれを使って」とかの指示を伝えるだけある。実際の表示は、ＸｗｉｎｄｏｗとＬｉｎｕｘの間で標準出力として割り当てられた表示デバイスのドライバを制御することで行われるためである。
【００２３】
メモリ性表示デバイスを用いた場合は、ＣＲＴモニタやＴＦＴ液晶モニタのように連続的にフレームバッファを読み込んで表示を行っていたのでは、省電力という利点を活かすことができない。一方、任意のタイミングで表示デバイスへの表示を行っていたのでは、アプリケーションで処理された結果をいつＸｗｉｎｄｏｗがフレームバッファに書き込んで終えたのかが判明することはなく、フレームバッファの更新途中の画像が表示されてしまう可能性があり、そのままでの使用は困難である。
【００２４】
そこで、Ｘｗｉｎｄｏｗを実装したシステムにおいて、Ｘｗｉｎｄｏｗに対応したＧＵＩアプリケーションでメモリ性表示デバイスの表示が可能なように描画を管理する管理プロセスを追加し、該管理プロセスで表示タイミングを管理することで、シングル走査でメモリ性表示デバイスの表示を行うことが可能となる。これにて、省電力の利点を活かした状態で、汎用のオペレーションシステムでのＧＵＩ環境の構築が実現されることになる。
【００２５】
以下に、メモリ性表示デバイスを備えた画像表示装置について図面を参照して説明する。図１に示すように、この画像表示装置１は、不揮発性のメモリ性表示デバイス１０を備え、操作スイッチなどを含む操作部１５からの指示により表示デバイス１０へ画像データ（図１（Ａ）参照）や、テキストデータ（図１（Ｂ）参照）などの電子データを画像表示する。
【００２６】
メモリ性表示デバイスとしては、強誘電性液晶表示素子、反強誘電性液晶表示素子、強誘電性高分子液晶表示素子、室温でコレステリック液晶相を示すカイラルネマチック液晶などを用いたコレステリック液晶表示素子、エレクトロクロミック表示素子、電気泳動セルを有する表示素子、乾式粉体を基板内に封入し電界で移動させて表示を行う粒子移動型表示素子、銀の析出と溶解により表示を行う表示素子、ツイストボールを有する表示素子など、従来知られている様々な表示素子が使用できる。
【００２７】
図１（Ｃ）は、不揮発性のメモリ性表示デバイス１０に画像データを表示する際に、ウインドウシステムであるＸｗｉｎｄｏｗとＧＵＩアプリケーションの処理の同期をとるために管理プロセスがなく、不具合な表示がなされた場合を示している。即ち、図１（Ｂ）の画面から図１（Ａ）の画面へ切り換わる途中の両者が混在した画像が表示されている例である。図１（Ａ），（Ｂ）は、管理プロセスによってＸｗｉｎｄｏｗとＧＵＩアプリケーションの処理の同期がとれた状態で表示が行われている場合を示している。
【００２８】
図２に画像表示装置１のハードウェア構成を示す。ハードウェアは、前記メモリ性表示デバイス１０やユーザーインターフェース部２０に加えて、外部インターフェース部２５、記録部３０、制御部３５にて構成されている。
【００２９】
ユーザーインターフェース部２０は、キースイッチ、タッチパネルなどが含まれる。外部インターフェース部２５は、ＬＡＮなどのネットワーク、ＰＣＭＣＩＡ規格のＰＣカードなどの拡張カードや外部機器、ＳＤメモリカードやコンパクトフラッシュ（登録商標）などの情報メディアとの接続を確立する。記録部３０は、ＳＤＲＡＭ３１とフラッシュＲＯＭ３２とからなり、ＯＳであるＬｉｎｕｘ、ウインドウシステムであるＸｗｉｎｄｏｗ、管理プロセス、ＧＵＩアプリケーションプログラム、表示データを格納している。制御部３５は、ＣＰＵ３６とメモリ性表示デバイス１０を駆動するためのＬＣＤドライバＩＣ３７とからなる。ＣＰＵ３６はユーザーインターフェース部２０からの入力・指示に応じて各部を制御する。ＬＣＤドライバＩＣ３７はメモリ性表示デバイス１０を駆動する。
【００３０】
図３に画像表示装置１のソフトウェアシステムの構成を示す。デバイス部４１に対してソフトウェア部４２は、全体を管理するＯＳであるＬｉｎｕｘ、ウインドウを管理するウインドウシステムであるＸｗｉｎｄｏｗ、ＧＵＩツールであるＧＴＫ＋、ＧＮＯＭＥ、ＧＵＩアプリケーションプログラム、ＸｗｉｎｄｏｗとＧＵＩアプリケーションの同期をとるための管理プロセスからなる。
【００３１】
図４に前記ソフトウェアシステムを使用して管理プロセスを無効化した状態で連続走査にて画像を描画する様子を示す。Ｘｗｉｎｄｏｗは、Ｌｉｎｕｘ上でＧＵＩを構築する際に必要なウインドウシステムであり、その機能としては、外部インターフェース部２５やユーザーインターフェイス部２０からの入力に対して、アクティブになっているウインドウを判別する。さらに、外部インターフェース部２５から入力されたコードを取得して、アクティブウインドウの対象となるＧＵＩアプリケーションに受信したコードを転送したり、画像のフレームバッファを更新するなどの作業を実行する。
【００３２】
なお、管理プロセスを無効化するとは、図５において管理プロセスに対してシグナルを出力しないことをいう。逆に、このシグナルが出力されることが管理プロセスを有効化することを意味する。
【００３３】
表示デバイス１０（ＬＣＤ）への描画を行うフレームバッファのデータの更新は、ＧＵＩアプリケーションからＸｗｉｎｄｏｗにＧＵＩアプリケーションが必要とする描画用パーツである様々なウィジェットの作成を依頼する際、ＸｗｉｎｄｏｗはＧＵＩアプリケーションから必要なウィジェットの依頼をバッファリングする。そして、Ｘｗｉｎｄｏｗが所定のタイミングで順次データの作成を行う。従って、全てのウィジェットの描画は、並列にドライバが１秒間に数十フレームといった頻度で連続的に行っているため、フレームバッファの更新の遅れが問題になることはない。しかし、シングル走査型の表示デバイスでは、アプリケーションの処理が終了し、フレームバッファの更新を行った後で表示を開始しないと、アプリケーションでの処理途中の画像が表示されてしまうことになる。
【００３４】
図５にシングル走査型であるメモリ性表示デバイス１０に本実施例１の如く管理プロセスを追加した場合の描画の様子を示す。
【００３５】
本実施例１は、ウインドウシステムにＸｗｉｎｄｏｗを搭載してＧＵＩ環境を実現しているシステムにおいて、シングル走査で画像の表示を行うメモリ性表示デバイス１０でもＧＵＩが実現できるように、ＸｗｉｎｄｏｗとＧＵＩアプリケーションの同期をとるための管理プロセスを備えている。
【００３６】
管理プロセスは、Ｘｗｉｎｄｏｗと並列に動作しており、ＧＵＩアプリケーションがキー入力を受信して、入力コードに応じた処理を開始又は終了した際に発信するシグナルを受信すると、予めフレームバッファの更新時間として設定した時間を待った後で、ＬＣＤドライバＩＣ３７にフレームバッファの画像データの描画を指示し、描画が終了するとアプリケーションから受信したシグナルを破棄して、次のシグナルの受信に備える。
【００３７】
前述の動作は、管理プロセスの追加と、ＧＵＩアプリケーション内で管理プロセス向けのシグナルを発信させる処理を追加することで、Ｘｗｉｎｄｏｗの仕様を変更することなく、シグナルの受信を待った後、管理プロセス内で所定の時間待って表示デバイス１０への描画を開始することで、簡易的にＸｗｉｎｄｏｗのフレームバッファへの更新終了を見ていることになり、ＧＵＩアプリケーションで作成途中の画像が表示されてしまうことはなく、シングル走査での安定した画像表示が実現される。
【００３８】
図６及び図７にキー入力により動作するＸｗｉｎｄｏｗに対応したＧＵＩアプリケーションによる描画の処理手順を示す。Ｘｗｉｎｄｏｗでは、ＧＵＩアプリケーションからウインドウに必要な部品であるウィジェットの作成依頼をバッファリングしている。そして、Ｘｗｉｎｄｏｗが所定のタイミングで順次データを作成し、フレームバッファの更新を行っている。
【００３９】
図６はＸｗｉｎｄｏｗに対応したＧＵＩアプリケーションでの処理手順である。ステップＳ１では、キー入力によりＧＵＩアプリケーションを起動してイニシャル処理を行う。ステップＳ２では、イニシャル処理の結果を表示するためのウインドウサイズ、ウインドウ内の構成などのウインドウデザインを作成する。図６におけるウインドウデザインの示す動作は、ＧＵＩアプリケーションのウインドウサイズ、ウインドウ内の構成などのウインドウデザインの描画に必要なウィジェットの作成をＸｗｉｎｄｏｗに対して依頼する一連の処理を示す。
【００４０】
ステップＳ３では、キー入力に備える。ステップＳ４では、キー入力があった場合に入力されたコードを取得するためのキーコード取得プロセスを起動する。ステップＳ５では、キーコード取得プロセスで取得したコードがアプリケーションの終了を示す場合は終了処理を行い、そうでなければ前記ステップＳ３に戻る。
【００４１】
図７はＸｗｉｎｄｏｗのキーコード取得の処理手順である。この処理はアプリケーションの稼働中、キー入力動作により起動する。まず、ステップＳ１１では、入力されたコードを取得する。ステップＳ１２では、入力されたコードに応じた処理をアプリケーションに行わせる。ステップＳ１３では処理に応じたウインドウデザインを作成する。
【００４２】
図８〜図１０は実施例１での描画処理手順を示す。図８は実施例１のＸｗｉｎｄｏｗに対応したＧＵＩアプリケーションでの処理手順である。ステップＳ３１では、キー入力によりＧＵＩアプリケーションを起動してイニシャル処理を行う。ステップＳ３２では、イニシャル処理の結果を表示するためのウインドウサイズ、ウインドウ内の構成などのウインドウデザインを作成する。ステップＳ３３では、管理プロセスにシグナルを発信する。本実施例１ではプロセス間のセマフォ（同期通信）にはファイルを使用するので、ステップＳ３３ではシグナルファイルを作成する。
【００４３】
ステップＳ３４では、キー入力に備える。ステップＳ３５では、キー入力があった場合に入力されたコードを取得するためのキーコード取得プロセスを起動する。ステップＳ３６では、キーコード取得プロセスで取得したコードがアプリケーションの終了を示す場合は終了処理を行い、そうでなければ前記ステップＳ３４に戻る。
【００４４】
図９は実施例１でのＸｗｉｎｄｏｗのキーコード取得の処理手順である。この処理はアプリケーションの稼働中、キー入力動作により起動する。まず、ステップＳ４１では、入力されたキーコードを取得する。ステップＳ４２では、シグナルファイルを作成する。ステップＳ４３では、入力されたコードに応じた処理をアプリケーションに行わせる。ステップＳ４４では処理に応じたウインドウデザインを作成する。
【００４５】
図１０は実施例１での管理プロセスの処理手順である。ステップＳ５１では、シグナルファイルがオープンできるか否かを確認して、ＧＵＩアプリケーションの処理によりシグナルファイルが作成されてオープンできたのであればステップＳ５２へ移行する。ステップＳ５２では、ＧＵＩアプリケーションで処理される負荷に応じて、アプリケーションの処理時間、フレームバッファの更新時間の間待機する。ステップＳ５３では、ＬＣＤドライバＩＣ３７を制御してメモリ性表示デバイス１０に対する描画処理を実行する。ステップＳ５４では、描画時の温度などの環境パラメータから算出した描画時間の間待機するか、制御部３５に設けられているＬＣＤコントローラ（図示せず）からの描画終了処理の信号を待って、シグナルファイルを破棄する。その後、前記ステップＳ５１に戻る。
【００４６】
前記管理プロセスは、Ｘｗｉｎｄｏｗに対応したＧＵＩアプリケーションとは独立しており、連続走査型の表示デバイスに接続されたターゲットで起動させる際は、ＧＵＩアプリケーション内で管理プロセスを無効にするだけでよく、大幅な変更をすることなく、連続走査型の表示デバイスに描画する場合にも対応させることができる。
【００４７】
なお、前記実施例ではキー入力やタッチパネルの操作により描画が指示される例を示したが、これに限らず、ＬＡＮや無線回線などから外部インターフェース部２５を通じて入力される描画指示に基づくものであってもよい。この点は以下の実施例でも同様である。
【００４８】
（実施例２、図１１〜図１４参照）
本実施例２は前記実施例１の管理プロセスに省電力制御のためのサスペンスモード制御を追加したものである。ハードウェア及びソフトウェアの構成は図２及び図３に示したものと同じである。図１１にシングル走査型であるメモリ性表示デバイス１０に本実施例２の如く管理プロセスを追加した場合の描画の様子を示す。
【００４９】
本実施例２は、ウインドウシステムにＸｗｉｎｄｏｗを搭載してＧＵＩ環境を実現しているシステムにおいて、シングル走査で画像の表示を行うメモリ性表示デバイス１０でもＧＵＩが実現できるように、ＸｗｉｎｄｏｗとＧＵＩアプリケーションの同期をとるための管理プロセスを備えている。
【００５０】
システムの起動時において、管理プロセスはＸｗｉｎｄｏｗと並列に動作しており、一連の処理を終了すると、省電力化のためにサスペンドモードに入り、キー入力待ちとなる。
【００５１】
ＧＵＩアプリケーションへキー入力を行うと、最初にサスペンドモードを管理するパワーマネジメントドライバが稼働して、システムの復帰処理を行い、サスペンドモードに入る前の状態までの復帰処理を行う。
【００５２】
復帰処理が終了した後、管理プロセスは、ＧＵＩアプリケーションが入力コードに応じた処理を開始し、または終了した際に発信するシグナルを受信すると、予めフレームバッファの更新時間として設定した時間を待った後で、ＬＣＤドライバＩＣ３７にフレームバッファの画像データの描画を指示し、描画が終了するとアプリケーションから受信したシグナルを破棄して、省電力化のためにサスペンドモードを実行し、次のキー入力に備える。
【００５３】
前述の動作は、実施例１に示した管理プロセス内に省電力化のためのサスペンドモードを追加することで、Ｘｗｉｎｄｏｗの仕様を変更することなくシングル走査での安定した画像表示と省電力制御が可能となる。
【００５４】
図１２〜図１４に本実施例２による描画の処理手順を示す。図１２はＸｗｉｎｄｏｗに対応したＧＵＩアプリケーションでの処理手順である。ステップＳ６１では、キー入力によりＧＵＩアプリケーションを起動してイニシャル処理を行う。ステップＳ６２では、イニシャル処理の結果を表示するためのウインドウサイズ、ウインドウ内の構成などのウインドウデザインを作成する。
【００５５】
ステップＳ６３では、管理プロセスにシグナルを発信する。本実施例２ではプロセス間のセマフォ（同時通信）にはファイルを使用するので、ここでは、シグナルファイルを作成する。ステップＳ６４では、キー入力に備える。ステップＳ６５では、キー入力があった場合に入力されたコードを取得するためのキーコード取得プロセスを起動する。ステップＳ６６では、キーコード取得プロセスで取得したコードがアプリケーションの終了を示す場合は終了処理を行い、そうでなければ前記ステップＳ６４に戻る。
【００５６】
図１３は実施例２でのＸｗｉｎｄｏｗのキーコード取得の処理手順である。この処理はアプリケーションの稼働中、キー入力動作により起動する。まず、ステップＳ７１では、入力されたキーコードを取得する。ステップＳ７２では、シグナルファイルを作成する。ステップＳ７３では、入力されたコードに応じた処理をアプリケーションに行わせる。ステップＳ７４では処理に応じたウインドウデザインを作成する。
【００５７】
図１４は実施例２での管理プロセスの処理手順である。ステップＳ８１では、シグナルファイルがオープンできるか否かを確認して、ＧＵＩアプリケーションの処理によりシグナルファイルが作成されてオープンできたのであればステップＳ８２へ移行する。ステップＳ８２では、ＧＵＩアプリケーションで処理される負荷に応じて、アプリケーションの処理時間、フレームバッファの更新時間の間待機する。ステップＳ８３では、ＬＣＤドライバＩＣ３７を制御してメモリ性表示デバイス１０に対する描画処理を実行する。ステップＳ８４では、描画時の温度などの環境パラメータから算出した描画時間の間待機するか、制御部３５に設けられているＬＣＤコントローラ（図示せず）からの描画終了処理の信号を待って、シグナルファイルを破棄する。
【００５８】
ステップＳ８５では、システム全体の省電力動作のためのサスペンドモードを処理する。ステップＳ８６では、入力動作に備え、入力があった場合には復帰動作を処理する。その後、前記ステップＳ８１に戻る。
【００５９】
前記管理プロセスは、Ｘｗｉｎｄｏｗに対応したＧＵＩアプリケーションとは独立しており、連続走査型の表示デバイスに接続されたターゲットで起動させる際は、ＧＵＩアプリケーション内で管理プロセスを無効にするだけでよく、大幅な変更をすることなく、連続走査型の表示デバイスに描画する場合にも対応させることができる。
【００６０】
（他の実施例）
なお、本発明に係る画像表示装置及び制御プログラムは前記実施例に限定するものではなく、その要旨の範囲内で種々に変更できることは勿論である。
【図面の簡単な説明】
【００６１】
【図１】本発明の一実施例である画像表示装置の表示デバイスへの画像表示状態を示し、（Ａ）は画像データを正常に表示している状態、（Ｂ）はテキストデータを正常に表示している状態、（Ｃ）は不具合な表示がなされた状態の説明図である。
【図２】前記画像表示装置のハードウェア構成を示すブロック図である。
【図３】前記画像表示装置のソフトウェアシステムを示すブロック図である。
【図４】前記ソフトウェアシステムを使用して連続走査にて画像を描画する様子を示す説明図である。
【図５】前記ソフトウェアシステムを使用してシングル走査にて画像を描画する様子（実施例１）を示す説明図である。
【図６】連続走査で行われるＧＵＩアプリケーションでの処理手順を示すフローチャート図である。
【図７】連続走査で行われるＸｗｉｎｄｏｗのキーコード取得の処理手順を示すフローチャート図である。
【図８】実施例１におけるＧＵＩアプリケーションでの処理手順を示すフローチャート図である。
【図９】実施例１におけるＸｗｉｎｄｏｗのキーコード取得の処理手順を示すフローチャート図である。
【図１０】実施例１における管理プロセスの処理手順を示すフローチャート図である。
【図１１】前記ソフトウェアシステムを使用してシングル走査にて画像を描画する様子（実施例２）を示す説明図である。
【図１２】実施例２におけるＧＵＩアプリケーションでの処理手順を示すフローチャート図である。
【図１３】実施例２におけるＸｗｉｎｄｏｗのキーコード取得の処理手順を示すフローチャート図である。
【図１４】実施例２における管理プロセスの処理手順を示すフローチャート図である。
【符号の説明】
【００６２】
１…画像表示装置
１０…メモリ性表示デバイス
２０…ユーザーインターフェース部
２５…外部インターフェース部
３０…記録部
３５…制御部
３６…ＣＰＵ
３７…ＬＣＤドライバＩＣ
【図１】
2006323313.tif 000003
【図２】
2006323313.tif 000004
【図３】
2006323313.tif 000005
【図４】
2006323313.tif 000006
【図５】
2006323313.tif 000007
【図６】
2006323313.tif 000008
【図７】
2006323313.tif 000009
【図８】
2006323313.tif 000010
【図９】
2006323313.tif 000011
【図１０】
2006323313.tif 000012
【図１１】
2006323313.tif 000013
【図１２】
2006323313.tif 000014
【図１３】
2006323313.tif 000015
【図１４】
2006323313.tif 000016