Android Paperカメラの核心パート３

さて今回は発熱と携帯の性能について

昨今パソコンの性能の指針であった動作周波数！！2.4ＧＨｚあたりで打ち止めになってます。
これは周波数を上げていくと、性能が上がるんですが、発熱が物凄いことになってしまい、
ここが限界となってしまってるからです。

で・・・・CPUの数を増やして性能を上げる方向へと転換しています。

携帯も同じで去年は2CPUから4CPUなんて時代になってます。

でも！CPUが増えようと、プログラムが１CPUしか使えないプログラムだと・・・・・
パラパラとしか動かないものになってしまいます。

で、これを回避するのがスレッド処理

同じ仕事を平行して行うのでCPUを個数分使いまわす感じで動かします。
JAVAでは簡単ですがCでスレッドはちょっと難しい～のですが・・・・・

ここで問題が発生します。

凄く複雑な計算を繰り返し行ってると、携帯が発熱を始めます。
ARROWSなんかは50°くらいまでになっちゃいます。
発熱を抑えるため携帯は性能を下げる処理に入り結果してプログラムが思うように動作しない、原因がつかめないパラドックに入ってしまいます。
JAVAだけで作ってるならば、ま～発熱はあんまりしないでしょうけど（笑

典型的な例はパズドラ、凄い発熱する機種があります。

4CPU+GPU(グラフィックCPU)でそれぞれ分散処理を行ってれば、必然的に発熱コース

ところがです！！！！！！！
Paperカメラは意外と発熱しないのです。難しい処理を独自アルゴリズムで軽い計算にしてるのか？？
たぶんOPEN GLで描画処理をGPU側で行ってると推測出来ます。

同様の処理が完成したのですが、発熱と性能ダウンの対策で現在パラドックス状態なのです、ただ！！！ある一つの解決の方策が見えてきました。

データ量を減らす。人間の目には感じることがない領域のデータを減らせば、計算量が減るのではないかと・・・・・・

試しに、スケッチの、もととなる白黒原図を32ビット画像から16ビット画像に変更してみたところ処理が1.5倍高速に、発熱も減りました。

マンガイラスト風にするのならばカメラから流れてくる画像データも半分の諧調でいいのだから、データ量が半分になるのでさらに高速になると思います。
動作速度もPaperカメラに近づきました。

フレームレートは毎秒25前後（4cpu機種で)、アニメ並みの動作です。

なんかチューニングをしている感じで、あるところまでは行くのですが、その先・・・・・・
カリカリチューンではなくて、万能な高性能、難しいです。その答えを見つける感覚が車ににている感じです。

Paperカメラの作者さんは天才だと思います。数学的、そしてデザインセンス

世界で同種のカメラは３つあります。
一つはPaperカメラ、もう一つはCartonカメラ（速さはあるのですがOpenGlを使い切ってないため手抜きしたスケッチエフェクトが人造的でいま三です）
最後の一つは和製の私のアプリ

今回の話はここまで、続きは次回で