JP6578901B2 - 表示制御装置 - Google Patents

Description

本発明は、ディスプレイの表示画面を制御する表示制御装置に関する。

近年は、より多くの情報をユーザに提示するために、車載ディスプレイが大型化しつつある。また、車載ディスプレイの大型化に伴い、複数種類のアプリケーションソフトウェア（以降、アプリ）のそれぞれに対応する画面を、同時に表示する機会も増加している。特許文献１には、複数種類のアプリのそれぞれに対応する画面を車載ディスプレイに同時に表示するための技術が開示されている。

なお、車載ディスプレイに表示する画面の種類としては、例えば、カメラ画面、エネルギーモニタ画面、デジタルテレビ画面、ブラウザ画面などがある。カメラ画面は、例えば車両後方を撮影する車載カメラが撮影している画像を表示する画面であり、エネルギーモニタ画面は、車両に搭載されているモータおよびバッテリーのエネルギーの流れや稼働状況を示す画面である。デジタルテレビ画面は、デジタルテレビ番組を表示する画面であり、ウェブブラウザ画面は、ウェブブラウザとして機能する画面である。もちろん、車載ディスプレイに表示される画面の種別は、以上で例示したもの以外にも様々なものがある。

特許第４４５５５９４号公報

車載ディスプレイに複数種類の画面を同時に表示するためには、描画用のマイクロコンピュータ（以降、描画マイコン）に、各画面に対応する画像を描画させる必要がある。その結果、複数種類の画面を同時に車載ディスプレイに表示させる場合には、描画マイコンの負荷が高くなりやすく、各アプリから要求される描画処理量が、描画マイコンの性能を超過する場合もある。描画マイコンの性能を超過する描画要求が生じた場合には、一部又は全部の画面において、フリーズや遅延などといった処理落ちが発生してしまう。

表示画面において処理落ちが発生してしまうと、ユーザに違和感を与えてしまう。特に、ディスプレイが備える全表示領域のうち、ユーザの目に止まりやすいエリアに表示されている画面において処理落ちが生じた場合には、ユーザに、相対的に大きい違和感を与えてしまう。

本発明は、この事情に基づいて成されたものであり、その目的とするところは、ディスプレイの表示領域のうちユーザにとって情報が見やすい位置に配置されている画面に、処理落ちが発生することを抑制可能な表示制御装置を提供することにある。

その目的を達成するための本発明は、ディスプレイの表示画面を制御する表示制御装置であって、所定の入力装置を介して、所定のアプリケーションソフトウェアの画面をディスプレイに表示するためのユーザによる指示操作を受け付ける操作受付部（Ｆ１）と、操作受付部が受け付けた指示操作に基づいて、アプリケーションソフトウェアの画面としてディスプレイに表示するための画像であるアプリ画像を描画する描画処理部（１１１）と、描画処理部が生成したアプリ画像を用いて、ディスプレイにおける表示画面として表示される画像である表示用画像を生成し、当該生成した表示用画像をディスプレイに表示する表示処理部（Ｆ３）と、を備え、表示画面には、複数の表示エリア（Ａｒ１、Ａｒ２、Ａｒ３）が設定されており、複数の表示エリアのそれぞれには、ユーザによる情報の見易さの順位を示すエリア格が予め割り当てられており、アプリケーションソフトウェアには、当該アプリケーションソフトウェアに対応する画面の表示先とする表示エリアが予め設定されており、描画処理部は、複数の表示エリアのうち、エリア格が高い表示エリアに表示するためのアプリ画像を、エリア格が低い表示エリアに表示するためのアプリ画像よりも優先的に描画し、ディスプレイの画面構成を調停する表示調停部（Ｆ２）を備え、アプリケーションソフトウェアには、そのアプリケーションソフトウェアに対応するアプリ画像を描画処理部が描画するための負荷が、高レベルであるか低レベルであるかを示す負荷レベルが設定されてあって、表示調停部は、負荷レベルが高レベルに設定されているアプリケーションソフトウェアのアプリ画像である高負荷アプリ画像を所定の表示エリアに表示させる指示操作を操作受付部が受け付けた場合において、当該高負荷アプリ画像を表示させる表示エリアよりもエリア格が高い他の表示エリアに既に他の高負荷アプリ画像を表示している場合には、今回受け付けた指示操作を破棄して、現在の画面構成を継続させることを特徴とする。

以上の構成によれば、描画処理部は、複数の表示エリアのうち、ユーザにとって見やすい位置に配置される表示エリアに表示するアプリ画像を優先的に描画する。したがって、ディスプレイが備える表示領域のうち相対的にユーザにとって情報が見やすい位置に配置されている画面において、処理落ちが発生することを抑制できる。

なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

第１実施形態に係る車載システム１００の概略的な構成の一例を示す図である。 ディスプレイ２の表示画面の構成について説明するための概念図である。 ディスプレイ２の画面構成の一例を示した図である。 ディスプレイ２の画面構成の一例示した図である。 ディスプレイ２の画面構成の一例示した図である。 ＨＣＵ１の概略的な構成の一例を示すブロック図である。 アプリ管理データＤｔについて説明するための図である。 ＨＣＵ１が実施する画面制御処理のフローチャートである。 第１実施形態における表示調停処理のフローチャートである。 図９に示すフローチャートの続きである。 図９に示すフローチャートの続きである。 図１１に示すフローチャートの続きである。 図１１に示すフローチャートの続きである。 図９に示すフローチャートの続きである。 図１４に示すフローチャートの続きである。 ユーザ操作に応じた画面構成の変化の一例を示す図である。 ユーザ操作に応じた画面構成の変化の一例を示す図である。 ユーザ操作に応じた画面構成の変化の一例を示す図である。 第２実施形態における表示調停処理のフローチャートである。 図１９に示すフローチャートの続きである。 図２０に示すフローチャートの続きである。 図１９に示すフローチャートの続きである。 ユーザ操作に応じた画面構成の変化の一例を示す図である。

［第１実施形態］
以下、本発明の第１の実施形態について図を用いて説明する。図１は、本発明に係る表示制御装置を適用した車載システム１００の概略的な構成の一例を示す図である。図１に示す車載システム１００は、車両に搭載されている。便宜上、ここでは車載システム１００が搭載されている車両は、駆動源としてモータと内燃機関の両方を備える車両（いわゆるハイブリッド車）とする。なお、他の態様として車載システム１００は、電気自動車に搭載されてあっても良いし、駆動源としてエンジンのみを備える車両に搭載されてあっても良い。

＜車載システム１００の概要＞
本実施形態に係る車載システム１００は、図１に示すように、ＨＣＵ１、ディスプレイ２、入力装置３、及び、種々の車載センサ４を備えている。ＨＣＵは、HMI (Human Machine Interface) Control Unitの略である。ＨＣＵ１は、ディスプレイ２、入力装置３、及び、種々の車載センサ４のそれぞれと、車両内に構築されている通信ネットワーク（以降、ＬＡＮ：Local Area Network）５を介して相互通信可能に構成されている。

ＨＣＵ１は、入力装置３へのユーザの操作や、車載センサ４から入力されるデータに基づいて、ディスプレイ２の表示画面を制御する装置である。つまり、ＨＣＵ１が請求項に記載の表示制御装置に相当する。このＨＣＵ１についての詳細は別途後述する。

ディスプレイ２は、ＨＣＵ１から入力された画像を表示する。ディスプレイ２は、例えば、インスツルメントパネルの中央付近に配置されている。ディスプレイ２は、例えばフルカラー表示が可能なものであり、周知の液晶ディスプレイや有機ＥＬディスプレイ等を用いて実現することができる。なお、ディスプレイ２は周知のヘッドアップディスプレイであってもよい。

入力装置３は、ディスプレイ２の表示内容の変更操作や、所定のアプリに対するユーザの指示操作を受け付けるための装置である。例えば入力装置３は、ディスプレイ２と一体になったタッチパネルとすればよい。仮に入力装置３としてタッチパネルを採用した場合には、入力装置３は、ユーザによるタッチ操作を検出すると、タッチパネル上においてユーザによってタッチされた位置（以降、タッチ位置）を示すタッチ位置信号をＨＣＵ１に出力する。他の態様として、入力装置３は、メカニカルなスイッチ等であってもよいし、図示しないマイクを備えた音声認識装置であってもよい。また、入力装置３として、それら複数種類の装置を備えていても良い。

車載センサ４は、車両の走行に関する種々の状態量を検出するための種々のセンサである。車両の走行に関する状態量とは、例えば、走行速度や、シフト位置、方向指示器の動作状態、バッテリー残量、燃料残量などである。つまり、走行速度を検出する速度センサや、シフト位置を検出するシフトポジションセンサ、方向指示器の動作状態を示す信号を出力するターンスイッチ等が、車載センサ４に含まれる。種々の車載センサ４の検出結果は、ＬＡＮ５を介してＨＣＵ１に逐次提供される。なお、車載センサ４に含まれるセンサは上述したものに限らない。また、上述した全てのセンサを備えている必要もない。ＨＣＵ１に対して検出結果を提供させる車載センサ４の種類は適宜設計されればよい。

＜ディスプレイ２における表示エリアについて＞
次に、本実施形態におけるディスプレイ２の表示画面の構成について説明する。本実施形態のＨＣＵ１は、ドライバから見て最前面となるレイヤである第１レイヤＬ１と、ドライバから見て第１レイヤよりも奥側に位置するレイヤである第２レイヤＬ２の、それぞれに配置した画像を重ね合わせた画像をディスプレイ２に表示するものである。換言すれば、ＨＣＵ１は、ディスプレイ２の表示画面を、第１レイヤＬ１と第２レイヤＬ２の２つのレイヤに分割して管理する。なお、ドライバから見て第１レイヤよりも奥側のレイヤとは、ディスプレイ２のバックライト２Ａ側のレイヤに相当する。

さらに、ＨＣＵ１は、第１レイヤＬ１及び第２レイヤＬ２を用いてディスプレイ２の表示画面を、図２に示すように、仮想的に（換言すればソフトウェア的に）、第１エリアＡｒ１、第２エリアＡｒ２、第３エリアＡｒ３の３つのエリアに分割して制御する。第１エリアＡｒ１が請求項に記載の第１表示エリアに相当し、第２エリアＡｒ２が請求項に記載の第２表示エリアに相当し、及び第３エリアＡｒ３が請求項に記載の第３表示エリアに相当する。

第１エリアＡｒ１は、第２レイヤＬ２に設けられる。ここでは一例として、第２レイヤ全域を第１エリアＡｒ１とする。また、第１レイヤＬ１を上下に二分割して得られる２つの領域のうち、相対的に上側の領域を第２エリアＡｒ２、下側の領域を第３エリアＡｒ３とする。

そのような構成においてＨＣＵ１は、第２エリアＡｒ２に表示すべき画像が存在しない場合、第２エリアＡｒ２を透過領域とし、第２レイヤＬ２（換言すれば第１エリアＡｒ１）において第２エリアＡｒ２の後方に位置する領域の画像をディスプレイ２に表示させる。また、第３エリアＡｒ３に表示すべき画像が存在しない場合も、第３エリアＡｒ３には透過領域とすることで、第１エリアＡｒ１に配置されている画像のうち、第３エリアＡｒ３の後方に位置する領域をディスプレイ２に表示させる。

ここでの透過領域とは、無色透明な画素を配置した領域である。例えば透過領域は、その領域を構成する画素の透過度を指定するパラメータ（いわゆるアルファ値）を１００％（つまり、完全透明な状態）に設定することで実現すれば良い。便宜上、或る表示エリアを透過領域に設定し、当該表示エリアに情報を表示しなくすることを、その表示エリアでの表示をオフにするとも記載する。一方、或る表示エリアに画像を表示させている状態を、当該表示エリアがオンとなっているとも記載する。

図３〜図５は、以上で述べた構成におけるディスプレイ２の表示画面の構成の一例を示す概念図である。ＨＣＵ１が、第２エリアＡｒ２、第３エリアＡｒ３をオフにしている場合、図３に示すように第１エリアＡｒ１の全領域がディスプレイ２に表示される。また、第２エリアＡｒ２をオフ、第３エリアＡｒ３をオンにしている場合には、図４に示すように第１エリアＡｒ１の上半分と、第３エリアＡｒ３の画像が、ディスプレイ２に表示される。

第２エリアＡｒ２、第３エリアＡｒ３の両方をオンにしている場合、図５に示すように第２エリアＡｒ２と第３エリアＡｒ３の画像がディスプレイ２に表示され、第１エリアＡｒ１の画像は表示されなくなる。なお、ここでは一例として、第２エリアＡｒ２に画像を表示する場合には、必ず第３エリアＡｒ３にも画像を表示するものとする。つまり、ディスプレイ２の表示画面として採用され得るレイアウトは、図３〜図５に示す３パターンでする。

＜表示エリア毎のエリア格について＞
上述した３つの表示エリアのそれぞれには、ユーザによる情報の見易さの順位を示すエリア格が予め割り当てられている。具体的には次の通りである。

第１エリアＡｒ１は、第２エリアＡｒ２や第３エリアＡｒ３の画像によって見えなくなってしまうため、相対的に、ユーザによる情報の見易さとしては、第２エリアＡｒ２や第３エリアＡｒ３に劣る。また、第２エリアＡｒ２は、第３エリアＡｒ３よりも上方に配置されているため、ユーザ（特にドライバ）は、車両前方を見ている状態から、より少ない視線移動で第２エリアＡｒ２を視認することができる。換言すれば、ドライバにとって第２エリアＡｒ２は、第３エリアＡｒ３よりも見やすい位置に設けられる表示エリアである。

つまり、ユーザにとって第１エリアＡｒ１よりも第３エリアＡｒ３のほうが見やすい表示エリアであり、第３エリアＡｒ３よりも第２エリアＡｒ２のほうが見やすい表示エリアとして機能する。第１エリアＡｒ１が、エリア格が最も低い表示エリアに相当し、第２エリアＡｒ２が、エリア格が最も高い表示エリアに相当する。また、第３エリアＡｒ３のエリア格は、第１エリアＡｒ１と第２エリアＡｒ２の中間である。

＜ＨＣＵ１の構成及び作動について＞
次に、ＨＣＵ１の構成及び作動について述べる。ＨＣＵ１は、通常のコンピュータとして構成されており、ＣＰＵ１１、ＲＡＭ１２、ＲＯＭ１３、Ｉ／Ｏ１４、フラッシュメモリ１５、及び、それらの部材を接続するバスラインなどを備えている。ＣＰＵは、Central Processing Unitの略であり、ＲＡＭは、Random Access Memoryの略であり、ＲＯＭは、Read Only Memoryの略である。

ＣＰＵ１１は、マイクロプロセッサ等を用いて実現されれば良い。図１の符号１１１が指し示す領域は、ＣＰＵ１１が備える処理能力（いわゆるＣＰＵリソース）のうち、ディスプレイ２に表示するための画像の描画に割り当てることができるリソース部分（以降、描画処理部）を、概念的に表している。なお、描画処理部１１１は、描画以外の処理を実施するプロセッサとは独立した、１つ又は複数のプロセッサを用いて実現されてもよい。

ＲＡＭ１２は、ＣＰＵ１１にとっての主記憶装置（いわゆるメモリ）として機能する。なお、ＣＰＵ１１にとってのメモリとして機能する記憶媒体はＲＡＭに限らない。他の種類の記憶媒体をＲＡＭ１２として採用してもよい。

ＲＯＭ１３には、通常のコンピュータを、本実施形態におけるＨＣＵ１として機能させるためのプログラム（以降、表示制御プログラム）等が書き込まれている。なお、上述の表示制御プログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよい。ＣＰＵ１１が当該表示制御プログラムを実行することは、表示制御プログラムに対応する方法が実行されることに相当する。

Ｉ／Ｏ１４は、ＨＣＵ１がＬＡＮ５を介して接続している他の機器（例えばディスプレイ２）とデータの入出力をするためのインターフェースである。Ｉ／Ｏ１４は、アナログ回路素子やＩＣなどを用いて実現されればよい。

フラッシュメモリ１５は、補助記憶装置（いわゆるストレージ）として機能する記憶媒体である。フラッシュメモリ１５は、書き換え可能な不揮発性の記憶媒体を用いて実現されればよい。フラッシュメモリ１５には、車両のユーザに対して種々の機能を提供するための種々のアプリケーションソフトウェア（以降、アプリ）がインストールされている。

本実施形態では一例として、図６に示すように、エネルギーモニタアプリＡｐ１、デジタルテレビアプリＡｐ２、後方監視アプリＡｐ３、エアコンアプリＡｐ４、ブラウザアプリＡｐ５、及びオーディオアプリＡｐ６がインストールされているものとする。

エネルギーモニタアプリＡｐ１は、車載センサ４から入力される情報に基づいて、車両に搭載されているモータおよびバッテリーのエネルギーの流れや稼働状況を示す画像を生成するアプリである。デジタルテレビアプリＡｐ２は、テレビ局から放送されるデジタルテレビ番組をディスプレイ２に表示させるアプリである。

後方監視アプリＡｐ３は、車両の後方を撮影する図示しないリアカメラの撮影映像をディスプレイ２に表示するためのアプリである。なお、後方監視アプリＡｐ３は、ユーザの操作に基づいて起動する他、シフト位置が後退位置となっている場合に自動的に起動されてもよい。

エアコンアプリＡｐ４は、車両に搭載された図示しない空調装置の動作を制御して、冷暖房のオン／オフの切り替え、温度調整、風量調整等に関する個々の処理を実行するためのアプリである。エアコンアプリＡｐ４は、目標温度の設定や風量調整、動作状況を示す画像をディスプレイ２に表示させる。ブラウザアプリＡｐ５は、インターネット上のＷｅｂサイトを閲覧するためのアプリである。

ブラウザアプリＡｐ５は、ユーザの入力によって定まるＷｅｂサイトをディスプレイ２に表示させる。オーディオアプリＡｐ６は、所定の記憶媒体に保存されている音楽コンテンツの再生、音量調整、ラジオの音声出力などの処理を実行するアプリである。

各アプリは、ユーザによって起動されている場合、表示調停部Ｆ２から指示されたＣＰＵリソースを用いて（換言すれば描画処理部１１１と協働して）、そのアプリの動作状態に応じた画像を描画し、その画像データを表示画像生成部Ｆ３に提供する。具体的には、描画処理部１１１が、各アプリからの要求に基づいて画像を描画する。そして、表示画像生成部Ｆ３は、アプリから提供された画像データに基づいて、ディスプレイ２に表示する画像を生成し、表示させる。その結果、ディスプレイ２には、ユーザの操作に応じたアプリの画面が、所定のレイアウトで表示される。

ここでの或るアプリの画面（以降、アプリ画面）とは、ディスプレイ２が備える全表示領域のうち、そのアプリの動作状態に応じた画像を表示している領域を指す。アプリ画面とは、例えば、当該アプリに対するユーザによる指示操作を受け付けるための画面や、ユーザの指示操作に対する応答として、所定の情報をユーザに提供するための画面などである。

エネルギーモニタアプリＡｐ１が描画するアプリ画面を、以降では、エネルギーモニタ画面と記載する。同様に、デジタルテレビアプリＡｐ２、後方監視アプリＡｐ３、エアコンアプリＡｐ４、ブラウザアプリＡｐ５、及びオーディオアプリＡｐ６の各々が描画する画面を、デジタルテレビ画面、後方監視画面、エアコン画面、ブラウザ画面、オーディオ画面と記載する。種々のアプリ画面として機能する画像が、請求項に記載のアプリ画像に相当する。

種々の表示エリアのうち、アプリ画面の表示先とする表示エリアは、アプリ毎に、そのアプリがユーザに対して提供する情報の種類（換言すればアプリの役務）に応じて予め設定されている。アプリ毎の表示エリアを示すデータ（以降、アプリ管理データ）Ｄｔは、フラッシュメモリ１５に格納されている。

また、アプリ管理データＤｔには、各アプリの表示エリアの他、アプリ毎に、そのアプリ画面を描画するためにＣＰＵ１１（具体的には描画処理部１１１）にかかる負荷のレベルが、高レベルであるか低レベルであるかを示すデータも含まれている。或るアプリ画面を描画するためにＣＰＵ１１にかかる負荷とは、そのアプリ画面を描画するために要するＣＰＵリソースに相当する。このアプリ管理データＤｔの詳細については別途後述する。

なお、本実施形態では、車室内においてユーザが利用可能な機能を提供するアプリの一例として、エアコンアプリＡｐ４等を例示したが、これに限らない。例えば、周知のナビゲーション装置に相当する機能を提供するアプリがインストールされていても良い。

また、本実施形態では一例として、ＨＣＵ１が、種々のアプリを備えている態様とするが、これに限らない。他の態様として、後述する種々のアプリの一部又は全部は、ＬＡＮ１を介して当該ＨＣＵ１と接続している、１つ又は複数の電子制御装置（以降、ＥＣＵ：Electronic Control Unit）が備えていてもよい。換言すれば、或るアプリに対応する機能は、所定のＥＣＵが提供する態様であってもよい。さらに、ＨＣＵ１がユーザによって車室内に持ち込まれた携帯端末と相互通信可能に接続される場合には、携帯端末にインストールされているアプリを、上述した種々のアプリと同様に取り扱う構成としてもよい。

ＨＣＵ１はＣＰＵ１１が、ＲＯＭ１３に格納されている表示制御プログラムを実行することによって実現する機能ブロックとして、図６に示すように操作受付部Ｆ１、表示調停部Ｆ２、表示画像生成部Ｆ３、及びアプリ管理部Ｆ４を備える。

操作受付部Ｆ１は、入力装置３を介して、ディスプレイ２の画面構成を変更するユーザの指示操作や、所定のアプリに対するユーザの指示操作を受け付ける。ディスプレイ２の画面構成を変更する指示操作とは、所定のアプリを起動させたり、起動中のアプリを終了させたりする操作である。それらの操作の内容は、入力装置３から入力される制御信号によって特定されればよい。

例えば入力装置３としてタッチパネルを採用している場合には、操作受付部Ｆ１は、入力装置３としてのタッチパネルから入力されるタッチ位置信号に基づいて、ディスプレイ２に表示しているボタンのうち、ユーザが選択したボタンを特定する。そして、ユーザによって選択されたボタンのボタンＩＤから、ユーザからの指示操作の内容を特定すればよい。ここでのボタンとは、ユーザの指示操作を受け付けるためのボタンとして機能する画面領域のことを指す。ボタンＩＤは、ボタン毎に予め設定されている識別番号であって、当該ボタンが選択された場合に実施すべき処理と対応付けられて記憶されている。

なお、起動中のアプリに対するユーザの指示操作を受け付けた場合には、そのアプリに対して、受け付けたユーザの操作内容を転送する。その場合に転送する操作内容とは、例えば当該アプリに対応する画面内におけるタッチ位置や、選択されたボタンのボタンＩＤ等とすればよい。

便宜上、以降では、或るアプリにおいて、当該アプリに対応する画面（つまりアプリ画面）がディスプレイ２の所定の表示領域に表示されている状態を、アクティブな状態と称する。また、或るアプリのアプリ画面をディスプレイ２に表示させることを、そのアプリをアクティブにするとも表現する。

表示調停部Ｆ２は、ディスプレイ２の画面構成を調整する処理（以降、表示調停処理）を実施する。表示調停処理の詳細については、別途後述するが、概略的には次の通りである。表示調停部Ｆ２は、操作受付部Ｆ１が受け付けた操作内容が、或るアプリをアクティブにする操作である場合には、アプリ管理データＤｔに基づいて、そのアクティブ化するアプリの画面表示先に設定されている表示エリアを特定する。また、当該アプリに対して、アプリ画面を描画するためのＣＰＵリソースを割り当てる。当該アプリは、割り当てられたＣＰＵリソースを用いてアプリ画面を描画し、逐次、そのアプリ画面に対応する画像データを表示画像生成部Ｆ３に提供する。

表示画像生成部Ｆ３は、アプリから提供される画像を、当該アプリに対応する表示エリアに配置する。そして、第１レイヤＬ１に配置されている画像と第２レイヤＬ２に配置されている画像を重ねあわせることで、ディスプレイ２に表示する画像（以降、表示用画像）のデータを生成する。なお、或るレイヤに配置される画像とは、完全透明な画像も含む。そのデータを逐次ディスプレイ２に出力し、ディスプレイ２に表示させる。この表示画像生成部Ｆ３が請求項に記載の表示処理部に相当する。

アプリ管理部Ｆ４は、フラッシュメモリ１５にインストールされているアプリについての情報を管理する機能ブロックである。換言すれば、アプリ管理部Ｆ４は、アプリ管理データＤｔを更新する。

＜アプリ管理データＤｔについて＞
次に、アプリ管理データＤｔについて述べる。アプリ管理データＤｔは、前述の通り、表示調停部Ｆ２と協働するアプリ毎の、アプリ画面の表示先とする表示エリアと負荷レベルを保持するデータである。アプリ毎の表示先は、そのアプリがユーザに対して提供する情報の種別に応じて決定される。

例えば、ドライバが車両を運転する上で有益な情報、特に、安全運転に寄与する情報は、ドライバにとって見やすい位置に表示されることが好ましい。すなわち、それらの情報を提供するアプリの画面は、エリア格が相対的に高い、第２エリアＡｒ２や第３エリアＡｒ３に表示されることが好ましい。

また、ユーザの快適性や利便性に関する情報を提供するアプリでも、その情報の種類によっては、エリア格が相対的に高い、第２エリアＡｒ２や第３エリアＡｒ３に表示させることが好ましい場合もある。

アプリ毎の表示エリアは、以上で述べた観点に基づいて適宜設計されれば良い。ここでは一例として、後方監視アプリＡｐ３及びエアコンアプリＡｐ４の表示先は第２エリアＡｒ２とし、デジタルテレビアプリＡｐ２及びオーディオアプリＡｐ６の表示先は第３エリアＡｒ３とする。また、エネルギーモニタアプリＡｐ１及びブラウザアプリＡｐ５の表示先は第１エリアＡｒ１とする。

また、図７に示すように、エネルギーモニタアプリＡｐ１、デジタルテレビアプリＡｐ２、後方監視アプリＡｐ３は、負荷レベルが高レベルなアプリとして認識されているものとする。アプリ毎の負荷レベルは、インストール時にアプリの配信元からアプリの情報として取得する態様としておいても良いし、ＨＣＵ１の設計者等によって予め設定されても良い。

さらに、アプリ毎の負荷レベルは、当該アプリを実際に複数回実行した時の負荷の平均値や中央値によってアプリ管理部Ｆ４が判定する態様としてもよい。その場合、初期状態においては高レベルとしておけばよい。つまり、初期状態においてはアプリの負荷レベルを高レベルに設定しておき、その後、複数回実行させた結果に基づいて負荷レベルは低レベルであると判定した場合には、当該アプリの負荷レベルを低レベルに変更してもよい。それらの判定及び設定の書き換えは、アプリ管理部Ｆ４によって実施されれば良い。

アプリ管理データＤｔは、新たなアプリがインストールされたり、アプリがアンインストールされたりした場合に、アプリ管理部Ｆ４によって更新されればよい。また、アプリ毎の表示エリアは、ユーザによって割り当てられても良い。

＜画面制御処理について＞
次に図８に示すフローチャートを用いて、ＨＣＵ１が、ユーザから入力された指示操作に基づいて、ディスプレイ２の画面構成を制御する処理（以降、画面制御処理）について説明する。図８に示すフローチャートは、例えば入力装置３から、ユーザによる指示操作が入力されたことを示す制御信号（例えばタッチ位置信号）が入力された場合に開始されればよい。

まず、ステップＳ１では操作受付部Ｆ１が、入力装置３から入力された制御信号に基づき、ユーザの指示操作を特定し、その特定した指示内容を、その操作に対応するアプリ（換言すれば捜査対象とするアプリ）に通知する。このステップＳ１での処理が完了するとステップＳ２に移る。

ステップＳ２では表示調停部Ｆ２が、ステップＳ１にて特定した操作が、ディスプレイ２の画面構成を変更する操作であるか否かを判定する。ここでの画面構成とは、オン状態とする表示エリアの組み合わせだけでなく、アクティブ状態とするアプリの組み合わせも含む。つまり、ディスプレイ２の画面構成を変更する操作とは、アクティブ状態とするアプリを変更する操作に相当する。

そして、ステップＳ１にて特定した操作が、ディスプレイ２の画面構成を変更させる操作である場合には、ステップＳ２が肯定判定されてステップＳ３に移る。一方、ステップＳ１で受け付けた操作が、ディスプレイ２の画面構成を変更させる操作ではない場合には、ステップＳ２が否定判定されて本フローを終了する。

ステップＳ３では表示調停部Ｆ２が図９〜図１５に示す表示調停処理を実施してステップＳ４に移る。詳細は後述するが、表示調停処理を実施することで、オン状態とする表示エリアや、アクティブ状態となるアプリが決定される。

ステップＳ４では、アクティブ状態となるアプリに対するＣＰＵリソースの割り振りを決定する。ここで、アクティブ状態となるアプリが複数存在する場合には、エリア格が高い表示エリアを表示先とするアプリに対して、優先的にＣＰＵリソースを割り当てる。換言すれば、エリア格が高い表示エリアの画像が優先的に描画されるように、ＣＰＵリソースを割り当てる。例えば、第２エリアＡｒ２を表示先とするアプリと、第３エリアＡｒ３を表示先とするアプリがアクティブとなっている場合には、第２エリアＡｒ２を表示先とするアプリに対して優先的にＣＰＵリソースを割り当てる。

なお、相対的にエリア格が高い表示エリア用の画面描写に全てのＣＰＵリソースを割り当てている状態において、相対的にエリア格の低い表示エリアに対する表示画面の変更するユーザ操作を受け付けた場合、エリア格の低い方の表示エリア用の画面の描画にＣＰＵリソースが全く割当たらない可能性がある。そのような場合には、エリア格の低い方の表示エリアの画面が１度も描画されず、ユーザにとっては画面構成が変更していないように見えるため、ユーザに違和感を与えてしまう恐れがある。

そこで、エリア格が高い表示エリア用の画面を描画するアプリに対して優先的にＣＰＵリソースを割り当てることを原則とする一方、相対的にエリア格が低い表示エリア用の画面を描画するアプリに対しても、最低限度のＣＰＵリソースを割り当てることが好ましい。ここでの最低限度のＣＰＵリソースとは、エリア格が低い方の表示エリアの表示画面を切り替えるユーザ操作に対して、少なくとも１回は、当該表示エリアの画面の更新を実施する程度のＣＰＵリソースである。

例えば、エリア格が低い方の表示エリアの表示画面を切り替えるユーザ操作を受け付けた場合には、ユーザ操作受付後に１Vsync信号が出力されたタイミングで、エリア格が低い方の表示エリアの表示画面を、新たな表示画面に更新させればよい。勿論、他の態様として、最低限度のＣＰＵリソースは数fps分のＣＰＵリソースとしてもよい。そのような態様によれば、エリア格が低い方の表示エリアの画面も、少なくとも１秒に数回の頻度で更新される。

ＣＰＵリソースが割り当てられた各アプリは、割り当てられたＣＰＵリソースを用いてアプリ画面を生成し、生成したアプリ画面に対応する画像データを表示画像生成部Ｆ３に逐次提供する。

ステップＳ５では表示画像生成部Ｆ３が、アクティブな各アプリからの画像を取得してステップＳ６に移る。ステップＳ６では表示画像生成部Ｆ３が、各アプリから提供された画像データを、それぞれ対応する表示エリアに配置した画像データ（つまり表示画像データ）を生成し、ディスプレイ２に表示して本フローを終了する。なお、ステップＳ５からステップＳ７までの処理は、新たに画面構成を変更する指示操作を受け付けたり、車両電源がオフとなったりするまで逐次実施されれば良い。

＜表示調停処理＞
次に、図９〜図１５に示すフローチャートを用いて表示調停部Ｆ２が実施する表示調停処理について説明する。図９に示すフローチャートは、図８のステップＳ３に移った時に開始されればよい。

まず、ステップＳ１０１では、図８のステップＳ１で受け付けた操作が、現在アクティブではないアプリを、アクティブにする操作であるか否かを判定する。換言すれば、ステップＳ１で受け付けた操作が、所定のアプリの画面を新たに表示させるための操作（以降、画面呼出操作）であるか否かを判定する。ステップＳ１で受け付けた操作が画面呼出操作である場合には、ステップＳ１０１が肯定判定されてステップＳ１０２に移る。一方、ステップＳ１で受け付けた操作が画面呼出操作ではない場合には、ステップＳ１０１が否定判定されて図１４のステップＳ１５０に移る。

なお、表示調停処理を実施する場合とは、ステップＳ１で受け付けた操作が、少なくとも、ディスプレイ２の画面構成を変更させる操作である場合である。したがって、Ｓ１０１において否定判定される場合とは、ステップＳ１で受け付けた操作が、現在アクティブなアプリのうち、何れかのアプリを終了させる操作が行われたことを意味する。特に、本実施形態においては、第１エリアＡｒ１を表示先とするアプリの終了操作は受け付けない構成となっている。そのため、ステップＳ１０１が否定判定される場合とは、ステップＳ１で受け付けた操作が、第２エリアＡｒ２用のアプリを終了させる操作、又は、第３エリアＡｒ３用のアプリを終了させる操作であることを意味する。

ステップＳ１０２では、アプリ管理データＤｔを参照し、ユーザ操作に基づいてアクティブ化するアプリの画面表示先が、第２エリアＡｒ２であるか否かを判定する。アクティブ化するアプリの画面表示先が第２エリアＡｒ２である場合には、ステップＳ１０２が肯定判定されてステップＳ１０３に移る。一方、アクティブ化するアプリの画面表示先が第２エリアＡｒ２ではない場合には、ステップＳ１０２が否定判定されて図１１のステップＳ１２０に移る。

ステップＳ１０３では、現在、第３エリアＡｒ３がオンとなっているか否かを判定する。第３エリアＡｒ３がオンとなっている場合にはステップＳ１０３が肯定判定されてステップＳ１０４に移る。一方、第３エリアＡｒ３がオフとなっている場合にはステップＳ１０３が否定判定されてステップＳ１０７に移る。

ステップＳ１０４では、所定の第３エリア退避条件が成立しているか否かを判定する。第３エリア退避条件とは、第３エリアＡｒ３に現在表示中の画面を退避させて、予め規定されている、後述の低負荷画面を第３エリアＡｒ３に表示する条件である。第３エリア退避条件が成立する場合とは、今回アクティブ化するアプリに対応する画面（以降、呼出画面）の描画負荷が高レベルであって、かつ、現在の第３エリアＡｒ３に表示中の画面を描画するための負荷も高レベルである場合である。

なお、或る表示エリアに表示する画面の描画負荷が高レベルであるか否かはアプリ管理データＤｔに基づいて判定される。例えば、アプリ管理データＤｔにおいて、第３エリアＡｒ３用の画面を現在描画しているアプリの負荷レベルが高レベルに設定されている場合、第３エリアＡｒ３に現在表示中の画面の描画負荷は高レベルであると判定される。呼出画面の描画負荷についても同様に、アプリ管理データＤｔに基づいて判定されれば良い。負荷レベルが高レベルに設定されているアプリの画面として描画される画像が、請求項に記載の高負荷アプリ画像に相当する。

第３エリア退避条件が成立している場合にはステップＳ１０４が肯定判定されてステップＳ１０５に移る。一方、第３エリア退避条件が成立していない場合にはステップＳ１０４が否定判定されて図１０に示すステップＳ１１０に移る。

ステップＳ１０５では、第３エリアＡｒ３に現在表示中の画面を退避リストに登録してステップＳ１０６に移る。退避リストは、描画負荷が高まってしまうことを避けるために、ディスプレイ２への表示（換言すればアプリによる描画処理）をいったん中断させた画面のリストである。

なお、退避リストは、退避させた画面の画面ＩＤを保持するものとすればよい。画面ＩＤは、アプリ毎（換言すれば画面毎）に固有の識別番号であって、他のアプリの画面と区別するための情報である。もちろん、退避リストは、退避させた画面を後で再び表示するために、退避させた画面の画像データ等も、退避させた画面の画面ＩＤと対応付けて保持していることが好ましい。また、退避リストは、退避されている画面が、何れの表示エリアに表示されていた画面であるかを示す情報を対応付けて保持していることが好ましい。退避リストは、例えばＲＡＭ１２が備える記憶領域を用いて実現されれば良い。

以降では便宜上、第３エリアＡｒ３から退避させた画面のことを、退避中の第３エリア画面とも記載する。

ステップＳ１０６では、本フロー終了後におけるディスプレイ２の画面構成を決定する。具体的には、第１エリアＡｒ１をオフにするとともに、第２エリアＡｒ２には呼出画面を配置し、第３エリアＡｒ３には、現在表示中の画面の代わりに、描画負荷が低レベルである所定の画面（以降、低負荷画面）を表示することを決定する。低負荷画面は予め設定されていればよい。例えば、第３エリアＡｒ３用の低負荷画面は、オーディオ画面とすればよい。或いは、ユーザが利用可能なアプリの一覧を表す画面（以降、メニュー画面）としてもよい。メニュー画面の画像データは、表示画像生成部Ｆ３によって生成されればよい。第３エリアＡｒ３用の低負荷画面の内容は適宜設計されれば良い。

ステップＳ１０７では、第１エリアＡｒ１に現在表示中の画面を、退避リストに登録してステップＳ１０８に移る。なお、本フロー開始時において、第２エリアＡｒ２がオンとなっている場合には、このステップＳ１０７は省略してステップＳ１０８に移ればよい。第２エリアＡｒ２がオンとなっている場合には、第１エリアＡｒ１はオフとなっているためである。

ステップＳ１０８では、ディスプレイ２の画面構成として、第１エリアＡｒ１をオフにするとともに、第２エリアＡｒ２には呼出画面を配置し、第３エリアＡｒ３には低負荷画面を表示することを決定し、ステップＳ１０９に移る。

ステップＳ１０９では、第３エリアＡｒ３に表示する画面が連動表示画面である旨を、フラグ等を用いて記憶する。ステップＳ１０９の処理が完了すると、本フローの呼び出し元である図８に画面制御処理に戻り、ステップＳ５を実施する（つまりリターンする）。連動表示画面とは、第２エリアＡｒ２をオン状態にすることに連動して、第３エリアＡｒ３に表示される画面である。

図１０のステップＳ１１０では、所定の第３エリア復帰条件が成立しているか否かを判定する。第３エリア復帰条件は、退避中となっている第３エリア画面を復帰（換言すれば再表示）させる条件である。第３エリア復帰条件が成立する場合とは、第２エリアＡｒ２に新たに表示する呼出画面の描画負荷が低レベルであって、かつ、退避中の第３エリア画面が存在する場合である。退避中の第３エリア画面が存在するか否かは、退避リストを参照することで判定されれば良い。

第３エリア復帰条件が成立している場合にはステップＳ１１０が肯定判定されてステップＳ１１１に移る。一方、第３エリア復帰条件が成立していない場合にはステップＳ１１０が否定判定されてステップＳ１１３に移る。

ステップＳ１１１では、ディスプレイ２の画面構成として、第１エリアＡｒ１をオフにするとともに、第２エリアＡｒ２には呼出画面を配置し、第３エリアＡｒ３には退避させている第３エリア画面を表示することを決定し、ステップＳ１１２に移る。ステップＳ１１２では、ステップＳ１１１で復帰させることが決定された第３エリア画面のデータを退避リストから除去し、呼び出し元にリターンする。

ステップＳ１１３では、第１エリアＡｒ１に現在表示中の画面を、退避リストに登録してステップＳ１１４に移る。ステップＳ１１４では、ディスプレイ２の画面構成として、第１エリアＡｒ１をオフにするとともに、第２エリアＡｒ２には呼出画面を配置し、第３エリアＡｒ３には第３エリアＡｒ３用の低負荷画面を表示することを決定する。そして、呼び出し元にリターンする。

図１１のステップＳ１２０では、アプリ管理データＤｔを参照し、アクティブ化するアプリの画面表示先が、第３エリアＡｒ３であるか否かを判定する。アクティブ化するアプリの画面表示先が第３エリアＡｒ３である場合には、ステップＳ１２０が肯定判定されてステップＳ１２１に移る。一方、アクティブ化するアプリの画面表示先が第３エリアＡｒ３ではない場合には、ステップＳ１２０が否定判定されて図１３のステップＳ１４０に移る。

ステップＳ１２１では、現在、第２エリアＡｒ２がオンとなっているか否かを判定する。第２エリアＡｒ２がオンとなっている場合にはステップＳ１２１が肯定判定されて図１２のステップＳ１３０に移る。一方、第２エリアＡｒ２がオフとなっている場合にはステップＳ１２１が否定判定されてステップＳ１２２に移る。

ステップＳ１２２では、所定の第１エリア退避条件が成立しているか否かを判定する。第１エリア退避条件とは、第１エリアＡｒ１に現在表示中の画面を退避させて、第１エリアＡｒ１に、第１エリアＡｒ１用の所定の低負荷画面を表示する条件である。第１エリア退避条件が成立する場合とは、今回第２エリアＡｒ２に新たに表示する呼出画面の描画負荷が高レベルであって、かつ、現在第１エリアＡｒ１に表示中の画面が描画負荷の高い画面となっている場合である。

第１エリアＡｒ１用の低負荷画面も、第３エリアＡｒ３用の低負荷画面と同様に予め設定されていればよい。例えば、第１エリアＡｒ１における低負荷画面は、第１エリアＡｒ１のサイズに応じたメニュー画面とすればよい。或いは、予め設定されている背景画像等としてもよい。第１エリアＡｒ１用の低負荷画面の内容は適宜設計されれば良い。

第１エリア退避条件が成立している場合にはステップＳ１２２が肯定判定されてステップＳ１２３に移る。一方、第１エリア退避条件が成立していない場合にはステップＳ１２２が否定判定されてステップＳ１２５に移る。

ステップＳ１２３では、第１エリアＡｒ１に現在表示中の画面を、退避リストに登録してステップＳ１２４に移る。なお、以降では便宜上、第１エリアＡｒ１から退避させた画面のことを、退避中の第１エリア画面とも記載する。

ステップＳ１２４では、ディスプレイ２の画面構成として、第１エリアＡｒ１には第１エリアＡｒ１用の低負荷画面を表示するとともに、第３エリアＡｒ３には呼出画面を配置することを決定し、ステップＳ１２９に移る。なお、第２エリアＡｒ２については、引き続きオフの状態が継続される。

ステップＳ１２５では、所定の第１エリア復帰条件が成立しているか否かを判定する。第１エリア復帰条件は、退避中となっている第１エリア画面を復帰（つまり再表示）させる条件である。第１エリア復帰条件が成立する場合とは、第３エリアＡｒ３に新たに表示する呼出画面の描画負荷が低レベルであって、かつ、退避中の第１エリア画面が存在する場合である。退避中の第１エリア画面が存在するか否かは、退避リストを参照することで判定できる。

第１エリア復帰条件が成立している場合にはステップＳ１２５が肯定判定されてステップＳ１２７に移る。一方、第１エリア復帰条件が成立していない場合にはステップＳ１２５が否定判定されてステップＳ１２６に移る。

ステップＳ１２６では、ディスプレイ２の画面構成として、第１エリアＡｒ１には現在表示中の画面の表示を継続させるとともに、第３エリアＡｒ３には呼出画面を配置することを決定し、ステップＳ１２９に移る。なお、第２エリアＡｒ２についてはオフの状態が継続される。

ステップＳ１２７では、ディスプレイ２の画面構成として、第１エリアＡｒ１には退避させていた第１エリア画面を復帰させるとともに、第２エリアＡｒ２はオフ状態を継続させ、第３エリアＡｒ３には呼出画面を配置することを決定し、ステップＳ１２８に移る。ステップＳ１２８では、復帰させる第１エリア画面のデータを退避リストから削除し、ステップＳ１２９に移る。

ステップＳ１２９では、第３エリアＡｒ３に現在表示中の画面を、退避リストに登録して呼び出し元にリターンする。ただし、第３エリアＡｒ３に現在表示中の画面が連動表示画面である場合には、退避リストに登録せずに呼び出し元にリターンする。

図１２のステップＳ１３０では、所定の第３エリア切替要求破棄条件が成立しているか否かを判定する。第３エリア切替要求破棄条件は、第３エリアＡｒ３の表示画面を切り替えるユーザ操作を破棄して、現在のディスプレイ２の画面構成を保持する条件である。第３エリア切替要求破棄条件が成立する場合とは、現在の第２エリアＡｒ２に描画負荷が高レベルな画面を表示してあって、かつ、第３エリアＡｒ３に新たに表示する呼出画面の描画負荷も高レベルに設定されている場合である。

第３エリア切替要求破棄条件が成立している場合にはステップＳ１３０が肯定判定されてステップＳ１３１に移る。一方、第３エリア切替要求破棄条件が成立していない場合にはステップＳ１３０が否定判定されてステップＳ１３２に移る。

ステップＳ１３１では、現在の画面構成を保持することを決定して呼び出し元にリターンする。なお、第２エリアＡｒ２は第３エリアＡｒ３よりもランク格が高いことから、第２エリアＡｒ２には、ユーザにとって相対的に有用性が高い画面が表示される。したがって、第３エリアＡｒ３の表示画面の切替操作によってＣＰＵリソースが逼迫し、第２エリア画面の描画性能が損なわれる恐れがある場合には、当該切替要求を棄却することで、第２エリア画面の描画性能を保護することができる。つまり、このような構成によれば、より有用性が高い画面の描画を保護することができる。

ステップＳ１３２では、ディスプレイ２の画面構成として、第１エリアＡｒ１はオフ状態を継続させるとともに、第２エリアＡｒ２には現在表示中の画面の表示を継続させ、第３エリアＡｒ３には呼出画面を表示させることを決定してステップＳ１３３に移る。

ステップＳ１３３では、ステップＳ１２９と同様に、現在の第３エリアＡｒ３に表示中の画面を退避リストに登録して呼び出し元にリターンする。ただし、現在の第３エリアＡｒ３に表示中の画面が連動表示画面である場合には、退避リストに登録せずに呼び出し元にリターンする。

図１３のステップＳ１４０では、現在、第２エリアＡｒ２がオンとなっているか否かを判定する。なお、ステップＳ１４０の判定処理を実施する場合とは、アクティブ化するアプリの画面表示先が第１エリアＡｒ１となっている場合である。

第２エリアＡｒ２がオンとなっている場合にはステップＳ１４０が肯定判定されてステップＳ１４４に移る。一方、第２エリアＡｒ２がオフとなっている場合にはステップＳ１４０が否定判定されてステップＳ１４１に移る。

ステップＳ１４１では、現在、第３エリアＡｒ３がオンとなっているか否かを判定する。第３エリアＡｒ３がオンとなっている場合にはステップＳ１４１が肯定判定されてステップＳ１４３に移る。一方、第３エリアＡｒ３がオフとなっている場合にはステップＳ１４１が否定判定されてステップＳ１４２に移る。

ステップＳ１４２では、ディスプレイ２の画面構成として、第１エリアＡｒ１に呼出画面を表示し、第２エリアＡｒ２、第３エリアＡｒ３はオフ状態を継続させることを決定してステップＳ１４６に移る。

ステップＳ１４３では、所定の第１エリア切替要求破棄条件が成立しているか否かを判定する。第１エリア切替要求破棄条件は、ユーザによって入力された第１エリアＡｒ１の表示画面を切り替える指示を破棄して、現在のディスプレイ２の画面構成を保持する条件である。第１エリア切替要求破棄条件が成立する場合とは、現在第３エリアＡｒ３に描画負荷が高レベルに設定されている画面を表示してあって、かつ、今回第１エリアＡｒ１に新たに表示する呼出画面の描画負荷も高レベルに設定されている場合である。

第１エリア切替要求破棄条件が成立している場合にはステップＳ１４３が肯定判定されてステップＳ１４４に移る。一方、第１エリア切替要求破棄条件が成立していない場合にはステップＳ１４３が否定判定されてステップＳ１４５に移る。

ステップＳ１４４では、現在の画面構成を保持することを決定して呼び出し元にリターンする。つまり、ユーザによって入力された、第１エリアＡｒ１を画面表示先とするアプリの呼出指示を破棄する。

なお、第２エリアＡｒ２や第３エリアＡｒ３は、第１エリアＡｒ１よりもランク格が高いことから、第２エリアＡｒ２や第３エリアＡｒ３には、第１エリアＡｒ１よりもユーザにとっての有用性が高い画面が表示されている。したがって、例えば、第２エリアＡｒ２がオンとなっている場合には、第１エリアＡｒ１に所定のアプリ画面を表示するように要求する指示操作を棄却することで、より有用性が高い画面の表示を継続させることができる。第３エリアＡｒ３に高負荷な画面が表示されている場合も同様である。

ステップＳ１４５では、ディスプレイ２の画面構成として、第１エリアＡｒ１には呼出画面を表示させるとともに、第２エリアＡｒ２はオフ状態を継続させ、第３エリアＡｒ３には現在表示中の画面の表示を継続させることを決定し、ステップＳ１４６に移る。

ステップＳ１４６では、退避リストのデータ更新を実施して呼び出し元にリターンする。具体的には、退避リストに第１エリア画面が登録されている場合には、その第１エリア画面のデータを削除する。

次に、図１４のステップＳ１５０以降のフローについて述べる。なお、ステップＳ１０１からステップＳ１５０へ移る場合とは、ステップＳ１において受け付けた操作が、第２エリアＡｒ２用のアプリを終了させる操作、又は、第３エリアＡｒ３用のアプリを終了させる操作である場合である。

まず、ステップＳ１５０では、ユーザ操作に基づいて終了させるアプリが、第２エリアＡｒ２と第３エリアＡｒ３のどちらの表示エリアを画面表示先とするアプリであるかを判定する。今回終了させるアプリが第２エリアＡｒ２を画面表示先とするアプリである場合には、ステップＳ１６０に移る。一方、今回終了させるアプリが第３エリアＡｒ３を画面表示先とするアプリである場合には、ステップＳ１５１に移る。

ステップＳ１５１では、現在、第２エリアＡｒ２がオンとなっているか否かを判定する。第２エリアＡｒ２がオンとなっている場合にはステップＳ１５１が肯定判定されてステップＳ１５２に移る。一方、第２エリアＡｒ２がオフとなっている場合にはステップＳ１５１が否定判定されてステップＳ１５３に移る。

ステップＳ１５２では、現在の画面構成を保持することを決定して呼び出し元にリターンする。なお、他の態様として、ステップＳ１５２では第３エリアＡｒ３に現在表示中の画面の代わりに、第３エリアＡｒ３用の低負荷画面を配置することを決定して呼び出し元にリターンする態様としてもよい。そのような態様によれば、第３エリアＡｒ３に表示される画面が切り替わったことから、ユーザは、自分自身が入力した第３エリアＡｒ３に対応するアプリを終了させる操作が実行されたことを認識することができる。また、所定の低負荷画面を代替画面として表示することで、ＣＰＵ１１への負荷を抑制することができる。

ステップＳ１５３では、退避リストを参照し、退避中の第１エリア画面が存在するか否かを判定する。退避中の第１エリア画面が存在する場合には、ステップＳ１５３が肯定判定されてステップＳ１５５に移る。一方、退避中の第１エリア画面が存在しない場合には、ステップＳ１５３が否定判定されてステップＳ１５４に移る。

ステップＳ１５４では、第３エリアＡｒ３をオフに設定して、呼び出し元にリターンする。なお、第１エリアＡｒ１に現在表示中の画面の表示は継続される。また、このステップＳ１５４の処理と平行して、第３エリアＡｒ３用の画面を描画していたアプリによる画面描画処理は停止される。

ステップＳ１５５では、ディスプレイ２の画面構成として、第１エリアＡｒ１には退避中となっている第１エリア画面を復帰させるとともに、第３エリアＡｒ３はオフにすることを決定してステップＳ１５６に移る。なお、第２エリアＡｒ２はオフの状態が継続される。ステップＳ１５６では、退避リストからステップＳ１５５で復帰させることが決定された第１エリア画面のデータを除去し、呼び出し元にリターンする。

図１５のステップＳ１６０では、退避リストを参照し、退避中の第３エリア画面が存在するか否かを判定する。退避中の第３エリア画面が存在する場合には、ステップＳ１６０が肯定判定されてステップＳ１６１に移る。一方、退避中の第３エリア画面が存在しない場合には、ステップＳ１６０が否定判定されてステップＳ１６３に移る。

なお、ステップＳ１６０の判定処理を実施する場合とは、第２エリアＡｒ２と第３エリアＡｒ３がオンとなっている場合において、第２エリアＡｒ２用の画面を描画しているアプリを終了させるユーザ操作を受け付けた場合である。第２エリアＡｒ２と第３エリアＡｒ３がオンとなっている場合には、退避リストには第１エリア画面が登録されている。つまり、ステップＳ１６０を実施する場合の前提として、退避リストには第１エリア画面が登録されている。

ステップＳ１６１では、ディスプレイ２の画面構成として、第１エリアＡｒ１に第１エリアＡｒ１用の低負荷画面を表示させ、第２エリアＡｒ２をオフにし、第３エリアＡｒ３には退避させている第３エリア画面を復帰させることを決定してステップＳ１６２に移る。ステップＳ１６２では、退避リストから、ステップＳ１６１で復帰させることを決定した第３エリア画面のデータを削除して呼び出し元にリターンする。

ステップＳ１６３では、現在第３エリアＡｒ３に表示中の画面が連動表示画面であるか否かを判定する。現在第３エリアＡｒ３に表示中の画面が連動表示画面である場合には、ステップＳ１６３が肯定判定されてステップＳ１６４に移る。一方、現在第３エリアＡｒ３に表示中の画面が連動表示画面ではない場合には、ステップＳ１６３が否定判定されてステップＳ１６７に移る。

ステップＳ１６４では、ディスプレイ２の画面構成として、第１エリアＡｒ１には退避中の第１エリア画面を復帰させるとともに、第２エリアＡｒ２及び第３エリアＡｒ３をオフとすることを決定してステップＳ１６５に移る。

ステップＳ１６５では、退避リストから、ステップＳ１５５で復帰させることが決定された第１エリア画面のデータを削除してステップＳ１６６に移る。ステップＳ１６６では、第３エリアＡｒ３に表示している画面が連動表示画面であるか否かを示すフラグを初期化する。なお、フラグが初期化された状態とは、第３エリアＡｒ３に表示している画面は連動表示画面ではないことを示す状態とすれば良い。ステップＳ１６６での処理が完了すると、呼び出し元にリターンする。

ステップＳ１６７では、現在第３エリアＡｒ３に表示している画面は、描画負荷が高レベルな画面であるか否かを判定する。第３エリアＡｒ３に現在表示中の画面が、描画負荷が高レベルな画面である場合には、ステップＳ１６７が肯定判定されてステップＳ１６８に移る。一方、第３エリアＡｒ３に現在表示中の画面が、描画負荷が高レベルな画面ではない場合には、ステップＳ１６７が否定判定されてステップＳ１６９に移る。

ステップＳ１６８では、ディスプレイ２の画面構成として、第１エリアＡｒ１には第１エリアＡｒ１用の低負荷画面を配置し、第２エリアＡｒ２はオフにし、第３エリアＡｒ３には現在表示中の画面を継続して表示することを決定して、呼び出し元にリターンする。

ステップＳ１６９では、ディスプレイ２の画面構成として、第１エリアＡｒ１には退避させている第１エリア画面を復帰させるとともに、第２エリアＡｒ２はオフにし、第３エリアＡｒ３には現在表示中の画面の表示を継続させることを決定する。そして、ステップＳ１７０に移る。

ステップＳ１７０では、ステップＳ１６９で復帰させることを決定した第１エリア画面のデータを、退避リストから削除して呼び出し元にリターンする。

以上で述べた表示調停処理を実施することで、オン状態とする表示エリアと、そのオン状態とする表示エリアにおいて画像を表示させるアプリの組み合わせが決定される。換言すれば、操作受付部Ｆ１が受け付けたユーザ操作に対する応答として、アクティブ状態となるアプリが決定される。そして、アクティブ状態となるアプリが複数存在する場合には、エリア格が高い表示エリアに対応するアプリに対して優先的にＣＰＵリソースを割り当てる。

＜ＨＣＵ１による画面制御＞
次に、図１６〜図１８を用いて、上述したＨＣＵ１による画面構成の切替態様の例を３つ示す。まずは、図１６に示す切替態様の一例について述べる。

図１６の（Ａ）は、第２エリアＡｒ２及び第３エリアＡｒ３がオフであって、かつ、第１エリアＡｒ１にエネルギーモニタ画面を表示している状態を表している。つまり、エネルギーモニタアプリＡｐ１のみがアクティブとなっている状態を表している。エネルギーモニタアプリＡｐ１は、本実施形態においては、図７に示すように負荷レベルが高いアプリである。エネルギーモニタ画面を表示している状態において、仮にデジタルテレビアプリＡｐ２をアクティブ化するユーザ操作を受け付けた場合、表示調停部Ｆ２は、同図（Ｂ）に示すように、第３エリアＡｒ３にデジタルテレビ画面を表示する。また、第１エリアＡｒ１には、第１エリアＡｒ１用の低負荷画面を表示する。

これは、新たに呼び出されるデジタルテレビ画面もまた負荷レベルが高レベルの画面であって、かつ、呼び出される画面の表示先（ここでは第３エリアＡｒ３）のほうが、エネルギーモニタ画面を表示している第１エリアＡｒ１よりもエリア格が高いためである。なお、退避されたエネルギーモニタ画面は、退避リストに登録される。

その後、仮に第２エリアＡｒ２に表示する画面をオーディオ画面に切り替えるユーザ操作を受け付けた場合には、同図（Ｃ）に示すように、第２エリアＡｒ２には、ユーザの指示操作に対応するオーディオアプリＡｐ６の画面を表示させる。また、第１エリアＡｒ１に、退避させておいたエネルギーモニタ画面を復帰させる。エネルギーモニタ画面を復帰させる理由は、第２エリアＡｒ２の表示画面が、負荷レベルが低レベルに設定されている画面に遷移したからである。

また、図１６の（Ｂ）に示す画面構成において、デジタルテレビアプリＡｐ２を終了させるユーザ操作を受け付けた場合には、同図（Ｄ）に示すように第２エリアＡｒ２をオフにする。そして、第１エリアＡｒ１に、退避させておいたエネルギーモニタ画面を復帰させる。

次に、図１７に示す切替態様の一例について述べる。図１７の（Ａ）は、図１６の（Ａ）と同様に、エネルギーモニタアプリＡｐ１のみがアクティブとなっている状態を表している。このようにエネルギーモニタアプリＡｐ１だけがアクティブとなっている状態において、仮に後方監視アプリＡｐ３をアクティブ化する指示操作を受け付けた場合には、表示調停部Ｆ２は、第３エリアＡｒ３には、第３エリアＡｒ３用の低負荷画面を表示させ、第２エリアＡｒ２に呼出画面（つまり後方監視画面）を表示させる。また、エネルギーモニタ画面を退避リストに登録して第１エリアＡｒ１はオフにする。

その後、図１７の（Ｂ）に示す画面構成において、後方監視アプリＡｐ３を終了させるユーザ操作を受け付けた場合には、同図（Ｃ）に示すように第２エリアＡｒ２及び第３エリアＡｒ３をオフにする。また、第１エリアＡｒ１に、退避させておいたエネルギーモニタ画面を復帰させる。

次に、図１８に示す切替態様の一例について述べる。図１８の（Ａ）は、デジタルテレビアプリＡｐ２とブラウザアプリＡｐ５がアクティブな状態となっている状態の画面構成を表している。ブラウザアプリＡｐ５は、図７に示すように、画面表示先が第１エリアＡｒ１であって、負荷レベルが低レベルのアプリである。

図１８の（Ａ）に示すように、デジタルテレビアプリＡｐ２とブラウザアプリＡｐ５がアクティブな状態となっている状態において、仮に後方監視アプリＡｐ３をアクティブ化するユーザ操作を受け付けた場合、表示調停部Ｆ２は、第１エリアＡｒ１をオフにするとともに、第２エリアＡｒ２に呼出画面（つまり後方監視画面）を表示する。また、第３エリアＡｒ３には、第３エリアＡｒ３用の低負荷画面を表示させる。このとき、デジタルテレビアプリＡｐ２とブラウザアプリＡｐ５の画面が、退避リストに登録される。

その後、図１８の（Ｂ）に示す画面構成において、後方監視アプリＡｐ３を終了させるユーザ操作を受け付けた場合には、同図（Ｃ）に示すように第２エリアＡｒ２をオフにするとともに、第１エリアＡｒ１及び第３エリアＡｒ３に、退避させておいたデジタルテレビアプリＡｐ２とブラウザアプリＡｐ５のそれぞれの画面を復帰させる。

図１６〜図１８を用いて説明したように、上述した表示調停処理によれば、負荷レベルが高レベルに設定されているアプリの画面を、同時に複数表示させることはない。仮に、負荷レベルが高レベルに設定されているアプリの画面を表示中において、他の表示エリアに負荷レベルが高レベルに設定されている他のアプリの画面を表示させる場合には、相対的にエリア格が高い表示エリアを画面表示先とするアプリの動作を優先させる。

＜第１実施形態のまとめ＞
以上の構成によれば、負荷レベルが高レベルに設定されているアプリの画面を、同時に複数表示させることはない。仮に負荷レベルが高レベルに設定されているアプリの画面を表示中において、他の表示エリアに負荷レベルが高レベルに設定されている他のアプリの画面を表示させる場合には、相対的にエリア格が高い表示エリアを画面表示先とするアプリの動作を優先させる。

したがって、以上の構成によれば、複数のアプリ画面をディスプレイ２に表示する際にＣＰＵリソースが逼迫する恐れを低減できる。換言すれば、表示画面にフリーズや遅延等など処理落ちが生じてしまう恐れを低減することができる。

さらに、以上の構成では、第１エリアＡｒ１と第３エリアＡｒ３がオンとなっており、かつ、第２エリアＡｒ２がオフとなっている場合には、第３エリアＡｒ３用の画面を描画するアプリに対してＣＰＵリソースが割り当てられる。また、第２エリアＡｒ２と第３エリアＡｒ３がオンとなっている場合には、第２エリアＡｒ２用の画面を描画するアプリに対して優先的にＣＰＵリソースを割り当てる。

したがって、以上の構成によれば、相対的にドライバの目に止まりやすい位置に表示されている画面に、フリーズや遅延等の不具合が生じてしまう恐れを低減することができる。

また、第２エリアＡｒ２がオンとなる場合には、第１エリアＡｒ１をオフとする。これにより、第１エリアＡｒ１用の画面を描画するアプリに対してＣＰＵリソースを割り当てる必要はなくなる。その結果、複数の表示エリアに対応する画面の描画処理によってＣＰＵリソースが高負荷状態となり、処理落ち等が発生する恐れを低減できる。

以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、以降で述べる第２実施形態や、種々の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。

なお、前述の実施形態で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略する。また、構成の一部のみに言及している場合、他の部分については先に説明した実施形態の構成を適用することができる。

［第２実施形態］
以上では、表示調停部Ｆ２が、負荷レベルが高レベルに設定されているアプリの画面を同時に複数表示させないように画面構成を調整する態様を例示したが、これに限らない。第２実施形態として以下に示すように、負荷レベルが高レベルに設定されているアプリの画面を同時に複数表示させてもよい。ただし、この第２実施形態においても、相対的にエリア格が高い表示エリア用の画面を描画するアプリに対して優先的にＣＰＵリソースを割り当てるという思想は同じである。

なお、第２実施形態と第１実施形態との違いは、表示調停処理の内容である。したがって、以降では主として、第２実施形態の表示調停部Ｆ２が実施する表示調停処理について、図１９〜図２２に示すフローチャートを用いて述べる。図１９に示すフローチャートは、図８のステップＳ３に移った時に開始されればよい。

まず、ステップＳ２０１では、図８のステップＳ１で受け付けた操作が、画面呼出操作であるか否かを判定する。ステップＳ１で受け付けた操作が画面呼出操作である場合には、ステップＳ２０１が肯定判定されてステップＳ２０２に移る。一方、ステップＳ１で受け付けた操作が画面呼出操作ではない場合には、ステップＳ２０１が否定判定されて図２２のステップＳ２３０に移る。

ステップＳ２０２では、アプリ管理データＤｔを参照し、ユーザ操作に基づいてアクティブ化するアプリの画面表示先が第２エリアＡｒ２であるか否かを判定する。アクティブ化するアプリの画面表示先が第２エリアＡｒ２である場合にはステップＳ２０２が肯定判定されてステップＳ２０３に移る。一方、アクティブ化するアプリの画面表示先が第２エリアＡｒ２ではない場合にはステップＳ２０２が否定判定されて図２０のステップＳ２１０に移る。

ステップＳ２０３では、現在、第３エリアＡｒ３がオンとなっているか否かを判定する。第３エリアＡｒ３がオンとなっている場合にはステップＳ２０３が肯定判定されてステップＳ２０４に移る。一方、第３エリアＡｒ３がオンとなっていない場合にはステップＳ２０３が否定判定されてステップＳ２０６に移る。

ステップＳ２０４では、第１エリアＡｒ１に現在表示中の画面を、退避リストに登録してステップＳ２０５に移る。なお、本フロー開始時において、既に第２エリアＡｒ２もオンとなっている場合には、このステップＳ２０４は省略してステップＳ２０５に移ればよい。第２エリアＡｒ２もオンとなっている場合には、第１エリアＡｒ１はオフとなっているためである。

ステップＳ２０５では、ディスプレイ２の画面構成として、第１エリアＡｒ１をオフにし、第２エリアＡｒ２には呼出画面を表示し、第３エリアＡｒ３には現在表示中の画面の表示を継続させることを決定し、呼び出し元である表示制御処理にリターンする。

ステップＳ２０６では、ディスプレイ２の画面構成として、第１エリアＡｒ１をオフにするとともに、第２エリアＡｒ２には呼出画面を表示し、第３エリアＡｒ３には第３エリアＡｒ３用の低負荷画面を表示することを決定し、ステップＳ２０７に移る。ステップＳ２０７では、第３エリアＡｒ３に表示する画面が連動表示画面である旨を、フラグ等を用いて保持する。そして、呼び出し元にリターンする。

図２０のステップＳ２１０では、アプリ管理データＤｔを参照し、アクティブ化するアプリの画面表示先は第３エリアＡｒ３であるか否かを判定する。アクティブ化するアプリの画面表示先が第３エリアＡｒ３である場合にはステップＳ２１０が肯定判定されてステップＳ２１１に移る。一方、アクティブ化するアプリの画面表示先は第３エリアＡｒ３ではない場合にはステップＳ２１０が否定判定されて図２１のステップＳ２２０に移る。

ステップＳ２１１では、現在、第２エリアＡｒ２がオンとなっているか否かを判定する。第２エリアＡｒ２がオンとなっている場合にはステップＳ２１１が肯定判定されてステップＳ２１２に移る。一方、第２エリアＡｒ２がオンとなっていない場合にはステップＳ２１１が否定判定されてステップＳ２１３に移る。

ステップＳ２１２では、ディスプレイ２の画面構成として、第２エリアＡｒ２には、現在表示中の画面を継続して表示させるとともに、第３エリアＡｒ３には呼出画面を表示することを決定して、呼び出し元にリターンする。なお、第１エリアＡｒ１はオフのままとなる。

ステップＳ２１３では、ディスプレイ２の画面構成として、第１エリアＡｒ１には現在表示中の画面を表示させるとともに、第３エリアＡｒ３には呼出画面を表示することを決定して、呼び出し元にリターンする。なお、第２エリアＡｒ２はオフのままとなる。

図２１のステップＳ２２０では、現在、第２エリアＡｒ２がオンとなっているか否かを判定する。なお、ステップＳ２２０の判定処理を実施する場合とは、アクティブ化するアプリの画面表示先が第１エリアＡｒ１に設定されている場合である。

第２エリアＡｒ２がオンとなっている場合にはステップＳ２２０が肯定判定されてステップＳ２２１に移る。一方、第２エリアＡｒ２がオフとなっている場合にはステップＳ２２０が否定判定されてステップＳ２２２に移る。

ステップＳ２２１では、現在の画面構成を保持することを決定して呼び出し元にリターンする。この場合、第１エリアＡｒ１を画面表示先とするアプリをアクティブ化するユーザ操作をキャンセルされることになる。

ステップＳ２２２では、現在、第３エリアＡｒ３がオンとなっているか否かを判定する。第３エリアＡｒ３がオンとなっている場合にはステップＳ２２２が肯定判定されてステップＳ２２３に移る。一方、第３エリアＡｒ３がオフとなっている場合にはステップＳ２２２が否定判定されてステップＳ２２４に移る。

ステップＳ２２３では、ディスプレイ２の画面構成として、第１エリアＡｒ１には呼出画面を表示させるとともに、第３エリアＡｒ３には現在表示中の画面の表示を継続させることを決定して、呼び出し元にリターンする。なお、第２エリアＡｒ２はオフのままとなる。

ステップＳ２２４では、ディスプレイ２の画面構成として、第１エリアＡｒ１に呼出画面を表示させることを決定して呼び出し元にリターンする。なお、第２エリアＡｒ２及び第３エリアＡｒ３はオフのままとなる。

次に、図２２のステップＳ２３０以降のフローについて述べる。ステップＳ２０１からステップＳ２３０へ移る場合とは、ステップＳ１において受け付けた操作が、現在第２エリアＡｒ２用の画面を描画しているアプリを終了させる操作、又は、第３エリアＡｒ３用の画面を描画しているアプリを終了させる操作である場合である。

ステップＳ２３０では、ユーザ操作に基づいて終了させるアプリは、何れの表示エリアを画面表示先とするアプリであるかを判定する。今回終了させるアプリが第２エリアＡｒ２を画面表示先とするアプリである場合には、ステップＳ２３１に移る。一方、今回終了させるアプリが第３エリアＡｒ３を画面表示先とするアプリである場合には、ステップＳ２３４に移る。

ステップＳ２３１では、現在第３エリアＡｒ３に表示中の画面が、連動表示画面であるか否かを判定する。現在第３エリアＡｒ３に表示中の画面が連動表示画面である場合には、ステップＳ２３１が肯定判定されてステップＳ２３２に移る。一方、現在第３エリアＡｒ３に表示中の画面が連動表示画面ではない場合には、ステップＳ２３１が否定判定されてステップＳ２３３に移る。

ステップＳ２３２では、ディスプレイ２の画面構成として、第１エリアＡｒ１には退避させている第１エリア画面を復帰させるとともに、第３エリアＡｒ３をオフにすることを決定してステップＳ２３６に移る。

ステップＳ２３３では、ディスプレイ２の画面構成として、第１エリアＡｒ１には退避させている第１エリア画面を復帰させるとともに、第３エリアＡｒ３には現在表示中の画面の表示を継続させることを決定してステップＳ２３６に移る。

ステップＳ２３４では、現在第２エリアＡｒ２がオンとなっているか否かを判定する。第２エリアＡｒ２がオンとなっている場合にはステップＳ２３４が肯定判定されてステップＳ２３７に移る。一方、第２エリアＡｒ２がオフとなっている場合にはステップＳ２３４が否定判定されてステップＳ２３５に移る。

ステップＳ２３５では、第１エリアＡｒ１に、退避させていた第１エリア画面を復帰させることを決定してステップＳ２３６に移る。ステップＳ２３６では、ステップＳ２３２等において復帰させることが決定された第１エリア画面のデータ（例えば画面ＩＤ）を退避リストから削除して呼び出し元に戻る。

ステップＳ２３７では現在の画面構成を保持することを決定して呼び出し元にリターンする。なお、この場合は、第３エリアＡｒ３用の画面を描画しているアプリを終了させるためのユーザ操作をキャンセルすることになる。

＜第２実施形態におけるＨＣＵ１による画面制御＞
次に、図２３を用いて、第２実施形態におけるＨＣＵ１による画面構成の切替態様の一例を述べる。便宜上、一例として描画処理部１１１は最大フレームレートとして60fps分の性能を備えているものとする。

図２３の（Ａ）は、エネルギーモニタアプリＡｐ１のみがアクティブな状態を表している。このようにエネルギーモニタアプリＡｐ１のみがアクティブな状態においては、ＣＰＵリソースは十分にあるため、エネルギーモニタ画面は、予め規定されたフレームレート（例えば40fps）で更新される。

この図２３の（Ａ）は、エネルギーモニタアプリＡｐ１のみがアクティブな状態において、仮にデジタルテレビアプリＡｐ２をアクティブ化するユーザ操作を受け付けた場合、表示調停部Ｆ２は、同図（Ｂ）に示すように、第１エリアＡｒ１におけるエネルギーモニタ画面の表示は継続するとともに、第２エリアＡｒ２に呼出画面（つまりデジタルテレビ画面）を表示する。

このとき、表示調停部Ｆ２は、相対的にエリア格が高い表示エリア用の画面を描画するデジタルテレビアプリＡｐ２に対して、優先的にＣＰＵリソースを割り当てる。例えば、デジタルテレビ画面のフレームレートの規定値が30fpsである場合には、30fps分のＣＰＵリソースを割り当てる。そして、表示調停部Ｆ２は、余ったＣＰＵリソース（例えば30fps）をエネルギーモニタアプリＡｐ１に割り当てる。

以上の処理によって、相対的に優先度が高いデジタルテレビ画面は、予め規定されたフレームレート（ここでは30fps）で更新される。また、エネルギーモニタ画面は、30fps相当の速度で更新される。つまり、相対的にエリア格が低い表示エリア用の画面を描画するエネルギーモニタ画面は、規定されたフレームレートよりも低速で更新される。

また、他の例として、第２エリアＡｒ２と第３エリアＡｒ３がオンとなっている状態において第２エリアＡｒ２用の画面を描画するアプリに30fps相当のＣＰＵリソースを割り当てた場合には、第３エリアＡｒ３用の画面を描画するアプリには、残りの30fps分のＣＰＵリソースを割り当てる。そのような場合において、仮に第３エリアＡｒ３用の画面の規定フレームレートが60fps必要である場合には、規定されたフレームレートの半分に相当する30fpsで、第３エリアＡｒ３の画面は更新される。なお、本来60fps分のＣＰＵリソースが必要なアプリに対して30fps分のＣＰＵリソースを割り当てるということは、２Vsyncに１回描画処理を実施させることに相当する。

なお、相対的にエリア格が低い表示エリア用に残ったＣＰＵリソースが、当該表示エリア用の画面を描画するアプリが要求するＣＰＵリソースに対して十分である場合には、必ずしも相対的にエリア格が低い表示エリア用の画面の更新が低速になるとは限らない。例えば、第２エリアＡｒ２と第３エリアＡｒ３がオンとなっている状態において、第３エリアＡｒ３用に余っているＣＰＵリソースが30fps分であり、かつ、第３エリアＡｒ３用の画面の規定フレームレートが20fps必要だった場合には、第３エリアＡｒ３の画面は、規定された頻度で更新される。

以上で述べた態様によれば、負荷レベルが高レベルに設定されているアプリの画面を同時に複数表示しつつ、相対的にエリア格が高い表示エリア用の画面の更新は、規定されたフレームレートで実施することができる。つまり、相対的にユーザの目に止まりやすい位置に配置される画面において処理落ち等が発生する恐れを低減することができる。

［変形例１］
以上では、ディスプレイの表示画面を３つの表示エリアに分割して制御する態様を例示したが、これに限らない。ディスプレイの表示画面は、４つ以上の表示エリアに分割されて制御されてもよい。その場合も、複数の表示エリアに対して、ＣＰＵリソースを割り当てる上での優先順位（つまり、エリア格）を、適宜定義すればよい。

［変形例２］
以上では、表示制御装置の適用例の一例として、車載ディスプレイを制御対象とする態様を例示したが、これに限らない。家庭やオフィスに設けられたディスプレイや、携帯端末のディスプレイにも適用可能である。

１００ 車載システム、１ ＨＣＵ（表示制御装置）、２ ディスプレイ、３ 入力装置、４ 車載センサ、５ ＬＡＮ、Ｌ１ 第１レイヤ、Ｌ２ 第２レイヤ、Ａｒ１ 第１エリア、Ａｒ２ 第２エリア、Ａｒ３ 第３エリア、１１ ＣＰＵ、１１１ 描画処理部、１２ ＲＡＭ、１３ フラッシュメモリ、１５ Ｉ／Ｏ、Ｆ１ 操作受付部、Ｆ２ 表示調停部、Ｆ３ 表示画像生成部（表示処理部）、Ｆ４ アプリ管理部、Ａｐ１〜Ａｐ６ アプリケーションソフトウェア

Claims (5)

1. ディスプレイの表示画面を制御する表示制御装置であって、
   所定の入力装置を介して所定のアプリケーションソフトウェアの画面を前記ディスプレイに表示するためのユーザによる指示操作を受け付ける操作受付部（Ｆ１）と、
   前記操作受付部が受け付けた前記指示操作に基づいて、前記アプリケーションソフトウェアの画面として前記ディスプレイに表示するための画像であるアプリ画像を描画する描画処理部（１１１）と、
   前記描画処理部が生成した前記アプリ画像を用いて、前記ディスプレイにおける表示画面として表示される画像である表示用画像を生成し、当該生成した表示用画像を前記ディスプレイに表示する表示処理部（Ｆ３）と、を備え、
   前記表示画面には、複数の表示エリア（Ａｒ１、Ａｒ２、Ａｒ３）が設定されており、
   複数の前記表示エリアのそれぞれには、ユーザによる情報の見易さの順位を示すエリア格が予め割り当てられており、
   前記アプリケーションソフトウェアには、当該アプリケーションソフトウェアに対応する画面の表示先とする前記表示エリアが予め設定されており、
   前記描画処理部は、複数の前記表示エリアのうち、前記エリア格が高い前記表示エリアに表示するための前記アプリ画像を、前記エリア格が低い前記表示エリアに表示するための前記アプリ画像よりも優先的に描画し、
   前記ディスプレイの画面構成を調停する表示調停部（Ｆ２）を備え、
   前記アプリケーションソフトウェアには、そのアプリケーションソフトウェアに対応する前記アプリ画像を前記描画処理部が描画するための負荷が、高レベルであるか低レベルであるかを示す負荷レベルが設定されてあって、
   前記表示調停部は、
   負荷レベルが高レベルに設定されている前記アプリケーションソフトウェアの前記アプリ画像である高負荷アプリ画像を所定の前記表示エリアに表示させる前記指示操作を前記操作受付部が受け付けた場合において、当該高負荷アプリ画像を表示させる前記表示エリアよりも前記エリア格が高い他の前記表示エリアに既に他の前記高負荷アプリ画像を表示している場合には、今回受け付けた前記指示操作を破棄して、現在の画面構成を継続させることを特徴とする表示制御装置。
2. 請求項１において、
   前記表示調停部は、
   前記高負荷アプリ画像を所定の前記表示エリアに表示させる前記指示操作を前記操作受付部が受け付けた場合において、当該高負荷アプリ画像を表示させる前記表示エリアよりも前記エリア格が低い他の前記表示エリアに他の前記高負荷アプリ画像を表示している場合には、前記描画処理部に今回受け付けた前記指示操作に対応する前記アプリ画像を優先的に描画させるとともに、他の前記高負荷アプリ画像を表示している前記表示エリアには、負荷レベルが低レベルに設定されている所定の前記アプリ画像を表示させることを特徴とする表示制御装置。
3. 請求項１又は２において、
   複数の前記表示エリアとして、第１表示エリア、第２表示エリア、及び第３表示エリアを備え、
   前記表示処理部は、前記表示画面においてより前面に表示されるレイヤである第１レイヤと、前記第１レイヤの後方に配置されるレイヤである第２レイヤの、それぞれのレイヤに配置された画像を重ね合わせることで前記表示用画像を生成するものであって、
   前記第１表示エリアは、前記第２レイヤに設けられる前記表示エリアであり、
   前記第２表示エリアと前記第３表示エリアは、前記第１レイヤに設けられる前記表示エリアであり、
   前記第２表示エリアは、前記第１レイヤにおいて前記第３表示エリアよりもユーザにとって相対的に見やすい位置に配置されており、
   前記表示処理部は、
   前記第２表示エリアに表示するための画像が前記描画処理部によって生成されていない場合には、前記第２表示エリアを透過させることで前記第１表示エリアに配置されている画像のうち、当該第２表示エリアの後方に位置する部分を表示するとともに、
   前記第３表示エリアに表示するための画像が前記描画処理部によって生成されていない場合には、前記第３表示エリアを透過させることで前記第１表示エリアに配置されている画像のうち、当該第３表示エリアの後方に位置する部分を表示するものであって、
   前記描画処理部は、前記第２表示エリアに表示するための前記アプリ画像を描画する必要がある場合には、前記第２表示エリアに表示するための前記アプリ画像を、他の前記表示エリアに配置するための前記アプリ画像よりも優先的に描画することを特徴とする表示制御装置。
4. 請求項３において、
   前記表示調停部は、前記第２表示エリアに前記高負荷アプリ画像を表示している状態において、前記操作受付部が前記第３表示エリアに前記高負荷アプリ画像を表示させるユーザの指示操作を受け付けた場合には、今回受け付けた前記指示操作を破棄して、現在の画面構成を継続させることを特徴とする表示制御装置。
5. 請求項３又は４において、
   前記表示調停部は、前記第３表示エリアに前記高負荷アプリ画像を表示している状態において、前記第２表示エリアに他の前記高負荷アプリ画像を表示するための前記指示操作を受け付けた場合、前記第３表示エリアに表示している画像を、負荷レベルが低レベルに設定されている所定の前記アプリケーションソフトウェアの前記アプリ画像に変更することを特徴とする表示制御装置。

Images