SDL_ttfのベンチマーク結果
2005年11月14日
条件を以下に示す。
1．テストにはAfter X-TT ProjectのFS-Gothicを利用する。
2．フォントのラスタライズ・ピクセルデータの生成・ピクセルデータの破棄の一連の動作を、「フォントの描画処理」と定義する。
3．今回は、一つのフォントの描画処理にかかる時間を評価対象とする。
4. フォントは24ポイントのものに限る。
5. ラスタライズするのに使う関数はTTF_RenderUNICODE_Blendedを用いる。
6．OSは、手元にあるWindowsに限る。
計測に用いるタイマーの精度が1(ms)であるため、もし1回の描画が1(ms)以下で終わってしまった場合には、描画速度が計測できない。そこで、今回はN回描画と生成を繰り返しすことで、1(ms)以上描画に時間がかかるようにNを設定し、そのデータをNで割ることでタイマーの精度を超えた計測を可能にする。
また、測定データに対してN回同期加算を行い、同期加算回数で正規化することで、測定に影響するような外乱に対して√N倍の精度で測定が行えることが保障されている。そのため、外乱はたいした問題ではない（ただし、変化しない、例えば常駐ソフトなどによるコンスタントな外乱や、真の測定データに対して大きすぎるデータの変化は問題となる）。
7．同期加算回数はN=100とする。
測定データを示したグラフの縦軸はフォントデータのラスタライズとBlendedピクセルデータの生成（アルファチャネルにラスタライズデータの描画）にかかった時間（ms表示）、横軸は文字コードを示している。
結果から考察できることを列挙する。
1．Celeron 733MHzやMobile Duron 900MHzでは常駐ソフトが起動していた。そのため、描画にかかる時間は他の場合に比べて急激に上昇している（常駐ソフトの影響は大きい）。
2．2.以外の場合ではフォントの描画には平均して0.1[ms]程度しかかかっていない（AthlonXP2000+においては30[us]程度でフォントの描画処理は完了してしまう）。
通常、文字生成はリアルタイムで行えることが望ましい。画面のFPS=60の際、1FPSの処理時間に対してフォント描画処理が占める時間的割合を計算すると
0.1/(1/60*1000)=0.006=0.6[％]
従って、たった0.6[％]となる（ただし、これは1FPSに一文字生成する場合に限った結果である。文字間の表示ウェイトは10〜20[ms]であることがほとんどなため、1FPS(16.777...(ms))で1文字表示ちという計算が妥当であると判断した）。1FPSに100文字描画しなければならない場合は、10[ms]かかることになる。この場合
10/(1/60*1000)=60[％]
となり、リアルタイムで100文字生成は難しいことがわかる。
もし常駐ソフトが起動していた場合は、平均して約0.5[ms]フォント描画処理にかかるとすると
0.5/(1/60*1000)=3[％]
となる。経験上、1FPS中の3[％]の処理にかかる割合は大きい（ここにリアルタイムでの画像処理や楽音信号の処理が入ってくるからだ）。従って、常駐ソフトは起動しないことが望ましい。
今回のテストで大体わかったが、SDL_ttfを用いても描画速度的には全然問題無い。一応、次はSDL_kanjiを用いてやってみようと思う。
コメント