(57)【要約】【課題】コマ落ちの発生頻度に応じて制御装置のパフォーマンスレベルを調整する。【解決手段】描画更新要求に対する画像データの転送が終了したか否かを判定する転送終了判定部（３２）と、転送が終了したと判定されなかった回数を計数する発生回数計数部（３３）と、計数された所定期間内の回数に基づいて、ＣＰＵのパフォーマンスレベルの上限値を制御するレベル制御部（３５）と、を備える。【選択図】図１
2017069713.tif 000002
【特許請求の範囲】
【請求項１】
表示パネルに表示される画像の表示制御を行う表示制御装置であって、
上記表示パネルに表示される１フレーム分の画像の更新要求である描画更新要求に対する、当該表示パネルへの当該画像を示す画像データの転送が終了したか否かを判定する転送終了判定部と、
上記転送終了判定部によって上記転送が終了したと判定されなかった回数を計数する計数部と、
上記計数部によって計数された所定期間内の上記回数に基づいて、上記表示制御装置を含む装置の各種処理を制御する制御装置のパフォーマンスレベルの上限値を制御するレベル制御部と、を備えることを特徴とする表示制御装置。
【請求項２】
上記レベル制御部は、上記計数部によって計数された上記回数が、上記所定期間としての第１所定期間において第１所定回数以上となった場合で、かつ上記パフォーマンスレベルの上限値が最大でない場合には、現在設定されている上記パフォーマンスレベルの上限値を上げることを特徴とする請求項１に記載の表示制御装置。
【請求項３】
上記レベル制御部は、上記計数部によって計数された上記回数が、上記第１所定期間よりも長い第２所定期間において、上記第１所定回数よりも多い第２所定回数以上となった場合には、現在設定されている上記パフォーマンスレベルの上限値を下げることを特徴とする請求項２に記載の表示制御装置。
【請求項４】
上記転送終了判定部は、上記描画更新要求を取得した回数である描画要求受付数が、上記描画更新要求に対する上記表示パネルへの画像データの転送が終了したことを示す転送終了割り込みを取得した回数である画像転送完了数よりも２以上多くなった場合に、上記画像データの転送が終了していないと判定することを特徴とする請求項１から３のいずれか１項に記載の表示制御装置。
【請求項５】
表示パネルに表示される画像の表示制御を行う表示制御装置の制御方法であって、
上記表示パネルに表示される１フレーム分の画像の更新要求である描画更新要求に対する、当該表示パネルへの当該画像を示す画像データの転送が終了したか否かを判定する転送終了判定ステップと、
上記転送終了判定ステップにおいて上記転送が終了したと判定されなかった回数を計数する計数ステップと、
上記計数ステップにおいて計数された所定期間内の上記回数に基づいて、上記表示制御装置を含む装置の各種処理を制御する制御装置のパフォーマンスレベルの上限値を制御するレベル制御ステップと、を含むことを特徴とする表示制御装置の制御方法。
【請求項６】
請求項１に記載の表示制御装置としてコンピュータを機能させるための表示制御プログラムであって、上記転送終了判定部、上記計数部および上記レベル制御部としてコンピュータを機能させるための表示制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、表示制御装置等に関する。
【背景技術】
【０００２】
動画の表示において、動画を構成する複数の画像のうち、少なくとも１フレーム分の画像が表示されない（描画更新要求に対する描画がなされない）所謂コマ落ちという現象が発生することがある。コマ落ちしたフレーム（画像データ）が多くなると、当該画像データが表示されないので、表示が固まった状態になってしまう。そのため、従来から、コマ落ちの発生を抑制する技術が開発されている。当該技術の一例としては、特許文献１に記載の発明が挙げられる。
【０００３】
特許文献１の再生装置では、取得したメインプロセッサの能力に応じて設定された条件を満たしている場合には６０ＦＰＳ（frame per second）の動画データがＧＰＵ（Graphics Processor Unit）に出力される。一方、当該条件を満たしていない場合には３０ＦＰＳの動画データがＧＰＵに出力される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−１７１８５７号公報（２０１１年９月１日公開）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１の再生装置は、コマ落ちの発生を監視することによって、メインプロセッサの能力を調整するものではない。
【０００６】
本発明は、前記の問題点に鑑みてなされたものであり、その目的は、コマ落ちの発生頻度に応じて制御装置のパフォーマンスレベルの調整することが可能な表示制御装置を実現することにある。
【課題を解決するための手段】
【０００７】
上記の課題を解決するために、本発明の一態様に係る表示制御装置は、表示パネルに表示される画像の表示制御を行う表示制御装置であって、上記表示パネルに表示される１フレーム分の画像の更新要求である描画更新要求に対する、当該表示パネルへの当該画像を示す画像データの転送が終了したか否かを判定する転送終了判定部と、上記転送終了判定部によって上記転送が終了したと判定されなかった回数を計数する計数部と、上記計数部によって計数された所定期間内の上記回数に基づいて、上記表示制御装置を含む装置の各種処理を制御する制御装置のパフォーマンスレベルの上限値を制御するレベル制御部と、を備える。
【発明の効果】
【０００８】
本発明の一態様によれば、コマ落ちの発生頻度に応じて制御装置のパフォーマンスレベルを調整することができるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態に係る表示ドライバの構成を示すブロック図である。
【図２】本発明の実施形態に係る表示装置の構成を示すブロック図である。
【図３】上記表示ドライバにおけるコマ落ち検出方法を説明するための図である。
【図４】上記表示ドライバにおける処理の流れを示すフローチャートである。
【図５】パフォーマンスレベルの上限値の制御方法を示すタイミングチャートである。
【発明を実施するための形態】
【００１０】
〔実施形態１〕
以下、本発明の実施の形態において、図１〜図５に基づいて説明すれば、以下のとおりである。
【００１１】
＜表示装置１の概略構成＞
図２を用いて、表示装置１の概略構成について説明する。図２は、本実施形態の表示装置１の構成を示すブロック図である。図２に示すように、表示装置１は、ホスト１０（表示制御装置）、液晶モジュール２０及び通信接続部３０を備えている。ここでは、表示装置１が携帯端末である場合を例に挙げて説明するが、これに限らず、表示装置１は、設置型の表示装置であってもよい。
【００１２】
ホスト１０は、液晶パネル２１（表示パネル）の表示動作を制御するものであり、アプリケーション実行部１１、表示ドライバ１２、画像処理・出力ＨＷ（hardware）１３、パフォーマンス制御部１４及びクロック・電圧制御部１５を備えている。
【００１３】
アプリケーション実行部１１は、携帯端末で動作する各種のアプリケーションを実行することで、画像データを生成する。また、アプリケーション実行部１１は、生成した画像データが示す画像の更新要求である描画更新要求を発行し、表示ドライバ１２に送信する。ここで、特に言及のない限り、画像データとは、液晶パネル２１に表示する１フレーム分の画像のデータを意味する。
【００１４】
表示ドライバ１２は、液晶パネル２１に表示される画像の表示制御を行う。具体的には、表示ドライバ１２は、アプリケーション実行部１１から描画更新要求を受信すると、液晶ドライバ２２への画像データの転送開始の指示である画像転送開始指示を画像処理・出力ＨＷ１３に送信する。また、表示ドライバ１２は、描画更新要求に対する液晶パネル２１への画像データの転送が終了したことを示す転送終了割り込みを画像処理・出力ＨＷ１３から受信する。表示ドライバ１２は、この転送終了割り込みの受信を確認することにより、上記画像転送開始指示を画像処理・出力ＨＷ１３に送信する。
【００１５】
また、表示ドライバ１２は、Vsync（垂直同期信号）割り込み（ＴＥ信号；転送タイミング信号）を液晶ドライバ２２から受信する。Vsync割り込みとは、液晶ドライバ２２がホスト１０に次のフレームの画像データの転送開始を指示する信号である。表示ドライバ１２は、Vsync割り込みを受信するたびにコマ落ちが発生しているか否かを判定し、その判定結果に応じて、ＣＰＵ（Central Processing Unit）のパフォーマンスレベルの変更を指示するためのパフォーマンス変更指示（Ｑｏｓ（Quality of service）信号）をパフォーマンス制御部１４に送信する。ＣＰＵのパフォーマンスとは、ＣＰＵに設定されるクロック周波数および電圧値等の、ＣＰＵの処理能力（処理速度）に関連したパラメータである。
【００１６】
パフォーマンス制御部１４は、表示ドライバ１２から受信したパフォーマンス変更指示に従って、ＣＰＵのパフォーマンスレベルの上限値を制御する。この制御には、パフォーマンスレベルの上限値を上げる処理、または下げる処理が含まれる。パフォーマンス制御部１４は、パフォーマンス変更指示に従って決定したパフォーマンスレベルの上限値を示すパフォーマンス制御指示をクロック・電圧制御部１５に送信する。
【００１７】
また、ホスト１０の画像処理・出力ＨＷ１３及びクロック・電圧制御部１５は、集積回路（ＩＣチップ）等に形成された電子回路（ハードウェア）によって実現される。画像処理・出力ＨＷ１３及びクロック・電圧制御部１５は、ＣＰＵの制御を受けて動作する。
【００１８】
画像処理・出力ＨＷ１３は、画像データを通信接続部３０を介して液晶ドライバ２２に転送（送信）する。具体的には、画像処理・出力ＨＷ１３は、表示ドライバ１２から画像転送開始指示を受信している場合には、液晶ドライバ２２からVsync割り込みを受信したタイミングで、画像データを液晶ドライバ２２に送信する。このタイミングで画像データを送信することにより、液晶パネル２１におけるティアリングの発生を抑制できる。また、画像処理・出力ＨＷ１３は、液晶ドライバ２２への画像データの転送が終了したタイミングで、転送終了割り込みを表示ドライバ１２に送信する。
【００１９】
クロック・電圧制御部１５は、ＣＰＵのパフォーマンスレベルを制御する。具体的には、クロック・電圧制御部１５は、ＣＰＵに現在設定されているパフォーマンスレベルの上限値を、パフォーマンス制御部１４から受信したパフォーマンス制御指示が示すパフォーマンスレベルの上限値に変更する。また、クロック・電圧制御部１５は、表示装置１が備える他のハードウェアのパフォーマンスレベル（当該ハードウェアに設定されているクロック周波数、電圧値等の大きさ）を制御する。
【００２０】
液晶モジュール２０は、ホスト１０から転送された画像データが示す画像を表示する。液晶モジュール２０は、液晶パネル２１及び液晶ドライバ２２を備えている。液晶パネル２１及び液晶ドライバ２２は、互いに物理的に接続されている。
【００２１】
液晶パネル２１は、複数の画素を備え、画像データ及び駆動信号に基づき、画像データが示す画像を表示する。液晶パネル２１の代わりに、有機ＥＬ（electroluminescence）ディスプレイ、プラズマディスプレイ等が用いられてもよい。
【００２２】
液晶ドライバ２２は、液晶パネル２１の表示動作を制御するものであり、ホスト１０から受信した画像データと共に、液晶パネル２１を駆動するための駆動信号（例えば、ソース信号、ゲート信号等）を液晶パネル２１に供給するチップである。具体的には、液晶ドライバ２２は、不図示のフレームメモリ及びＴＧ（タイミングジェネレータ）等を備える。フレームメモリは、例えば、１フレームの画像データを格納することができるＶＲＡＭ（video random access memory）である。受け取った画像はフレームメモリに書き込まれる。そして、ＴＧが指示するタイミングに従って、フレームメモリから画像データが読み出され、液晶パネル２１に出力される。ＴＧは、上記駆動信号を生成し、液晶パネル２１に供給すると共に、液晶パネル２１の駆動タイミングに合わせて、フレームメモリから画像データを読み出すタイミングを決定する。また、ＴＧは、Vsync割り込みを生成し、ホスト１０に送信する。
【００２３】
通信接続部３０は、ホスト１０と液晶モジュール２０とを接続するための、伝送線路（transmission lines）を備える。伝送線路は、信号を転送するためのライン（配線または光ファイバ等）である。通信接続部３０は、例えば、ＭＩＰＩ（登録商標、Mobile Industry Processor Interface）規格に適合した通信インターフェースである。ただし、通信インターフェースの仕様はこれに限らず、通信接続部３０が伝送線路を備えていればよい。すなわち、通信接続部３０は、少なくとも、画像処理・出力ＨＷ１３から画像データを液晶ドライバ２２に送信できると共に、液晶ドライバ２２からVsync割り込みを画像処理・出力ＨＷ１３及び表示ドライバ１２に送信できればよい。
【００２４】
＜表示ドライバ１２の詳細構成＞
図１は、本実施形態の表示ドライバを示すブロック図である。表示ドライバ１２は、画像転送指示部３１、転送終了判定部３２、発生回数計数部３３、発生回数比較部３４及びレベル制御部３５を備えている。
【００２５】
画像転送指示部３１は、アプリケーション実行部１１が生成した画像データの、画像処理・出力ＨＷ１３への転送を制御する。具体的には、画像転送指示部３１は、アプリケーション実行部１１から描画更新要求を受信すると、画像転送開始指示を画像処理・出力ＨＷ１３に送信する。但し、画像転送指示部３１は、割り込み計数部４２が転送終了割り込みを受信したことを示す割り込み完了通知を受信することで、前回の描画更新要求に対する液晶ドライバ２２への転送処理が完了していると判定できた場合のみ、画像転送開始指示を送信する。また、画像転送指示部３１は、描画更新要求を受信するたびに、描画更新要求を取得したことを示す要求取得通知を転送終了判定部３２（具体的には、要求計数部４１）に送信する。
【００２６】
転送終了判定部３２は、描画更新要求に対する、液晶パネル２１への画像データの転送が終了したか否かを判定するものであり、要求計数部４１、割り込み計数部４２及びコマ落ち判定部４３を備えている。
【００２７】
要求計数部４１は、画像転送指示部３１がアプリケーション実行部１１から取得する描画更新要求の回数である描画要求受付数を計数する。本実施形態では、要求計数部４１は、画像転送指示部３１から要求取得通知を受信するたびにその回数を計数することで、描画要求受付数を計数する。要求計数部４１は、当該回数を要求計数データとしてコマ落ち判定部４３に送信する。
【００２８】
割り込み計数部４２は、画像処理・出力ＨＷ１３から取得した転送終了割り込みの回数を、画像処理・出力ＨＷ１３から液晶ドライバ２２への画像データの転送が完了した回数である画像転送完了数として計数する。割り込み計数部４２は、当該回数を割り込み計数データとしてコマ落ち判定部４３に送信する。
【００２９】
コマ落ち判定部４３は、Vsync割り込みのタイミングで、描画要求受付数と画像転送完了数との比較結果に基づいて、液晶パネル２１への画像データの転送が終了したか否かを判定することにより、所謂コマ落ちが発生したか否かを判定する。具体的には、コマ落ち判定部４３は、Vsync割り込みのタイミングで、描画要求受付数が画像転送完了数よりも２以上多くなった場合（すなわち、描画要求受付数−画像転送完了数≧２の場合）に、コマ落ちが発生したと判定する。コマ落ち判定部４３は、コマ落ちが発生したと判定した場合には、コマ落ちが発生したことを示すコマ落ち発生通知を発生回数計数部３３に送信する。コマ落ち判定部４３は、コマ落ちが発生するたびに、コマ落ち発生通知を発生回数計数部３３に送信する。
【００３０】
なお、本実施形態では、描画要求受付数−画像転送完了数≧２の場合にコマ落ちが発生したと判定するが、これに限らず、描画要求受付数−画像転送完了数≧所定数（所定数は３以上）となった場合にコマ落ちが発生したと判定してもよい。但し、コマ落ちの発生を精度良く検出することを考慮すれば、描画要求受付数−画像転送完了数≧２の場合にコマ落ちが発生したと判定することが好ましい。
【００３１】
発生回数計数部３３は、転送終了判定部３２によって液晶ドライバ２２への画像データの転送が終了したと判定されなかった回数（すなわち、コマ落ちの発生回数）を計数する。本実施形態では、発生回数計数部３３は、所定期間内に、コマ落ち判定部４３からコマ落ち発生通知を受信した回数を上記発生回数として計数する。発生回数計数部３３は、所定期間内に計数された上記発生回数を示す回数データを発生回数比較部３４に送信する。
【００３２】
発生回数計数部３３は、コマ落ち判定部４３の検出結果を受けて、コマ落ちが発生した時刻を示す時刻情報を時系列に記録していく。発生回数比較部３４は、Vsync割り込みが入力されたタイミングで、毎回図４に示すフロー（Ｓ２、Ｓ６、Ｓ１０の処理）を実行する。第１所定期間、第２所定期間および第３所定期間の３つの所定期間が予め設定されており、発生回数比較部３４は、現在（例えば、Vsync割り込みが入力されたタイミング）から第１所定期間前までのコマ落ち回数、現在から第２所定期間前までのコマ落ち回数、および現在から第３所定期間前までのコマ落ち回数を、発生回数計数部３３による時刻情報の記録から算出する。本実施形態では、第１所定期間は３０ｍｓ、第２所定期間は５００ｍｓ、第３所定期間は３０００ｍｓに設定されているが、これに限らず、任意の期間を設定できる。
【００３３】
第１所定期間は、ある程度（一般に表示品位が低下すると推定される程度）の発生頻度でコマ落ちが発生しているときのコマ落ちの発生回数を計数する期間である。第１所定期間は、コマ落ちの発生頻度を抑制するための処理を随時行うことができるよう、第２所定期間及び第３所定期間より短期間であることが好ましい。
【００３４】
第２所定期間は、第１所定期間で所定回数のコマ落ちが発生している場合に、そのコマ落ちの発生頻度が継続した状態で（または大きくなった状態で）、第１所定期間よりも長期間に亘ってコマ落ちが発生しているかどうかを確認する期間である。そのため、第２所定期間は、第１所定期間よりも長く設定されていることが好ましい。
【００３５】
すなわち、第１所定期間は、短期間に小さいレベルのコマ落ち（表示品位の低下の度合いが小さいコマ落ち）が発生しているかどうかを確認するための期間であり、第２所定期間は、長期間に重大なレベルの激しいコマ落ち（表示品位の低下の度合いが長期間に亘り大きいコマ落ち）が発生しているかどうかを確認するための期間である。
【００３６】
第３所定期間は、第２所定期間後のパフォーマンスレベルの上限値の制御により、コマ落ちの発生頻度が低下したかどうかを確認するための期間である。そのため、少なくとも第１所定期間よりも長い期間が設定されていることが好ましく、第２所定期間と同等の長さに設定されていればよい。
【００３７】
発生回数比較部３４は、発生回数計数部３３から受信した回数データが示す、所定期間内のコマ落ちの発生回数を、所定回数と比較する。発生回数比較部３４は、当該発生回数が所定回数以上であると判定した場合に、その判定結果を、レベル制御部３５に送信する。
【００３８】
第１所定期間におけるコマ落ちの発生回数は所定回数としての第１所定回数と比較され、第２所定期間におけるコマ落ちの発生回数は所定回数としての第２所定回数と比較され、第３所定期間におけるコマ落ちの発生回数は所定回数としての第３所定回数と比較される。本実施形態では、第１所定回数は２回、第２所定回数は５０回、第３所定期間は３００回に設定されているが、これに限らず、任意の期間を設定できる。上述した第１、第２及び第３所定期間の長さにあわせて、各所定期間におけるコマ落ちの発生頻度が確認できる程度の回数に設定されていればよい。例えば、第２所定回数は第１所定回数より多い回数が設定される。
【００３９】
レベル制御部３５は、発生回数計数部３３によって計数された所定期間内のコマ落ちの発生回数に基づいて、パフォーマンス変更指示をパフォーマンス制御部１４に送信することで、パフォーマンスレベルの上限値を制御する。レベル制御部３５におけるパフォーマンスレベルの上限値の変更制御については、図４および図５を用いて後述する。
【００４０】
＜コマ落ち検出方法＞
次に、図３に基づいて、コマ落ち検出方法の一例について説明する。図３は、表示ドライバ１２におけるコマ落ち検出方法を説明するための図である。なお、Vsync割り込みの発行間隔（受信間隔）は、画像のフレームレートが１２０ＦＰＳの場合には約８ｍ秒であり、６０ＦＰＳの場合には約１６．７ｍ秒である。また、図３に示すように、描画要求受付数は、表示ドライバ１２による描画更新要求の受信タイミング（具体的には、要求計数部４１による要求取得通知の受信タイミング）でカウントアップされる。一方、画像転送完了数は、表示ドライバ１２（具体的には、割り込み計数部４２）による転送終了割り込みの受信タイミングでカウントアップされる。また、コマ落ち判定部４３によるコマ落ち判定（コマ落ち検出）は、Vsync割り込みの受信タイミングで行われる。
【００４１】
図３に示すように、表示ドライバ１２のコマ落ち判定部４３は、時刻Ｔ１でVsync割り込みを受信する。表示ドライバ１２は、時刻Ｔ１よりも前に描画更新要求及び転送終了割り込みを受信していないため、時刻Ｔ１での描画要求受付数及び画像転送完了数は共に「０」である。そのため、コマ落ち判定部４３は、コマ落ちが発生していないと判定する。
【００４２】
その後、表示ドライバ１２は、アプリケーション実行部１１から１つ目の描画更新要求を受信すると、要求計数部４１は描画要求受付数を「１」とし、画像転送指示部３１は画像転送開始指示を画像処理・出力ＨＷ１３に送信する。画像処理・出力ＨＷ１３は、時刻Ｔ２においてVsync割り込みを受信したタイミングで（すなわち、Vsync割り込みに同期させて）、１つ目の描画更新要求に対する画像データの転送処理を行う。また、コマ落ち判定部４３は、時刻Ｔ２における「描画要求受付数（１）−画像転送完了数（０）」を算出し、その差が２より小さいためコマ落ちが発生していないと判定する。なお、描画要求受付数と画像転送完了数とは、更新タイミングが異なるため、描画要求受付数−画像転送完了数＝１の場合、１つの画像データが次のVsync割り込み受信時に転送されるのを待機している状態である。描画要求受付数−画像転送完了数≧２の場合は、画像データの転送が次の描画更新要求までに完了しておらず、コマ落ちが発生したことを示す。
【００４３】
次に、図３の例では、表示ドライバ１２は、上記転送中に（当該転送に係る転送終了割り込みを受信する前に）２つ目の描画更新要求を受信している。表示ドライバ１２は、１つ目の描画更新要求に対する転送終了割り込みを画像処理・出力ＨＷ１３から受信した後、２つ目の描画更新要求に対する画像転送開始指示を画像処理・出力ＨＷ１３に送信する。画像処理・出力ＨＷ１３は、時刻Ｔ３においてVsync割り込みを受信したタイミングで、２つ目の描画更新要求に対する転送処理を行う。
【００４４】
ここで、アプリケーション実行部１１は、図２に示すようにVsync割り込み及び転送終了割り込みを受信しないため、液晶ドライバ２２への画像データの送信タイミング（液晶パネル２１の描画更新タイミング）を特定できない。そのため、アプリケーション実行部１１は、アプリケーションの実行結果に従って画像データを随時生成し、生成するたびに（すなわち、画像データの転送が終了したか否かにかかわらず）表示ドライバ１２に描画更新要求を送信している。一方、表示ドライバ１２は、描画更新要求の受信と、当該描画更新要求に対する転送終了割り込みの受信とを管理している。具体的には、画像転送指示部３１は、描画更新要求に対する転送終了割り込み（すなわち、割り込み完了通知）を受信しないと、次の描画更新要求を受信していたとしても、当該次の描画更新要求に対する画像転送開始指示を画像処理・出力ＨＷ１３を送信しない。
【００４５】
なお、要求計数部４１は、上記２つ目の描画更新要求を受信したタイミングで描画要求受付数を「２」とする。また、割り込み計数部４２は、１つ目の描画更新要求に対する転送終了割り込みを受信したタイミングで画像転送完了数を「１」とする。また、コマ落ち判定部４３は、時刻Ｔ３において、「描画要求受付数（２）−画像転送完了数（１）」を算出し、差が２より小さいためにコマ落ちは発生していないと判定する。
【００４６】
その後、表示ドライバ１２は、３つ目の描画更新要求を、２つ目の描画更新要求に対する転送終了割り込み受信後であるが、時刻Ｔ４の直前で受信する。そして、この例においては、画像転送開始指示は時刻Ｔ４より後に、画像処理・出力ＨＷ１３に送信される。そのため、３つ目の描画更新要求に対する転送処理は、次のVsync割り込みの受信タイミングである時刻Ｔ５で行われる。
【００４７】
なお、割り込み計数部４２は、２つ目の描画更新要求に対する転送終了割り込みを受信したタイミングで画像転送完了数を「２」とする。要求計数部４１は、３つ目の描画更新要求を受信したタイミングで描画要求受付数を「３」とする。また、コマ落ち判定部４３は、時刻Ｔ４において、「描画要求受付数（３）−画像転送完了数（２）」を算出し、差が２より小さいためにコマ落ちは発生していないと判定する。
【００４８】
その後、表示ドライバ１２は、３つ目の描画更新要求に対する画像転送開始指示を送信後、時刻Ｔ５において当該描画更新要求に対する転送処理が行われる前に、４つ目の描画更新要求を受信する。しかし、上述のように、画像処理・出力ＨＷ１３は、次のVsync割り込み受信時（時刻Ｔ５）に、３つ目の描画更新要求に対する転送処理を行うため、４つ目の描画更新要求の受信から次のVsync割り込みの受信までの間において、３つ目の描画更新要求に対する転送終了割り込みを受信しない。そのため、表示ドライバ１２が、４つ目の描画更新要求に対する画像転送開始指示を送信することができない。つまり、画像処理・出力ＨＷ１３は、時刻Ｔ５におけるVsync割り込み受信時に４つ目の描画更新要求に対する転送処理を行うことができない。そのため、４つ目の描画更新要求に対応する画像データが液晶ドライバ２２に送信されないため、当該画像データが示す画像が液晶パネル２１に表示されないといったコマ落ちが発生する。
【００４９】
このコマ落ちの発生は、コマ落ち判定部４３によって検出される。すなわち、要求計数部４１は、４つ目の描画更新要求の受信タイミングで描画要求受付数を「４」とする。一方、３つ目の描画更新要求に対する転送処理は時刻Ｔ５において行われるため、３つ目の描画更新要求に対する転送終了割り込みは、時刻Ｔ５より後に画像処理・出力ＨＷ１３から送信される。そのため、時刻Ｔ５においては、画像転送完了数は「２」のままである。従って、コマ落ち判定部４３は、時刻Ｔ５において「描画要求受付数（４）−画像転送完了数（２）＝２」と算出し、差が２以上となるためコマ落ちが発生したと判定する。
【００５０】
このように、コマ落ち判定部４３は、画像データの転送タイミングであるVsync割り込みを受信するたびに、描画要求受付数と画像転送完了数とを比較するので、コマ落ちする画像データ数を正確に計数できる。
【００５１】
＜表示ドライバ１２における処理（パフォーマンスレベルの上限値の制御方法）＞
次に、図４および図５に基づいて、表示ドライバ１２における処理の一例について説明する。図４は、表示ドライバ１２における処理の流れを示すフローチャートである。図５は、ＣＰＵのパフォーマンスレベルの上限値の制御方法を示すタイミングチャートである。なお、図５に記載の描画更新レートとは、アプリケーション実行部１１が画像データを生成し、描画更新要求を発行する処理速度である。
【００５２】
ここで、本実施形態では、パフォーマンスレベルの上限値Ｌは、予め決められた０≦Ｌ≦６３の６４個のいずれかに設定される。この６４個の上限値Ｌは、クロック周波数および電圧値等のＣＰＵの処理能力に関連した各種パラメータの値にそれぞれ対応付けられている。上限値Ｌ＝６３は最大値であり、このとき上記各種パラメータの値もそれぞれ最大値をとる。上限値Ｌ＝０は最小値であり、このとき上記各種パラメータの値もそれぞれ最小値をとる。なお、上限値Ｌ＝０のときの各種パラメータの値は０ではなく、ＣＰＵが最小限の動作（例えば、コマ落ち判定処理等）を行うことが可能な程度の値に設定されている。すなわち、上限値Ｌ＝０の場合であっても、ＣＰＵは休止しておらず動作可能である。また、上限値Ｌの最大値は６３に限らず、任意に設定可能である。
【００５３】
まず、図４に示すように、パフォーマンス制御部１４は、ＣＰＵにかかる負荷（処理負荷）に伴って、パフォーマンスレベルの上限値Ｌを決定する（Ｓ１）。クロック・電圧制御部１５は、現在設定されている上限値Ｌを、パフォーマンス制御部１４が決定した上限値Ｌに変更する。
【００５４】
コマ落ちが発生すると、コマ落ち判定部４３はコマ落ちが発生したと判定する（転送終了判定ステップ）。そして、発生回数計数部３３は、コマ落ちの発生回数の計数を開始する（計数ステップ）。発生回数比較部３４は、発生回数計数部３３によって計数された上記発生回数が、第１所定期間（Ｔｄｒｏｐ１）において第１所定回数（Ｎｄｒｏｐ１）以上のコマ落ちが発生しているか否かを判定する（Ｓ２）。本実施形態では、発生回数比較部３４は、Ｔｄｒｏｐ１＝３０ｍｓ内にＮｄｒｏｐ１＝２回以上、コマ落ちが発生したかを判定する。第１所定回数以上であると判定された場合（Ｓ２でＹＥＳ）、レベル制御部３５は、現在設定されている上限値Ｌに所定値Ｌｄｒｏｐ１（本実施形態では、Ｌｄｒｏｐ１＝１）を加えた値を、新たな上限値Ｌとして算出する（Ｓ３；レベル制御ステップ）。そして、レベル制御部３５は、算出した上限値Ｌが、上限値Ｌの最大値（本実施形態では「６３」）を超えていないか否かを判定する（Ｓ４；レベル制御ステップ）。レベル制御部３５は、超えていない場合には（Ｓ４でＮＯ）、算出した上限値Ｌを新たな上限値Ｌに設定し、超えている場合には（Ｓ４でＹＥＳ）、新たな上限値Ｌとして最大値６３に設定する（Ｓ５；レベル制御ステップ）。
【００５５】
すなわち、レベル制御部３５は、コマ落ちの発生回数が第１所定期間において第１所定回数以上となった場合で、かつ現在設定されている上限値Ｌが最大でない場合には、当該現在設定されている上限値Ｌを上げる。なお、Ｓ２でＮＯの場合には、Ｓ６の処理へ移行する。
【００５６】
また、発生回数比較部３４は、第２所定期間（Ｔｄｒｏｐ２）内に第２所定回数（Ｎｄｒｏｐ２）以上のコマ落ちが発生しているか否かを判定する（Ｓ６）。本実施形態では、発生回数比較部３４は、Ｔｄｒｏｐ２＝５００ｍｓ内にＮｄｒｏｐ２＝５０回以上、コマ落ちが発生したかを判定する。第２所定回数以上であると判定された場合（Ｓ６でＹＥＳ）、レベル制御部３５は、現在設定されている上限値Ｌを下げる。具体的には、レベル制御部３５は、現在設定されている上限値Ｌから所定値Ｌｄｒｏｐ２（本実施形態では、Ｌｄｒｏｐ２＝８）を引いた値を、新たな上限値Ｌとして算出する（Ｓ７；レベル制御ステップ）。そして、レベル制御部３５は、算出した上限値Ｌが、上限値Ｌの最小値（本実施形態では「０」）を下回っていないか否かを判定する（Ｓ８；レベル制御ステップ）。レベル制御部３５は、下回っていない場合には（Ｓ８でＮＯ）、算出した上限値Ｌを新たな上限値Ｌに設定し、下回っている場合には（Ｓ８でＹＥＳ）、新たな上限値Ｌとして最小値０に設定する（Ｓ９；レベル制御ステップ）。なお、Ｓ６でＮＯの場合には、Ｓ１０の処理へ移行する。
【００５７】
また、発生回数比較部３４は、第３所定期間（Ｔｄｒｏｐ３）内に第３所定回数（Ｎｄｒｏｐ３）以上のコマ落ちが発生しているか否かを判定する（Ｓ１０）。本実施形態では、発生回数比較部３４は、Ｔｄｒｏｐ３＝３０００ｍｓ内にＮｄｒｏｐ３＝３００回以上、コマ落ちが発生したかを判定する。第３所定回数以上であると判定された場合（Ｓ１０でＹＥＳ）、レベル制御部３５は、現在設定されている上限値Ｌを上げる。具体的には、レベル制御部３５は、現在設定されている上限値Ｌに所定値Ｌｄｒｏｐ３（本実施形態では、Ｌｄｒｏｐ３＝８）を加えた値を、新たな上限値Ｌとして算出する（Ｓ１１）。そして、レベル制御部３５は、算出した上限値Ｌが、上限値Ｌの最大値（本実施形態では「６３」）を超えていないか否かを判定する（Ｓ１２）。レベル制御部３５は、超えていない場合には（Ｓ１２でＮＯ）、算出した上限値Ｌを新たな上限値Ｌに設定し、超えている場合には（Ｓ１２でＹＥＳ）、新たな上限値Ｌとして最大値６３に設定する（Ｓ１３）。
【００５８】
なお、（１）Ｓ２〜Ｓ５の処理、（２）Ｓ６〜Ｓ９の処理、および（３）Ｓ１０〜Ｓ１３の処理はそれぞれ独立して行われればよく、（１）〜（３）の処理順は図４に示すフローに限定されない。例えば、（１）〜（３）の処理が並行して行われてもよい。
【００５９】
次に、図５に示すタイミングチャートを参照して、上記処理の流れについて説明する。図５の例では、時刻Ｔ１１において、アプリケーション実行部１１によって画像データの生成処理が開始される。そのため、パフォーマンス制御部１４は、当該生成処理が重くなった（当該生成処理に負荷がかかる）と判断し、１つ目の描画更新要求を取得した時点で、パフォーマンスレベルの上限値Ｌを所定値だけ上げる（図４のＳ１）。その後、描画更新レートが徐々に増加していくと、その分表示ドライバ１２に要求されるＣＰＵの負荷も増加する。そして、当該負荷（現在設定されている上限値Ｌ）を超えた処理速度で画像データが生成されると、液晶ドライバ２２に転送できない画像データが発生してしまう。すなわち、コマ落ちが発生してしまう。
【００６０】
図５では、時刻Ｔ１２の前でコマ落ちが発生している。コマ落ち判定部４３が１つ目のコマ落ちの発生を検出した時点で、発生回数計数部３３は、コマ落ちの回数を計数する。第１所定期間である期間「Ａ」において２回のコマ落ちが発生しているため、レベル制御部３５は、Ｓ３及びＳ４の処理を行い、時刻Ｔ１２において、現在設定されている上限値Ｌを所定値Ｌｄｒｏｐ１だけ上げる。その後の期間（期間「Ａ」及び「Ｂ」の間）においてコマ落ちは発生していない。そのため、発生回数比較部３４は所定回数のコマ落ちが発生していないと判定する。
【００６１】
その後、時刻Ｔ１２後に、再びコマ落ちが発生している。コマ落ち判定部４３が当該コマ落ちの発生を検出した時点で、発生回数計数部３３は、コマ落ちの発生回数を計数する。第１所定期間である期間「Ｂ」においては１回のコマ落ちしか発生していないため、発生回数比較部３４は所定回数のコマ落ちが発生していないと判定する。
【００６２】
その後の時刻Ｔ１３までの期間では描画更新レートが変化しているが、当該描画更新レートに対応し得る上限値Ｌに設定されているため、コマ落ちが発生していない。その後、時刻Ｔ１３の前で描画更新レートが急激に低下している。パフォーマンス制御部１４は、画像データの生成処理が軽くなった（当該生成処理に負荷がかからなくなった）と判断し、その低下にあわせて、時刻Ｔ１３において上限値Ｌを所定値だけ下げる（Ｓ１）。その後、描画更新レートは、最大値１２０ＦＰＳまで急激に上昇している。そのため、パフォーマンス制御部１４は、画像データの生成処理が重くなったと判断し、時刻Ｔ１４において、上限値Ｌを所定値だけ上げる（Ｓ１）。図５に示すように、ここでは、パフォーマンス制御部１４は、段階的に上限値Ｌを上げて、上限値Ｌを最大値まで上げている。これは、例えば、表示ドライバ１２以外の他のドライバ（例えば、表示ドライバ１２の処理とは関連しない通信処理に係るドライバ）からの処理の要求がＣＰＵに入り、当該他のドライバから上限値Ｌを上げる旨の指示がパフォーマンス制御部１４に入ったことに起因する。
【００６３】
その後、コマ落ちが発生すると、コマ落ち判定部４３が当該コマ落ちの発生を検出した時点で、発生回数計数部３３は、コマ落ちの発生回数を計数する。第１所定期間である期間「Ｃ」において２回のコマ落ちが発生しているため、レベル制御部３５は、Ｓ３及びＳ４の処理を行う。ここでは、上限値Ｌはすでに最大値となっているため、そのまま最大値が維持される（Ｓ５）。また、発生回数比較部３４によって第２所定期間である期間「Ｄ」において５０回以上の激しいコマ落ちが発生していると判定される。そのため、レベル制御部３５は、Ｓ７及びＳ８の処理を行い、時刻Ｔ１５において、現在設定されている上限値Ｌを所定値Ｌｄｒｏｐ２だけ下げる。
【００６４】
一般に、ＣＰＵの負荷が限界に近い状態となった場合、アプリケーション実行部１１の処理よりも、表示ドライバ１２の処理（描画系処理）が優先される。しかし、ＣＰＵの負荷がさらに重くなりさらに限界に近くなる（上限値Ｌが最大となる）と、表示ドライバ１２に処理順が巡って来なくなる。本実施形態のように、非常に大きな負荷がかかるアプリケーション（例えば、描画更新に係るアプリケーション）を実行する場合には、このような状況が生じ得る。この場合、表示ドライバ１２は、アプリケーション実行部１１からの描画更新要求を処理しきれなくなるため、コマ落ちが発生してしまい、表示品位が低下してしまうことがある。
【００６５】
また、ＣＰＵは各種ドライバの複数の処理を実行する。そのため、表示ドライバ１２の処理に対応するパフォーマンスレベルの上限値のみを選択的に上げることは困難である。従って、上記のようにＣＰＵの負荷が限界に近い状態において、例えば大きな負荷がかかるアプリケーションが実行されていると、表示ドライバ１２の処理が他のドライバの処理に更に圧迫されて動作できなくなり、コマ落ちが更に激しくなってしまう場合がある。
【００６６】
本実施形態では、レベル制御部３５は、上記のように、第１所定時間よりも長い第２所定期間においても、コマ落ちが連続的に発生している状態が続いていると判定された場合には、ＣＰＵの負荷が限界に近い状態であると推定し、時刻Ｔ１５において上限値Ｌを下げる。これにより、アプリケーション実行部１１の描画更新レートが小さくなる。すなわち、上限値Ｌが下がるため表示ドライバ１２に対するＣＰＵの負荷も下がるが、その分描画更新レートも下がる。そのため、ＣＰＵの負荷が限界に近い状態で大きな負荷がかかるアプリケーションが実行されている場合であっても、アプリケーション実行部１１の処理にＣＰＵの負荷がとられすぎて、表示ドライバ１２が動作できなくなってしまうという状況を回避できる。すなわち、描画更新要求に対する画像データの転送処理を改善できるので、コマ落ちの発生頻度を低下させることができる。
【００６７】
図５では、時刻Ｔ１５で上限値Ｌを下げることにより、描画更新レートも１２０ＦＰＳから９０ＦＰＳへと低下している。その結果、期間「Ｅ」においてコマ落ちの発生頻度が低下している。そのため、発生回数比較部３４は、第３所定期間において第３所定回数以上のコマ落ちが発生していないと判定する。
【００６８】
なお、従来の装置では、ＣＰＵの負荷が限界に近い状態で激しいコマ落ちが発生している場合には、当該コマ落ちの発生を抑制するために、パフォーマンスレベルの上限値を変更せず、描画更新レートを大きく低下させていた（図５の描画更新レートの点線部分）。しかしこの場合、液晶ドライバ２２に転送される画像データが極端に少なくなってしまうため、表示品位が低下する場合があった。しかし、本実施形態の表示ドライバ１２によれば、上述のとおり、ＣＰＵの負荷が限界に近い状態で激しいコマ落ちが発生している場合にはパフォーマンスレベルの上限値を下げるので、描画更新レートの大幅に低下させることなく、コマ落ちの発生頻度を低下させることができ、一定の表示品位を確保できる。
【００６９】
＜本実施形態における主な効果＞
このように、表示ドライバ１２は、コマ落ちの所定期間内の発生回数に基づいて、ＣＰＵのパフォーマンスレベルの上限値を制御するので、コマ落ちの発生頻度を考慮して適切なパフォーマンスレベルの上限値に調整することができる。
【００７０】
具体的には、表示ドライバ１２は、第１所定時間内で発生したコマ落ちの発生回数が第１所定回数以上となったと判定した場合には、コマ落ちが激しくなってきたと判定する。そして、現在設定されているパフォーマンスレベルの上限値が最大でない場合には、当該上限値を上げる。これにより、表示ドライバ１２は、自機のパフォーマンスを向上させることができる。
【００７１】
一方、表示ドライバ１２は、第１所定時間よりも長い第２所定時間内で発生したコマ落ちの発生回数が第２所定回数以上となったと判定した場合には、パフォーマンスレベルの上限値を上げてもコマ落ちが激しいと判定し、現在設定されているパフォーマンスレベルの上限値を下げる。すなわち、表示ドライバ１２は、所定時間においてコマ落ちが激しい状態が継続している場合には、逆にパフォーマンスレベルの上限値を下げる。これにより、描画更新レートが小さくなるので、激しいコマ落ちの発生を回避し、コマ落ちのレートを安定化させることができる。
【００７２】
ここで、コマ落ちは不定期に発生するので、画面（液晶パネル）は不定期に更新される。そのため、動画の連続性が損なわれるので、画面の視認性が悪くなり、ユーザーは見づらく不快に感じる。これに対して、描画更新レートを下げた場合、画面は定期的に更新されるため、動画の連続性が確保される。そのため、画面の視認性の低下を抑制でき、ユーザーは見づらく感じない。本実施形態では、コマ落ちの発生回数を抑制し、かつ描画更新レートを下げているので、単位時間当たりのフレーム数が同じ比率であったとしても、動画の連続性が確保されることにより、視認性が損なわれない。
【００７３】
なお、特許文献１の再生装置では、メインプロセッサの能力を基準にフレームレートを設定しているため、不必要に低いフレームレートに設定してしまう可能性がある。そのため、不必要に表示品位を低下させてしまう可能性がある。本実施形態の表示ドライバ１２は、上記のようにＣＰＵのパフォーマンスレベルの上限値を制御するので、特許文献１の再生装置のように不必要に表示品位を低下させてしまうことはない。
【００７４】
〔実施形態２；ソフトウェアによる実施例〕
実施形態１で述べたホスト１０の構成は、以下のように実現可能である。
【００７５】
すなわち、図２に示すホスト１０のアプリケーション実行部１１、表示ドライバ１２（図１で示す各機能ブロックを含む）及びパフォーマンス制御部１４は、例えばＣＰＵを用いてソフトウェアによって実現される。
【００７６】
この場合、表示装置１は、各機能を実現するソフトウェアであるプログラムの命令を実行するＣＰＵ（ホスト１０を含む表示装置１の各種処理を制御する制御装置）、上記プログラムおよび各種データがコンピュータ（またはＣＰＵ）で読み取り可能に記録されたＲＯＭ（Read Only Memory）または記憶装置（これらを「記録媒体」と称する）、上記プログラムを展開するＲＡＭ（Random Access Memory）などを備えている。そして、コンピュータ（またはＣＰＵ）が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。なお、本発明は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
【００７７】
なお、アプリケーション実行部１１、表示ドライバ１２及びパフォーマンス制御部１４は、ハードウェアで実現されてもよい。
【００７８】
〔まとめ〕
本発明の態様１に係る表示制御装置は、表示パネルに表示される画像の表示制御を行う表示制御装置であって、上記表示パネルに表示される１フレーム分の画像の更新要求である描画更新要求に対する、当該表示パネルへの当該画像を示す画像データの転送が終了したか否かを判定する転送終了判定部と、上記転送終了判定部によって上記転送が終了したと判定されなかった回数を計数する計数部と、上記計数部によって計数された所定期間内の上記回数に基づいて、上記表示制御装置を含む装置の各種処理を制御する制御装置のパフォーマンスレベルの上限値を制御するレベル制御部と、を備える。
【００７９】
上記構成によれば、計数部が計数する回数は、所謂コマ落ちが発生した回数である。表示制御装置は、そのコマ落ちの所定期間内の発生回数に基づいて、制御装置のパフォーマンスレベルの上限値を制御する。それゆえ、表示制御装置は、コマ落ちの発生頻度を考慮して適切なパフォーマンスレベルの上限値に調整することができる。
【００８０】
さらに、本発明の態様２に係る表示制御装置は、態様１において、上記レベル制御部は、上記計数部によって計数された上記回数が、上記所定期間としての第１所定期間において第１所定回数以上となった場合で、かつ上記パフォーマンスレベルの上限値が最大でない場合には、現在設定されている上記パフォーマンスレベルの上限値を上げてもよい。
【００８１】
コマ落ちが発生すると、滑らかな動画再生が困難となる。上記構成によれば、比較的短い所定期間である第１所定期間（例えば３０ｍｓ）内のコマ落ちの発生回数が、発生回数の閾値として比較的小さい第１所定回数（例えば２回）以上の場合で、かつパフォーマンスレベルの上限値が最大でない場合には、パフォーマンスレベルの上限値を上げる。これにより、表示制御装置のパフォーマンス（描画関連処理のパフォーマンス）を向上させることができる。それゆえ、コマ落ちの発生を抑制することが可能となる。
【００８２】
さらに、本発明の態様３に係る表示制御装置は、態様２において、上記レベル制御部は、上記計数部によって計数された上記回数が、上記第１所定期間よりも長い第２所定期間において、上記第１所定回数よりも多い第２所定回数以上となった場合には、現在設定されている上記パフォーマンスレベルの上限値を下げてもよい。
【００８３】
一般に、制御装置の負荷が限界に近い状態となった場合、アプリケーションの処理よりもドライバの処理の方が優先される。すなわち、描画更新要求の発行処理よりも、表示制御装置における処理が優先される。しかし、制御装置の負荷がさらに重くなりさらに限界に近くなると、表示制御装置に処理順がなかなか巡って来なくなる。この場合、表示制御装置は、描画更新要求を処理しきれなくなるため、コマ落ちを発生させてしまう。そのため、上記構成のように、比較的長い第２所定期間（例えば５００ｍｓ）内に第２所定回数（５０回）以上のコマ落ちが発生している場合にパフォーマンスレベルの上限値を下げることにより、上記状態と想定されるときの、単位時間あたりに発行される描画更新要求数（描画更新レート）を小さくすることでコマ落ちの頻度を下げることができる。
【００８４】
したがって、制御装置の負荷が限界に近く、表示制御装置にかかる当該負荷の割合が少なくなっている状態であっても、表示制御装置は、取得した描画更新要求に対する画像データの転送の割合（描画レート）を、パフォーマンスレベルの上限値を下げる前に比べて増やすことができる。換言すれば、上記状態において、コマ落ちの発生割合を低くして一定の描画レートを確保することができるので、表示が固まってしまうような現象の発生を抑制し、一定の表示品位を確保することができる。すなわち、制御装置の負荷に依存せずに、滑らかな表示を維持することができる。
【００８５】
さらに、本発明の態様４に係る表示制御装置は、態様１から３のいずれかにおいて、上記転送終了判定部は、上記描画更新要求を取得した回数である描画要求受付数が、上記描画更新要求に対する上記表示パネルへの画像データの転送が終了したことを示す転送終了割り込みを取得した回数である画像転送完了数よりも２以上多くなった場合に、上記画像データの転送が終了していないと判定してもよい。
【００８６】
上記構成によれば、コマ落ちの発生回数を確実に計数することができる。
【００８７】
さらに、本発明の態様５に係る表示制御装置の制御方法は、表示パネルに表示される画像の表示制御を行う表示制御装置の制御方法であって、上記表示パネルに表示される１フレーム分の画像の更新要求である描画更新要求に対する、当該表示パネルへの当該画像を示す画像データの転送が終了したか否かを判定する転送終了判定ステップと、上記転送終了判定ステップにおいて上記転送が終了したと判定されなかった回数を計数する計数ステップと、上記計数ステップにおいて計数された所定期間内の上記回数に基づいて、上記表示制御装置を含む装置の各種処理を制御する制御装置のパフォーマンスレベルの上限値を制御するレベル制御ステップと、を含む。
【００８８】
上記方法によれば、態様１の表示制御装置と同様の効果を奏する。
【００８９】
さらに、本発明の各態様に係る表示制御装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記表示制御装置が備える各部（ソフトウェア要素）として動作させることにより上記表示制御装置をコンピュータにて実現させる表示制御装置の表示制御プログラム、およびそれを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に入る。
【００９０】
本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。さらに、各実施形態にそれぞれ開示された技術的手段を組み合わせることにより、新しい技術的特徴を形成することができる。
【符号の説明】
【００９１】
１  表示装置（表示制御装置を含む装置）    １２  表示ドライバ（表示制御装置）
２１  液晶パネル（表示パネル）            ３２  転送終了判定部
３３  発生回数計数部（計数部）            ３５  レベル制御部
【図１】
2017069713.tif 000003
【図２】
2017069713.tif 000004
【図３】
2017069713.tif 000005
【図４】
2017069713.tif 000006
【図５】
2017069713.tif 000007