INASOFT 管理人のひとこと


フリーソフトダウンロードサイト「INASOFT」の管理人 矢吹拓也 が日々の「ひとこと」を語るページです。
2021年1月1日より、旧ブログ(blog.inasoft.org)からお引越ししました。
・INASOFT Webサイト: https://www.inasoft.org/
・管理人のふたこと(長文記事/寄稿文): https://www.inasoft.org/talk/
本業の方のお仕事が再び忙しくなりつつあるので、断続的にしばらく更新が止まることがあります。

目次 | ←前へ / 2019-12-19 01:52 / 次へ→ / 最新へ⇒

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

2019/12/19 1:52:03


RSSRSS配信中

https://www.inasoft.org/








昨日の対応の続きです。

本日付で「マウスのお供v1.62.05β」を公開しています。

更新内容は、昨日のブログで予告していた件を含め、以下の通り。

  • クリップボード内の画像を表示するとき、一辺のサイズが320ピクセルを超えていたら縮小表示するようにした
    20191219_mtmo_imageclip2.jpg

  • クリップボード内に画像があるときにクリップボードをクリアしても、表示内容が更新できていなかったので修正。(昨日のブログのコメント欄での指摘より)
  • クリップボードの監視で遅延設定をしていなかったとき、クリップボードからの画像取得でリソースリークが発生していたため修正。(昨日のブログのコメント欄での指摘より)
縮小表示については、昨日はStrechBlt() APIを使おうかと考えていましたが、描画のたびに縮小のためにCPUパワーを使うのも無駄な気がしましたので、クリップボードから得たビットマップハンドルをコピーするためのCopyImage() の段階で縮小しておき、保持しつづけておくことにしました。


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

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

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

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

20191219_antias.png

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

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

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

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

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

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

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

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

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




目次 | ←前へ / 2019-12-19 01:52 / 次へ→ / 最新へ⇒


目次の表示:


ブログではないので、コメント機能とトラックバック機能は提供していません。ご質問・ご意見等はメールフィードバックまたはTwitter等からお願いします。いただいたご質問・ご意見などは、この「管理人のひとこと」の記事に追加、あるいは新規の記事にする形で一部または全文をそのまま、あるいは加工させていただいた上で、ご紹介させていただく場合があります。
当サイトでは掲載内容による不具合等に関する責任を持ちません。また、内容の正確性についての保証もありませんので、情報をご利用の際は、利用者の自己責任で確認をお願いします。本ページは公開から1年半後の任意のタイミングで削除される予定です。




2557645 (+0456)[+0622]

Copyright© 2010-2021 INASOFT