変形系のフィルタを実装していて 0〜1範囲のブレンド式の境界付近の微分による導関数連続性がどーのこーの.

思いがけない所で思いがけない議論が思い出されるもので、まさか以前読んだPerlin Noiseの改善の話(2002年頃だったかな)が役立つとは思いませんでした. まーつまりはA * n + B * (1-n) みたいな式の外側において混合式の不連続性が目立つのでHermite多項式(-2n^3 + 3n^2で1次微分連続, 6n^5 -15n^4 + 10n^3で2次微分まで連続) が利用できるという話.

実際の演算に適用すると、まぁ劇的に改善する事もあればフィルタアルゴリズムによっては適用を誤るとむしろ不自然さや扱い難さだけが強調される個所もあるのでそう簡単なモノでも無いのだが、こういう関係無い話が繋がるのが非常に総合芸能としてのプログラムの楽しい所 :-)

しかし、変形フィルタは出力のオーバーサンプルのボケが気になるなぁ、、、少し真面目に窓関数の使用を検討した方が良いかも、など分かる人にしか分からないよーな話で〆というカンジ、結構ペースが乗ってきましたよ.

インクリメンタルGCの実装完了(但しSweepフェーズのみ) 取り合えず上手く動いている模様につき暫くこれで使って様子見. 指標としては取り合えず実時間分周でリミッターを超えたらfull GCに移行する形. 実時間GCは指標としては余り妥当なものでは無いのだが、ある一定のパフォーマンスを保証するという所では比較的安定している気がしたので. ただギリギリのラインで増加傾向で動かれるとリミッターを超えた時に少々負荷が厳しいかもしれないのが気にかかる所ではあり、暫く様子見で考える事にする.

まぁ実際実装してみたら一瞬止まるのもイラッっと来るが、ある程度継続的に速度が遅くなるのもイラつくので何とも言いがたい気分になった部分もあったのだが(苦笑)

それ以外にGCルーチンでミスってた個所を修正、初期の実験コードが紛れ込んでいてn^2になっていた個所があった :-< 直したつもりだったのだが、、、修正した所平均して10倍以上パフォーマンスが上がる、何とも恥ずかしい限り.

まぁこの他にはペイントソフトをチマチマと、ただ細かい所の修正がメインなので取り分けて書く事も無し.

---------------

Java6 update 10が出ている、Nimbus (Swingの新しいLook&Feel) を試したくて落としたが、実際適用してみるとフォントのbold解除が効かない個所があったりアイテムの標準サイズが少し大きめだったりでイマイチ綺麗じゃない、後はメインマシンがまだwin2kという事もあり、フォームを表示した際の全体のデザインはどうにもMetalやOcean以上に限りなくダサい気がする. まぁこの辺はVistaとかの環境ではまた見え方が違うのかもしれないが(※1) :-<

ただ少々面白い誤算だったのはインストール後にプロセスリストを見ると jqs.exeというプロセスが常駐しており、これがJavaのランタイムの一部をキャッシュしているらしい、十分試してはいないがIE上でプロセス内初回起動でもアプレットの起動がflash並みになっていたりと非常に好感が持てる、これだけでもランタイムを入れる価値はあるかもしれない、以前の状態では実質Javaアプレットは選択肢に無い状況でブラウザ内で動作させるコンポーネント選択としてはFlashが最も妥当だったが、これならばいけそうではある、とは言えランタイムをインストールして下さいと言えるのはもう少し先かもしれないが(苦笑(※2)
(訂正: オンラインでの初回起動は少し軽くはなったもののやっぱり重かった:-<)

一方FlashはFlash10からローカルファイルが読めるようになった辺りが大きく(※3) セキュリティモデルの関係からローカルファイルのみもしくはネットワークファイルのみのいずれかに限定されるので、企業ユースでは辛いがエンドユーザーサイドへのプレゼンテーションとしてはまだアプレットに対するアドバンテージがあると言えるかもしれない. (逆にFlashのフレームワークは実行モデルの全てを非同期で書かなければならないというのが少々難があり、ある規模以上のアプリを組もうとすると結構効いてきそうな予感もしている)

まぁ対岸の分野ではあるが、予想よりも早く面白くなるかもしれない;-)
(無論そこで始めてスタートラインではあるし、.NETの時も同様の期待をしたがそれ程の状況にならなかった事を考えると過度な期待はせぬ方が良いかもしれないが)

※1) ただ同系統のデザインでもFlexのGUIは良く見える事から、やっぱり (少なくとも標準状態は) ダサいのかもしれない.

※2) 余談だがFlashのバージョンの見せ方と比較するとJavaの実行環境のバージョンはエンドユーザーサイドには分かり辛いよなぁ 「Flash 10が必要」ならFlash 9では駄目な事が分かるが「JRE6 Update10以降」と言っても「Javaの6は入っているのに」ってなカンジになりそうではある :-<

※3) Flash10 Player自体は正式配布になっているが、製作環境としては現状Flex SDKのNightly Buildの環境しかない( + Flash10用に設定ファイルの書き換え要).

ここ2日程はシェルのネームスペースの列挙をあれやこれや、つまりはWindowsがフォルダ階層とは別に持っているデスクトップをトップレベルとする階層構造の事だが、意外とこれがC++で扱うとShellのアロケータやらシェル独自のパス(pidl)の解析やらで死ぬ程面倒だったりする、まぁ直近で使う予定は無いものだが、アプリケーションを作る上では明確に欠けているパーツだったのでというカンジ.

つまりは↓みたいな事を実現する為

大した話では無いのだがドライブの選択とかフォルダの選択とかで使うカンジ、よくあるドライブの選択でA:\,C:\とかだけしか出てなかったりフォルダ選択でSHBrowseForFolderで選択した結果がエディットボックスに'c:\〜'などとだけ書いてあるとどうにも締まらないなぁなど思ったり、エクスプローラと同様に少しプルダウンで相対位置の確認をしたい場合などにもごく微妙にストレスがかかる印象があったので.

アプリケーションによってはマシンに認識されている近くのPCなどを選択する場合などにも使えたり、幾つかはそれ用に特化した代替手段もあるのだが、どうにも万能とは行かないので、やはりWinに認識されているものをそのまま引張って来る方が良かろうという具合、まぁ地味な小物 ;-)

# 地味なんだが殆どのアプリに関係する要素でもあるので、ここまで使い難いのはどうかと思ってしまう :-< ＞Shellのnamespace周りのAPI

---------------

まぁそれ以外にはこんなもの↓を作っていたり.

トーンカーブは余り使わないのでチェック埋め程度のつもりだったのだが、拡張で透明度や彩度・明度に適用出来るようにするとかなり便利な事に気付く. 実際RGBモードは完全におまけ程度(笑) 怠けずにヒストグラムも同時表示する方が良いかなーとかまーつらつらと.

、、、なんかねー、最近カスタムコントロール作るのがやたら楽しくなってきてて(苦笑)

その後少々挙動が気になる所があって調べていた所、気になる記事が

Internet Explorer リーク パターンを理解して解決する

COMの限界とは言え話にならんな、こりゃ:-< 昨日色々書いたがそれ以前の問題で当座はDOMの要素はstaticとして書き換える程度が妥当、という所か.デバッグ中に少々気になったのは、一部の宙ぶらりんなCOM要素がページ切り替えても残っているっぽいのだよねぇ. というかリンク先に色々書いてあるけど、基本的にはieの要素がCOMになっているのが全ての元凶、クロージャは循環参照を暗黙に生成する為コストが高いのは事実だが、ガベージコレクタがしっかりしていれば何の問題も無い. 大体Windowのリサイズや子コントロールなど循環参照無しで制御するのは(不可能では無いが)至難の業であるワケで :-<

現時点ではちょっと見て終わりのメディア以上のある程度の連続オペレーションを提供する実装には 完全に無いわ これは(--#

# 余談だがCOMのリファレンスカウンタ (特にアウトプロセスサーバ) とgcの相性の問題は色々あるらしく、.NETからExcelなどを呼び出す常套としては最近はScriptControlでVBScriptにディスパッチし、一括してシャットダウンするような手法がメジャーだったりするらしい. スクリプトエンジンdllのプロセス内の寿命の関係もありJScript (gc実装としてはVBScriptがリファレンスカウンタのみ (当然循環参照は禁物) で即時処理するのに対しこちらはfull GCのみで寿命管理している模様(実装が余り良くない為パフォーマンスの悪化が顕著になりがちな傾向有)) で同様の事が可能かどうかは不明ではある、自前のへっぽこ言語はリファレンスカウンタとMark&Sweep GCのハイブリッド(※1 になっているので余り気にした事は無いが、言語の内部構造が比較的単純なので成立する話、まぁ粒度の細かい外部リソースの管理とgcの寿命管理の相性というのはそれはそれで難儀なものではある :-<

※1) この手のGC実装のパフォーマンス議論は色々あるので一概にこれが良いという意図は無い、言語のプリミティブの粒度と想定用途やインタプリタ部のデザイン、言語コアのメモリ管理モデルにも大きく左右される部分でもあり、自作の言語ではfull GCのみと比較した場合に総じて速度とメモリ消費の安定性を考慮した結果良い結果となったので採用したというだけの話 (構造的に世代別・インクリメンタル(※2 GCなどは実装が難しかった部分もある) 何か調べ物しているとこの手の不毛な議論もかなり目に付くがそんなの知った事じゃない :-P

※2) と思ったが久しぶりに構造を見直したらインクリメンタルGCは実装できそうな気がしてきた、というカンジでまずは検討からToDoリストに追加、、、KOJIさんに指摘されたペイントソフトのバグ修正やらPhotoshopにあって自作ソフトに無い機能の実装やら何やら、際限なくToDoがたまっている気も orz

ペイントソフトの機能を追加して時間が余ったので一般的なブラウザ上のJavaScriptなどいじる、webページの修飾の為のJavaScriptを書くのなど何年ぶりだろう、下手をすればまだwebの草創期の時代、学生時代のアルバイト以来かもしれない(笑) などと思いながら、取り合えずのデバッグコンソールを作るつもりがそれなりに興が乗って丸一日いじる事に、何となく流行りモノ (というにはちと時期を逃した感はあるが) の「JavaScriptでWindow」みたいなカンジになった(苦笑)

こんな具合 (注: 現状イベント設定やiframeメンバ参照の関係上 IEのみ動作、フォントサイズ小推奨)

、、、まぁほんの余興のみ ;-) Windowコンポーネントの設計がまとまっていない事もあって内部iframeのイベントを横取りしていない為ドラッグでフォーカスを取られると移動とリサイズがやり難いのはご愛嬌(divならスムーズになるが、細かいスクロールが扱えない:-<) ただ触ってみたカンジマウスイベント周りがかなり弱い&粒度が荒いので、今の所 「無いな」 というカンジ. 真面目にある程度インタラクティブな操作をするコンポーネントならFlashを使う方が妥当だろう (FlashもNativeに比べればコントロール範囲・イベントの精度とも限定されるが、mousemoveイベントでボタンの状態が取れる為、一時的にクライアント領域を外れてもそれなりの一貫性は維持できる、具体的にはmousedownで遷移するのでは無くmousemoveで以前のボタン状態と変わっていたら押下・解放とみなすカンジ)

まぁFlashについてもその可能性について誰かさんから容赦無いツッコミが出そうな気はするが、その話はとりあえず今回は抜きという事で(ぉ

# どーでも良いがJavaScriptのクロージャは参照型 (not 値のコピー) かつブロックスコープも無い (ループで大量生成する場合ブロック変数に閉じ込める事ができない) という事でメニュー生成部がクロージャで各項目を閉じ込めて更にその内部でイベントハンドラを作るというかなりグチャグチャなデザインになったのは嫌なカンジ :-< (別途idで管理するのは邪魔臭いので全部クロージャでチェーンする形)

# で、その後で何か面白いネタは無いかなーと本屋に行ってAjax周りの書籍を見たらその9割 (冗談抜きのマジな数字) が触りだけ説明して「ライブラリを使いましょう！googleのサービスに接続しましょう！」な内容で激しく萎える事しきり :-P

PSD周りのソースの整理をしていて数ヶ月前に作ったAPD(AzPainter) <-> PSDの変換プログラムの存在を思い出す、とは言え該当ソフトを使っているワケでは無く、あくまで自作ペイントソフトのフォーマットを模索する為、様々なソフトを調査していた際に使った事が無かったzlibのメモリ圧縮機能の習作として作ってみたというだけの事.

まぁ放っておくのも後々何かしら気になるという具合なのでそういった余分なものを断ち切る意味も込めてjunk行きとして区切りとしておくという程度、メンテナンスする気は無いのであしからず ;-)

しかしPSD機能のライブラリ化は色々難があってイマイチ進まず、取り合えずPSD読んでるソフト全てでソースは共通化したが、アルファチャンネル名など一部の情報が前後するので、汎用的なコールバックなどで扱うには難があり、読み込み・保存の為だけに全てのデータを一括して作成するとメモリを大幅に消費するのでNG やはり効率を考慮すると実装ソフトに合わせてその内部形式そのまま読み書きという具合である程度の作り込みは避けられぬ模様、残念 :-<

まーそんな具合だったり、延々カスタムコントロールを作ってたりとWin32に戻ってます.

---------------

進化論関連の本を読んでいた時にあったネタ、何でも比較的近年(2006年)のアメリカでの調査によると全体の31%は聖書の創世記にある生物の起源を事実として信じているのだそーな (この結果はアンケートという明確な回答を要求する手法に因る為、漠然とした消極的認識も入れるともう少し比率が上がる気もする) 背景文化が変われば何とやらという所かもしれない、実際海外で日本人が「自分は無神論者だ」というとかなり奇異の目で見られるらしいし(笑)

まぁだからと言って揶揄するものでも無い、概念は違えども日本でも人と話していて (漠然とした消極的認識も含め) 所謂「魂」の存在を信じているという人間が多い事にも正直驚かされる :-P

なお僕自身は別に信じる、信じない (主観における行動の背景や検証結果からの仮説の提示としては有益だが、信じる・信じないと表明するだけの行為は単に無益なだけだ:-P) という立場は無く、単に事実として観測される内容から裏付けの無いものは除外するだけという立場 (個人的な行動戦略上未知の要因としてマージンを設けるかはまた別の問題). 検証可能な反証がでてくればそれに応じて認識を修正すれば良く、検証可能な材料が無い以上それを前提とする事は誤りであるというカンジ. ただ所謂「魂」という概念は文化的断絶があった頃の原始的なコロニー時代から各地で見られる為、人間の自我認識の発達 (他の生物と対比して(※1)) と合わせどのような背景からそのような発想に至ったのかというプロセスには非常に興味がある所.

※1) チンパンジーによる実験では自己と他者における明確な認識上の区分がある事は実験で確認されている(但しそれらを鳥瞰的に見て全体という構図の中で自己を捉えられるかという点についてはまだ不明) また昔猫を飼っていた時の経験で飼い猫が自分の餌場に連れて行こうとしたりする行動があって、非常に面白いと感じた、反面比較的 (昆虫などと比べると) 近縁の爬虫類などではそれ程明確な行動は見えていないのは少々気になる所ではある (短期的な行動は反射行為である可能性も高く自我認識の証明にはならない為)

友人と話しててたまに上がるJITの実装ネタ、無駄に色々考えて難しいかと思っていたが基本的には以下のような考え方で実現できるんだね.

void *jitcode(){
    /*
        以下のコード相当
        mov eax, dword ptr[esp+4]
        add eax, 7
        ret
    */
    unsigned char code[]={
        0x8b,0x44,0x24,0x04,
        0x83,0xc0,0x07,0xc3,
    };
    void *r=malloc(8);
    memcpy(r,code,8);
    return r;
}

int main(void){
    int(*func)(int)=(int(*)(int))jitcode();
    int r=func(10);
    printf("%d\n",r);
    free(func);
    return 0;
}

DEPが有効な環境では一旦コンパイルしてからVirtualProtectで実行可能bitを立てた領域にコピーしないと多分動作しない、まぁx86のニモニック見たらやたら複雑化してるんで、自分で作るものじゃねーと思いましたけど(苦笑)

# ついつい次のステップが見えないものについては反射的に「難しい」と感じてしまうクセは直さないといけませんね、反省.

---------------

半年に1回程度のレンタルビデオ強化週間、まずはバイオハザードIII、最早バイオでは無くマッドマックスと化しておりました、まぁそのギャップが面白く笑えましたが. 個人的には (ゲームの) バイオシリーズは意図的にプレイヤーのアクション選択肢を制限して弾薬と回復アイテムでバランス取っている印象が強いので、ガチのアクションとして映画版もゲームにして欲しい所です、ええ(笑)

---------------

JavaとC#を対比しながらの検討、画像処理用のバッファを実装してみたが、BufferedImage/Bitmapとの転送でJavaの方がC#の4倍程度遅い、、、一応C#がフォーマット変換を介して転送しているのに対しJavaの場合はBufferedImageのピクセルフォーマットをそのままアクセスしているのだが、Marshal.Copyでラスタ単位での一括転送が出来るC#に対しJava版はDataBufferに対するget/setElemを使っているのが難点かもしれない (処理にも因るが本来画像処理の縦横二段階ループ内で関数呼び出しは結構影響が大きく全域において必要なのは結構痛い、またbyteがsignedなのも正直かなり頭痛の種) ループ内条件分岐展開すると想定して全部外に追い出したテストでも3倍強の遅さととちとキツめ、まぁただ好意的に解釈すれば使用コンパイラの最適化性能によっても左右され得るのと同レベルの速度差と言えなくもない(かも).

しかしGUIパーツの殆どをラップしたり、標準のレイアウトマネージャも細かい調整が効き難い為nullレイアウト+自前マネージャとなったりであってほぼ全て独自環境状態、この状態では上手く立ち上がってもNetBeansなんかは使えないよなぁなどと思う事しきり、まぁとは言え思っていたよりは好感触で通常アプリとの一貫性を犠牲にすれば、中規模のフリーソフト程度のGUIなら実現できるかなぁという印象. GUIについてはEclipseやNetBeans、よくあるJavaで書かれたエンプラ系のお粗末なアプリなどのもっさり感がかなり印象を悪くしているんじゃないかという気がしないでもない.

ただ一点気になるのは幾つかのパーツでレスポンスがNativeに比べ数〜数十msec単位で重い事、昔のVBなどでも同様の印象のGUIが量産され、意識されるレベルぎりぎりである為「重い〜重くない〜」の論争になりがちな領域、ただこの手の無意識下に作用する問題はボディブローのようにジワジワと操作する人間に作用する. 遅延パターンの印象としてはマシン速度というよりはイベントと画面更新の繰り回しでミスった場合の挙動に似ている気がするのだが、Win32ならInvalidateRect〜UpdateWindowの細かい制御がレスポンス調整には必須となる個所、一方Javaで (多分) それに相当する paintImmediately の説明には 'このメソッドを呼び出す必要はほとんどありません' と書かれていて少々不安を煽られる気もしてみたり :-<

Java/C#を中断してWin32で使っているスクロールライブラリに手を入れる、よくあるクライアントサイズに合わせて必要であればスクロールバーを表示するというアレ、今まで使っていたのは1dot単位のスクロールしかサポートしておらずテキストエディタ等には不向きであった為、これを任意の単位でのスクロールに対応させた.

すぐ終わると高を括っていたが、双方向にスクロールバーを出す場合にクライアント領域見積もりの補正を一方の辺の補正結果に合わせて再度補正しなければならない事に気付かず3時間程悩む、今まで使っていたものにも問題があったのだが、任意単位でのスクロールをサポートしない場合特定の条件のみで1pixelの誤差しか出ない為気付かなかった模様、まぁ何とか改修完了.

思う所あって1日コーヒーを断っていたのだが、日常的に1日の水分摂取のほぼ100%をコーヒーで賄い100gのインスタントコーヒーを1週間足らずで開ける生活のせいか、やたら体はだるいわ、睡眠量は増えは、煙草は増えるは、頭は回らないは、最悪な事にプログラムも禄に書けないわという体たらく. お茶で誤魔化すものの、コーヒー程の利尿作用が見込めぬ為か、体内の水分調節が上手く行かず吐き気を催す始末.

スクロールバーの実装の必要が出てきて、コーディングを始めて暫くは我慢したのだが、結局まともに頭が回らないと話にならないという事で挫折、2杯程飲むとやはり全然調子が違う、、、一応完成したのでもう一度再開する予定だが、、、何か色々駄目かもという気もしてしまい少々落ち込むorz

まー、で何をやっているかというと

みたいなワケです.

---------------

C++/Java/C#とやってて少々気になった事、何故以下のように書けないかは考えてみても良いかもしれない.

if( (var a=foo())<0 && bar(a) ){
	...
}

結構使うタイプの条件判断、ちなみにfor,whileはちゃんとスコープを作成して上のような宣言を許可する(※1)のだが (それでも複合文だと駄目だが) 、、、コンパイラの実装上は左程問題無い筈で、何か中途半端な気がする:-<

※1) VC6のfor文のバグは有名な話、自分の場合割と深刻なデバッグ時には複数のコンパイラを併用して検証する事が多いので未だにこれの影響を受ける事になる :-<