(57)【要約】【課題】  画像形成装置に関して、パフォーマンスの劣化を抑えながらも、効率的にソフトウェアレンダリングを行う。【解決手段】  描画コマンドから中間データを生成し、ハードウェアによるレンダリングが可能であるかを判断し、ハードウェアによるレンダリングができない場合に、ソフトウェアによるレンダリングを行い、かつ、中間データの生成によるメモリ消費量に基づいてソフトウェアによるレンダリングで使用するメモリサイズを切り替える。【選択図】  図６
2006289899.tif 000002
【特許請求の範囲】
【請求項１】
描画コマンドに従ってラスタイメージに展開可能な中間データを生成する中間データ生成手段と、
中間データを解釈し、画像データとしてラスタイメージを出力する第一のレンダリング手段と、
中間データを解釈し、画像データとしてラスタイメージを出力する第二のレンダリング手段と、
第一のレンダリング手段が中間データをレンダリング可能かどうか判定するレンダリング判定手段と、
第一のレンダリング手段のレンダリングが成功したかどうかを判定するレンダリング結果判定手段と、
第一のレンダリング手段では中間データをレンダリングできないと判定された場合や、第一のレンダリング手段によるレンダリングが失敗した場合に、第二のレンダリング手段によるレンダリングに切り替えるレンダリング切替手段と、
中間データの生成によるメモリ消費量を算出するメモリ管理手段とを備え、
レンダリング判定手段の判定とメモリ管理手段が算出するメモリ消費量に従いレンダリングに使用するメモリのサイズを切り替えることを特徴とする画像形成装置。
【請求項２】
中間データ生成中に、第二のレンダリング手段が必要とするメモリを予め確保することを特徴とする請求項１の画像形成装置。
【請求項３】
中間データ生成中に、レンダリング判定手段によって、第一のレンダリング手段によるレンダリングが失敗する可能性があると判定された場合、第二のレンダリング手段のためのメモリを予め確保することを特徴とする請求項１の画像形成装置。
【請求項４】
メモリを確保する際に、第二のレンダリング手段が必要とする最小限のメモリを確保することを特徴とする請求項２，請求項３の画像形成装置。
【請求項５】
メモリを確保する際に、予め設定されたサイズのメモリを確保することを特徴とする請求項２，請求項３の画像形成装置。
【請求項６】
中間データ生成中に、レンダリング判定手段によって、第一のレンダリング手段によるレンダリングが不可能と判定された場合、第二のレンダリング手段のレンダリングに必要なメモリを予め確保することを特徴とする請求項３の画像形成装置。
【請求項７】
メモリを確保する際に、予め設定されたサイズのメモリを確保することを特徴とする請求項５の画像形成装置。
【請求項８】
レンダリング判定手段が、レンダリングに失敗する可能性があると判定する場合は必要最低限の、レンダリングできないと判定される場合はそれより多くのメモリを確保することを特徴とする請求項６の画像形成装置。
【請求項９】
メモリ管理手段が算出するメモリ消費量に応じて、第二のレンダリング手段のために確保するメモリのサイズを変更することを特徴とする請求項６の画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、描画コマンドに従って中間データを生成し、生成された中間データをレンダリングすることでラスタデータを生成する手段を備える画像形成装置に関する。
【背景技術】
【０００２】
描画コマンドに従って生成された中間データが、ハードウェアのスペック不足やハードウェアのバグが原因でレンダリングできないという問題がある。ソフトウェアでレンダリングすることで、この問題を回避することができるが、ソフトウェアレンダリングは、ハードウェアレンダリングに比べ、レンダリング処理速度が遅く、またソフトレンダリング用に別途メモリを確保する必要がある。
【０００３】
ハードウェアのスペック不足を補うためにフトウェアによるレンダリングに切替える処理に関しては、いくつか先行特許がある。例えば、特開平７−１３７３５３は、色階調、解像度を低下させながらもある程度色品位を保持し、少ないメモリ容量でレンダリングを実現させている。しかし、ソフトウェアレンダリングによるパフォーマンスの劣化を、メモリの取得方法で抑えるということは考慮されていない。
【特許文献１】特開平７−１３７３５３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ソフトウェアレンダリングのために、常に大量のメモリを確保することができればソフトウェアによるレンダリングを効率的に行うことができ、パフォーマンスの劣化を極力抑えることができる。
【０００５】
しかし、メモリは基本的に中間データの生成とその保持のために使用されており、ハードウェアのバグやスペック不足という稀な条件の下で必要になるソフトウェアレンダリングのために大量のメモリを確保することはできない。
【０００６】
そのため、パフォーマンスの劣化を抑えながらも、効率的にソフトウェアレンダリングを行う方法が求められている。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明の画像形成装置は、描画コマンドに従ってラスタイメージに展開可能な中間データを生成する中間データ生成手段と、中間データを解釈し、画像データとしてラスタイメージを出力する第一のレンダリング手段と、中間データを解釈し、画像データとしてラスタイメージを出力する第二のレンダリング手段と、第一のレンダリング手段が中間データをレンダリング可能かどうか判定するレンダリング判定手段と、第一のレンダリング手段のレンダリングが成功したかどうかを判定するレンダリング結果判定手段と、第一のレンダリング手段では中間データをレンダリングできないと判定された場合や、第一のレンダリング手段によるレンダリングが失敗した場合に、第二のレンダリング手段によるレンダリングに切り替えるレンダリング切替手段と、中間データの生成によるメモリ消費量を算出するメモリ管理手段とを備え、レンダリング判定手段の判定とメモリ管理手段が算出するメモリ消費量に従い、レンダリングに使用するメモリのサイズを切り替えることを特徴とする。
【発明の効果】
【０００８】
本発明によって、ハードウェアからソフトウェアによるレンダリングに切り替える時の状態によって、レンダリングに必要なメモリの取得方法を変更し、パフォーマンスの劣化を極力抑えながら、効率的なレンダリングを行なうことが可能になる。
【発明を実施するための最良の形態】
【０００９】
（実施例１）
図１は実施例１、２、３、４の画像形成装置の内部構造を示す図である。
【００１０】
図１において、１０１は、描画コマンドに従って生成された中間データからラスタイメージを生成するレンダラ１０２と、メモリの管理を行うメモリ管理部１０３と、メモリ領域１０４から構成される画像形成装置である。また、メモリ領域１０４は、描画コマンドを受け取る入力データ用メモリ領域１０５と、中間データを保持する中間データ用メモリ領域１０６と、最終的なラスタイメージを格納する出力データ用メモリ領域１０７と、レンダリング時に使用されるレンダリング用メモリ領域１０８で構成される。
【００１１】
レンダラ１０２は、レンダリングをハードウェアで行うハードウェアレンダラ１０２ａと、ソフトウェアで行うソフトウェアレンダラ１０２ｂで構成される。
【００１２】
さらに、レンダリング用メモリ領域１０８はレンダリング時ワークメモリとして使用されるワークメモリ領域１０８ａと、レンダリング時に生成されるラスタイメージを格納するラスタイメージ用領域１０７ｂと、レンダリング時に付加される属性情報を格納する領域１０７ｃで構成される。
【００１３】
本実施例における、描画コマンドを読み込んでからラスタイメージを生成するまでの手順を図２のフローチャートを用いて説明する。
【００１４】
ステップＳ２０１において、ソフトウェアレンダリング用のメモリを確保する。ステップＳ２０２において、中間データを生成する。ステップＳ２０３において、中間データをハードウェアでレンダリングする。ステップＳ２０４において、レンダリングが成功したかどうか判断する。
【００１５】
レンダリングが正常に終了した場合は、ステップＳ２０６へ、ハードウェアのバグやハードウェアのスペック不足が原因でレンダリングに失敗した場合は、ステップＳ２０５へ進む。
【００１６】
ステップＳ２０５において、Ｓ２０２において生成した中間データを今度はソフトウェアでレンダリングする。ステップＳ２０６において、ステップＳ２０１において確保したソフトウェアレンダリング用のメモリを開放する。
【００１７】
（実施例２）
実施例２における、描画コマンドを読み込んでからラスタイメージを生成するまでの手順を図３のフローチャートを用いて説明する。
【００１８】
実施例１では、必ずしも使用されないソフトウェアレンダリング用のメモリを常に確保していたが、本実施例では、ソフトウェアレンダリングを行う可能性がある時だけ、ソフトウェアレンダリング用のメモリを確保する。
【００１９】
ステップＳ３０１において、中間データを生成する。また、その中間データがハードウェアでレンダリング可能かどうかを判断する情報を収集する。
【００２０】
例えば、ハードウェアレンダラがＣＭＹＫ、ＲＧＢＡなど４チャンネルまでの色空間のレンダリングに対応している時、中間データにＣＭＹＫＡ５チャンネルのデータが含まれている場合、それは明らかにハードウェアではレンダリングできない。また、ある条件下ではハードウェアレンダラのバグに遭遇する可能性が高いと判明してことがある。
【００２１】
ステップＳ３０１では、このような条件に該当するかどうかを判断する情報を収集しながら、中間データを生成する。
【００２２】
ステップＳ３０２において、生成した中間データをハードウェアがレンダリングできない可能性があるかどうかを実際に判断し、その後の処理を決定する。ハードウェアでレンダリングできない可能性が少しでもある場合は、ステップＳ３０３へ進み、確実にハードウェアでレンダリングできると判断できる場合はステップＳ３０８に進む。
【００２３】
ステップＳ３０３において、ソフトウェアレンダリング用のメモリを確保する。ステップＳ３０４において、中間データをハードウェアでレンダリングする。ステップＳ３０５において、レンダリングが成功したかどうか判断する。
【００２４】
レンダリングが正常に終了した場合は、ステップＳ３０７へ、ハードウェアのバグやスペック不足が原因でレンダリングが失敗した場合は、ステップＳ３０６へ進む。
【００２５】
ステップＳ３０６において、Ｓ３０１において生成した中間データを今度はソフトウェアでレンダリングする。ステップＳ３０７において、ソフトウェアレンダリング用のメモリを開放する。ステップＳ３０８において、Ｓ３０１において生成した中間データをハードウェアでレンダリングする。
【００２６】
（実施例３）
実施例３における、描画コマンドを読み込んでからラスタイメージを生成するまでの手順を図４のフローチャートを用いて説明する。本実施例では、ソフトウェアレンダリング用のメモリ確保の条件をさらに細分化している。
【００２７】
ステップＳ４０１において、中間データを生成する。また、その中間データがハードウェアでレンダリング可能かどうかを判断する情報を収集する。
【００２８】
例えば、ハードウェアレンダラがＣＭＹＫ、ＲＧＢＡなど４チャンネルまでの色空間のレンダリングに対応している時、中間データにＣＭＹＫＡ５チャンネルのデータが含まれている場合、それは明らかにハードウェアではレンダリングできない。また、ある条件下ではハードウェアレンダラのバグに遭遇する可能性が高いと判明していることがある。
【００２９】
ステップＳ４０１では、このような条件に該当するかどうかを判断する情報を収集しながら、中間データを生成する。
【００３０】
ステップＳ４０２において、生成した中間データをハードウェアがレンダリングできないかどうかを判断する。ハードウェアのスペック不足などで明らかにハードウェアでレンダリングできないと判断できる場合は、ステップＳ４０３へ進み、そうでない場合はステップＳ４０４に進む。
【００３１】
ステップＳ４０３において、ソフトウェアレンダリング用のメモリを確保する。
【００３２】
ステップＳ４０４において、生成した中間データをハードウェアがレンダリングできない可能性があるかどうかを実際に判断し、その後の処理を決定する。
【００３３】
ハードウェアでレンダリングできない可能性が少しでもある場合は、ステップＳ４０５へ進み、確実にハードウェアでレンダリングできると判断できる場合はステップＳ４１０に進む。
【００３４】
ステップＳ４０５において、ソフトウェアレンダリング用のメモリを確保する。ステップＳ４０６において、中間データをハードウェアでレンダリングする。ステップＳ４０７において、レンダリングが成功したかどうか判断する。レンダリングが正常に終了した場合は、ステップＳ４０９へ、ハードウェアのバグ等でレンダリングに失敗した場合は、ステップＳ４０８へ進む。
【００３５】
ステップＳ４０８において、Ｓ４０１において生成した中間データを今度はソフトウェアでレンダリングする。ステップＳ４０９において、ソフトウェアレンダリング用のメモリを開放する。ステップＳ３１０において、Ｓ４０１において生成した中間データをハードウェアでレンダリングする。
【００３６】
（実施例４）
本実施例では、実施例３においてソフトレンダリング用のメモリを確保する際に（ステップＳ４０３、ステップＳ４０５）、確保するメモリサイズを条件に応じて切り替える。その切り替え処理について図５のフローチャートを用いて説明する。
【００３７】
図６は本実施例において、具体例として使用する３段階のメモリサイズを示す。レベル１、レベル２、レベル３の異なるメモリサイズを用意し、それぞれ全体メモリサイズの１／４、１／８、１／１６のサイズとしている。
【００３８】
ステップＳ５０１において、中間データを生成する。
【００３９】
ステップＳ５０２において、その中間データの後に続いて生成される中間データがないかどうかを判断する。後に続く中間データがなく、最後の中間データと判断される場合はステップＳ５０４へ、そうでない場合はステップＳ５０３へ進む。
【００４０】
ステップＳ５０３において、生成した中間データがハードウェアでレンダリング可能かどうかを判断する。ハードウェアのスペック不足などで明らかにハードウェアでレンダリングできないと判断できる場合は、ステップＳ５０５へ進み、そうでない場合はステップＳ５０６に進む。
【００４１】
ステップＳ５０４において、レベル１のメモリサイズを取得する。
【００４２】
生成した中間データの後に続く中間データがない場合は、余っているメモリを有効に利用し、ソフトウェアレンダリングのパフォーマンスを少しでも向上させる必要がある。
【００４３】
ステップＳ５０５において、レベル２のメモリサイズを取得する。
【００４４】
ソフトウェアレンダリングが実行されることが明白な場合は、中間データの生成、保持のためのメモリを意識しながらも、ソフトウェアレンダリング用のメモリを予めある程度は確保しておき、ソフトレンダリング時のパフォーマンス劣化を極力抑える必要がある。
【００４５】
ステップＳ５０６において、レベル３のメモリサイズを取得する。
【００４６】
本ステップには、ソフトウェアレンダリングが必要かどうか判らない、という状況の場合に到着する。このような状況は稀である（例えばハードウェアのバグに遭遇すること）と考え、本ステップでは、ソフトウェアレンダリングに最低限必要なメモリだけを確保する。つまり、中間データの生成や保持のためのメモリをできるだけ多く確保しておき、中間データ生成時のパフォーマンス劣化を極力抑える必要がある。
【００４７】
以上を実施例３に当てはめる場合、ステップＳ４０３で確保するメモリサイズはレベル１、もしくはレベル２となり、ステップＳ４０５で確保するメモリサイズはレベル１、もしくはレベル３となる。
【００４８】
本実施例によれば、メモリの利用状況とハードウェアによるレンダリングの可能性に応じて、ソフトウェアレンダリング用のメモリサイズを適切に確保することが可能になり、レンダリングや中間データ生成のパフォーマンス劣化を極力抑えることが可能になる。
【図面の簡単な説明】
【００４９】
【図１】画像形成装置の構成図。
【図２】実施例１におけるレンダリング処理を示すフローチャート。
【図３】実施例２におけるレンダリング処理を示すフローチャート。
【図４】実施例３におけるレンダリング処理を示すフローチャート。
【図５】実施例４におけるメモリ取得時の処理を示すフローチャート。
【図６】本実施例において、具体例として使用する３段階のメモリサイズを示す。
【符号の説明】
【００５０】
１０１  画像形成装置
１０２  レンダラ部
１０３  メモリ管理部
１０４  メモリ領域
１０５  入力データ用メモリ領域
１０６  中間データ用メモリ領域
１０７  出力データ用メモリ領域
１０８  レンダリング用メモリ領域
１０８ａ  ワーク領域
１０８ｂ  ラスタイメージ格納領域
１０８ｃ  属性情報格納領域
【図１】
2006289899.tif 000003
【図２】
2006289899.tif 000004
【図３】
2006289899.tif 000005
【図４】
2006289899.tif 000006
【図５】
2006289899.tif 000007
【図６】
2006289899.tif 000008