INASOFT 管理人のひとこと

■クリップボードの中身が画像の場合に対応してみた続き！…マウスのお供v1.62.05β

• クリップボード内の画像を表示するとき、一辺のサイズが320ピクセルを超えていたら縮小表示するようにした。
  
  
  
• クリップボード内に画像があるときにクリップボードをクリアしても、表示内容が更新できていなかったので修正。（昨日のブログのコメント欄での指摘より）
• クリップボードの監視で遅延設定をしていなかったとき、クリップボードからの画像取得でリソースリークが発生していたため修正。（昨日のブログのコメント欄での指摘より）

ところで、ヘルプ内にも書いてありますが、コピーした画像の中に真緑(R=0, G=255, B=0)のピクセルがあると、そのピクセルは通過色扱いになります。

今のところ仕様ということになりますが、長期的にどうしようかは考え中です。本ソフト内の他の機能と衝突しないシンプルな解決法が見つかれば、その時また考えようかと思います。

実は昨日、フィードバックより「フォントのアンチエイリアスが効いていないようですが」というお問い合わせもいただいております。これは仕様です。

背後で動作している他ソフトウェアのピクセルと、ほどよくミックスした色を表示しなければならないとか、考えるだけで気が狂いそうな気がするので。アンチエイリアスは行わないようにしています。

普通は、自プログラムの背景に対して文字描画を行うことになります。これならOSが自動的にアンチエイリアス処理をしてくれるので、プログラマーは何も考えなくてよいことになります。もし本プログラムで何も考えずにアンチエイリアスをONにしてしまうと、背景通過用のグリーンバックの緑色を背景としてアンチエイリアスな文字描画が発生するため、中途半端な濃度の緑の部分が現れ、そこが通過しなくなり、文字の周辺にヘンな緑色が漂う微妙な文字が描画されることになります。

昔だったら、若気の至りでDirectDrawを使ってみようかとか、GDI+でなんとかならないかとか、背景を画像としてキャプチャ（コピー）して一時的に自ウィンドウの一部として描画した上、そこへアンチエイリアスなフォントの文字を描画しようかとか考えたかもしれませんが、ちょっとムリ…。

ただ、なんとなくこの2つの問題は、そのシンプルな解決法が見つかれば同時に解決されそうな気がしています。

カラーキー指定でなく、アルファ値指定で半通過ウィンドウを作る例のアレが、うまく活用できれば、どうにかならないかな、と。

とはいえ、文字全体を均一の濃度で表示したいのではなく、アンチエイリアスっぽさを実現するために文字の一部（主に端っこ）のみを薄めに表示したいということになります。文字の場所により、描画すべき濃度が異なるわけです。それどころか、サブピクセルレンダリングとかいう、文字の端っこに色がついているケースもあります。

というわけで、指定サイズでフォントを描画した時に算出されたアンチエイリアスのほどよい濃淡情報（ピクセル単位）およびサブピクセルのための色情報を何らかの方法で抽出してアルファ値に置き換えて、CreateDIBSection() APIに与えてピクセル単位の半通過情報のみのビットマップデータを作って、アルファ値付きのメモリデバイスコンテキストを作って(CAPTUREBLT付きのBitBlt)、UpdateLayeredWindow() APIに渡してやる。それを秒単位で更新される文字情報ごとに動的に変化させつつ・・・頭が痛くなってきた。

ちなみに、濃淡情報およびサブピクセルのための色情報のピクセル単位での抽出は、おそらく、メモリデバイスコンテキスト上に仮にDrawText() してみた結果をピクセル単位で取り出すとか、GetGlyphOutline() APIでがんばるとかですね。本ソフトの場合、秒単位での描画が必要になるほか、描画される文字は毎回変わります。毎秒毎秒CPUパワーを湯水のごとく使うことになりそうです。

頭痛くなりついでですけど、ゲーム機…例えばNintendo3DSのすれ違い通信のゲームアプリで、すれ違ったキャラとハイタッチした瞬間、人数を示す文字が一瞬拡大・縮小するんですが、あの人数の文字って、アンチエイリアスがかかっていますよね。

一瞬一瞬ごとに、アンチエイリアスの位置は変化しているだろうし、きっと動的に再計算が走っているだろうし、…もっと頭が痛くなってきたので、やっぱり頭が痛くなってきたので今日はここらへんで。