JP2015087569A - 画像処理装置 - Google Patents

Abstract

【課題】一方のアプリによる表示画像を他方のアプリによる表示画像にワイプインなどで切り換える際の画面ちらつきを抑制できる画像処理装置を提供すること。
【解決手段】アプリ１がワイプアウトのための画面データを第１バッファに書き込みながら、アプリ３がワイプインのための画面データを第３バッファに書き込む間に、アプリ１による書き込み量が所定量に達すると（時点ｔ１）、その画面データＺ１を中間バッファに記憶させる。その後、アプリ３による画面データの書き込みが、中間バッファ内の画面データＺ１と同じ領域まで終了すると（時点ｔ２）、アプリ３による画面データＺ３と中間バッファ内の画面データＺ１とを合成した合成画面データＺ４をＶＲＡＭに書き込み、その合成画面データＺ４をディスプレイに表示させる。この処理を、切り換え開始から終了までの間、アプリ１による書き込み量が所定量に達するごとに繰り返し実行する。
【選択図】図５

Description

本発明は、画面をディスプレイに表示する画像処理装置に関する。

近年の多機能化した画像処理装置は、各種画面を表示するディスプレイを備えている。
例えば、コピー等の操作画面の表示やユーザーからの操作入力の受け付けを行うアプリケーションプログラム（以下、単に「アプリ」という。）Ａや、操作機能とは別に、ネットワークを介して種々の情報を表示したりその情報の検索入力を受け付けたりする情報提供用のアプリＢをそれぞれ個別にインストールして、必要なアプリを起動することにより、操作用の画面だけを表示させたり、情報提供用の画面だけ表示させたり、また操作用の画面から情報提供用の画面へ切り換えたりすることができる。

このような画面切り換えを行う場合、画面全体を瞬時に切り換えてしまうと、ユーザーは、画面が切り換わったことを目視で認識し難いことが多い。
そこで、従来から、画面を瞬時に切り換えるのではなく、画面が少しずつ切り換わっていく制御が行われている。例えば、ディスプレイに表示されている画面上における画像１が一方向に徐々にスライドしてディスプレイの枠外に消えていきながら（スライドアウト）、これに伴って新たな画像２が同方向にディスプレイの枠外から枠内に徐々にスライドして入り込んでくるように（スライドイン）、画面を切り換える制御がある。

このような切り換え制御を行えば、ユーザーは、１画面上で画像が切り換わっていく様子を目視できるので、画面の切り換わりを認識し易くなる。

特開２０１２−３８０３９号公報 特開２００４−２９４６７７号公報

ところが、アプリＡにより書き換えられている画像１の画面データと、アプリＢにより書き換えられている画像２の画面データとを書き換え途中で合成して、１つの画面データを生成することにより、アプリＡによる画像１がスライドアウトしながらアプリＢによる画像２がスライドインするように画面切り換えを行う構成をとる場合、書き換えの時間（速度）が各アプリ間で異なると、画面のちらつきが発生するという問題がある。

具体的には、画像１よりも画像２の書き換えが遅ければ、ディスプレイ上では、スライドアウトにより枠外に消えていく画像１に対してスライドインにより枠内に入り込んでくる画像２が追い付けずに、画像１と画像２との間に隙間が生じたようになって画面が切り換わるようになる。
逆に、画像１よりも画像２の書き換えが速ければ、画像１に対して画像２の一部が重なったような状態で画面が切り換わるようになる。この２つの画像の隙間や重なりが、ユーザーにとっては画面のちらつきと映ってしまう。

このような問題は、例えば既存のアプリＡに対して、これとは別の機能を追加するためにサードベンダーからアプリＢの提供を受けるような環境下で、異なるアプリＡとＢ間で画面切り換え時の画面データの書き換えを完全に同期して行えない場合に生じ易い。また、スライドインなどに限られず、例えばワイプインやワイプアウトなどを含む画面の切り換え制御一般に生じ得る。

本発明は、上記の問題点に鑑みてなされたものであって、画面の切り換え時のちらつきを抑制することができる画像処理装置を提供することを目的としている。

上記目的を達成するために、本発明に係る画像処理装置は、ユーザーからの入力を受け付ける操作部に設けられたディスプレイ上で、第１画像をその一部から全体に亘って徐々に消去しつつ新たな第２画像を徐々に現出するようにして画面を切り換える画像処理装置であって、第１記憶部と、第２記憶部と、中間記憶部と、前記第１画像を前記徐々に消去するための画面データを前記第１記憶部に書き込む第１アプリケーションと、前記第２画像を前記徐々に現出するための画面データを前記第２記憶部に書き込む第２アプリケーションと、前記第１と第２のアプリケーションのうち、画面データの書き込みが速い方のアプリケーションによる記憶部への書き込み途中に所定量のデータが書き込まれるごとに、その書き込まれた画面データを前記中間記憶部に記憶させる中間処理部と、画面データの書き込みが遅い方のアプリケーションによる記憶部への書き込み途中に、前記中間処理部により前記中間記憶部に記憶された画面データと合成されるべき画面データが書き込まれるごとに、その画面データと、これに対応する、前記中間記憶部に記憶されている画面データとを合成する合成部と、前記合成部により画面データが合成されるごとに、その合成画面データを前記ディスプレイに送ってその画像を前記ディスプレイに表示させる表示制御部と、を備えることを特徴とする。

また、前記第１アプリケーションと第２アプリケーションのそれぞれは、予め決められたデータ量の書き込みを行うごとに、その旨を示す書き込み通知を出力し、前記中間処理部は、前記第１アプリケーションと第２アプリケーションのうち、前記書き込み通知を先に出力したアプリケーションを、前記速い方のアプリケーションとし、前記合成部は、前記第１アプリケーションと第２アプリケーションのうち、前記速い方のアプリケーションよりも前記書き込み通知を後に出力したアプリケーションを、前記遅い方のアプリケーションとするとしても良い。

ここで、前記予め決められたデータ量は、前記第１アプリケーションと第２アプリケーションのそれぞれで、前記所定量以下であり同じ値である、または、前記所定量以下の異なる値であり一方が他方の倍数であるとしても良い。
また、前記中間処理部は、前記速い方のアプリケーションからの書き込み通知とこれよりも前の過去の書き込み通知とに基づき、前記中間記憶部に記憶されている画面データのうち、当該アプリケーションにより前記記憶部に書き込まれた画面データとの差分に相当する部分のデータだけを書き換えることにより、前記記憶部に書き込まれた画面データの前記中間記憶部への記憶を実行させるとしても良い。

さらに、前記所定量のデータは、予め決められたデータ量を示すバンド単位のデータであるとしても良い。
また、前記第１アプリケーションは、前記ディスプレイに表示される画面内において所定の一方向に前記第１画像の一方端から他方端に向かって透明領域が徐々に拡大するように、前記画面データを前記第１記憶部に漸次書き込み、前記第２アプリケーションは、前記ディスプレイに表示される画面内において前記所定の一方向と同方向に前記第２画像が当該画面の枠外から枠内に徐々に入ってくるように、前記画面データを前記第２記憶部に漸次書き込み、前記合成部は、前記第１アプリケーションによる画面データで表される画像が最上位になり、その下に前記第２アプリケーションによる画面データで表される画像が重なり合って１つの画面が生成されるように、それぞれの画面データを合成するとしても良い。

さらに、前記第１画像とは別の第３画像をその一部から全体に亘って徐々に消去しつつ、前記第２画像とは別の第４画像を徐々に現出するように画面を切り換えることも可能であり、前記第１アプリケーションは、前記第３画像を徐々に消去するための画面データを前記第１記憶部に書き込むことが可能であり、前記第２アプリケーションは、前記第４画像を徐々に現出するための画面データを前記第２記憶部に書き込むことが可能であり、前記第１画像と前記第２画像に対する各画面データに適用される前記所定量Ｈと、前記第３画像と前記第４画像に対する各画面データに適用される前記所定量Ｈ１とが異なるとしても良い。

ここで、前記第３画像と第４画像は、前記第１画像と第２画像よりも前記ディスプレイ上における表示領域が小さく、前記所定量Ｈよりも前記所定量Ｈ１の方が大きいとしても良い。
また、前記第１アプリケーションと第２アプリケーションは、それぞれが画面データの書き込み開始に際し、その書き込み範囲を含む書き込み開始通知を出力し、前記合成部は、前記出力された書き込み開始通知に含まれる書き込み範囲に基づき、前記第１画像と第２画像の大きさが異なり、小さい方の画像が大きい方の画像内に収まることを判断すると、各画像がその書き込み範囲に基づく位置で上下に重なるように、前記それぞれの画面データの合成を行うとしても良い。

さらに、前記第１アプリケーションと第２アプリケーションは、それぞれが画面データの書き込み開始に際し、その書き込み範囲を含む書き込み開始通知を出力し、前記中間処理部は、前記出力された書き込み開始通知に含まれる書き込み範囲に基づき、前記第１画像と第２画像が重なっているか否かを判定し、重なっていないことが判定されると、前記画面データの前記中間記憶部への記憶を禁止し、前記合成部は、前記画面データの前記中間記憶部への記憶が禁止されると、前記合成を禁止して、これに代えて、前記第１アプリケーションにより前記第１記憶部に書き込まれた画面データと、前記第２アプリケーションにより前記第２記憶部に書き込まれた画面データとを一定周期ごとに合成するとしても良い。

上記のように構成すれば、合成部により合成される合成画面データは、一方と他方のそれぞれのアプリケーションによる、合成されるべき２つの画面データが合成されたものになる。従って、例えばスライドアウトする画像に対してスライドインする画像が追い付けないために画像間に隙間が生じるなどによる画面ちらつきの発生を防止できる。

本実施の形態に係るＭＦＰの全体の概略構成を示す図である。 ＭＦＰの制御部の構成を示すブロック図である。 画面データの合成を説明するための図である。 （ａ）は、画面の切り換え開始直前にアプリ１〜３により生成されていた画面の例を示す図であり、（ｂ）は、新たに生成される画面の例を示す図であり、（ｃ）は、画面の切り換え開始から終了までの間に画面が遷移する様子を示す図である。 画面切り換えを行う場合の制御方法（実施例）を説明するための図である。 ２つの画面を重ね合わせた場合の表示例を示す図である。 画面切り換え制御を行わない場合の比較例を説明するための図である。 画面切り換え制御のシーケンス図の一部を示す図である。 画面切り換え制御のシーケンス図の残りの一部を示す図である。 画面切り換え制御のシーケンス図の残りの別の部分を示す図である。 アプリによる画面データ書き込み処理の内容を示すフローチャートである。 描画制御部による画面切り換え処理の内容を示すフローチャートである。 変形例に係る画面切り換え処理の一部だけを抜き出して示すフローチャートである。 変形例に係る画面切り換えの様子を示す図である。 変形例に係る画面切り換え制御の場合の画面データの例を示す図である。

以下、本発明に係る画像処理装置の実施の形態を多機能複合機（ＭＦＰ：Multiple Function Peripheral）に適用した場合を例にして説明する。
＜ＭＦＰの全体構成＞
図１は、本実施の形態に係るＭＦＰ１０の全体の概略構成を示す図である。
同図に示すように、ＭＦＰ１０は、スキャナー部１１と、プリント部１２と、操作部１３と、制御部１４などを備え、原稿の画像を読み取るスキャンジョブと、読み取って得られた画像データに基づいて原稿画像をシートにプリントするコピージョブと、ＬＡＮなどのネットワークを介して接続されている外部端末（不図示）からのジョブの要求を受け付けて、受け付けたジョブに係る画像をシートにプリントするプリントジョブ等の各種ジョブを実行する機能を有する。

スキャナー部１１は、原稿の画像を読み取って画像データを得る画像読取装置である。
プリント部１２は、シート上に画像をプリントする画像形成装置である。
操作部１３は、ユーザーがＭＦＰ１の前に立ったときに操作し易い位置、ここではスキャナー部１１の前面に配設されている。
操作部１３は、ユーザーからのコピー枚数やジョブ開始指示などの入力を受け付けるための各種キーに加えて、透明のタッチパネルが張り付けられたディスプレイ９を備える。

ディスプレイ９は、制御部１４からの指示に基づく各種ジョブに関する画面を表示し、またタッチパネルを介してユーザーからのジョブ実行などのためのタッチ入力を受け付ける。操作部１３において受け付けられた入力の情報は、制御部１４に送られる。
＜制御部の構成＞
制御部１４は、図２のブロック図に示すように、通信インターフェース（Ｉ／Ｆ）部２１と、ＣＰＵ２２と、ＲＯＭ２３と、アプリ記憶部２４と、データ記憶部２５と、描画制御部２６と、表示制御部２７を備え、各部はバスを介して相互に通信可能になっている。

通信Ｉ／Ｆ部２１は、ネットワーク、ここではＬＡＮカード、ＬＡＮボードといったＬＡＮに接続するためのインターフェースであり、ＬＡＮを介して外部（不図示）からのプリントジョブのデータやインターネット上のサーバー（不図示）などからの各種情報を示すデータを受信する。
ＣＰＵ２２は、ＲＯＭ２３から必要なプログラムを読み出して、スキャナー部１１、プリント部１２などの動作を制御して、コピーやプリントなどの各ジョブを円滑に実行させる。例えば、プリントジョブの場合、通信Ｉ／Ｆ部２１からのプリントジョブのデータを受け付けつけると、そのデータをプリント部１２でプリントするためのデータに変換する。また、スキャナー部１１により得られた画像データを受け付けると、その画像データをプリントするためのデータに変換する。そして、変換されたデータをプリント部１２に送信し、プリント部１２に対してそのデータに基づくプリントを実行させる。

また、ＣＰＵ２２は、アプリ記憶部２４に記憶されている各種アプリケーションを必要に応じて読み出して、読み出したアプリケーションによる機能を実行させる。
アプリ記憶部２４は、不揮発性の記憶手段であり、第１アプリケーション１、第２アプリケーション２、第３アプリケーション３が記憶されている。
第１アプリケーション１（以下、「アプリ１」という。）は、ユーザーがコピージョブ等を実行するときに操作に用いる操作用画面を操作部１３のディスプレイ９に表示するためのプログラムである。操作用画面には、例えばコピージョブにおけるユーザーからのシートサイズの選択を受け付けるためのシートサイズ選択画面やコピー濃度の選択を受け付けるための濃度選択画面などの種々の画面が含まれる。

第２アプリケーション２（以下、「アプリ２」という。）は、ユーザーがＭＦＰ１０の管理情報（累積プリント枚数など）を参照するときの管理画面を操作部１３のディスプレイ９に表示するためのプログラムである。管理情報は、不図示の記憶部に記憶され、プリントやコピージョブごとにその枚数などが更新されるようになっている。
第３アプリケーション３（以下、「アプリ３」という。）は、コピー等のジョブや管理情報とは別の、ネットワーク上の外部サーバーなどから通信Ｉ／Ｆ部２１を介して取得された各種情報をユーザーが参照したりその情報を検索入力したりするための情報提供用の情報画面を操作部１３のディスプレイ９に表示するためのプログラムである。

アプリ１とアプリ２は、ジョブ実行やＭＦＰ１０の管理に用いられるアプリケーションであるのに対し、アプリ３は、ジョブや管理とは関係のない情報参照等の機能を有するアプリケーションになっており、ＭＦＰ１０の固有の機能ではないことから、例えばサードベンダーから提供されたアプリをアプリ３として用いるように構成することもできる。
ここで、本実施の形態に用いられるアプリ１〜３は、アプリ１と２よりもアプリ３の方が、ディスプレイ９上において同じ大きさの領域に画面を表示するための画面データをバッファ（後述）に書き込むのに要する時間が長くかかるという関係を有している。

この書き込み時間（速度）の違いにより、アプリ１または２による画面からアプリ３による画面に切り換える際にちらつきが発生することのないように画面切り換え制御（後述）が実行される。なお、本実施の形態では、画面切り換え方法としてワイプインとワイプアウトが用いられる。アプリ１〜３は、不図示のＯＳ（オペレーションシステム）上で動作してその機能を実行する。

データ記憶部２５は、第１バッファ３１と、第２バッファ３２と、第３バッファ３３と、中間バッファ３４と、ＶＲＡＭ（Video RAM）３５を有する。
第１バッファ３１は、アプリ１で生成された操作用画面の画面データが書き込まれる記憶部である。
第２バッファ３２は、アプリ２で生成された管理画面の画面データが書き込まれる記憶部である。

第３バッファ３３は、アプリ３で生成された情報画面の画面データが書き込まれる記憶部である。以下、アプリ１〜３を特に区別しない場合には、総称して「アプリ」といい、１つのアプリに対応するバッファを、符号を付さずに「バッファ」という場合がある。
中間バッファ３４は、画面切り換え制御を行う際に、アプリによる画面データを一時的に保存するための記憶部として用いられる。

ＶＲＡＭ３５は、操作部１３のディスプレイ９に画面を表示するのに必要な画面データを一時的に保存するための記憶部である。
描画制御部２６は、ディスプレイ９にどのアプリによる画面を表示したり切り換えたりするかを統括的に制御するものであり、中間処理部５１とデータ合成部５２を有する。
中間処理部５１は、中間バッファ３４を用いて画面切り換え制御を実行する。

データ合成部５２は、画面切り換え制御以外のときには、ユーザーからの指示に基づき、ディスプレイ９に表示すべき画面の画面データが書き込まれているバッファからその画面データを読み出して、ＶＲＡＭ３５に書き込む。
例えば、アプリ１による操作用画面を表示させる場合には、アプリ１により生成され、第１バッファ３１に書き込まれている画面データが読み出されて、ＶＲＡＭ３５に書き込まれる。

一方、画面切り換え制御のときには、アプリ１〜３のうち、画面に表示される画像のワイプアウトを担当するアプリがバッファに書き込む画面データと、新たな画像のワイプインを担当するアプリがバッファに書き込む画面データとを、画面切り換え開始から終了までの間に亘って一定量のデータが生成されるごとに合成して、合成するごとに、その合成画面データをＶＲＡＭ３５に順次、書き込んで更新する。

この画面データの合成は、本実施の形態では、例えば図３に示すようにワイプアウトされる画像を表す画面４１が最上位で、ワイプインされる画像を表す画面４２がその下に重ね合わされて１つの画面が生成されるように、画面４１の画面データと画面４２の画面データとが合成されることにより行われる。
ユーザーは、最上位の画面４１の画像を目視でき、その下に隠れる画面４２の画像を原則、目視できないが、画面４１の画像の一部に透明領域（後述）が含まれるようにアプリが画面４１の画面データを生成することにより、画面４１の下に位置する画面４２の画像のうち、その透明領域に対応する部分画像がその透明領域を介してユーザーが目視できる状態になるようになっている。

画面切り換えの開始から終了までの間に亘って、ＶＲＡＭ３５上の合成画面データを書き換える（更新）ごとに、画面４１の画像は、所定の一方向（図３の例では下から上に向かう方向）に下側から徐々に上側にかけて全体が消えていくとともに、その消えた下側の領域が透明領域になって上に向かって拡大していくように表示内容が遷移しつつ、画面４２の画像は、同じ方向（下から上に向かう方向）にディスプレイ９の表示領域（全面）の枠外から枠内に表示画像が徐々に入ってくる（現出する）ように表示内容が遷移する。

従って、ユーザーは、画面の切り換えの間に、画面４１において徐々に拡大していく透明領域を介して、画面４１の下に位置する画面４２の画像がワイプインによりディスプレイ９の表示領域の枠外から枠内に入ってくるのを見ることができる。
なお、画面４１等の大きさは、ディスプレイ９の枠一杯に画面が表示される場合の大きさに限られず、例えばディスプレイ９の全体表示領域のうち、一部の矩形領域を画面４１等の大きさとして、画面４１等を表示するとしても良い。

表示制御部２７は、ＶＲＡＭ３５に書き込まれている画面データ（合成画面データ）をディスプレイ９に送り、その画面データに係る画面の画像をディスプレイ９に表示させる制御を実行する。
＜画面切り換え制御の概要＞
まず、図４を用いて画面の切り換え制御の概要を説明する。

図４（ａ）は、画面の切り換え開始直前に、アプリ１により第１バッファ３１に書き込まれていた画面データによる画面６１と、アプリ２により第２バッファ３２に書き込まれていた画面データによる画面６２と、アプリ３により第３バッファ３３に書き込まれていた画面データによる画面６３の例を示し、図４（ｂ）は、アプリ３により新たに第３バッファ３３に書き込まれる画面データによる画面６４の例を示している。

図４（ｃ）は、現在、ディスプレイ９に画面６１が表示されている状態で、ユーザーによるキー等の操作入力により画面６４への切り換えが指示された場合の切り換え開始から終了までの間に遷移する表示画面の様子の例を時間の経過順に示している。
なお、同図に示す符号９１は、ディスプレイ９の全体表示領域の外枠を示し、符号７０は、ワイプアウトする画面の画像とワイプインする画面の画像との境界線を示している。

本実施の形態の画面切り換えは、図４（ｃ）に示すように最初に表示されていたアプリ１による画面６１の画像が所定の一方向にその下側の部分（一方端）から上側（他方端）に向かって徐々に消去（ワイプアウト）されながら、その消去領域に、アプリ３による新たな画面６４の画像がその下側の部分から上側に向かって徐々に現出してくる（ワイプイン）ように行われる。
＜画面切り換え制御の方法＞
このような画面切り換えを行う場合の制御方法を図５により説明する。

図５は、実施例に係る画面切り換え時の画面データの合成方法を説明するための模式図であり、画面切り換えの間に、第１バッファ３１、第２バッファ３２、第３バッファ３３、中間バッファ３４、ＶＲＡＭ３５のそれぞれに書き込まれる１画面領域に相当する画面データの例を時間経過順（時点ｔ０〜ｔ６）に示している。
ここで、同図の時点ｔ０は、画面切り換え開始時であり、時点ｔ６は、画面切り換え終了時である。また、第１バッファ３１等に書き込まれている画面データの画像を一例として、矩形の１画面領域の外枠９２内において、アルファベットの文字（例えばＡやＢなど）と文字以外の背景部分（下地）とを合わせたもので示している。なお、下地は、特に透明と規定しない限り、非透明になっているものとする。時点ｔ０では、各画面データにおける下地は、非透明である。

以下、外枠９２内において同図の上方向を上、下方向を下、左方向を左、右方向を右と規定し、外枠９２における左上隅の角の位置をＸＹ座標系で〔０，０〕、左下隅の角の位置を〔０，１０〕、右上隅の角の位置を〔１０，０〕、右下隅の角の位置を〔１０，１０〕と規定し、１画面領域内の位置を座標位置で現す場合がある。座標位置は、全てのバッファ３１〜３４、ＶＲＡＭ３５について共通である。

同図に示すように、時点ｔ０では、第１バッファ３１にはアプリ１による画面を示す画面データＺ０が書き込まれており、第２バッファ３２にはアプリ２による画面を示す画面データが書き込まれており、第３バッファ３３にはアプリ３による画面を示す画面データＺ２が書き込まれており、ＶＲＡＭ３５には、第１バッファ３１に書き込まれている画面データと同じ画像を示す画面データが書き込まれている。

ＶＲＡＭ３５に書き込まれている画面データの画像がディスプレイ９に表示されることから、時点ｔ０では、その時点でＶＲＡＭ３５に書き込まれている画面データ、すなわちアプリ１による画面と同じ画面の画像がディスプレイ９に表示されていることになる。
同図では、時点ｔ０でディスプレイ９に表示されている画面（すなわち、アプリ１による画面と同じ画面）の画像が時点ｔ０〜ｔ６にかけてワイプアウトしながら、アプリ３により新たに生成される画面の画像がワイプインするようにして画面が切り換わっていく様子の例が示されている。

第１バッファ３１に書き込まれている画面データは、時点ｔ０から時点ｔ１、ｔ２と時間が経過するに連れて、元の画像の下端から上方向に向かって消えていき、その消えていく部分の代わりに透明領域（斜線部分）Ｐが上方向に拡大していくように漸次書き換えられていることが判る。
この透明領域Ｐへの書き換えは、時点ｔ０での画面データＺ０に対して、アプリ１により元の画像の下端から上方向に向かって例えば左右方向を走査線とするラスタースキャンにより透明を示すデータが画素単位で書き込まれていくことにより行われる。

時点ｔ１での透明領域Ｐ１は、座標位置で示す４点〔０，７〕、〔０，１０〕、〔１０，７〕、〔１０，１０〕を角とする矩形領域に相当し、時点ｔ２での透明領域Ｐ２は、座標位置で示す４点〔０，４〕、〔０，１０〕、〔１０，４〕、〔１０，１０〕を角とする矩形領域に相当し、時点ｔ３以降での透明領域Ｐ３は、座標位置で示す４点〔０，０〕、〔０，１０〕、〔１０，０〕、〔１０，１０〕を角とする矩形領域（１画面領域の全体）になっており、Ｐ１＜Ｐ２＜Ｐ３の大小関係を有している。

なお、同図では、時点ｔ０とｔ１間や時点ｔ１とｔ２間などの各時点間における画面データの書き込みの様子を示していないが、時点ｔ０〜ｔ３間についてはアプリ１による透明領域の書き込みが連続的に継続して実行されている。
第２バッファ３２に書き込まれている画面データは、時点ｔ０〜ｔ６にかけて同じである（変化していない）。第２バッファ３２に書き込まれているアプリ２による画面が切り換え対象になっていないからであり、同図の例では、アプリ２は、時点ｔ０〜ｔ６にかけて第２バッファ３２への画面データの書き込みを実行しない。

第３バッファ３３に書き込まれている画面データは、時点２に至ると、Ｑ１で示す領域において、時点ｔ０での元の画像の下側部分に代えて、新たな画像の下側部分が現れるように書き換えられていることが判る。
この書き換えは、時点ｔ０での画面データＺ２に対して、アプリ３により元の画像の下端から上方向に向かって例えばラスタースキャンにより、新たな画像の下端から上方向に向かってその画像部分を示すデータが書き込まれていくことにより行われる。

上記のアプリ１と同様に、アプリ３による第３バッファ３３への画面データの書き換えは、時点ｔ０〜ｔ２間などの各時点間にも連続的に実行されているが、その書き換えの様子については省略されている。
時点ｔ２におけるアプリ３による第３バッファ３３への画面データＺ３の時点ｔ０からの書き込み領域（新たな画像領域）Ｑ１は、座標位置で示せば、点〔０，７〕、〔０，１０〕、〔１０，７〕、〔１０，１０〕を角とする矩形領域に相当する。この新たな画像領域Ｑ１の大きさは、時点ｔ１におけるアプリ１による透明領域Ｐ１の大きさに等しく、透明領域Ｐ１と新たな画像領域Ｑ１とは、１画面領域内において同じ座標位置同士のものということになる。

つまり、時点ｔ１におけるアプリ１による画面データＺ１をディスプレイ９に表示させたと仮定したときの画面Ｚ１ａ（図６）と、時点ｔ２におけるアプリ３による画面データＺ３をディスプレイ９に表示させたと仮定したときの画面Ｚ３ａ（図６）とを、画面Ｚ１ａが最上位になりその下に画面Ｚ３ａが隠されるように重ね合わせて１つの画面Ｚ４ａを生成（合成）したとすれば、画面Ｚ３ａにおける元の画像領域Ｑ１ａが最上位の画面Ｚ１ａにおける元の画像領域Ｐ１ａに隠されて見えず、画面Ｚ３ａにおける新たな画像領域Ｑ１が最上位の画面Ｚ１ａにおける透明領域Ｐ１を透かして見えるようになる。

この合成画面Ｚ４ａでは、ワイプアウトする画像とワイプインする画像との境界を示す境界線７５が左右方向に平行な１本の直線になるので、ワイプアウトする画像とワイプインする画像との間に隙間が空いたり一部が重複したりすることによる画面ちらつきが発生しない状態にすることができる。
合成画面Ｚ４ａは、図５に示す時点ｔ２におけるＶＲＡＭ３５に書き込まれている合成画面データＺ４をディスプレイ９に表示させたと仮定したときの仮想画面に相当する。

このような合成画面データＺ４を生成するには、画面の切り換え途中に、アプリ１による画面データＺ１の生成とアプリ３による画面データＺ３の生成が同期して行われることが望ましい。
ところが、上記のようにアプリ３は、アプリ１よりも画面データの生成やバッファへの書き込みが遅いために、同じ大きさの領域に対する画面データの書き込みであっても、画面データＺ１については時点ｔ１で行えるのに対し、画面データＺ３については時点ｔ１よりも後の時点ｔ２まで行えず、その時間がずれることになる。

そこで、本実施の形態では、次のような処理を行う。
すなわち、時点ｔ１における第１バッファ３１に書き込まれている画面データＺ１を読み出して中間バッファ３４に記憶させる。中間バッファ３４に記憶された画面データは、アプリ１による画面データＺ１と同じデータであるので、画面データＺ１と称する。
その後、アプリ３による第３バッファ３３への画面データの書き込みが、中間バッファ３４に記憶されている画面データＺ１の透明領域Ｐ１と同じ座標位置である領域Ｑ１まで進むと（時点ｔ２）、第３バッファ３３に現に書き込まれている画面データＺ３と、中間バッファ３４に記憶されている画面データＺ１とを合成して、その合成画面データＺ４をＶＲＡＭ３５に書き込む。

そして、ＶＲＡＭ３５に書き込まれた合成画面データＺ４をディスプレイ９に転送して、ディスプレイ９に表示させる。なお、時点ｔ２以降、アプリ１と同様に、アプリ３による第３バッファ３３への画面データの書き込みも継続実行されることはいうまでもない。
このような画面データの合成は、画面切り換え終了までの間に繰り返し実行される。
具体的には、時点ｔ２において第１バッファ３１に書き込まれている画面データＺ５を読み出して中間バッファ３４に記憶させる。この記憶された画面データは、アプリ１による画面データＺ５と同じデータであるので、画面データＺ５と称する。

その後、アプリ３による第３バッファ３３への画面データの書き込みが、中間バッファ３４に記憶されている画面データＺ５の透明領域Ｐ２と同じ座標位置である領域Ｑ２まで進むと（時点ｔ４）、第３バッファ３３に現に書き込まれている画面データＺ６と、中間バッファ３４に記憶されている画面データＺ５とを合成して、その合成画面データＺ７をＶＲＡＭ３５に書き込む（更新する）。

ＶＲＡＭ３５に書き込まれた合成画面データＺ７がディスプレイ９に転送されて、ディスプレイ９に表示される。
この時点ｔ４よりも前の時点ｔ３では、第１バッファ３１に書き込まれている画面データＺ８が中間バッファ３４に記憶されている（Ｚ８）。
時点ｔ４よりも後に、アプリ３による第３バッファ３３への画面データの書き込みが、中間バッファ３４に記憶されている画面データＺ８の透明領域Ｐ３（１画面全体）と同じ座標位置である領域Ｑ３まで進むと（時点ｔ６）、第３バッファ３３に現に書き込まれている画面データＺ９と、中間バッファ３４に記憶されている画面データＺ８とを合成して、その合成画面データＺ１０をＶＲＡＭ３５に書き込む。

ＶＲＡＭ３５に書き込まれた合成画面データＺ１０がディスプレイ９に転送されて、ディスプレイ９に表示される。これにより、画面切り換えが終了する。
上記では、時点ｔ２、ｔ４、ｔ６のそれぞれだけで合成画面が生成される例を説明したが、各時点間の時間間隔を狭くするほど合成画面の生成間隔も短くなり、単位時間当たりのＶＲＡＭ３５への合成画面の更新回数が増えて、それだけ人の目には、ワイプアウトする表示画像とワイプインする表示画像との境界線７５がよりスムーズに上下方向に移動しているように見えることになる。合成画面の更新回数は、各アプリによる画面データのバッファへの書き込み処理能力や画面データの中間バッファ３４やＶＲＡＭ３５への転送、記憶等の処理能力によるが、例えば１秒間に数十回とすることができる。
＜画面切り換え制御を行わない場合の比較例＞
図７は、上記の画面切り換え制御を行わない場合の比較例を説明するための図である。

この比較例は、アプリ１による第１バッファ３１への画面データの書き込みとアプリ３による第３バッファ３３への画面データの書き込みについては図５における実施例と同じであるが、実施例の中間バッファ３４が存在せず、それぞれの時点ごとに、第１バッファ３１に書き込まれている画面データと第３バッファ３３に書き込まれている画面データとが合成される構成になっている。

アプリ３の方がアプリ１よりもバッファへの画面データの書き込みが遅いので、比較例の場合、例えば時点ｔ１では、アプリ１による第１バッファ３１への透明領域Ｐ１の書き込みに対し、アプリ３による第３バッファ３３への新たな画像領域Ｑ４の書き込みが追い付いていない。
このため、時点ｔ１において第１バッファ３１に書き込まれている画面データＺ２１と第３バッファ３３に書き込まれている画面データＺ２２とを合成した合成画面データＺ２３を見ると、アプリ１による画像領域Ｐ４ａとアプリ３による元の画像領域Ｑ４ａとアプリ３による新たな画像領域Ｑ４とが上下に並んだような画面になる。

この画面は、アプリ１による画像領域Ｐ４ａ（ワイプアウトする画像）とアプリ３による新たな画像領域Ｑ４（ワイプインする画像）との間に隙間が生じた画面に相当し、画面ちらつきの要因になる。
時点ｔ２以降の各時点でも、合成画面データＺ２４やＺ２５等を見ると、時点ｔ１と同様にちらつきの要因を含むデータしか生成できないことが判り、結果的に、比較例の構成では、画面切り換え開始（時点０）から終了（時点ｔ６）までの間に亘って、画面ちらつきが生じながら画面が切り換わることが生じ易いものになる。

本実施の形態では、図５に示すような画面切り換え制御を行うので、切り換え途中での画面ちらつきを防止して、画面切り換えをよりスムーズに実行できるようになる。
＜画面切り換え制御のシーケンス図＞
図８〜図１０は、本実施の形態に係る画面切り換え制御のシーケンス図を示す図であり、図５に示す画面切り換えの例と同じ画面切り換えを行う場合の例を示している。

図８に示すようにアプリ１と３は、画面切り換え指示を受け付ける（Ｇ１，Ｇ２）。
この画面切り換え指示は、例えばユーザーが操作部１３上で現在の操作用画面（アプリ１による画面）から情報画面（アプリ３による画面）への切り換えのためのキー入力操作を行ったときのその入力情報をＣＰＵ２２が受け付けたときに発せられる。
切り換え指示を受け付けたアプリ１は、現在、ディスプレイ９に表示されている操作用画面の画像をワイプアウトするための画面データを第１バッファ３１に書き込む処理を開始する。具体的には、上記の図５に示すように画面下から上に向かって透明領域Ｐが広がっていくような画面データの書き込みを開始する。時点ｔ０での画面データＺ０は、図５に示す画面データＺ０に相当する。

アプリ１は、書き込み開始を示す書き込み開始通知を描画制御部２６に送信する（Ｇ３）。この書き込み開始通知には、書き込み範囲を座標位置で示す情報が含まれる。
書き込み範囲は、矩形であり、その対角となる一方の角の座標位置と他方の角の座標位置により特定されるようになっている。図５の例では、書き込み範囲が画面全体になっており、左上隅の角を示す座標位置〔０，０〕と右下隅の角を示す座標位置〔１０，１０〕が書き込み範囲を示す座標位置になる。

アプリ１と同様に、切り換え指示を受け付けたアプリ３は、新たな情報画面の画像をワイプインするための画面データを第３バッファ３３に書き込む処理を開始し、書き込み範囲を座標位置で示す情報を含む書き込み開始通知を描画制御部２６に送信する（Ｇ４）。書き込み範囲は、アプリ１と同じである。
描画制御部２６は、アプリ１と３からの書き込み範囲を示す情報に基づき、アプリ１と３によりそれぞれ書き込まれる範囲が重なっているか否かを判定する（Ｇ５）。

図５の例のように重なっている場合には、ワイプアウトとワイプインによる画面ちらつきの発生要因になり、重なっていない場合（１画面内にアプリごとに別々の領域に別々の小さな画面がウインドウ形式で表示される場合など）には、画面ちらつきの発生要因がないことになる。以下では、重なっている場合の例を説明する。
アプリ１は、第１バッファ３１への画面データの書き込み途中に、その書き込み開始から所定量Ｈのデータ（透明領域のデータ）を書き込むと（時点ｔ１：画面データＺ１の生成）、その書き込んだ透明領域Ｐ１の範囲を座標位置で示す書き込み通知を描画制御部２６に送信する（Ｇ６）。図８の例では、座標位置が〔０，７〕と〔１０，１０〕になっている。

ここで、所定量Ｈのデータは、例えば１画面の全範囲をラスタースキャンする場合の走査線の全本数Ｎを複数ｎに等分割したときの（Ｎ／ｎ）本の走査線に相当するデータ量（画素数）とすることができる。この所定量Ｈは、アプリ３にも適用される。
なお、所定量Ｈは、１画面内の表示画像がワイプアウトとワイプインにより段階的に遷移する際の１段階（１ステップ）の変化量を示すので、所定量Ｈが小さいほど（ｎの値が大きいほど）、画面切り換え開始から終了までの間における合成画面データのＶＲＡＭ３５への書き換え回数が増えて、ユーザーにとっては、それだけ画面の遷移がよりスムーズに行われるように見えるようになる。

描画制御部２６は、アプリ１からの書き込み通知（Ｇ６）を受信した時点で、これと同じ座標位置を示すアプリ３からの書き込み通知を受信しているか判断し、未受信を判断すると、アプリ１による画面データＺ１を第１バッファ３１から読み出して中間バッファ３４に記憶する（Ｇ７）。このＧ７は、中間処理部５１が担当する。
ここで、画面データＺ１の中間バッファ３４への記憶は、書き込み通知（Ｇ６）に含まれる座標位置（上記例では、〔０，７〕と〔１０，１０〕）を示す情報と画面データＺ１とが対応付けされた状態で実行される。これにより、中間バッファ３４に記憶されている１以上の画面データのそれぞれについて、その座標位置を示す情報を参照すれば、どの座標位置まで画面データが書き込まれた画面データであるかを特定することができる。

従って、中間バッファ３４に記憶されている１以上の画面データのうち、その記憶後に別のアプリから受け付けた書き込み通知に含まれる座標位置に対応する画面データと同じ座標位置の画面データを中間バッファ３４から読み出すことができる。中間バッファ３４にＺ１とは別の画面データ（Ｚ３など）が記憶される際にも、上記同様に、その画面データとその座標位置とが対応付けされた状態で管理される。

アプリ３は、第３バッファ３３への画面データの書き込み途中に、その書き込み開始から所定量Ｈのデータを書き込むと（時点ｔ２）、その書き込んだ範囲を座標位置で示す書き込み通知を描画制御部２６に送信する（Ｇ８）。図８の例では、座標位置が〔０，７〕と〔１０，１０〕になっている。
描画制御部２６は、アプリ３からの書き込み通知（Ｇ８）を受信すると、これと同じ座標位置を示すアプリ１からの書き込み通知を既に受信しているので、アプリ３による画面データＺ３を第３バッファ３３から読み出し（Ｇ９）、同じ座標位置まで書き込まれたアプリ１による画面データＺ１を中間バッファ３４から読み出す（Ｇ１０）。

そして、読み出した画面データＺ１とＺ３（同じ座標位置を示すもの）を合成して、その合成画面データＺ４をＶＲＡＭ３５に書き込む（Ｇ１１）。このＧ１１は、データ合成部５２が担当する。
ＶＲＡＭ３５に書き込まれた合成画面データＺ４は、ディスプレイ９に送られて、合成画面データＺ４に係る画像がディスプレイ９に表示される。

図９に移って、アプリ１は、第１バッファ３１への画面データの書き込み途中に、前回の書き込み通知時に書き込まれた範囲（上記例では、座標位置〔０，７〕と〔１０，１０〕）から、さらに所定量Ｈのデータを書き込むと（画面データＺ５の生成）、その書き込んだ範囲を座標位置で示す書き込み通知を描画制御部２６に送信する（Ｇ１２）。図９の例では、座標位置が〔０，４〕と〔１０，７〕になっている。

描画制御部２６は、アプリ１からの書き込み通知を受信した時点で、これと同じ座標位置を示すアプリ３からの書き込み通知を受信していないことを判断すると、アプリ１による画面データＺ５を第１バッファ３１から読み出して中間バッファ３４に記憶する（Ｇ１３）。このＧ１３は、中間処理部５１が担当する。
画面データＺ５の中間バッファ３４への記憶は、例えば既に中間バッファ３４に記憶されている画面データＺ１とは別の記憶領域に画面データＺ５の全体を中間バッファ３４に書き込む方法や、画面データＺ５のうち、既に中間バッファ３４に記憶されている画面データＺ１との差分、つまり座標位置〔０，４〕と〔１０，７〕で示される部分領域に相当する部分のデータだけを、中間バッファ３４に記憶されている画面データＺ１に対して書き換える方法などにより行うとしても良い。このことは、後述の他の画面データＺ５、Ｚ８などを中間バッファ３４に記憶させる場合にも同様に適用される。

アプリ１による書き込みが進み、前回の書き込み通知時に書き込まれた範囲（上記例では、座標位置〔０，４〕と〔１０，７〕）から、さらに所定量Ｈのデータを書き込むと（時点ｔ３：画面データＺ８の生成）、その書き込んだ範囲を座標位置で示す書き込み通知を描画制御部２６に送信する（Ｇ１４）。図９の例では、座標位置が〔０，０〕と〔１０，４〕になっている。

画面データＺ８は、書き込み範囲の全域に対して書き込みが終了したデータ（全域が透明領域のデータ）に相当するので、アプリ１は、書き込み終了を示す書き込み終了通知を描画制御部２６に送る（Ｇ１５）。
描画制御部２６は、アプリ１からの書き込み通知（Ｇ１４）を受信した時点で、これと同じ座標位置を示すアプリ３からの書き込み通知を受信していないことを判断すると、アプリ１による画面データＺ８を第１バッファ３１から読み出して中間バッファ３４に記憶する（Ｇ１６）。このＧ１６は、中間処理部５１が担当する。

第３バッファ３３への画面データの書き込みを実行中のアプリ３は、前回の書き込み通知時に書き込まれた範囲（上記例では、座標位置〔０，７〕と〔１０，１０〕）から、さらに所定量Ｈのデータを書き込むと（時点ｔ４：画面データＺ６の生成）、その書き込んだ範囲を座標位置で示す書き込み通知を描画制御部２６に送信する（Ｇ１７）。図９の例では、座標位置が〔０，４〕と〔１０，７〕になっている。

描画制御部２６は、アプリ３からの書き込み通知（Ｇ１７）を受信すると、これと同じ座標位置を示すアプリ１からの書き込み通知を既に受信していることを判断し、アプリ３による画面データＺ６を第３バッファ３３から読み出し（Ｇ１８）、同じ座標位置まで書き込まれたアプリ１による画面データＺ５を中間バッファ３４から読み出す（Ｇ１９）。
そして、読み出した画面データＺ５とＺ６（同じ座標位置を示すもの）を合成して、その合成画面データＺ７をＶＲＡＭ３５に書き込む（Ｇ２０）。このＧ２０は、データ合成部５２が担当する。

ＶＲＡＭ３５に書き込まれた合成画面データＺ７は、ディスプレイ９に送られ、これまでディスプレイ９に表示されていた合成画面データＺ４に係る画像に代えて、合成画面データＺ７に係る画像がディスプレイ９に表示される。
図１０に移って、アプリ３による書き込みが進み、前回の書き込み通知時に書き込まれた範囲（上記例では、座標位置〔０，４〕と〔１０，７〕）から、さらに所定量Ｈのデータを書き込むと（時点ｔ６：画面データＺ９の生成）、その書き込んだ範囲を座標位置で示す書き込み通知を描画制御部２６に送信する（Ｇ２１）。図１０の例では、座標位置が〔０，０〕と〔１０，４〕になっている。

画面データＺ９は、書き込み範囲の全域に対して書き込みが終了したデータに相当するので、アプリ３は、書き込み終了を示す書き込み終了通知を描画制御部２６に送る（Ｇ２２）。
描画制御部２６は、アプリ３からの書き込み通知（Ｇ２１）を受信すると、これと同じ座標位置を示すアプリ１からの書き込み通知を既に受信していることを判断し、アプリ３による画面データＺ９を第３バッファ３３から読み出し（Ｇ２３）、同じ座標位置まで書き込まれたアプリ１による画面データＺ８を中間バッファ３４から読み出す（Ｇ２４）。

そして、読み出した画面データＺ８とＺ９（同じ座標位置を示すもの）を合成して、その合成画面データＺ１０をＶＲＡＭ３５に書き込む（Ｇ２５）。このＧ２５は、データ合成部５２が担当する。
ＶＲＡＭ３５に書き込まれた合成画面データＺ１０は、ディスプレイ９に送られ、これまでディスプレイ９に表示されていた合成画面データＺ７に係る画像に代えて、合成画面データＺ１０に係る画像がディスプレイ９に表示される。

なお、描画制御部２６は、アプリ１と３のそれぞれからの書き込み終了通知の受信により、アプリ１による第１バッファ３１への画面データの書き込みと、アプリ３による第３バッファ３３への画面データの書き込みの終了を判断する。
＜画面切り換え制御のフロー＞
図１１は、アプリ１〜３のそれぞれが画面切り換え制御の際に実行する画面データ書き込み処理の内容を示すフローチャートである。ここでは、アプリ１による処理を例に説明するが、他のアプリ２と３についても基本的に同様の処理が実行される。

同図に示すように、アプリ１は、画面切り換え指示を受け付けると、書き込み開始通知を描画制御部２６に送信し（ステップＳ１）、画面切り換え指示に基づく画面データを第１バッファ３１に書き込む処理を開始する（ステップＳ２）。
以降、アプリ１による画面（図４の画面６１など）がディスプレイ９上において一方向に下（一方端）から上（他方端）にかけて徐々に消去されるように画面データが第１バッファ３１に漸次書き込まれていく。なお、アプリ３であればその画面（図４の画面６４など）がディスプレイ９上において一方向に下から上にかけて、アプリ１による画面の消去領域に徐々に現出されるように画面データが第３バッファ３３に漸次書き込まれていく。

画面データの書き込み開始からの書き込み量Ｊが所定量Ｈに達したか否かを判断する（ステップＳ３）。アプリ１は、自己が第１バッファ３１に書き込んだデータ量を１画素単位または１走査線単位でカウントした値を書き込み量Ｊとして、そのカウント値が所定量Ｈに達すると、画面データの書き込み量Ｊが所定量Ｈに達したことを判断する。
書き込み量Ｊが所定量Ｈに達したことを判断すると（ステップＳ３で「ＹＥＳ」）、書き込んだ範囲を座標位置で示す書き込み通知を描画制御部２６に送信して（ステップＳ４）、ステップ５に移る。

ステップＳ５では、画面データの書き込みが終了したか否かを判断する。
画面データの書き込みが終了していないことを判断すると（ステップＳ５で「ＮＯ」）、ステップ３に戻る。
ステップＳ３では、前回、書き込み量Ｊが所定量Ｈに達した以降からの書き込み量Ｊが所定量Ｈに達した否かを判断する。この判断は、例えば前回、所定量の画面データの書き込みが終了した時点で上記のカウント値を０にリセットして、カウントを０から開始した後、そのカウント値（書き込み量Ｊ）が所定量Ｈに達したか否かを判断することにより行われる。

書き込み量Ｊが所定量Ｈに達したことを判断すると（ステップＳ３で「ＹＥＳ」）、その書き込んだ範囲を座標位置で示す書き込み通知を描画制御部２６に送信し（ステップＳ４）、画面データの書き込みが終了していなければ（ステップＳ５で「ＮＯ」）、再度、ステップＳ３に戻って、ステップ３以降を実行する。
アプリ１は、第１バッファ３１への画面データの書き込み開始から終了までの間、画面データの書き込み量Ｊが所定量Ｈに達するごとに、書き込み通知を描画制御部２６に送信する（ステップＳ３〜Ｓ５）。

アプリ１は、画面データの書き込みが終了したことを判断すると（ステップＳ５で「ＹＥＳ」）、書き込み終了通知を描画制御部２６に送信して（ステップＳ６）、当該処理を終了する。
図１２は、描画制御部２６が実行する画面切り換え処理の内容を示すフローチャートである。

同図に示すように、描画制御部２６は、各アプリ（上記例では、アプリ１と３）から書き込み開始通知を受信すると（ステップＳ１１）、書き込み開始通知に含まれる書き込み範囲に基づき、各アプリによるそれぞれの画面に重なりがあるか否かを判定する（ステップＳ１２）。この判定は、一方のアプリによる１画面上における書き込み範囲と他方のアプリによる１画面上における書き込み範囲をそれぞれの座標位置から特定することにより行われる。

例えば、図５の例で示すように一方と他方のアプリがそれぞれ１画面の全体領域を書き換える場合には、重なりがあると判定される。これとは別に、１画面上において一方のアプリがある部分領域に小さな画面をウインドウ表示し、他方のアプリが別の部分領域に別の小さな画面をウインドウ表示するような場合には、重なりがないと判定される。
描画制御部２６は、重なりがあることを判定すると（ステップＳ１３で「ＹＥＳ」）、いずれかのアプリから書き込み通知を受信したか否かを判断する（ステップＳ１４）。

ここで、書き込み通知の受信を判断すると（ステップＳ１４で「ＹＥＳ」）、その書き込み通知に含まれる座標位置を示す情報（上記図８の例では、〔０，７〕と〔１０，１０〕など）と同じ座標位置を示す書き込み通知を他方のアプリから受信済みか否かを判断する（ステップＳ１５）。
図８においてアプリ１からの書き込み通知を受信した場合（Ｇ６）を例にすると、他方のアプリであるアプリ３からの同じ座標位置を示す書き込み通知（Ｇ８）を未だ受信していないことになるので、未受信と判断する。未受信を判断することは、書き込み通知を出力したアプリが画面データのバッファへの書き込みが速い方のアプリであり、他方のアプリが遅い方のアプリであることをそれぞれ判断したことに等しい。

描画制御部２６は、未受信であることを判断すると（ステップＳ１６で「ＮＯ」）、書き込み通知を出力したアプリが画面データのバッファへの書き込みの速い方のアプリと判断して、そのアプリによりバッファに書き込まれている画面データを読み出して中間バッファ３４に記憶させ（ステップＳ１７）、ステップ１４に戻る。
図８において、アプリ１が書き込み通知を出力した場合（Ｇ６）を例にすると、アプリ１による画面データＺ１を第１バッファ３１から読み出してその画面データＺ１を中間バッファ３４に記憶させる（Ｇ７）。

画面データＺ１の中間バッファ３４への記憶は、上記のように書き込み通知に含まれる座標位置を示す情報（〔０，７〕と〔１０，１０〕）と画面データＺ１とを対応付けることにより行われる。画面データと座標位置とが対応付けされて中間バッファ３４に記憶されることは、他の画面データＺ３などについても同様である。
描画制御部２６は、ステップＳ１４において、再度、いずれかのアプリからの書き込み通知を受信したか否かを判断する。

ここで、書き込み通知の受信を判断すると（ステップＳ１４で「ＹＥＳ」）、その書き込み通知に含まれる座標位置と同じ座標位置を示す書き込み通知を他方のアプリから受信済みか否かを判断する（ステップＳ１５）。
図８においてアプリ３からの書き込み通知を受信した場合（Ｇ８）を例にすると、他方のアプリであるアプリ１からの同じ座標位置を示す書き込み通知（Ｇ６）を既に受信していることになるので、受信済みと判断する。

描画制御部２６は、受信済みであることを判断すると（ステップＳ１６で「ＹＥＳ」）、その書き込み通知を出力したアプリが画面データのバッファへの書き込みの遅い方のアプリと判断して、中間バッファ３４に記憶されている画面データのうち、書き込み通知を出力したアプリによる画面データと同じ座標位置を示す画面データを中間バッファ３４から読み出し（ステップＳ１８）、書き込み通知を出力したアプリによる画面データをそのアプリに対応するバッファから読み出す（ステップＳ１９）。

そして、描画制御部２６は、読み出されたそれぞれの画面データを合成して、合成画面データを生成する（ステップＳ２０）。
図８において、アプリ３が書き込み通知を出力した場合（Ｇ８）を例にすると、同じ座標位置の画面データＺ１を中間バッファ３４から読み出し（Ｇ１０）、アプリ３による画面データＺ３を第３バッファ３３から読み出し（Ｇ９）、読み出された画面データＺ１と画面データＺ３とを合成する（Ｇ１１）。

描画制御部２６は、合成画面データをＶＲＡＭ３５に書き込むと（ステップＳ２１）、書き込みが終了か否かを判断する（ステップＳ２２）。この書き込み終了の判断は、書き込み終了通知を最後に受信したアプリによる画面データの合成（図１０の例ではＧ２５）が終了したことを判断することにより行われる。
描画制御部２６は、書き込みが終了していないことを判断すると（ステップＳ２２で「ＮＯ」）、ステップＳ１４に戻って、ステップＳ１４以降の処理を実行する。

書き込み終了が判断されるまで、ステップＳ１４〜Ｓ２２の処理が繰り返し実行される。これにより、一方と他方のアプリによる同じ座標位置の画面データの書き込みが行われるごとに、同じ座標位置同士の画面データを合成した合成画面データが順次、ＶＲＡＭ３５に書き込まれて更新されていく。
描画制御部２６は、書き込み終了を判断すると（ステップＳ２２で「ＹＥＳ」）、当該処理を終了する。

また、描画制御部２６は、各アプリによる書き込み領域に重なりがないことを判断すると（ステップＳ１３で「ＮＯ」）、各アプリに対応するそれぞれのバッファから、各アプリによる画面データを一定周期で読み出して、その読み出しごとに、それぞれの画面データを合成した合成画面データをＶＲＡＭ３５に書き込む処理を書き込み終了までの間、実行した後（ステップＳ２３）、当該処理を終了する。この一定周期の読み出しは、例えば１秒間に数十回などとすることができる。

ステップＳ２３の処理は、上記の画面データの中間バッファ３４への記憶の禁止と、この禁止の判断により、第１バッファ３１〜第３バッファ３３からの画面データと中間バッファ３４からの画面データとの合成を禁止する処理に相当する。
以上、説明したように画面切り換えを担当する２つのアプリによる画面データのバッファへの書き込み途中に、書き込みの速い方のアプリによる画面データが所定量書き込まれるごとに、その時点での画面データを一時的に中間バッファ３４に記憶する。

そして、中間バッファ３４に記憶されている画面データと合成されるべき画面データ（上記例では、書き込まれた範囲を示す座標位置が同じ画面データ）が、書き込みの遅い方のアプリにより書き込まれるごとに、遅い方のアプリによる画面データと、これに対応する、中間バッファ３４に記憶されている画面データ（速い方のアプリによるもの）とを合成し、その合成画面データを順次、ＶＲＡＭ３５に書き込むことにより、ＶＲＡＭ３５に書き込まれる合成画面データを更新していく構成としている。

従って、２つのアプリが同じデータ量の画面データを書き込むのに要する時間が異なる特性を有しており、それぞれのアプリが別々に生成した画面データを各バッファに書き込みを行う構成をとっても、ＶＲＡＭ３５に書き込まれる合成画面データは、一方と他方のそれぞれのアプリによる、合成されるべき（同じ座標位置まで書き込まれた）２つの画面データが合成されたものになる。

これにより、例えばワイプアウトする表示画像に対してワイプインする表示画像が追い付けずに表示画像間に隙間が生じることなどによる画面ちらつきの発生を防止できる。
なお、本発明は、画像処理装置に限られず、例えば表示画面の切換方法であるとしても良い。また、その方法をコンピュータが実行するプログラムであるとしても良い。本発明に係るプログラムは、例えば磁気テープ、フレキシブルディスク等の磁気ディスク、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＭＯ、ＰＤなどの光記録媒体、フラッシュメモリ系記録媒体等、コンピュータ読み取り可能な各種記録媒体に記録することが可能であり、当該記録媒体の形態で生産、譲渡等がなされる場合もあるし、プログラムの形態でインターネットを含む有線、無線の各種ネットワーク、放送、電気通信回線、衛星通信等を介して伝送、供給される場合もある。

（変形例）
以上、本発明を実施の形態に基づいて説明してきたが、本発明は、上述の実施の形態に限定されないのは勿論であり、以下のような場合も本発明に含まれる。
（１）上記実施の形態では、描画制御部２６は、一方のアプリからの書き込み通知を受信した時点で、同じ座標位置を示す書き込み通知を他方のアプリから未だ受信していなかった場合にだけ（図１２のステップＳ１６で「ＮＯ」）、一方のアプリによる画面データを中間バッファ３４に記憶させる（ステップＳ１７）、すなわち、他方のアプリからの書き込み通知の有無を、画面データの中間バッファ３４への書き込み要否の判断条件としたが、これに限られない。

例えば、他方のアプリからの書き込み通知を参照せず、アプリごとに、今回と過去（前回）のそれぞれの書き込み通知に含まれる座標位置に差分（相違）があるか否かを、画面データの中間バッファ３４への書き込み要否の判断条件とすることもできる。
図１３は、この判断条件に基づく画面切り換え処理の一部を示すフローチャートであり、図１２に示す画面切り換え処理と異なる部分だけを抜き出しており、他の部分は、図１２に示すフローチャートと同じになっている。

図１３に示すように、アプリからの書き込み通知を受信すると（ステップＳ１４で「ＹＥＳ」）、今回の書き込み通知に含まれる座標位置と、同じアプリからの前回の書き込み通知に含まれていた座標位置との差分の有無を判断する（ステップＳ３１）。
この判断は、アプリからの書き込み通知を受信するごとに、そのアプリの名称とその書き込み通知が何回目の受信であるかを示す番号とその書き込み通知に含まれる座標位置とを対応付けた情報を管理して、書き込み通知を出力したアプリに対する今回と前回のそれぞれの座標位置を比較することにより行われる。

差分があることを判断すると（ステップＳ３２で「ＹＥＳ」）、今回の書き込み通知に対応する画面データが未だ中間バッファ３４に記憶されていないとして、その画面データを中間バッファ３４に記憶させて（ステップＳ３３）、ステップＳ３４に移る。
一方、差分がないことを判断すると（ステップＳ３２で「ＮＯ」）、今回の書き込み通知に対応する画面データが既に中間バッファ３４に記憶されているとして、ステップＳ３３を実行せずに、ステップＳ３４に移る。

ステップＳ３４では、中間バッファ３４に記憶されている画面データのうち、書き込み通知を出力したアプリによる画面データと同じ座標位置を示す、他のアプリからの画面データが存在するか否かを判断する。
この判断は、中間バッファ３４に記憶されている１以上の画面データごとにその画面データに対応付けて管理されている座標位置を参照することにより行われる。

存在することを判断すると（ステップＳ３５で「ＹＥＳ」）、その同じ座標位置を示す他のアプリからの画面データを中間バッファ３４から読み出して（ステップＳ３６）、ステップＳ１９以降の処理を実行する。一方、存在しないことを判断すると（ステップＳ３５で「ＮＯ」）、ステップＳ１４に戻って、次回の書き込み通知の受信を待つ。
前回と今回のそれぞれの書き込み通知に含まれる座標位置に差分がある場合に限って画面データを中間バッファ３４に書き込む構成をとる場合に、その差分の有無を判断することにより、画面データの中間バッファ３４への書き込み要否を決めることができる。

前回と今回のそれぞれの書き込み通知に含まれる座標位置に差分があるということは、その差分の量だけ画面データが書き換えられたことを意味する。
例えば、画面データのバッファへの書き込みが１本の走査線単位であり、１本の走査線に相当する全画素に対するデータの書き込みが終了するまでの間、前回と同じ座標位置を示す書き込み通知を複数回、出力するような第３ベンダーによるアプリが用いられる場合に、そのアプリからの書き込み通知を受信するごとに、画面データの中間バッファ３４への記憶を行わなくて済み、描画制御部２６の処理負担を軽減することができる。

（２）また、上記の差分の有無を判断することに代えて、例えば、その差分が閾値を超えた場合にだけ、中間バッファ３４への記憶が必要と判断する方法をとることもできる。
例えば、各アプリが１本の走査線のデータをラスタースキャンにより書き込むごとに書き込み通知を出力する構成であり、閾値を５とすれば、５本の走査線分のデータ量を１つのバンド単位として、アプリにより５本の走査線分のデータがバッファに書き込まれるごとに、そのアプリによる画面データが中間バッファ３４に記憶されていく。

この閾値（１バンドのデータ量）を小さくするほど、画面切り換え開始から終了までの間に、アプリがバッファに書き込んでいる途中の画面データが中間バッファ３４に記憶される回数が増える。
このことは、合成画面データのＶＲＡＭ３５への書き換え回数が増えることに等しいので、上記の所定量Ｈを小さくすることと同様に、ユーザーは、ディスプレイ９上での表示画面の切り換わりがよりスムーズに行われていることを目視できるようになる。閾値（１バンドのデータ量）は、各アプリに共通の値を予め決めておくとしても良いし、アプリごとに異なる値を予め決めておくこともできる。

アプリごとに閾値が異なる場合、例えばアプリ１が閾値５であれば、アプリ３が閾値１０のように一方が他方の倍数になるなど、同じ書き込み量（座標位置）同士の画面データを合成できるように決められる。
実施の形態では、各アプリがそれぞれ同じ所定量Ｈ（上記の閾値に相当）を有するとしたが、本変形例のようにアプリごとに所定量Ｈを異なる値をとる構成を実施の形態に適用する場合でも、アプリごとに一方が他方の倍数になっていれば、同じ座標位置同士の画面データを合成することができる。

（３）また、実施の形態では、アプリ１による１つの画面６１の画像をアプリ３による１つの画面６４の画像に切り換える場合に１つの所定値Ｈ（上記の閾値に相当）を適用する場合の例を説明したが、これに限られない。
例えば、アプリ１が上記の画面６１の画像（第１画像）とは別の第３画像を表示可能であり、アプリ３も上記の画面６４の画像（第２画像）とは別の第４画像を表示可能である場合に、アプリ１による第３画像の画面データとアプリ３による第４画像の画面データに対しても、上記と同じ所定量Ｈを適用するとしても良いし、これとは異なる所定量Ｈ１を適用するとしても良い。

上記のように所定値Ｈを小さくするほど、ワイプインとワイプアウトにより表示画面が段階的に遷移する際の１ステップの変化量が小さくなって画面切り換えがより細やか（スムーズ）に行われているようにユーザーには見える。
従って、異なる複数の画像のうち、ワイプインする１つの画像とワイプアウトする１つの画像について、異なる複数通りの組み合わせを事前に決めておき、その組み合わせごとに、画面の切り換えをより細やかに行う場合には所定値Ｈを小さくし、その必要がない場合には、所定値を大きくするように所定値Ｈの大きさを変化させるとしても良い。

どの画像の組み合わせに対して所定値Ｈをどの大きさに設定するかを予め実験などにより決めておくことができる。
例えば、ディスプレイ９上での画像の大きさ（表示領域）が小さい方が大きい場合よりもユーザーに切り換え動作が見え難くなるので、所定量Ｈを大きくすることができる。
具体的には、第１画像と第２画像よりも第３画像と第４画像の方がディスプレイ９上における表示領域が小さい場合には、第１画像と第２画像に対する所定量をＨ、第３画像と第４画像に対する所定量をＨ１とすると、Ｈ＜Ｈ１の関係とすれば、第１画像と第２画像に対しては画面切り換えがよりスムーズ（細か）に行われているように見せることができ、第３画像と第４画像に対しては、中間バッファ３４への画面データの書き込み回数が減って、それだけ描画制御部２６の処理負担を軽減できる。

（４）さらに、上記に代えて、例えばそれぞれのアプリによる画面データを、書き込み通知の受信ごとに、特に何らかの判断を行うことなく、中間バッファ３４に記憶させる構成をとることもできる。
この場合、両方のアプリによる画面データのバッファへの書き込みの実行中に、両方のアプリによる画面データが全て中間バッファ３４に記憶され、中間バッファ３４に記憶されている両方のアプリの画面データのうち、書き込み領域が同じ座標位置を示す画面データ同士（合成されるべき画面データ同士）を、書き込み順序が早いものから合成して、合成ごとに、その合成画面データをＶＲＡＭ３５に書き込む構成がとられる。

（５）上記実施の形態では、ワイプアウトのための画面データを生成するアプリ１の方がワイプインのための画面データを生成するアプリ３よりも画面データのバッファへの書き込みが速い場合の例を説明したが、これに限られない。
例えば、アプリ３の方がアプリ１よりも画面データの書き込みが速い場合には、次のようになる。すなわち、（ａ）速い方のアプリ３により第３バッファ３３に画面データＺ３が書き込まれると、その画面データＺ３を中間バッファ３４に書き込む。

（ｂ）その後、遅い方のアプリ１により、画面データＺ３と同じ書き込み量（座標位置）に相当する画面データＺ１が第１バッファ３１に書き込まれると、その画面データＺ１を第１バッファ３１から読み出し、中間バッファ３４から画面データＺ３を読み出す。
（ｃ）読み出された画面データＺ１とＺ３を合成して（合成順は、Ｚ１が最上位、Ｚ３がＺ１の下）、合成画面データＺ４をＶＲＡＭ３５に書き込む。以降、アプリ３により画面データが所定量Ｈだけ第３バッファ３３に書き込まれるごとに、上記の（ａ）〜（ｃ）を繰り返し実行する。つまり、ワイプアウトする画像が最上位になり、ワイプインする画像がその下位に位置するように各画像の重なりの順位が決められ、その決められた順位に基づき各画面データが合成される。

なお、画面切り換え開始から終了までの間で、仮に、ある部分区間αではアプリ１の方がアプリ３よりもバッファへの書き込みが速いという関係を有するが、別の部分区間βではその関係が逆になるような場合があっても、速い方のアプリによる画面データを中間バッファ３４に一時的に記憶させておけば、その後、遅い方のアプリによる画面データと合成して合成画面データを生成することができる。

（６）上記実施の形態では、描画制御部２６は、アプリから、書き込み対象範囲のうち、どの部分領域まで画面データをバッファに書き込んだかを座標位置で示す書き込み通知を所定量のデータが書き込まれるごとに受信して、そのアプリによる画面データのバッファへの書き込み量を判断するとしたが、これに限られない。
アプリからの書き込み通知を受信しなくても、バッファへの画面データの書き込み中にその書き込み量を検出できる他の方法、例えばバッファが自己への書き込み量を検出可能であれば、そのバッファから描画制御部２６が書き込み量の検出値を取得するなどの方法を用いるとしても良い。

また、例えば、それぞれのアプリと描画制御部２６双方が参照可能なメモリ空間を有し、それぞれのアプリが画面データのバッファへの書き込み中にその書き込んだ領域の座標位置またはその書き込み量（例えば、書き込んだライン数、画素数、全体の書き込み量（全体画像）に対する割合（％）を示す値など）を一定周期ごとにそのメモリ空間に書き込んでいき、これに並行して描画制御部２６が定期的にそのメモリ空間をポーリングすることにより、それぞれのアプリの書き込み量を判断する構成などをとることもできる。

（７）上記実施の形態では、各アプリ１〜３による画面が同じ大きさである場合の例を説明したが、これに限られず、異なる場合にも適用できる。例えば、アプリ１による画像の大きさに対し、アプリ３による画像がその左右方向長さ（幅）が同じで上下方向長さ（高さ）が半分の大きさであり、アプリ１による画像の下半分の領域にアプリ３による新たな画像が挿入されるように画面切り換えが行われる場合が考えられる。

この場合、切り換え終了時点の表示画面は、その下半分の領域にアプリ３による画像が表示され、その上半分の領域は透明領域になる。仮に、アプリ１〜３による各画面データを合成し、各アプリによる画像の重なり順位を上からアプリ１（最上位）、３、２（最下位）のように設定すれば、表示画面の上半分には、アプリ２による画像が表示される。
各画像の大きさが異なり、小さい方の画像が大きい方の画像内に収まることの判断は、各アプリからの書き込み開始通知に含まれる書き込み範囲（座標位置）を参照することにより行うことができる。各アプリによる画面データを、各画像がその座標位置に基づく位置で上下に重なり合うように合成することにより実現できる。

（８）上記実施の形態では、３つのアプリ１〜３がそれぞれワイプインやワイプアウトのための画面データを、対応するバッファに書き込んでいくデータ書込手段として機能する例を説明したが、アプリの数は３つに限られず、複数であるとしても良い。
複数のアプリのうち、現在の表示画像をワイプアウトするための画面データの書き換えを担当するアプリと、新たな画像をワイプインするための画面データの書き換えを担当する別のアプリがそれぞれ個別に実行される。

（９）上記実施の形態では、画面の切り換えがワイプインとワイプアウトにより行われるとしたが、これに限られない。例えば、上記のスライドインとスライドアウトによる切り換え制御の場合にも適用できる。
スライドインとスライドアウトの場合、図１４の例に示すように画面６１が表示されている状態から画面６５、６６、６７を経て画面６４まで切り換わるように制御される。

すなわち、ディスプレイ９上に最初に表示されているアプリ１による画像８１が一方向（ここでは上方向）に徐々にスライド移動して外枠９１から枠外に消えながら（スライドアウト）、その消去領域に、アプリ３による新たな画像８２が同方向、すなわち枠外から枠内に下から上方向に徐々にスライド移動して入ってくるように（スライドイン）、画面が切り換えられる。

図１５は、スライドアウトとスライドインによる画面切り換え制御を実行する場合の画面データの例を示す模式図である。
スライドアウトするための画面データＺ１ｂは、その下側に透明領域Ｐ１が存在し、この透明領域Ｐ１については、図５のワイプアウトの例による画面データＺ１と同じである。一方で、図１５に示す画面データＺ１ｂでは、元の画像領域８３が透明領域Ｐ１の幅の分だけ上方にスライド移動しているので、この画像領域８３については、図５のワイプアウトの例による画面データＺ１とは異なっている。

つまり、実施の形態におけるワイプアウトの場合であれば、１画面全体のうち透明領域Ｐ１の部分だけを所定量Ｈだけ書き換えると、書き込み通知を描画制御部２６に出力する構成をとれば良いが、本変形例におけるスライドアウトの場合、図１５に示す画面データＺ１ｂのように画面データＺ０に対して、透明領域Ｐ１も画像領域８３も含めて１画面全体を書き換える必要があるので、１画面全体の書き込みが終了してから、書き込み通知を描画制御部２６に出力する構成がとられる。

続いて、現在の画面データＺ１ｂから次の画面データＺ５ｂへの１画面全体の書き換えを開始し、画面データＺ５ｂの第１バッファ３１への書き込みが終了すると、再度、書き込み通知を描画制御部２６に出力する。このアプリ１による１画面全体についての画面データの書き換えが画面の切り換え終了までの間に亘って繰り返し実行される。
スライドインの場合、ここではスライドアウトと同様に１画面全体の画面データが書き換えられる構成がとられ、アプリ３は、画面データＺ３ｂに示すように、入り込んでくる新たな画像領域Ｑ１ｂについて、その上端の部分から表示されるように画面データを第３バッファ３３に書き込む。

実施の形態におけるワイプインでは、図５の画面データＺ３に示すように新たな画像領域Ｑ１の下端の部分から表示されるように画面データが書き込まれていたが、この点で変形例における図１５に示すスライドインとは異なっている。本変形例では、アプリ３もアプリ１と同様に、１画面全体についての画面データの書き込みが終了すると、書き込み通知を描画制御部２６に出力する。

続いて、図１５に示すように現在の画面データＺ３ｂから次の画面データＺ６ｂへの書き換えを開始し、画面データＺ６ｂの第３バッファ３３への書き換えが終了すると、再度、書き込み通知を描画制御部２６に出力する。アプリ３による１画面全体についての画面データの書き換えが画面の切り換え終了までの間に亘って繰り返し実行される。
アプリ１による画面データの第１バッファ３１への書き込みと、アプリ３による画面データの第３バッファ３３への書き込みとが並行して行われている間、アプリ１による画面データＺ１ｂが中間バッファ３４に記憶され、その後、アプリ３による画面データＺ３ｂの書き込みが終了すると、画面データＺ１ｂとＺ３ｂとが合成されて、その合成画面データＺ４ｂがＶＲＡＭ３５に記憶されることは、上記実施の形態と同じである。

これ以降、同じ座標位置まで書き込まれたアプリ１と３による画面データ同士を合成した合成画面データをＶＲＡＭ３５に記憶させることが、画面の切り換え終了までの間に亘って繰り返し実行されることも、上記実施の形態と同じである。
このスライドインとスライドアウトを用いる場合、アプリ１〜３のそれぞれは、１画面全体に対する画面データを書き換えたことを条件に、その書き込みを示す書き込み通知を描画制御部２６に出力するために、図１１のステップＳ３では、所定量Ｈが１画面全体に相当する書き込み量に予め設定される。

なお、スライドインでは、例えばアプリ３による画面データＺ３ｂ（図１５）に示すように、元の画像領域Ｑ１ａについては書き換えの必要がないので、新たな画像領域Ｑ１ｂまで書き込みが終了するごとに、書き込み通知を出力する構成をとることも可能である。
この構成をとる場合、アプリ３の方がアプリ１よりも画面データの所定量の書き込みが速くなれば、中間バッファ３４にはアプリ３による画面データが記憶されることになる。

また、ワイプインやスライドインなどとは別の画面の切り換え制御にも同様に適用でき、すなわちディスプレイ９上で、第１画像をその一部から全体に亘って徐々に消去しながら、新たな第２画像が徐々に現出するようにして画面を切り換える制御一般に適用することができる。さらに、ワイプインなどによる画像の移動方向は、上記のようにディスプレイ９上において下から上に向かう方向に限られず、例えば上から下、右下隅から左上隅に向かう方向などの一の方向をとることができる。

（１０）上記実施の形態では、本発明に係る画像処理装置をＭＦＰに適用した場合の例を説明したが、これに限られない。ディスプレイ９を有する操作パネルなどの操作部１３を備える画像処理装置であれば、例えば複写機、プリンター、スキャナー、ファクシミリ装置等に適用できる。また、上記の実施の形態などの処理がソフトウェアにより行なわれる構成であっても良いし、ハードウェア回路を用いて行なわれる構成であっても良い。

また、上記実施の形態及び上記変形例の内容をそれぞれ可能な限り組み合わせるとしても良い。

本発明は、ディスプレイに表示される画面を切り換える機能を有する画像処理装置に広く適用することができる。

１ 第１アプリケーション
２ 第２アプリケーション
３ 第３アプリケーション
９ ディスプレイ
１０ 画像処理装置
１３ 操作部
１４ 制御部
２６ 描画制御部
２７ 表示制御部
３１ 第１バッファ
３２ 第２バッファ
３３ 第３バッファ
３４ 中間バッファ
３５ ＶＲＡＭ
４１、４２、Ｚ１ａ、Ｚ３ａ 画面
５１ 中間処理部
５２ データ合成部
８１、８２、Ｐ１ａ、Ｑ１、Ｑ１ａ、Ｑ１ｂ、Ｑ２ 画像領域
Ｐ１、Ｐ２、Ｐ３ 透明領域（画像領域）
Ｚ０、Ｚ１、Ｚ２、Ｚ３、Ｚ５、Ｚ６、Ｚ８、Ｚ９、Ｚ１ｂ、Ｚ３ｂ、Ｚ５ｂ 画面データ
Ｚ４、Ｚ７、Ｚ１０、Ｚ４ｂ 合成画面データ
Ｚ４ａ 合成画面

Claims (10)

1. ユーザーからの入力を受け付ける操作部に設けられたディスプレイ上で、第１画像をその一部から全体に亘って徐々に消去しつつ新たな第２画像を徐々に現出するようにして画面を切り換える画像処理装置であって、
   第１記憶部と、第２記憶部と、中間記憶部と、
   前記第１画像を前記徐々に消去するための画面データを前記第１記憶部に書き込む第１アプリケーションと、
   前記第２画像を前記徐々に現出するための画面データを前記第２記憶部に書き込む第２アプリケーションと、
   前記第１と第２のアプリケーションのうち、画面データの書き込みが速い方のアプリケーションによる記憶部への書き込み途中に所定量のデータが書き込まれるごとに、その書き込まれた画面データを前記中間記憶部に記憶させる中間処理部と、
   画面データの書き込みが遅い方のアプリケーションによる記憶部への書き込み途中に、前記中間処理部により前記中間記憶部に記憶された画面データと合成されるべき画面データが書き込まれるごとに、その画面データと、これに対応する、前記中間記憶部に記憶されている画面データとを合成する合成部と、
   前記合成部により画面データが合成されるごとに、その合成画面データを前記ディスプレイに送ってその画像を前記ディスプレイに表示させる表示制御部と、
   を備えることを特徴とする画像処理装置。
2. 前記第１アプリケーションと第２アプリケーションのそれぞれは、予め決められたデータ量の書き込みを行うごとに、その旨を示す書き込み通知を出力し、
   前記中間処理部は、
   前記第１アプリケーションと第２アプリケーションのうち、前記書き込み通知を先に出力したアプリケーションを、前記速い方のアプリケーションとし、
   前記合成部は、
   前記第１アプリケーションと第２アプリケーションのうち、前記速い方のアプリケーションよりも前記書き込み通知を後に出力したアプリケーションを、前記遅い方のアプリケーションとすることを特徴とする請求項１に記載の画像処理装置。
3. 前記予め決められたデータ量は、
   前記第１アプリケーションと第２アプリケーションのそれぞれで、前記所定量以下であり同じ値である、または、前記所定量以下の異なる値であり一方が他方の倍数であることを特徴とする請求項２に記載の画像処理装置。
4. 前記中間処理部は、
   前記速い方のアプリケーションからの書き込み通知とこれよりも前の過去の書き込み通知とに基づき、前記中間記憶部に記憶されている画面データのうち、当該アプリケーションにより前記記憶部に書き込まれた画面データとの差分に相当する部分のデータだけを書き換えることにより、前記記憶部に書き込まれた画面データの前記中間記憶部への記憶を実行させることを特徴とする請求項２または３に記載の画像処理装置。
5. 前記所定量のデータは、予め決められたデータ量を示すバンド単位のデータであることを特徴とする請求項１〜４のいずれか１項に記載の画像処理装置。
6. 前記第１アプリケーションは、
   前記ディスプレイに表示される画面内において所定の一方向に前記第１画像の一方端から他方端に向かって透明領域が徐々に拡大するように、前記画面データを前記第１記憶部に漸次書き込み、
   前記第２アプリケーションは、
   前記ディスプレイに表示される画面内において前記所定の一方向と同方向に前記第２画像が当該画面の枠外から枠内に徐々に入ってくるように、前記画面データを前記第２記憶部に漸次書き込み、
   前記合成部は、
   前記第１アプリケーションによる画面データで表される画像が最上位になり、その下に前記第２アプリケーションによる画面データで表される画像が重なり合って１つの画面が生成されるように、それぞれの画面データを合成することを特徴とする請求項１〜５のいずれか１項に記載の画像処理装置。
7. 前記第１画像とは別の第３画像をその一部から全体に亘って徐々に消去しつつ、前記第２画像とは別の第４画像を徐々に現出するように画面を切り換えることも可能であり、
   前記第１アプリケーションは、
   前記第３画像を徐々に消去するための画面データを前記第１記憶部に書き込むことが可能であり、
   前記第２アプリケーションは、
   前記第４画像を徐々に現出するための画面データを前記第２記憶部に書き込むことが可能であり、
   前記第１画像と前記第２画像に対する各画面データに適用される前記所定量Ｈと、前記第３画像と前記第４画像に対する各画面データに適用される前記所定量Ｈ１とが異なることを特徴とする請求項１〜６のいずれか１項に記載の画像処理装置。
8. 前記第３画像と第４画像は、前記第１画像と第２画像よりも前記ディスプレイ上における表示領域が小さく、前記所定量Ｈよりも前記所定量Ｈ１の方が大きいことを特徴とする請求項７に記載の画像処理装置。
9. 前記第１アプリケーションと第２アプリケーションは、それぞれが画面データの書き込み開始に際し、その書き込み範囲を含む書き込み開始通知を出力し、
   前記合成部は、
   前記出力された書き込み開始通知に含まれる書き込み範囲に基づき、前記第１画像と第２画像の大きさが異なり、小さい方の画像が大きい方の画像内に収まることを判断すると、各画像がその書き込み範囲に基づく位置で上下に重なるように、前記それぞれの画面データの合成を行うことを特徴とする請求項１〜８のいずれか１項に記載の画像処理装置。
10. 前記第１アプリケーションと第２アプリケーションは、それぞれが画面データの書き込み開始に際し、その書き込み範囲を含む書き込み開始通知を出力し、
    前記中間処理部は、
    前記出力された書き込み開始通知に含まれる書き込み範囲に基づき、前記第１画像と第２画像が重なっているか否かを判定し、重なっていないことが判定されると、前記画面データの前記中間記憶部への記憶を禁止し、
    前記合成部は、
    前記画面データの前記中間記憶部への記憶が禁止されると、前記合成を禁止して、これに代えて、前記第１アプリケーションにより前記第１記憶部に書き込まれた画面データと、前記第２アプリケーションにより前記第２記憶部に書き込まれた画面データとを一定周期ごとに合成することを特徴とする請求項１〜９のいずれか１項に記載の画像処理装置。

Images