DIBセクションに自前描画することで、なんとか最新端末のiアプリ並みのパフォーマンスを確保することができた。ヤレヤレ(^^;
１）DIBセクションのピクセルフォーマットを物理画面と同じにする。
物理画面のピクセルフォーマットを普通に取得する手段はないようで、下記を参考にDirectDrawを使用して取得するようにした。
http://d.hatena.ne.jp/freebeans/20061003/p1
ありがたやありがたや。ああ、皆苦労してるのね(--;
２）物理画面への転送を省きBitBltは使わない。塗り潰しも自前のほうが速い。
DIBセクション用の描画処理ロジックは全部スクラッチで書いた。古いWindows用のコードを引っ張り出して流用しようと思ったら、8BITカラー専用だったり、インラインアセンブラの比率が高かったりで使えず。8BITパレットの変換テーブルを使った近似色による擬似半透明描画とか実装してるし。「昔の俺は何気にスゲぇ」とか思った(^^;
３）何があってもStretchBlt()だけは使わない。
移植元が240x240ピクセルの携帯用アプリなので、画面解像度が高い端末では物理画面に描画する時に整数倍に拡大しているのだが、DIBセクションを直接StretchBlt()するより、作業用のDIBセクションに自前で拡大してからBitBlt()するほうが速い。StretchBlt()はホントに遅いのね。ハードウェアアクセラレーションは効いてないんだろうなぁ。
４）描画処理はC言語で書いてもそれなりに十分な速度が出る。
モバイルとはいえCPUクロックは500MHz以上だもんね(^^;
５）ARMはメモリー・アライメントにうるさい
たとえば4バイト整数としてメモリアクセスする場合、そのアドレスは4の倍数でないと例外が発生する。気軽にBYTEのポインタをDWORDのポインタにキャストして4バイトまとめてゴニョゴニョする、とかできないわけです。
http://jr0bak.homelinux.net/~imai/linux/arm_gcc_badknowhow/arm_gcc_badknowhow-4.html
http://itpro.nikkeibp.co.jp/article/COLUMN/20070509/270418/?ST=develop&P=2
むしろ何でもできちゃうx86が特異なのだが、長いことx86ベッタリの生活をしてるので「何でこれが例外なんだ！」と悩むこと２時間（苦笑。x86でもアライメントが合っていないアクセスはパフォーマンスが落ちるが、4バイトまとめて持ってきて演算して結果を4バイトまとめて格納、なんて場合は便利なんだよねー。
関係ないけど、ARM用のLinuxはアライメントの例外をトラップして良きに計らってくれるらしい。これは忘れないようにしないとね〜。気づかずに多用したらゲロ重になるよな。ARMのLinuxでアライメントを気にするようなコーディングをする機会があるか判らんけど(^^;
