Diary of Sacred Fox - July 21, 2004

# この先は聖狐のVB6 → C# .NETアプリ移植奮戦記となっております
# 興味が無ければ読まないことをお薦め

どうやら.NET Frameworkには既に画面中にあるものに対して何らかの色のBitwizeな演算をすることで画像を得るペンマスクペンにVBでいうCopy Pen + αに相当するものしかなさそう相当するものが存在しない様子
DrawModeプロパティがPen.Colorプロパティに相当と言うのは酷いんじゃ…
Illust Logic Paintの移植にはどうしても実際は白黒で用意された数字のイメージを任意の背景色と前景色(どちらかは白)で表示する処理類する処理が必要だったので他の解決法を探したところ…
代わりにイメージ転送の際に色変換行列を作ることが出来るようだったので, イメージ転送後にマスクをかけていたので, 転送と同時にマスクをかけるように変更すればOKそうこれを使うように
しかしあまりにも周りがゴテゴテしていて使いづらかったので, 必要レベルのWrapperを書くことにした
以下, そのWrapper

// Imageの白をwc, 黒をbcに線形でマッピングするCGの講義で出て来た4 + 1次の同時座標によるアフィン変換, ただし座標空間じゃなくて色空間なのが哀しいところ, しかも使ってるのは拡大縮小と平行移動だけだし…変換行列を持つImageAttributesを返す
private static この辺の機能はあまり普通じゃないのか, デフォルトのネームスペースには入っていてくれないので, 今回は直接指定System.Drawing.Imaging.ImageAttributes ImgAttrByColors(Color wc, Color bc) {
    System.Drawing.Imaging.ImageAttributes iattr = new System.Drawing.Imaging.ImageAttributes();
    System.Drawing.Imaging.このクラス, ヘルプの説明が不十分すぎる, コンストラクタでfloat[] []を取る時に取る行列は列ベクトルのベクトル(つまりMatrix12は[1] [2]要素), 要素の順番はRGBAWの順の模様, いろいろ実際に動かした方が早そうColorMatrix cm = new System.Drawing.Imaging.もうひとつColorMatrix(float[] [])なコンストラクタもあったが, 使いづらいので後から要素を指定することに, せめてfloat[,]だったらなぁ…ColorMatrix();
    cm.Matrix00 = (float) (wc.R - bc.R) / 255;
    cm.Matrix11 = (float) (wc.G - bc.G) / 255;
    cm.Matrix22 = (float) (wc.B - bc.B) / 255;
    cm.Matrix33 = 1;
    cm.Matrix40 = (float) bc.R / 255;
    cm.Matrix41 = (float) bc.G / 255;
    cm.Matrix42 = (float) bc.B / 255;
    cm.Matrix44 = 1;
    iattr.SetColorMatrix(cm);
    return iattr;
}

あとは, これで得られたImageAttributesを使ってDrawImage(Image, Rectangle, int, int, int, int, ここは何も考えずにGraphicsUnit.Pixelを指定すれば良いだけGraphicsUnit, ImageAttributes)を呼べばいいだけ
個人的にはDrawImage(Image, Rectangle, int, int, int, intの代わり, どうせImage全体を描くし, 拡大縮小する気も毛頭無いので…Point, ImageAttributes)ぐらいで十分なんだけど, ImageAttributesを取ろうとすると流石に平行四辺形変形のついているバージョンは呼びたくないし…このぐらい大きなものしか残っていないのがちょっと哀しい
因みにDrawImage()は30種類のオーバーロードを持つ関数, こんな中途半端なところで終わらせるぐらいなら, もっと増やしてあらゆる可能な組み合わせでいけるようにしてくれとか言いたくなってくる何だかなぁ…
因みにこれを乗っけることで元のプログラムよりもこの部分では恐らく重たくなってしまう予感, まぁこれはフレームワークが違うのだから仕方が無いのその代わり別のところでもう少し高速化努力をして, それで取り返せない部分は諦めると言う意味割り切るしかなさそうだが…

注: 日記スクリプトの関係上一部コメント内でfloat[][]とすべきところをfloat[] []としています, ご了承ください, スクリプト用のタグと被るのでタグの中にはかけないのよね…

画面のリフレッシュをするとき, VB6でPaintイベントハンドラを直接呼ぶ代わりにInValidateしてからUpDateという方法を取ると, どうやらPaintイベントハンドラにはこっちが描く前にBackground Colorでわざわざ塗りつぶしてから寄越してくれるみたい, 画面がちらつくからいらないっちゅーねん

で, 解決策
結構邪道かもしれないけど, VB6でやっていたことにさらに近づけているだけともいえそう

Paintイベントハンドラの中身を別のvoid (void)なメソッドに写す, 但し, Graphicsオブジェクトの取得を

Graphics g = e.Graphics;

から

Graphics g = 適宜書き換えてくださいpanel1.CreateGraphics();

とし, 最後に

明示的にCreateしたのでDisposeしなければならない, e.Graphicsの場合は要らないみたいだけど…g.Dispose();

を加える

そして, Paintイベントハンドラにはこのメソッドへの呼び出し文だけを記述する

最後にpanel1.Invalidate();な部分もこのメソッドの呼び出しに置き換える

注意点は背景色での塗りつぶし処理をRedraw時にスキップするので, ちゃんと描かないところは消しておくこと(謎)

もしかしたらPaintイベントハンドラのときはちゃんと与えられたe.Graphicsが存在しているところで別にCreateGraphics()するのに抵抗感が無ければ何の問題も無いと思うのですが, こんなことして本当にいいの? と聖狐は思うので… この辺の回答を求む > 識者 …といっても周囲にはそんなにいなさそうだしなぁ…eの中のGraphicsを使うべきかも知れない, この辺はgの取得と解放を行うWrapperをオーバーロード関数として作るだけ, お手軽もう1段メソッドを噛ませばいいだけだが…