(57)【要約】      （修正有）【課題】画像処理の終了時間をより確実に短縮させることができる制御装置、制御方法、及びプログラムを提供する。【解決手段】印刷データを受信する受信部２１１と、受信した印刷データに対して複数の画像処理を複数のＣＰＵ２３１〜２３３により分担して実行する複数の画像処理２３０と、を有する。第１レンダリング部の第１ＣＰＵに割当てられている第１印刷データの第１画像処理を第２レンダリング部の第１ＣＰＵに委譲させるか判定する。このとき、第２レンダリング部の第１ＣＰＵが次に実行予定の印刷データの第１画像処理を実行するまでに第１印刷データの第１画像処理を完了できる場合、委譲させると判定する。【選択図】図２
2016107570.tif 000002
【特許請求の範囲】
【請求項１】
印刷データを受信する受信手段と、
前記受信手段により受信した印刷データに対して複数の画像処理をそれぞれ異なる処理部により順に実行する画像処理手段と、
一の画像処理手段に割当てられている第１印刷データの第１画像処理を、他の画像処理手段に委譲させるか判定する判定手段と、
を有し、  前記判定手段は、他の画像処理手段において前記第１画像処理が割当てられている処理部が、次に実行予定の印刷データの第１画像処理を実行するまでに前記第１印刷データの第１画像処理を完了できる場合、委譲させると判定することを特徴とする制御装置。
【請求項２】
前記判定手段は、一の画像処理手段の第１画像処理の平均処理時間及び他の画像処理手段の第１画像処理の平均待ち時間に基づいて、委譲させるか判定することを特徴とする請求項１に記載の制御装置。
【請求項３】
前記判定手段は、一の画像処理手段の第１画像処理の平均処理時間が他の画像処理手段の第１画像処理の平均待ち時間以下であった場合、委譲させると判定することを特徴とする請求項２に記載の制御装置。
【請求項４】
前記判定手段は、一の画像処理手段の第１画像処理の平均処理時間、他の画像処理手段の第１画像処理の平均待ち時間、及び前記一の画像処理手段と前記他の画像処理手段との間のデータの転送時間に基づいて、委譲させるか判定することを特徴とする請求項１〜３のいずれか１項に記載の制御装置。
【請求項５】
各画像処理手段の各処理部の処理状況を管理する管理手段をさらに備え、
前記判定手段は、前記管理手段により管理された処理状況に基づいて委譲させるか判定することを特徴とする請求項１〜４のいずれか１項に記載の制御装置。
【請求項６】
前記管理手段は、各処理部の処理状況を管理する管理テーブルを備え、各処理部の所定単位の処理が終了する毎に前記管理テーブルを更新することを特徴とする請求項５に記載の制御装置。
【請求項７】
各処理部は、それぞれ実行する画像処理の内容が予め決められていることを特徴とする請求項１〜６のいずれか１項に記載の制御装置。
【請求項８】
前記画像処理手段により処理済みのデータに基づいて印刷を実行する印刷部をさらに備えることを特徴とする請求項１〜７のいずれか１項に記載の制御装置。
【請求項９】
印刷データに対して複数の画像処理をそれぞれ異なる処理部により順に実行する画像処理手段を複数備える装置の制御方法であって、
第１画像処理手段に割当てられている第１印刷データの第１画像処理を、他の画像処理手段に委譲させるか判定する判定工程を備え、
前記判定工程では、他の画像処理手段において前記第１画像処理が割当てられている処理部が、次に実行予定の印刷データの第１画像処理を実行するまでに前記第１印刷データの第１画像処理を完了できる場合、委譲させると判定することを特徴とする制御方法。
【請求項１０】
請求項１〜８のいずれか１項に記載の制御装置の各手段としてコンピュータを機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の画像処理部を有する画像処理手段の制御装置、制御方法、及びプログラムに関するものである。
【背景技術】
【０００２】
プリンタなどに代表される印刷装置において、印刷ジョブを複数のプロセッサに割り当て、該複数のプロセッサにおいて並行して画像生成を行うことで画像処理時間を短縮する方法が知られている。この際、各プロセッサに割り当てられる処理内容が異なるため、処理量が多い処理内容を割り当てられたプロセッサに比べて処理量が少ない処理内容を割り当てられたプロセッサの稼働時間が減ってしまう。
【０００３】
そこで、特許文献１には、印刷ジョブの画像データの処理を複数の処理プロセス（以下、ステージともいう）に分割し、複数のプロセッサでそれぞれ処理させる画像形成装置において、複数のプロセッサ間で処理分担を変更することが開示されている。具体的には、あるステージの処理を終えたプロセッサに対し他のステージの処理を割り振ることで、割り振られた処理量が少ないプロセッサも休止することなく稼働させる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−３２６３０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１では、各プロセッサが複数種の画像処理を実行しており、特定の画像処理を実行するプロセッサを複数用いる場合については言及されていなかった。なお、特許文献１に記載の方法を、特定の画像処理を実行するプロセッサを複数有する画像処理部を複数用いる画像処理装置に適用した場合、画像処理を高速化できないことがある。画像処理部を複数用いる際に、あるステージの処理を終えたプロセッサに対し他のステージの処理を割り振った場合の問題点について図１５及び図１６を用いて説明する。
【０００６】
図１５（ａ）は印刷ジョブの画像処理を複数のプロセッサ（ＣＰＵ）で並行に行う画像処理装置の構成図である。ここではＣＰＵ数は３つとし、それぞれ画像補正ステージ、リッピング（ＲＩＰ）ステージ、面付けステージを処理することとする。この画像処理装置に複数印刷ジョブを投入した際の各ＣＰＵの処理内容を図１５（ｂ）に示す。図１５（ｂ）に示すように、ジョブＡ，Ｂ，Ｃが画像処理装置に投入され、それぞれのジョブのステージ１（画像補正），２（ＲＩＰ），３（面付け）をＣＰＵ１，２，３で処理する。具体的には、まず、ジョブＡのステージ１の処理をＣＰＵ１で行い、処理結果がバッファに保持される。ＣＰＵ２は、ステージ１の処理結果をバッファから取得し、ステージ２の処理を行う。ＣＰＵ１は、ジョブＡのステージ１の処理を終えた後、ジョブＢのステージ１の処理を開始する。このように、３つのＣＰＵが異なるジョブの処理を並行して行うことで、処理時間の高速化を図ることができる。ここで、各ＣＰＵにおける各ステージの処理時間が図１５（ｂ）のようにＣＰＵ間でばらつきが無い場合は、ジョブが投入され続ける限りＣＰＵは動作し続けることが可能である。しかしながら、実際には印刷ジョブを構成する要素はジョブによって異なるため、各ステージの処理にかかる時間はジョブによって異なる。
【０００７】
図１６（ａ）はステージ１の処理がステージ２やステージ３よりも重いジョブが３つ投入された時の動作例である。ＣＰＵ２は、ステージ１の処理が終わるまではステージ２の処理を開始することができないため、ジョブＡのステージ２の処理を終えた後、ジョブＢのステージ２の処理を開始するまでに稼働していない時間が存在する。ここで、図１６（ａ）の画像処理装置１と並列に動作する画像処理装置２が存在する場合について説明する。図１６（ｂ）は、画像処理装置２にステージ２の処理が重いジョブが３つ投入された場合の動作例を示す図である。画像処理装置２でも画像処理装置１と同様に、ＣＰＵ６は、ジョブＤのステージ３の処理を終えた後、ジョブＥのステージ３の処理を開始するまでに稼働していない時間が存在する。そこで、稼働していないＣＰＵに対して未処理のステージの処理を割り振ると、図１７のようになる。
【０００８】
図１７は、画像処理装置１のＣＰＵ２がジョブＡの処理を終えた後の非稼働時に、画像処理装置２のＣＰＵ５が行う予定だったジョブＦの処理を割り振った際の画像処理装置１、２の動作例である。図１７に示すように、画像処理装置２は処理負荷の高いステージ２の処理を画像処理装置１に割り振ることによって、処理の終了時間が早くなる。一方、画像処理装置１はＣＰＵ２の非稼働時間に画像処理装置２のステージ２の処理を行う。これにより、本来ＣＰＵ１がジョブＢの処理を完了したあと開始するはずだったＣＰＵ２のジョブＢの処理が、割り込まれたジョブＦの処理により開始が遅れ、結果としてジョブＢの終了時間が割り込まれなかった場合に比べて遅延してしまう。このように、あるタイミングで手が空いているＣＰＵに単純に処理を割り振るだけでは、従来行われる予定だった処理の開始が遅れることになってしまう。特に、描画完了したラスターイメージを印刷しながら次の印刷のための画像処理を行う印刷装置では、予定通りに処理が終わらなくなると印刷装置がストップしてしまい、生産性を著しく下げてしまう。
本発明はこのような事情に鑑み、画像処理の終了時間をより確実に短縮させることができる制御装置、制御方法、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明に係る制御装置は、印刷データを受信する受信手段と、前記受信手段により受信した印刷データに対して複数の画像処理をそれぞれ異なる処理部により順に実行する画像処理手段と、一の画像処理手段に割当てられている第１印刷データの第１画像処理を、他の画像処理手段に委譲させるか判定する判定手段と、を有し、前記判定手段は、他の画像処理手段において前記第１画像処理が割当てられている処理部が、次に実行予定の印刷データの第１画像処理を実行するまでに前記第１印刷データの第１画像処理を完了できる場合、委譲させると判定する。
【発明の効果】
【００１０】
以上説明したように、本発明によれば、複数の画像処理をそれぞれ異なる処理部により順に実行する画像処理手段を複数用いる場合、画像処理の終了時間をより確実に短縮させることができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態に係る印刷装置のハードウェアの構成を示す図である。
【図２】本発明の一実施形態に係る印刷装置における制御の構成を説明するためのブロック図である。
【図３】本発明の一実施形態に係る印刷装置における制御の構成を説明するためのブロック図である。
【図４】本発明の一実施形態に係るコントローラ部の処理を示すフローチャートである。
【図５】本発明の一実施形態に係る各レンダリング部の処理を示すフローチャートである。
【図６】本発明の一実施形態に係る負荷監視部の処理を示すフローチャートである。
【図７】本発明の一実施形態に係る処理負荷管理テーブルの例を示す図である。
【図８】本発明の一実施形態に係る処理委譲判定の第一処理を示すフローチャートである。
【図９】本発明の一実施形態に係る第一動作例を示す図である。
【図１０】本発明の一実施形態に係る第二動作例を示す図である。
【図１１】本発明の一実施形態に係る第三動作例を示す図である。
【図１２】本発明の一実施形態に係る印刷装置における制御の構成を説明するためのブロック図である。
【図１３】本発明の一実施形態に係るレンダリング部間通信速度情報例である。
【図１４】本発明の一実施形態に係る処理委譲判定の第二処理を示すフローチャートである。
【図１５】複数のプロセッサで複数のステージ処理を並行して処理する例を説明する図である。
【図１６】複数のプロセッサ間で複数のステージ処理を並行して処理する際の状況を示す図である。
【図１７】複数のプロセッサ間でステージ処理を委譲した際の状況を示す図である。
【発明を実施するための形態】
【００１２】
（実施形態１）
以下、添付図面を参照して本発明の好適な実施の形態を例示的に詳細に説明する。但し、この実施の形態に記載されている構成要素の相対配置、装置形状等は、あくまで例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。
【００１３】
本実施形態では、制御装置を含む印刷装置を例に挙げて説明する。本明細書において「印刷装置」とは、印刷機能に特化した専用機に限らず、印刷機能とその他の機能を複合した複合機や、記録紙上に画像やパターンを形成する製造装置等も含むものとする。
【００１４】
図１は、本実施形態に係る印刷装置のハードウェアの構成を示す概略ブロック図である。印刷装置１００は、図１に示すように、中央処理装置（ＣＰＵ）１０１と、ＲＯＭ１０２と、ＲＡＭ１０３と、通信部１０４と、記録部１０５と、操作部１０６と、表示部１０７とを有する。なお、これらはシステムバスを介して互いに接続されている。
【００１５】
ＣＰＵ１０１は、ＲＯＭ１０２に記憶されているプログラムに従って、ＲＡＭ１０３、通信部１０４、記録部１０５、操作部１０６及び表示部１０７を制御する。
【００１６】
ＲＯＭ１０２は、ＣＰＵ１０１が実行する各種制御プログラムや印刷装置１００の各種動作に必要な固定データを格納する。例えば、印刷装置１００の記録（印刷）処理を実行するプログラムを記憶する。
【００１７】
ＲＡＭ１０３は、ＣＰＵ１０１の作業エリアとして用いられたり、種々の受信データの一時格納領域として用いられたり、各種設定データを記憶させたりする。外部装置１０から送られてくる記録データ（印刷データ）、即ち、記録部１０５で記録（印刷）される記録データは、ＲＡＭ１０３に一時的に記憶される。
【００１８】
通信部１０４は、外部装置と印刷装置１００との通信を制御する。
記録部（印刷部）１０５は、後述するプリンタエンジン部を有する。
操作部１０６は、電源ボタン、リセットボタンなどの各種ボタンを含み、ユーザが印刷装置１００を操作する際に使用される。
【００１９】
表示部１０７は、例えば、タッチパネルの液晶ディスプレイで構成され、印刷装置１００の状態や各種設定を表示する。なお、ユーザは、表示部１０７を介して、各種設定の入力を行うこともできる。表示部１０７は、操作指示の受付や装置状態の表示を行う。
【００２０】
図２は、本実施形態に係る印刷装置における制御の構成を説明するためのブロック図である。実施形態１に係る印刷装置１００は、コントローラ部２１０と、プリンタエンジン２２０と、複数のレンダリング部２３０とを有する。これらの構成要素は、それぞれ、例えば、図１の印刷装置１００に実装されるハードウェアとして実現されてもよいし、ハードウェアとソフトウェアと協働して実現されてもよい。
【００２１】
データに基づき画像を印刷する印刷装置１００は、ＨｏｓｔＰＣ３００からＰＤＬ等の印刷ジョブデータ（印刷データともいう）を受信する。そして、印刷装置１００は、印刷ジョブデータに画像処理をすることにより画像データ（ビットマップデータ）を生成し、画像データに基づいて、カット紙や連続紙などの印刷メディアに印刷を行う。
【００２２】
コントローラ部２１０は、外部装置から印刷データ等を受信する受信部２１１と、受信した印刷データを保存するスプーラ２１２と、レンダリング部と通信する通信部２１３と、を有する。コントローラ部２１０は、ＨｏｓｔＰＣ３００から受信した印刷ジョブデータ１０２を受信部２１１において受信し、スプーラ２１２に保持する。一旦保持した印刷ジョブデータに対し、印刷ジョブの内容やユーザーインターフェース部１４０からの指示に基づきコマンドやデータを作成する。また、コントローラ部２１０は、作成したコマンドやデータを、画像装置通信部２１３を介して後述するレンダリング部２３０に送信する。そして、レンダリング部２３０からレンダリング後のビットマップデータを受け取ると、受け取ったビットマップデータをプリンタエンジン部２２０へ送信する。
【００２３】
レンダリング部２３０は、コントローラ部２１０が作成したコマンドやデータに基づきレンダリング処理を行い、印刷用ビットマップデータの生成を行う。印刷装置１００は、レンダリング部２３０を複数有し、各レンダリング部２３０は、一以上のプロセッサ（本実施形態では、ＣＰＵ）を有する。図２に示すように、レンダリング部２３０は、３つのＣＰＵ（ＣＰＵ２３１〜２３３）と、ＣＰＵの前段に設けられるバッファと、ＣＰＵの後段に設けられるバッファと、負荷監視部２３４と、処理負荷管理テーブル２３５と、通信コントロール部２３６とを有する。本実施形態では、各レンダリング部２３０は、いずれも同じ構成を有するものとするが、一部が異なる構成となっていてもよい。
【００２４】
本実施形態では、レンダリング部２３０の各ＣＰＵ（ＣＰＵ２３１〜２３３）は、図１に示すＣＰＵ１０１とは異なるものであり、図示しないＲＡＭに記憶されているプログラムに従って、画像処理（描画処理ともいう）を実行する。具体的には、ＣＰＵの前段に配置されたバッファから入力データを取得し、特定の処理（ステージ処理）を行い、後段のバッファに処理結果を出力する。ここで、ステージ処理とは、例えば、画像補正処理、ＲＩＰ処理、面付け処理である。なお、ＲＩＰ処理は、画像補正処理済みのデータに実行することができ、面付け処理は、ＲＩＰ処理済みのデータの実行することができる。本実施形態では、各ＣＰＵに、それぞれ異なるステージの処理を分担させる（割当てる）。本実施形態では、詳細は後述するが、レンダリング部１のＣＰＵ２３１に画像補正処理、ＣＰＵ２３２にＲＩＰ処理、ＣＰＵ２３３に面付け処理を実行させる。
【００２５】
ＣＰＵから出力された処理結果は、次のステージの入力データとなり、次のステージを処理するＣＰＵが、上記と同様にステージ処理を行う。印刷ジョブデータに対して、全てのステージ処理を行うと、ビットマップデータが生成される。なお、本実施形態では、ＣＰＵ２３１の画像補正処理の処理結果は、ＣＰＵ２３２の入力データとなり、ＣＰＵ２３２のＲＩＰ処理の処理結果は、ＣＰＵ２３３の入力データとなり、ＣＰＵ２３３の画像補正処理の処理結果は、ビットマップデータとなる。
【００２６】
負荷監視部２３４は、各ＣＰＵの処理の開始タイミング及び処理の終了タイミングを監視し、その結果を処理負荷管理テーブル２３５に記録する。すなわち、各プロセッサの所定単位（本実施形態では、ジョブ単位）の処理が開始する毎に開始タイミングを更新し、各プロセッサの所定単位（本実施形態では、ジョブ単位）の処理が終了する毎に、処理の終了タイミングを更新する。
【００２７】
通信コントロール部２３６は、コントローラ部２１０から印刷ジョブデータを受信し、ＣＰＵ２３１の前段に設けられるバッファに保持する。さらに、通信コントロール部１２３６は、ＣＰＵ２３３の処理結果をＣＰＵ２３３の後段に設けられるバッファから取得し、ビットマップデータとしてコントローラ部２１０へ送信する。さらに、本実施形態では、通信コントロール部２３６は、特定のＣＰＵの処理結果をそのＣＰＵの後段に設けられるバッファから取得し、他のレンダリング部２３０に送信し、特定のＣＰＵのステージ処理を他のレンダリング部のＣＰＵに委譲する。処理ステージの委譲方法の詳細については後述する。
【００２８】
プリンタエンジン部２２０は、記録部１０５が備える。プリンタエンジン部２２０は、例えば、インクジェット方式の記録ヘッド、各カラーインク、キャリッジ及び記録紙の搬送機構を含む記録ユニットと、記録データに基づいて記録用パルスを生成するＡＳＩＣを含む電気回路と、を含む。プリンタエンジン部２２０は、ビットマップデータを受信すると、ビットマップデータに基づいて、画像をシートに印刷する。印刷の際には、プリンタエンジン部２２０は、ビットマップデータに対してプリンタエンジンの扱う色空間であるＣＭＹＫ等への変換処理や、必要に応じて２値化処理等を行う。
【００２９】
ＨｏｓｔＰＣ３００は、印刷装置１００の外部に接続され、印刷装置１００に印刷を行わせるための印刷ジョブデータの供給源となる装置であり、種々の印刷ジョブのオーダーを発行する。ＨｏｓｔＰＣ３００は、本実施形態では、汎用のパーソナルコンピュータ（ＰＣ）としたが、これに限定されず、他のタイプのデータ供給装置としてもよい。他のタイプのデータ供給装置としては、画像をキャプチャーして画像データを生成する画像キャプチャー装置がある。画像キャプチャー装置は、原稿上の画像を読取って画像データを生成するリーダ（スキャナ）、ネガフィルムやポジフィルムを読取って画像データを生成するフィルムスキャナなどである。また、画像キャプチャー装置の他の例として静止画を撮影してデジタル画像データを生成するデジタルカメラ、動画を撮影して動画像データを生成するデジタルビデオもある。その他、ネットワーク上にフォトストレイジを設置したり、着脱可能な可搬性メモリを挿入するソケットを設けたりし、フォトストレイジや可搬性メモリに格納された画像ファイルを読み出して画像データに生成して印刷するものとしてもよい。また、汎用的なＰＣに代え、印刷装置専用の端末とするなど、種々のデータ供給装置としてもよい。これらのデータ供給装置は印刷装置１００の構成要素としてもよいし、印刷装置１００の外部に接続した別の装置としてもよい。
【００３０】
図４のフローチャートを用いて、本実施形態に係るコントローラ部２１０の処理の流れを説明する。図４のフローチャートは、図１のＣＰＵ１０１が、ＲＯＭ１０２に格納されている制御プログラムをＲＡＭ１０３にロードし、それを実行することにより行われる処理の流れを示す。
【００３１】
まず、ステップＳ３０１で、ＨｏｓｔＰＣ３００から印刷ジョブデータを受信すると、スプーラ２１２に印刷ジョブデータを保持する。
【００３２】
次に、ステップＳ３０２で、あるレンダリング部２３０に対して印刷ジョブデータを送信してレンダリング処理を依頼する。レンダリング部２３０が複数ある場合に、いずれのレンダリング部に処理を依頼する（割り振る）かを決定する方法は種々あり、特に限定されないが、本実施形態では、処理を依頼した時間が最も古いレンダリング部２３０に対して処理を依頼する。例えば、レンダリング部２３０が２つある場合、４つの印刷ジョブをレンダリング部１、２、１、２の順で処理を依頼する。なお、他の割り振り方法としては、各レンダリング部２３０の処理性能を監視して最も処理性能が高いものに割り振る方法、各レンダリング部２３０の処理負荷を監視して最も処理負荷が低いものに割り振る方法が挙げられる。
【００３３】
ステップＳ３０３で、コントローラ部２１０は、通信部２１３を介してビットマップデータを受信する（ステップＳ３０３）。具体的には、レンダリング部２３０は、依頼された印刷ジョブデータをレンダリングしてビットマップデータを生成し、通信コントロール部２３６を介してコントローラ部２１０へ送信すると、これを受信する。
【００３４】
ステップＳ３０４で、受信したビットマップデータをプリンタエンジン部２２０へ送信する。プリンタエンジン部２２０は受信したビットマップデータを紙などの印刷メディア（記録媒体ともいう）に印刷する。
【００３５】
ステップＳ３０５で、ＨｏｓｔＰＣ３００から印刷ジョブデータが投入されているか判定する。印刷ジョブが投入されていた場合（Ｓ３０５でＹｅｓ）、ステップＳ３０１へ戻り、上述した処理を繰り返す。投入されていなければコントローラ部２１０は処理を終了し、次の印刷ジョブデータの投入に備える。なお、Ｓ３０２〜Ｓ３０４の実行中に印刷ジョブデータが投入された場合は、並行してＳ３０１〜Ｓ３０４の処理を実行する。
【００３６】
レンダリング部２３０の処理の流れを図４のフローチャートを用いて説明する。図４のフローチャートは、図１のＣＰＵ１０１が、ＲＯＭ１０２に格納されている制御プログラムをＲＡＭ１０３にロードし、それを実行することにより行われる処理の流れを示す。
【００３７】
ステップＳ４０１で、コントローラ部２１０から印刷ジョブデータを受信するとバッファに保持する。
【００３８】
レンダリング部２３０は、一以上のプロセッサ（ＣＰＵ）を有しており、一つの印刷ジョブデータに対して各ステージの処理を行う。レンダリング部が持つＣＰＵの数分、以下に示すＳ４０３〜Ｓ４０９を繰り返す。なお、各ＣＰＵで行うステージ処理はＣＰＵ毎に異なるが、処理の流れは同じである。
【００３９】
まず、ステップＳ４０３で、処理負荷管理テーブル２３５を参照し、レンダリング部２３０で実行予定のステージ処理を処理委譲するかを判断する。ここで、処理委譲とは、一のレンダリング部に割当てられた処理を他のレンダリング部に受け渡して実行させることを指す。なお、ステップＳ４０３の本処理の詳細は別途図を用いて説明する。
【００４０】
ステップＳ４０４で、ステップＳ４０３において、ステージ処理を処理委譲したか判定する。処理委譲したと判定した場合（Ｓ４０４でＹｅｓ）、ステップ４０２へ戻って、次のＣＰＵのステージ処理に進む。例えば、画像補正ステージの処理を他のレンダリング部に委譲した場合（Ｓ４０４でＹｅｓ）、ＲＩＰ処理のループに進む（Ｓ４０２）。処理委譲していないと判定した場合（Ｓ４０４でＮｏ）、ステップＳ４０５へ進む。  ステップＳ４０５で、処理負荷の監視を開始する。この処理については、詳細は後述する。
【００４１】
ステップＳ４０６で、ＣＰＵは、前段に配備されたバッファからデータを取得する。このデータは、最初のステージ処理を行うＣＰＵの場合、コントローラ部２１０から受信した印刷ジョブデータであり、以降のステージ処理を行うＣＰＵの場合は、前段のＣＰＵがステージ処理を行った後のデータである。
【００４２】
ステップＳ４０７で、ＣＰＵは、バッファから取得したデータに対して、それぞれのＣＰＵに割当てられたステージ処理を行う。
【００４３】
ステップＳ４０８で、ＣＰＵは処理結果を後段に配備されたバッファに保持させる。
【００４４】
ステップＳ４０９で、処理負荷の監視を終了する。
【００４５】
ステップＳ４０２からステップＳ４１０までが一つのＣＰＵの処理の流れである。このようにＣＰＵは、自身のステージ処理を終えたら、該ステージ処理を含む印刷ジョブデータの全ステージ処理が終わるのを待たずに、次の印刷ジョブデータのステージ処理を行うことができる。これにより、複数の印刷ジョブを複数ＣＰＵで並行して処理できる。最後のステージ処理が終了すると、ビットマップデータが生成され、ステップＳ４１１で該ビットマップデータをコントローラ部２１０へ送信する。
【００４６】
ステップＳ４１２でコントローラ部２１０から新たな印刷ジョブデータが投入されているか判定する。新たな印刷ジョブデータが投入されていたら（ステップＳ４１２でＹｅｓ）、ステップＳ４０１へ戻って、上述した処理を繰り返す。新たな印刷ジョブデータが投入されていなければ（ステップＳ４１２でＮｏ）、レンダリング部２３０は、処理を終え次の印刷ジョブデータの投入に備える。
【００４７】
図６は、負荷監視部２３４の処理の流れを示すフローチャートである。図６のフローチャートは、ＣＰＵ１０１が、ＲＯＭ１０２に格納されている制御プログラムをＲＡＭ１０３にロードし、それを実行することにより行われる処理の流れを示す。図６に示すフローチャートは、図４のステップＳ４０５及びＳ４０９の処理を詳細に説明するためのものである。
【００４８】
ステップＳ５０１で、ＣＰＵ２３１の処理が開始した時刻を取得し、処理負荷監視テーブル２３５に保存する。ステップＳ５０２でＣＰＵ２３１の処理が終了した時刻を取得し、処理負荷監視テーブル２３５に保存する。ステップＳ５０３で処理負荷管理テーブル２３５を更新し、処理を終了する。具体的には、後述する通り、各ＣＰＵの処理ステージの平均処理時間、平均待ち時間、処理委譲希望フラグ、他ジョブ処理可能フラグを更新する。なお、負荷監視部２３４は各ＣＰＵの処理が開始・終了する毎に同様の処理を繰り返す。
【００４９】
ここで、図７を用いて、処理管理テーブルの情報管理について説明する。図７（ａ）は、処理負荷管理テーブル２３５の一例を示す図である。本実施形態では、図７（ｂ）に示すように、レンダリング部２３０は、三つのＣＰＵ１、２、３（それぞれ２３１，２１４，２１５）を持ち、それぞれ画像補正、リッピング（ＲＩＰ）、面付けのステージ処理を行う。一つの印刷ジョブに対して、上述した三つのステージ処理を全て行うことで、ビットマップデータが完成する。処理負荷管理テーブル２３５は、各ＣＰＵが処理する処理ステージ、その処理ステージの平均処理時間、平均待ち時間、処理委譲希望フラグ、他ジョブ処理可能フラグを有する。
【００５０】
平均処理時間は、ある印刷ジョブに対する各ステージの処理時間の平均値である。具体的には、ステップＳ５０１により取得された処理開始時間及びＳ５０２により取得された処理終了時間に基づいて特定される処理時間を平均した値である。例えば、二つの印刷ジョブに対してＣＰＵ１の画像補正ステージでかかった処理時間がそれぞれ７０ｍｓｅｃ、９０ｍｓｅｃであった場合、ＣＰＵ１の平均処理時間は８０ｍｓｅｃとなる。本実施形態では、これまでに投入された全ジョブの平均を算出するようにしたが、これに限定されず、近傍数ジョブの平均を算出するようにしても良い。ここで、例えば、アルバムを連続して印刷する商業用印刷装置や、カタログを連続して印刷する商業用印刷装置の場合、同程度のデータサイズのジョブが連続して投入されることが多い。したがって、平均処理時間を特定することにより、これから処理予定のデータの処理時間を予測することができる。
【００５１】
平均待ち時間は、印刷ジョブ毎の待ち時間の平均である。具体的には、前回の印刷ジョブのステップＳ５０２で取得したステージ処理終了時間と、今回の印刷ジョブのステップＳ５０１で取得したステージ処理開始時間の差の平均時間である。例えば、ＣＰＵ１の画像補正ステージが最初の印刷ジョブの処理を終了した時間が１２時００分で、次のジョブの処理を終了した時間が１２時００分１０秒だったとすると、待ち時間は１０秒となる。上述した通り、例えば、アルバムを連続して印刷する商業用印刷装置や、カタログを連続して印刷する商業用印刷装置の場合、同程度のデータサイズのジョブが連続して投入されることが多い。したがって、平均待ち時間を特定することにより、これから処理予定のデータの処理開始までの時間を予測することができる。
【００５２】
処理委譲希望フラグは、該ＣＰＵの平均処理時間が他のＣＰＵの平均処理時間に比べて設定した閾値以上に大きい場合にＯＮとなるフラグである。他のＣＰＵに処理を委譲する際の通信やデータコピーのコストを鑑み、平均処理時間にそれほどの差が無い場合は処理を委譲しないほうが速度的に有利な場合がある。このため、本実施形態では、閾値を設けることにより、平均処理時間の差が小さい場合は、委譲しないようにする。閾値は、レンダリング部２３０に予め設定されていてもよいし、ユーザが設定してもよいし、レンダリング部２３０に予め設定された値を変更できるようにしてもよい。なお、本実施形態においては、通信やデータコピーのコストはないものとし、閾値＝０とする。
【００５３】
他ジョブ処理可能フラグは、該ＣＰＵの平均待ち時間が他のＣＰＵの平均待ち時間に比べて設定した閾値以上に大きい場合にＯＮとなるフラグである。なお、閾値を設けている理由は、処理委譲希望フラグの場合と同様に、処理を委譲しないほうが速度的に有利な場合があるためである。ただし、本実施形態では、通信やデータコピーのコストはないものとし、閾値＝０とする。
【００５４】
図７（ａ）では、ＣＰＵ１の平均処理時間（８０ｍｓｅｃ）は、ＣＰＵ２の平均処理時間（２０ｍｓｅｃ）やＣＰＵ３の平均処理時間（２０ｍｓｅｃ）との差が６０ｍｓｅｃであり、閾値０よりも大きい。したがって、処理委譲希望フラグはＯＮとなる。また、ＣＰＵ２の平均待ち時間（３０ｍｓｅｃ）は、ＣＰＵ１の平均待ち時間（０ｍｓｅｃ）との差が３０ｍｓｅｃであり、閾値０よりも大きい。したがって、他ジョブ処理可能フラグはＯＮとなる。
【００５５】
図８は、処理委譲判定の処理の流れを示すフローチャートである。図８のフローチャートは、ＣＰＵ１０１が、ＲＯＭ１０２に格納されている制御プログラムをＲＡＭ１０３にロードし、それを実行することにより行われる処理の流れを示す。図８は、図４のステップＳ４０３の処理を詳細に説明するためのものである。
【００５６】
ステップＳ７０１で、処理負荷管理テーブル２３５から、各ＣＰＵの平均処理時間の情報、各ＣＰＵの処理委譲希望フラグの情報を取得する。
【００５７】
ステップＳ７０２で、各ＣＰＵのステージ処理の処理委譲希望フラグがＯＮか判定する。処理委譲希望フラグがＯＦＦであれば（Ｓ７０２でＮｏ）、処理委譲判定を終了する。処理委譲希望フラグがＯＮであれば（Ｓ７０２でＹｅｓ）、ステップＳ７０３で他のレンダリング部２３０の通信コントロール部２３６に問い合わせを行い、Ｓ７０４へ進む。具体的には、他のレンダリング部２３０に対して、処理委譲希望フラグがＯＮのＣＰＵと同じステージを処理するＣＰＵの他ジョブ処理可能フラグがＯＮであるか問合せをする。なお、問合せを受けた他のレンダリング部２３０は、処理負荷管理テーブル２３５から他ジョブ処理可能フラグの情報を取得する。
【００５８】
ステップＳ７０４で、対象のレンダリング部２３０において処理委譲希望フラグがＯＮの処理ステージと同じステージを処理するＣＰＵであって、他ジョブ処理可能フラグがＯＮのＣＰＵが存在するか判定する。他のレンダリング部２３０において一つも上述したＣＰＵが存在しない場合（ステップＳ７０４でＮｏ）、処理委譲判定を終了する。他のレンダリング部２３０において該当するＣＰＵが存在した場合（ステップＳ７０４でＹｅｓ）、ステップＳ７０５へ進む。
【００５９】
ステップＳ７０５で、他のレンダリング部２３０において、委譲希望フラグがＯＮの処理が割当てられているＣＰＵが、次に実行予定の印刷データの処理を実行するまでに、委譲されるデータの処理を完了できるか判定する。本実施形態では、処理委譲希望フラグがＯＮとなっているＣＰＵのステージ処理の平均処理時間が、他のレンダリング部２３０の処理可能フラグがＯＮとなっているＣＰＵのステージ処理の平均待ち時間以下か判定する。平均処理時間が平均待ち時間より長い場合は、元々そのレンダリング部２３０に割当てられていたステージ処理が遅れる可能性があるためである。
【００６０】
平均処理時間が平均待ち時間より大きいと判定された場合（Ｓ７０５でＮｏ）、処理委譲判定を終了する。
【００６１】
平均処理時間が平均待ち時間以下と判定された場合（Ｓ７０５でＹｅｓ）、Ｓ７０６で、他のレンダリング部２３０の処理可能フラグがＯＮとなっているＣＰＵにステージ処理を委譲する。具体的には、処理委譲希望フラグがＯＮとなっているＣＰＵでステージ処理をする予定であったデータをバッファから取得し、通信コントロール部２３６を介して他のレンダリング部２３０に送信する。図示しないが、他のレンダリング部２３０では送信されたデータを該ＣＰＵの前段のバッファに保持し、ステージ処理を行った後、処理前のデータを送信したレンダリング部２３０へ処理後のデータを返信する。
【００６２】
ステップＳ７０７で、他のレンダリング部２３０で処理を終えたデータ、すなわち、他のレンダリング部２３０から返信された処理後のデータを受け取り、該ＣＰＵの後段のバッファに格納する。
【００６３】
最後に、ステップＳ７０８で処理負荷管理テーブル２３５を更新し、処理委譲希望フラグをＯＦＦにする。
【００６４】
処理を委譲する際の実際の動作例を図３及び図９を用いて説明する。
【００６５】
図３は、本実施形態に係る図１のブロック図をより具体的に表した図である。図３に示すように、本実施形態では、印刷装置１００はレンダリング部を二つ有するものとし、それぞれレンダリング部１（２３０ａ）、レンダリング部２（２３０ｂ）とする。レンダリング部１（２３０ａ）は、三つのＣＰＵ１，２，３（それぞれ２３１ａ、２３２ａ、２３３ａ）を有し、それぞれ画像補正、リッピング（ＲＩＰ）、面付けの各ステージ処理を行うものとする。一つの印刷ジョブに対して三つのステージ処理を行うことで、ビットマップデータが完成する。レンダリング部２（２３０ｂ）もレンダリング部１（２３０ａ）と同様、三つのＣＰＵ４，５，６（それぞれ２３１ｂ、２３２ｂ、２３３ｂ）を有するものとし、それぞれ画像補正、リッピング（ＲＩＰ）、面付けの各ステージ処理を行うものとする。また、ＣＰＵ１の後段に設けられるバッファは、ＣＰＵ２の前段に設けられるバッファを兼ねており、ＣＰＵ２の後段に設けられるバッファは、ＣＰＵ３の前段に設けられるバッファを兼ねている。
【００６６】
図３における印刷装置１００のレンダリング部以外の構成は図１と同じであるため、説明を省略する。
【００６７】
図９は、図３の構成におけるレンダリング部１（２３０ａ）およびレンダリング部２（２３０ｂ）の図中に示した時点（図中、「現在時点」と表記する）での処理状況を示す例である。図９（ａ）は、横軸は処理時間を示し、処理時間が進むにつれ各ＣＰＵでどのジョブを処理中かを示している。なお、現在時点までは、実際に処理にかかった時間であり、現在時点以降の時間は予想時間である。
【００６８】
レンダリング部１（２３０ａ）には、ジョブＡ，Ｂ，Ｃが投入されており、現在ＣＰＵ１（２３１ａ）ではジョブＣの１ステージ目を、ＣＰＵ２（２３２ａ）ではジョブＢの２ステージ目を処理中である。ジョブＡ，Ｂ，Ｃはいずれもステージ１の処理に時間がかかっており、ステージ２，３の処理は、それに引きずられて次の処理開始までに間がある。すなわち、図中の「現在時点」までに、ＣＰＵ２（２３２ａ），３（２３３ａ）が稼働していない時間が存在する。
【００６９】
レンダリング部２（２３０ｂ）には、ジョブＤ，Ｅ，Ｆ，Ｇが投入されており、現在ＣＰＵ４（２３１ｂ）ではジョブＧの１ステージ目を、ＣＰＵ５（２３２ｂ）ではジョブＥの２ステージ目を処理中である。ジョブＤ，Ｅ，Ｆ，Ｇはいずれもステージ２の処理に時間がかかっており、ステージ３の処理は、それに引きずられて次の処理開始までに間があり、ＣＰＵ６（２３３ｂ）が稼働していない時間が存在する。この「現在時点」での処理負荷管理テーブルを図９（ｂ）に示す。レンダリング部１（２３０ａ）はＣＰＵ１（２３１ａ）の平均処理時間がＣＰＵ２（２３２ａ），３（２３３ａ）に比べて長いため処理委譲希望フラグがＯＮになっている。ＣＰＵ２（２３２ａ）はＣＰＵ１（２３１ａ）の処理時間に引きずられてステージ処理の開始時間が遅れて平均待ち時間が長くなっているため、他ジョブ処理可能フラグがＯＮになっている。レンダリング部２（２３０ｂ）はＣＰＵ５（２３３ｂ）の平均処理時間がＣＰＵ４（２３１ｂ），６（２３２ｂ）に比べて長いため処理委譲希望フラグがＯＮになっている。また、ＣＰＵ６（２３３ｂ）は、図示していないがジョブＤ以前に受け付けていたジョブも、ジョブＤ同様にステージ３の処理時間が比較的短かったため、平均待ち時間が長くなっている。したがって、他ジョブ処理可能フラグがＯＮになっている。
【００７０】
この時点でレンダリング部２（２３０ｂ）で処理を実行中のジョブＧについて考える。まず、ジョブＧが投入された時点で図５のステップＳ４０３においてＣＰＵ４（２３１ｂ）の画像補正の処理委譲判定を行う。図８のステップＳ７０２で、図９（ｂ）に示すレンダリング部２の処理負荷管理テーブル２３５の画像補正の処理委譲希望フラグを確認する（Ｓ７０１）。レンダリング部２の処理負荷管理テーブル２３５の画像補正の処理委譲希望フラグはＯＦＦのため（Ｓ７０２でＮｏ）、処理委譲の判定処理を終え、処理委譲することなくレンダリング部２（２３０ｂ）で処理を行う。次に、ジョブＧのＣＰＵ５（２３２ｂ）のＲＩＰ処理の処理委譲判定を行う。図８のステップＳ７０２で、ＲＩＰ処理の処理委譲希望フラグを確認し（Ｓ７０１）、処理委譲希望フラグがＯＮのため（Ｓ７０２でＹｅｓ）ステップＳ７０３に進む。レンダリング部１（２３０ａ）ではＲＩＰ処理の他ジョブ処理可能フラグがＯＮになっているため（Ｓ７０４でＹｅｓ）、ステップＳ７０５に進む。処理を委譲しようとしているＣＰＵ５（２３２ｂ）の平均処理時間は５０ｍｓｅｃで、委譲処理を受け付けようとしているレンダリング部１（２３１ａ）のＣＰＵ２（２３２ａ）の平均待ち時間３０ｍｓｅｃよりも大きい。よって、処理委譲不可と判定し、処理委譲判定を終了する。したがって、ジョブＧのＲＩＰ処理は委譲することなく、レンダリング部２（２３０ｂ）で処理することとなる。
【００７１】
仮に、ジョブＧのＲＩＰ処理をレンダリング部１（２３０ａ）に委譲した場合について説明する。この場合、レンダリング部１（２３０ａ）において、ジョブＣの画像補正処理が終わった段階でも委譲されたジョブＧのＲＩＰ処理が終わらず、ジョブＧが委譲されていない場合に即座に処理可能だったジョブＣのＲＩＰ処理が待たされることになる。ジョブＣのＲＩＰ処理が遅れることによりコントローラ部２１０からプリンタエンジン部２２０へのジョブＣのビットマップデータの供給に遅れが生じ、プリンタエンジン部２２０の動作を止めてしまう恐れがある。これに対し、本実施形態では、Ｓ７０５の判断により、ビットマップデータの供給に遅れが生じるのを抑制することができる。
【００７２】
図１０は、図３の構成におけるレンダリング部１（２３０ａ）およびレンダリング部２（２３０ｂ）の図中に示した時点（図中、「現在時点」と表記する）での処理状況を示す例である。図１０（ａ）は、横軸は処理時間を示し、処理時間が進むにつれ各ＣＰＵでどのジョブを処理中かを示している。なお、現在時点までは、実際に処理にかかった時間であり、現在時点以降の時間は予想時間である。
【００７３】
図１０（ａ）では、レンダリング部１（２３０ａ）には、ジョブＡ，Ｂ，Ｃが投入されており、現在、ジョブＣの１ステージ目を処理中である。ジョブＡ，Ｂ，Ｃは、いずれも画像補正の処理に時間がかかっているのは、図９に示す例と同じであるが、画像補正の平均処理時間が図９よりも長い。レンダリング部２（２３０ｂ）にはジョブＤ，Ｅ，Ｆ，Ｇが投入されており、その状況は図９と同様であるため、説明を省略する。この「現在時点」での処理負荷管理テーブルを図１０（ｂ）に示す。レンダリング部１（２３０ａ）は、ＣＰＵ１（２３１ａ）の平均処理時間（画像補正の平均処理時間）がＣＰＵ２（２３２ａ），３（２３３ａ）に比べて長いため処理委譲希望フラグがＯＮになっている。ＣＰＵ２（２３２ａ）はＣＰＵ１（２３１ａ）の処理時間に引きずられてステージ処理の開始時間が遅れて平均待ち時間が長くなっているため、他ジョブ処理可能フラグがＯＮになっている。レンダリング部２（２３０ｂ）は、ＣＰＵ５（２３３ｂ）の平均処理時間がＣＰＵ４（２３１ｂ），６（２３２ｂ）に比べて長いため処理委譲希望フラグがＯＮになっている。また、ＣＰＵ６（２３３ｂ）は、平均待ち時間が長くなっているため、他ジョブ処理可能フラグがＯＮになっている。
【００７４】
この「現在時点」でのレンダリング部２（２３０ｂ）のジョブＧのＲＩＰ処理の委譲について説明する。図８のステップＳ７０５までは、図９のときと同じ処理フローとなるため説明を省略する。ステップＳ７０５において、処理を委譲しようとしているＣＰＵ５（２３２ｂ）の平均処理時間は５０ｍｓｅｃで、委譲処理を受け付けようとしているレンダリング部１（２３３ａ）のＣＰＵ２（２３２ａ）の平均待ち時間６０ｍｓｅｃよりも小さい。よって、処理委譲が可能と判断しレンダリング部２（２３０ｂ）のジョブＧのＲＩＰステージ処理をレンダリング部１（２３０ａ）に処理委譲する。
【００７５】
ジョブＧのＲＩＰ処理の処理委譲を行って所定時間を経過した時点の処理状況の例を図１１に示す。図１１では、ジョブＧのＲＩＰ処理は、画像補正処理が終わったと同時にレンダリング部２（２３０ｂ）からレンダリング部１（２３０ａ）に送信されている。レンダリング部１（２３０ａ）のＣＰＵ２（２３２ａ）では、ジョブＢのＲＩＰ処理を終えた後、委譲されたジョブＧのＲＩＰ処理を行い、処理結果をレンダリング部２（２３０ｂ）に返す。その後ＣＰＵ２（２３２ａ）ではジョブＣのＲＩＰ処理を行っている。このとき、ジョブＣのＲＩＰ処理の開始時間は、ジョブＧの処理を委譲されなかった場合と同じであり、ジョブＣの終了時間が遅延していない。レンダリング部２（２３０ｂ）ではジョブＧのＲＩＰ処理をレンダリング部１（２３０ａ）に委譲したため、ＣＰＵ５（２３３ｂ）では、ジョブＦのＲＩＰ処理を終えた後にジョブＨのＲＩＰ処理を開始することが可能となる。また、ジョブＧの処理委譲によりジョブＧのＲＩＰ処理終了時間が早まりＣＰＵ６（２３３ｂ）においてジョブＧの面付け処理開始時間が早まる。結果として、ＣＰＵ６（２３３ｂ）は、無稼働時間が短縮され、ジョブＧの終了時間が早まる。
【００７６】
本実施形態では、複数の画像処理部（レンダリング部１及びレンダリング部２）を備え、一の画像処理部（レンダリング部１）が有するＣＰＵ２に、異なる画像処理部（レンダリング部２）の処理を実行させる。具体的には、処理委譲を希望するＣＰＵ（画像処理部）の平均処理時間と、他ジョブの処理を可能とするＣＰＵ（画像処理部）の平均待ち時間を比較して、処理の委譲をするか判定する。これにより、他ジョブの処理を可能とするＣＰＵ（画像処理部）に元々割当てられていたジョブの印刷データの終了時間を変更させることなく、処理委譲を希望するＣＰＵを備えるレンダリング部の処理時間を短縮することができる。
【００７７】
本実施形態では、上述した通り、他ジョブの処理を可能とするＣＰＵ（画像処理部）に元々割当てられていたジョブの印刷データの終了時間を変更させることなく、処理委譲を希望するＣＰＵを備えるレンダリング部の処理時間を短縮することができる。すなわち、他の画像処理部に処理を渡さない場合に比べて、他の画像処理部に処理を委譲した画像処理の終了時間を早くすることができ、受信した印刷ジョブデータの全体の処理速度を向上させることができる。
【００７８】
（実施形態２）
本実施形態では、画像処理部（レンダリング部）間のデータの通信速度を考慮して、委譲を行うか判定する。なお、本実施形態のハードウェアの構成は実施形態１と同様であるため、ハードウェアの構成については説明を省略する。なお、図１２を用いて、本実施形態について説明するが、図３と同様の構成については、図３と同一番号を付し、説明を省略する。
【００７９】
実施形態２に係る印刷装置１００は、コントローラ部２１０と、プリンタエンジン２２０と、複数のレンダリング部２３０とを有する。コントローラ部２１０及びプリンタエンジン２２０は、実施形態１と同様であるため、説明を省略する。
【００８０】
レンダリング部１２３０は、コントローラ部１２１０が作成したコマンドやデータに基づきレンダリング処理を行い、印刷用ビットマップデータの生成を行う。印刷装置１００は、レンダリング部１２３０を複数有し、各レンダリング部１２３０は、一以上のＣＰＵを有する。図３に示すように、レンダリング部１２３０は、３つのＣＰＵ（ＣＰＵ２３１〜２３３）と、バッファと、バッファと、負荷監視部２３４と、処理負荷管理テーブル２３５と、通信コントロール部１２３６と、を有する。なお、３つのＣＰＵ（ＣＰＵ２３１〜２３３）、バッファ、負荷監視部２３４、及び処理負荷管理テーブル２３５は、実施形態１と同様であるため説明を省略する。また、本実施形態では、各レンダリング部１２３０は、いずれも同じ構成を有するものとするが、一部が異なる構成となっていてもよい。
【００８１】
本実施形態に係る通信コントロール部１２３６は、レンダリング部間の通信速度情報１２３７を保持する。また、通信コントロール部１２３６は、コントローラ部２１０から印刷ジョブデータを受信し、バッファに保持する。また、通信コントロール部１２３６は、ＣＰＵ２３３の処理結果をＣＰＵ２３３の後段のバッファから取得し、ビットマップデータとしてコントローラ部２１０へ送信する。さらに、本実施形態では、通信コントロール部２３６は、特定のＣＰＵの処理結果をそのＣＰＵの後段に設けられるバッファから取得し、他のレンダリング部１２３０に送信し、特定のＣＰＵのステージ処理を他のレンダリング部のＣＰＵに委譲する。
【００８２】
図１４のフローチャートを用いて、本実施形態の処理委譲の判定処理について説明する。図１３のフローチャートは、ＣＰＵ１０１が、ＲＯＭ１０２に格納されている制御プログラムをＲＡＭ１０３にロードし、それを実行することにより行われる処理の流れを示す。図１３は、図４のステップＳ４０３の処理を詳細に説明するものである。
【００８３】
ステップＳ７０４までは、図８と同じ処理フローのため説明を省略する。Ｓ７０４でＹｅｓと判定された場合、ステップＳ１３０１で、処理委譲希望フラグがＯＮのステージ処理のデータサイズをバッファから取得する。本実施形態では、データサイズの取得は、処理委譲希望フラグがＯＮのステージ処理の前段のステージ処理が終わった処理済データのサイズを取得する。なお、データサイズの取得はこれに限定されず、前段のステージ処理が終わっていなかった場合でも、近傍数ジョブの該処理委譲希望フラグがＯＮのステージ処理のデータサイズの平均値を取得してもよい。
【００８４】
次に、ステップ１３０２で、通信コントロール部１２３６は、レンダリング部間の通信速度情報１２３７を参照し、他のレンダリング部１２３０に該データサイズを送信する際に必要な転送時間を計算する。なお、本実施形態では、転送時間を計算するものとしたが、これに限定されず、バッファ等に保持されたデータサイズと転送時間のテーブルに基づいて転送時間を取得してもよい。レンダリング部間の通信速度情報１２３７の例を図１３に示す。図１３は、レンダリング部２（１２３０ｂ）の通信コントロール部２３６ｂが他のレンダリング部を通信相手とした場合の通信速度情報１２３７を示す。図１３に示すように、レンダリング部２は、通信相手がレンダリング部１（１２３０ａ）である場合、通信速度は１００Ｍｂｐｓである。なお、自身と通信することは無いため、レンダリング部２（１２３０ｂ）との通信速度情報は無い。本実施形態では、レンダリング部１２３０を二つ有する印刷装置１００を例に挙げて説明するが、印刷装置１００が３以上のレンダリング部１２３０を有する場合や、さらに他のレンダリング部を用いる場合は、各レンダリング部に対する通信速度情報を保持する。ステップＳ１３０２では、図１２に記載のようなレンダリング部間の通信速度情報１２３７ｂ用いてデータ転送時間を算出する。例えば、処理委譲しようとしているステージ処理のデータサイズが１０ＭＢｙｔｅだった場合、レンダリング部２とレンダリング部１で該データを送受信するのにかかる時間は、
１０ＭＢｙｔｅ／１００Ｍｂｐｓ／８ｂｉｔ×通信回数２＝０．０２５ｓｅｃ＝２５ｍｓｅｃとなる。なお、通信回数が２回とは、１回目は処理前のデータの送信であり、２回目は処理後の印刷データの受信である。
【００８５】
ステップＳ１３０３で、処理委譲希望フラグがＯＮのＣＰＵのステージ処理の平均処理時間とステップＳ１３０２で導出した転送時間との合計時間が、他のレンダリング部の他ジョブ処理可能フラグがＯＮとなっているステージ処理の平均待ち時間以下か判定する。例えば、レンダリング部１（１２３０ａ）、２（１２３０ｂ）が、図１０に示した処理状況である場合、処理を委譲しようとしているＣＰＵ５（２３２ｂ）の平均処理時間は５０ｍｓｅｃで、データ転送時間は上述の通り２５ｍｓｅｃである。これらの和である７５ｍｓｅｃは、委譲処理を受け付けようとしているＣＰＵ２（２３２ａ）の平均待ち時間６０ｍｓｅｃよりも大きい（Ｓ１３０３でＮｏ）。したがって、処理委譲は不可と判定し処理委譲の判定を終了する。この場合、ジョブＧのＲＩＰ処理は委譲することなく、レンダリング部２（１２３０ｂ）で処理することとなる。仮に、ジョブＧのＲＩＰ処理をレンダリング部１（１２３０ａ）に委譲した場合、レンダリング部１（１２３０ａ）において、ジョブＣの画像補正処理が終わった段階でも委譲されたジョブＧのＲＩＰ処理は実行中となる。したがって、ジョブＧが委譲されなかった場合に即座に処理可能だったジョブＣのＲＩＰ処理が待たされることになってしまう。ジョブＣのＲＩＰ処理が遅れることによりコントローラ部２１０からプリンタエンジン部２２０へのジョブＣのビットマップデータの供給に遅れが生じ、プリンタエンジン部２２０の動作を止めてしまう恐れがある。これに対し、本実施形態では、Ｓ１３０３の判断により、ビットマップデータの供給に遅れが生じるのを抑制することができる。本実施形態では、複数のレンダリング部が処理中の複数のステージの処理状況を管理し、複数のレンダリング部間で、処理負荷が重い処理を他の処理に影響しない範囲で委譲しあうことで処理速度を向上させることができる。その結果、ユーザは、より高速にレンダリング結果を得ることができる。
【００８６】
（他の実施形態）
本発明は上述した実施形態に限定されるものではない。例えば、上述した実施形態では、レンダリング部は、印刷装置が全て備えるものとしたが、一部又は全部を印刷装置に接続される外部装置が備えるものとしてもよい。この場合は、処理負荷管理テーブルでは、通信速度も考慮して閾値を設定するようにすればよい。
【００８７】
上述した実施形態では、複数の印刷ジョブ（印刷ジョブデータ）を受信した場合に複数のレンダリング部にジョブを振り分ける場合を例に挙げて説明したが、これに限定されるものではなく、複数の処理単位を有する印刷ジョブデータの画像処理にも適用できる。具体的には、例えば、１つの印刷ジョブデータが複数ページを有している場合、印刷ジョブデータを分割して、各レンダリング部にそれぞれ数ページずつ振り分けてもよい。
【００８８】
また、上述した実施形態では、処理委譲を希望するレンダリング部のステージの平均処理時間と、他ジョブの処理が可能なレンダリング部のステージの平均待ち時間に基づいて、処理委譲をするか判定したが、これに限定されるものではない。受け渡し先となるレンダリング部において、その受け渡し先となるレンダリング部のＣＰＵの処理の空き時間に、処理委譲を希望するレンダリング部から受け渡したいデータの処理ができるか判定できるものであればよい。すなわち、受け渡し先となるレンダリング部のＣＰＵが既に割当てられている実行予定の印刷データの処理を開始するまでに、受け渡したい印刷データの処理が完了できるか判定できるものであればよい。例えば、処理委譲したいデータのデータサイズに基づいて、受け渡し先となるレンダリング部における処理委譲したいデータの処理時間を算出し、受け渡し先となるレンダリングの次の処理開始までの時間と比較してもよい。この場合は、受け渡し先となるレンダリングの次の処理開始までの時間も、例えば、処理中のデータのデータサイズに基づいて算出してもよい。
【００８９】
また、上述した実施形態では、各レンダリング部がＣＰＵを複数備えるものとしたが、これに限定されず、各ステージ処理を実行できるステージ処理部であればよい。例えば、ステージ処理専用のハードウェアであってもよいし、ＧＰＵ等であってもよい。
【００９０】
また、上述した実施形態では、各レンダリング部２３０が負荷監視部２３４及び処理負荷管理テーブル２３５を備えるものとしたが、これに限定されるものではない。例えば、複数のレンダリング部２３０で共通の負荷監視部２３４としてもよいし、複数のレンダリング部で共通の処理負荷管理テーブル２３５としてもよい。
【００９１】
上述した実施形態では、レンダリング部を２つ用いる場合について説明したが、３つ以上のレンダリング部を用いる場合についても同様である。
【００９２】
上述した実施形態では、ＣＰＵ１０１が処理委譲の判定を行うものとしたが、これに限定されず、各レンダリング部が判定を行う手段を備えていてもよい。
【００９３】
上述した実施形態は、以下の処理を実行することによっても実現される。すなわち、上述した実施形態の機能を実現するソフトウエア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。また、プログラムは、１つのコンピュータで実行させても、複数のコンピュータを連動させて実行させるようにしてもよい。また、上記した処理の全てをソフトウエアで実現する必要はなく、処理の一部または全部をＡＳＩＣ等のハードウェアで実現するようにしてもよい。また、ＣＰＵも１つのＣＰＵで全ての処理を行うものに限らず、複数のＣＰＵが適宜連携をしながら処理を行うものとしてもよい。
【符号の説明】
【００９４】
１００  印刷装置
１０１  ＣＰＵ
１０２  ＲＯＭ
１０３  ＲＡＭ
２１０  コントローラ部
２２０  プリンタエンジン部
２３０  レンダリング部
【図１】
2016107570.tif 000003
【図２】
2016107570.tif 000004
【図３】
2016107570.tif 000005
【図４】
2016107570.tif 000006
【図５】
2016107570.tif 000007
【図６】
2016107570.tif 000008
【図７】
2016107570.tif 000009
【図８】
2016107570.tif 000010
【図９】
2016107570.tif 000011
【図１０】
2016107570.tif 000012
【図１１】
2016107570.tif 000013
【図１２】
2016107570.tif 000014
【図１３】
2016107570.tif 000015
【図１４】
2016107570.tif 000016
【図１５】
2016107570.tif 000017
【図１６】
2016107570.tif 000018
【図１７】
2016107570.tif 000019