今日は「Pixel-to-Pixel速度比較 」のまとめをしたかったのですが、
うっかり大変なことを忘れておりました。
家族でちょっとしたイベントのある夜だったのです。
・・・ということであまり綺麗にまとめる時間がなくなってしまいました。
でもざっくり書いてみます。（あとで修正するかもしれません）
25:00追記
前回「ある条件」って書いてたのでそれに即して書き記します。
私が目的にしていることはDirectXで背景画をリアルタイムで書き換える手段の検討でした。
目的から考えれば手段としてはGDI+に頼ること自体が方向性として微妙だったなと途中で気付いたのです。
つまり「私がやりたいことはライブラリImageUtilsで処理を書く必要があるかどうか」という条件だったわけです。
流れる星などのエフェクト効果はピクセルで描画できたら実装できそうに思いました。そこからGDI+へ考えを進めるのではなくてDirectXのピクセルレンダリングのパスへそういうピクセル単位でのドットON/OFFを設定できるのかという方向へ話をもっていくべきでした。この話の方向はいづれ考えてみようと思います。
そういうわけですが。
たとえ微妙方向性だとしても乗りかかってしまった船なので、とりあえずこのエントリーは決着は付けようと思っています。
●ColorMatrixが速いのはおかしい
私は実は計測する前からLockBits/UnlockBitsの方が速いと予想していました。
（追記：前回納得できていない、と書いたのは、上の追記に書いたとおり話が微妙だってたことに気付いたのもありますが、予想が外れていて納得できないという意味もありました）
前回ColorMatrixが速くなったような結論が出たのは、
速度重視思想だけでは無いImageUtilsを使用したためだと考えれば納得できます。
●作者junkiさんの記事
Bitmap の内部色データにアクセスする (1)
「このコードは、前回の配列コピーの場合より、さらに４倍以上速い。この方法は unsafe{} ブロックを含むが、もっとも高速なので以後はこの方法を使うことにする。」
この時点ではライブラリでunsafeを使用する事を考えていらっしゃいました。
Bitmap の内部色データにアクセスする (3)
「図は、今回つくったクラスをつかって画像のすべてのピクセルの R 成分と G 成分を入れ換えたものである。ここでテストしたように、前回の unsafe コードに比べると ３－４割時間がかかって遅くなるが、なによりポインタをあらわに使わないで済むことは重要である。」
しかしunsafeを使用するデメリットなどをjunkiさんなりに考慮された上で最終的には時間がかかってもunsafe未使用方式を採用に到っておられます。
●まとめ
ライブラリImageUtilsの思想は「GDI+の描画処理で加工できないBitmap（具体的には８ビットのカラーパレット式ビットマップなど）を加工できる」という事を可能とするライブラリでした。
私がそのImageUtilsを使って処理を書きたいのであればColorMatrixでは処理を書けないということになります。
私が扱う画像がGDI+で加工する事をしたい＆unsafeは使いたくないのであればColorMatrixを使えばよいということになります。
私が扱う画像がGDI+で加工する事をしたい＆unsafeを使っても速くしたいのであればLockbits/UnlockBitsを使えばよいということになります。
つまり何の速度差を知りたかったのかを明確にしなければ議論することができない話だったとわかりました。
●次回？
ということでもうちょっと観点を明確にしてちゃんと実測してみたいと思います。