« GetTextExtentExPointの続き | トップページ | Iである »

2007年1月10日 (水)

GetTextExtentExPointの締めくくり

えらい、まとまりのない文章になってしまった。前回でいきなり問題にぶつかったとかいてるが、要は自前でGetTextExtentExPointを使いクリッピングを行った方が速いか遅いかだ。ということで、パフォーマンスをとってみた。文字数10240の文字列(Unicodeだから20KBytes)をウィンドウのクライアント領域の左隅から計1万回描画してみた。

  • GDIのクリッピングに任せた場合:約4100ms
  • 自前でGetTextExtentExPointでクリッピングした場合:約5600ms

ははは。って感じである。逆に遅くなった・・・今回、GetTextExtentExPointを呼び出す時に渡すnMaxExtentにクライアント領域の幅ではなくクライアント領域の幅+マージンを渡している。なぜなら、今回はワードラップを行うのではなく、文字列を切り捨てるためにGetTextExtentExPointを呼び出しているので、クライアント領域の幅を渡すと、場合によっては、クライアント領域の一番右側に表示される文字がかって切り捨てられて、GDIのクリッピングに任せた場合と結果が異なってしまうからだ。マージンをどれくらい渡すかだが、GetTextMetricで返される構造体のtmAveCharWidth(平均文字幅)の3倍以上とっとけば、結果がずれることはほぼないだろう。ExtTextOutの呼び出しは前々回と同じように、GetTextExtentExPointで返されたlpnFitを文字数として、ExtTextOutの第7引数cbCountに渡している。

ところで、やはり、自前クリッピングの方が遅くなってるのは、前回書いたように、GetTextExtentExPointの呼び出しで毎回文字列全体の寸法(lpSize)が求められているためだろう・・・ちなみに、触れずにきたが、この話では、固定ピッチフォントと可変ピッチの両方を想定しているので、単純に幅の計算や切り捨てる部分の計算できない。

というか、巨大な長さの文字列を描画するはめにはなるかもしれんが、そんな文字列を現実問題1万回描画するシチュエーションが見つからない。描画対象が画面の場合、少なくとも縦方向の解像度数以上描画しても意味ないし、縦1200ピクセルだと多くても120回くらいになる。ということで、素直にGDIのクリッピングに任せた方が吉。ってことで終了。ははは

« GetTextExtentExPointの続き | トップページ | Iである »

Windows」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1497665/39651893

この記事へのトラックバック一覧です: GetTextExtentExPointの締めくくり:

« GetTextExtentExPointの続き | トップページ | Iである »

自作ソフトウェア

無料ブログはココログ

メモ