「Scaleform GFx」コンテンツのベストプラクティス

概要

「Unreal Engine 3」における Scaleform GFx の統合を利用して Flash のコンテンツを開発する際に最善のパフォーマンスを得るためには、守るべき事項および実装しなければならない最適化が多数あります。この文書では、それらのベストプラクティスを多数解説しています。

描画プリミティブ

描画プリミティブ (draw primitives、DP) とは、同一レイヤー上のシェープのグループのような 2D Flash の要素をレンダリングするために、GFx によって作成される 3D メッシュオブジェクトのことです。各描画プリミティブは、独立してレンダリングされ、かなり高いコストがかかります。概して、シーンに導入される DP (描画プリミティブ) が多くなれば、表示パフォーマンスはそれにつれて直線的に減少する傾向にあります。したがって、DP の数をできるだけ低く抑えることがベストプラクティスとなります。DP の数は、GFxPlayer HUD によって知ることができます。F2 キーを押すと、AMP HUD サマリーのスクリーンが表示されます。このスクリーンでは、トラインアグルの数、DP、メモリ使用、その他最適化情報が表示されます。

以下に、DP 数を押さえるのに役立つ事項をあげます。

1. グラディエント フィル (漸次的塗りつぶし) のいくつかが 1 つのシェープ内で同時に使用されると、DP の数を増やす可能性があります。
2. ベクター グラフィックスが、ソリッド フィル (濃淡のない塗りつぶし) をともない、同一レイヤー上にストローク (輪郭) がない場合は、コストが低くなります。単一のレイヤーにおいてこれらのタイプのシェープを表すには、それがどのくらいの量であっても、1 つの DP しか必要となりません。これは、シェープが異なるカラーを使用していても変わりません。
3. ベクター シェープ (またはベクター シェープのグループ) がそれ自身のレイヤー上にある場合は、ベクター シェープそれぞれが 1 つの DP を必要とします。
4. ストロークは、そのすべてが同一のソリッドカラーでない場合、フィルよりもコストが高くなります。
5. レイヤー上の異なる (異なるカラーの) ソリッド ストロークは、DP を 1 つ増やします。
6. 空のムビークリップは DP を必要としません。ただし、オブジェクトが中にあるムービークリップは、そのオブジェクトによって指示を受ける DP の量を必要とします。
7. アルファ、およびブレンド、透過処理は必要な DP 数に影響しません。ただし、レンダリング パフォーマンスには影響します。
8. ステージにおける各ビットマップ/テクスチャは、1 つの DP を必要とします。
9. 各テキストフィールドは少なくとも 1 つの DP を必要とします。境界/背景を追加すると、DP がもう 1 つ必要となります。たいていの場合テキスト グリフのすべては、1 つの DP を伴ったテクスチャからレンダリングされることになりますが、大きなテキストは、各グリフが個別のプリミティブを使用するベクター シェープとして描画されることになる場合があります。ベクター グリフのクリッピングが必要な場合は、テキストフィールドはマスクを使用します。それによって、DP が 1 つ増えることになります。現在のところマスクはパフォーマンスにかなり負荷をかけます。これにはクリップされたテキストフィールドが関わっています。

ムービークリップ

1. ムービークリップを非表示にするのではなく、使用されていないときにタイムラインから完全に除去するのが最善です。もしそうでない場合は、Advance 中に処理時間を占有する可能性があります。
2. ムービークリップの過度のネスティングは、パフォーマンスに影響があるので、避けるべきです。
3. ムービークリップを非表示にするには、 _alpha=0 ではなく、 _visible=false を使用する必要があります。非表示のムービークリップにおいてアニメーションを確実に停止させるために、stop() 関数を呼び出します。そうしなければ、非可視のアニメーションがまだ動作を継続するため、パフォーマンスに影響します。

ビットマップ 対 ベクター グラフィックス

Flash のコンテンツは、画像のみならずベクター アートを使用して作成することが可能です。GFx は、ベクター グラフィックスとビットマップ グラフィックスをシームレスにレンダリングすることができます。ただし、それぞれには長所と短所があります。ベクター グラフィックスとビットマップ グラフィックスのどちらを選択するかという問題は必ずしも簡単な問題ではありません。複数の要因に依存することが多いです。このセクションでは、ベクター グラフィックスとビットマップ グラフィックスの相違点について論じることによって、コンテンツ作成の決定に役立てます。

ベクター グラフィックスは、サイズをスケーリングした場合でもスムーズな形を維持できますが、ビットマップ グラフィックスはそれとは異なり、スケーリングすると箱状になったり、ピクセル化することもあります。ただし、ベクター グラフィックスは、ビットマップ グラフィックスよりも、生成にはより強力な処理能力を必要とします。単純なソリッドカラーのシェープであればビットマップ グラフィックスと同じくらい速いものの、トライアングルおよびシェープ、フィルを多く伴う複雑なベクター グラフィックスは、レンダリングによる負荷が大きいです。そのため、ベクター シェープを頻繁に使用すると、アプリケーション全体のパフォーマンスを低下させることがあります。概算で言えば、200 を超えるトライアングルを生成するベクター シェープであれば、ビットマップへの変換が最善となるでしょう。

ビットマップ グラフィックスの方が適するアプリケーションもあります。これは、レンダリングにベクター グラフィックスほど時間がかからないからです。ただし、ビットマップ グラフィックスは、ベクター グラフィックスに比較して著しくメモリの必要量を増加させます。

ベクター グラフィックス

ベクター グラフィックスは、他の画像フォーマットよりもコンパクトです。その理由は、ビットマップの生のグラフィック (ピクセル) データではなく、ベクターによって実行時に画像をレンダリングするのに必要な数的処理 (点、カーブ、フィル) を定義するからです。ただし、ベクター データを最終的な画像に変換するには、時間を要します。また、これは、グラフィックの見かけ、あるいはスケールに有意義な変化がある場合にはいつでも実行されなければなりません。ムービークリップに含まれる複雑なシェープの輪郭がフレーム毎に変化するのであれば、アニメーションの実行速度は遅くなります。

以下にあげるのは、ベクター グラフィックスを効率的にレンダリングする際に役立つガイドラインです。

• 複雑なベクター グラフィックスをビットマップに変換する試験を行い、これがどのくらいパフォーマンスに影響を与えるかをテストします。
• アルファ ブレンドを使用する際、次のことに留意します。
  • ソリッドフィルのストロークは、アルファ ブレンドのストロークよりも計算のコストは低い。これは、非常に効率的なアルゴリズムを使用しているためです。
  • 透過処理 (アルファ) の使用を避けます。Flash は、透明性のあるシェープの下にあるピクセルをすべてチェックしなければなりません。これによって、レンダリングの速度がかなり低下します。クリップを非表示にするには、 _alpha プロパティを 0 に設定するのではなく、 _visible プロパティを false に設定します。グラフィックスのレンダリングは、 _alpha が 100 に設定されると最速となります。ムービークリップのタイムラインを空のキーフレームに設定する (ムービークリップに表示するコンテンツがなくなる) と、さらに高速となります。Flash が非可視のクリップを依然レンダリングしようとすることがあります。その場合は、 _visible プロパティを false に設定するだけではなく、 _x および _y プロパティを可視的ステージから離れた位置に設定することによって、当該クリップをステージから除きます。 * ベクター シェープを最適化します。
  • ベクター グラフィックスを使用する際、余計な点を除去して、シェープを可能な限り単純化します。これによって、プレイヤーが各ベクター シェープについて計算しなければならない計算量が削減されます。
  • 円および正方形、線を含むプリミティブ ベクターを使用します。
  • Flash の描画パフォーマンスは、1 フレーム当たりいくつの点が描画されるかということに関連します。Modify (修正) -> Shape (シェープ) のサブメニューを使用してシェープを最適化します。次に、Smooth (スムーズ)、あるいは Straighten (直線化)、または Optimize (最適化) のいずれかを選択することによって (当該のグラフィックに依存します)、描画に必要となる点の数を削減します。これによって、GFx ベクター テセレーションのコードによって作成されるメッシュ データを削減することができます。
• コーナーはカーブよりも負荷が少ない。
  • 過剰なカーブおよび点をともなう複雑なベクターを避けます。
  • コーナーのレンダリングは、カーブよりも計算処理上単純です。可能な場合は、フラットなエッジを堅持します。特に、非常に小さいベクター シェープを堅持します。カーブはこのようにしてシミュレートすることができます。
• グラディエント フィルおよびグラディエント ストロークを倹約しながら使用します。
• シェープのアウトライン (ストローク) を避けます。
  • 避けられる場合は、ベクター シェープを伴ったストロークの使用を避けます。理由は、これによってレンダリングされるラインの数が増えるからです。
  • ベクター画像のまわりのアウトラインは、パフォーマンスヒット (余分な負荷) をもたらします。
  • フィルがレンダリングするのは外側のシェープだけですが、アウトラインがレンダリングするのは外側と内側のシェープです。 すなわち、ラインを描画する場合、フィルに比較して 2 倍の作業量が必要になるということです。
• Flash の描画 API の使用を最小限に抑えます。必要以上に使用すると、パフォーマンスのオーバーヘッドが著しく増加する場合があります。必要な場合は、描画 API を使用して、ムービークリップ上で 1 度描画します。このようなカスタムのムービークリップをレンダリングすることについては、パフォーマンス上の負荷はかかりません。
• マスクの使用を制限します。マスクされたピクセルが、たとえ描画されていなくても、レンダリング時間を依然消費し続けて、パフォーマンスに悪い影響を及ぼします。使用されるマスクの数に比例して、複数のマスクがこの影響に寄与します。多くの場合、アーティストがマスクを使用して求める視覚効果は、実際のところマスクを必要としないということに留意してください。特に、マスクを使用して、シェープをビットマップから切り取るのが一般的となっています。Flash Studio においてビットマップ フィルをシェープに直接適用することによって、同じことをはるかに効率的に行うことができます。これによって、Scaleform が特許出願中の EdgeAA アンチ エイリアシングによる利点が加わります。
• 可能な場合は必ず、複数のオブジェクトを 1 つのシェープに変換することによって、余分な描画プリミティブを生成しないようにします。
• シェープが作成された後は、余分なメモリを使わずに、平行移動および回転、ブレンドすることができます。ただし、新しく大きなシェープを生じさせたり、かなり規模の大きいスケーリングを実行する場合は、テセレーションによってより多くのメモリが消費されます。
• EdgeAA が有効になっていると、複数のソリッドカラーからビルドされたシェープは、複数のグラディエント/ビットマップからビルドされたシェープよりも高速にレンダリングします。1 つのシェープ内でグラディエント/ビットマップを接続すると、警告が出されます。これは、描画プリミティブの数が急激に増加するためです。

ビットマップ

最適化かつストリームライン化されたアニメーションまたはグラフィックスを作成する最初のステップは、これらを作成する前にプロジェクトの基本方針および計画を策定することです。ファイルサイズおよびメモリ使用、作成すべきアニメーションの長さに関するターゲットを指定するとともに、開発プロセス全体を通じてテストすることによって、プロジェクトが順調に進行していることを確認します。

レンダリング パフォーマンスに影響与える重要なファクターには、先に説明した描画プリミティブだけではなく、描画された総サーフェス面積があります。可視的なシェープまたはビットマップは、ステージに配置されるたびにレンダリングされる必要があり、ビデオカードのフィル レートを消費します。このことは、たとえ他のオーバラップするシェープによって表示されない場合であっても同様です。現在のビデオカードは、ソフトウェアの Flash よりも桁違いに高速ですが、オーバーラップしているアルファ ブレンドされた大規模なオブジェクトがスクリーン上にある場合、依然としてパフォーマンスを大きく低下させます。このことは、低性能および旧式のハードウェアでは特に顕著です。このような理由で、オーバーラップしているシェープおよびビットマップを平坦化させるとともに、不明瞭化またはクリップオフ化されたオブジェクトを明示的に非表示にすることが重要になります。

オブジェクトを非表示にするには、SWF ファイルにおいて _alpha レベルを 0 に変更するのではなく、ムービー クリップ インスタンスの _visible プロパティを false に設定するのが最善の措置です。GFx は、 _alpha 値が 0 のオブジェクトを描画することはありませんが、その子のせいで依然として、アニメーションおよび ActionScript に起因して CPU の処理に負荷が加わる場合があります。インスタンスの可視性が false に設定されるならば、CPU サイクルおよびメモリの節約のポテンシャルが保たれることによって、SWF ファイルがよりスムーズなアニメーションとなるとともに、アプリケーションの全体的パフォーマンスも向上します。アセットをアンロードしたり、場合によってはリロードする代わりに、 _visible プロパティを false に設定することによって、プロセッサへの負荷を著しく下げることができます。

以下に、ビットマップ グラフィックスを効率的にレンダリングするためのガイドラインをいくつかあげます。

• 幅および高さについては、2 の累乗を使用して、すべてのテクスチャ/ビットマップを作成します。ビットマップ サイズの例としては、16x32、256x128、1024x1024、512x32 などのようになります。
• 画像に JPEG 圧縮を使用しないでください。ファイルのロード中に解凍時間が必要となってしまいます。
• gfxexport ツールを使用する際は、DDS テクスチャ圧縮のスイッチを有効にして、最終の SWF ファイルを GFX フォーマットに変換できるようにすることによって、テクスチャによるビットマップ メモリの必要量を削減します。圧縮されたテクスチャは、圧縮されていないテクスチャと比較すると、ビットマップ メモリの節約量が最大 4 倍まで向上します。DDS フォーマットは情報損失の多い圧縮を使用します。したがって、生成されたビットマップのクオリティが充分なものであることを確認する必要があります。gfxexport の -qp または -qh オプションを使用することによって、最も高いクオリティの DDS テクスチャを得ることができます。（ただし、これらのオプションを使用すると、ビットマップ画像の処理に時間かかります）。
• より少ないビットマップを使用するか、あるいは、より小さなディメンションをもったたビットマップ使用します。あるいはその両方を実行します。
• ビットマップが、大きく単純なシェープを表示するために使用される場合は、ベクター グラフィックスを使用してビットマップを再作成します。これにより、Edge AA をともなった高いクオリティを実現できるとともに、メモリの節約にもなります。
• 必要に応じて ActionScript を通じて大きなビットマップをロードおよびアンロードすることを考慮してください。
• SWF/GFX ファイルのサイズは、メモリ使用量の判断基準にすべきではありません。SWF ファイルあるいは JPG ファイルのサイズがたとえ小さくても、ロードされて解凍されると多くのメモリを消費する可能性があります。たとえば、ある SWF ファイルに、1024×1024 の埋め込み JPEG 画像が含まれている場合、ファイルサイズは小さいでしょうが、実行時にはその画像のために 4MB のメモリが消費されることになるのです。（テクスチャ圧縮は想定していません）。
• UI で使用されている画像ファイルの数とサイズを監視し続けることが大切です。すべての画像サイズを計算し、それらを合計して 4 を乗じます。(通常、1 ピクセルにつき 4 バイトとなります)。テクスチャ圧縮を用いて画像のメモリ使用を 4 倍削減するために、gfxexport ツールは、 -i DDS オプションをともなって使用すべきであることに留意してください。AMP を使用して、ビットマップによって消費されるメモリ量をチェックします。
• 概して言えば、たいていのケースにおいて、ビットマップは複雑なシェープを高速で処理できますが、ベクターの方が美しく仕上がります。正確なトレードオフは、システムのフィル レートおよび変換シェーダー パフォーマンス、CPU の速度に依存して決まります。最終的には、これを知る唯一の方法は、ターゲットのシステムでパフォーマンスをテストするというものです。
• グラディエント テクスチャだけを含むマスター gradient.swf ファイルを作成して、必要に応じてこのファイルを他の SWF ファイルにインポートします。gfxexport ツールを使用し、 -d0 スイッチを利用して gradients.swf をエクスポートします。このスイッチによって圧縮が無効になります。また、これは、その swf ファイルの中にあるすべてのテクスチャに適用されます。それによって、このファイル内にあるすべてのテクスチャ (グラディエントを利用している) が、バンディングから確実に免れることができるようになります。
• アルファ チャンネルをともなったビットマップを可能な限り避けます。
• 画像処理アプリケーション (たとえば、Flash ではなく Adobe PhotoshopR) においてビットマップを最適化します。
• ビットマップの透過処理が必要な場合は、PNG を使用し、描画される総サーフェス面積を削減します。
• オーバーラップする大きなビットマップを避けます。理由は、フィルレートのパフォーマンスに影響するからです。
• ビットマップは、アプリケーションで使用するサイズでインポートします。大きなグラフィックスをインポートして Flash でスケールダウンしてはいけません。ファイルサイズと実行時メモリの浪費につながります。

アニメーション

アニメーションをアプリケーションに追加する場合は、FLA ファイルのフレームレートについて考慮します。最終的な SWF ファイルのパフォーマンスに影響を与える可能性があります。フレームレートの設定を高くしすぎると、パフォーマンス上の問題を招く可能性があります。特に、ドキュメントのフレームレートでティックされるアニメーションを作成するために、AS が使用されるたり、アセットが多数使用される場合に注意が必要です。

ただし、フレームレートもアニメーションのスムーズな再生に影響を及ぼします。たとえば、12 FPS (frames per second、1 秒当たりのフレーム数) に設定されているアニメーションは、毎秒ごとにタイムラインから 12 フレームを再生することになります。ドキュメントのフレームレートが 24 FPS に設定されている場合、アニメーションは、12 FPS で設定される場合よりもスムーズにアニメートされるように見えます。ただし、24 FPS のアニメーションは、12 FPS の場合に比較すると 2 倍の速度で再生されます。したがって、トータルの時間 （秒単位） は半分になります。そのため、5 秒間のアニメーションを高いフレームレートで作成するには、低いフレームレートで作成する場合に比べると、この 5 秒間を満たすために余分なフレームが必要となり、総ファイルサイズが大きくなるのです。

注意: onEnterFrame イベント ハンドラーを使用してスクリプト化されたアニメーションを作成する場合、アニメーションはドキュメントのフレームレートで動作します。これは、タイムライン上でモーション トゥイーンを作成する場合と同様です。onEnterFrame イベント ハンドラーの代替となるものが、setInterval です。フレームレートに依存せずに、指定されたミリ秒のインターバルで関数が呼び出されます。onEnterFrame の場合と同じように、setInterval がより頻繁に使用されて関数が呼び出されると、アニメーションによるリソースに対する負荷はいっそう大きくなります。

実行時にスムーズなアニメーションをレンダリングできる最低限のフレームレートを使用すべきです。これによって、プロセッサーへの負荷が軽くなります。30～40 FPS を超えるフレームレートを使用しないようにします。この値を超える高いフレームレートは、CPU の負荷を増加させるものの、アニメーションのスムーズ化にはさほど貢献しません。 たいていの場合、Flash の UI は、その基礎となるゲームのターゲット フレームレートの半分のレートに設定しても大丈夫です。

以下に、効率的なアニメーションを設計、作成するためのガイドラインをあげます。

• ステージにおけるオブジェクト数と、ものの動く速度が、全体的なパフォーマンスに影響を与えます。
• ステージに大量のムービークリップがあり、なおかつ、on/off を素早くスイッチする必要がある場合は、ムービークリップを付属/除去するのではなく、_visible = true/false を使用することによって、そのビジビリティを制御すべきです。
• トゥイーンの使用に充分注意してください。
  • 同時にあまりに多数のアイテムをトゥイーンしないようにします。トゥイーンまたはシーケンス アニメーション (あるいはその両方) の数を削減することによって、1 つの始まりが他の終わりになるようにします。
  • 可能な場合は、標準の Flash Tween クラスの代わりに、タイムラインのモーション トゥイーンを使用することによって、パフォーマンスのオーバーヘッドを著しく小さくします。
  • Scaleform では、標準の Flash Tween クラスの代わりに、CLIK Tween クラス (gfx.motion.Tween) の使用が推奨されています。その理由は、より小さく、速く、クリーンだからです。
• フレームレートは低く保ちます。理由は、高フレームレートと低フレームレートの差が顕著になる場合はそれほど多くないからです。フレームレートを高くすると、アニメーションのスムーズ性も高まりますが、パフォーマンスへの影響が大きくなります。ゲームが 60 FPS で動作しても、Flash のファイルを 60 FPS に設定する必要はありません。Flash のフレームレートは、望みの視覚効果を作り出すのに必要な最低限のレートにするべきです。
• 透過処理とグラディエントは、プロセッサーに負荷をかけるため、節約して使用すべきです。
• 焦点領域を充分に設計かつアニメートし、さらに、スクリーンの他の領域においてアニメーションとエフェクトを削減します。
• 遷移中は、受動的なバックグラウンド アニメーション (例: 微細なバックグラウンド エフェクト) を休止させます。
• アニメートされた要素の追加/削除についてテストすることによって、パフォーマンスに対する影響度について評価します。
• トゥイーンのイージングをうまく活用します。遅いハードウェアでは、遅れが出現します。
• 円を正方形に変形させるようなシェープ モーフィング アニメーションは避けます。CPU への負荷が非常に高いためです。シェープ トゥイーン (モーフィング) は極めて大きな負荷を CPU にかけます。理由は、シェープが毎フレームごとに再計算されるからです。負荷の大きさは、シェープの複雑度に依存します (エッジ、カーブ、交差の数)。ただし、これが有用なシナリオもあります。その場合は、負荷が許容範囲にあるかどうかを確認するためにプロファイリングする必要があります。4 トライアングル トゥイーンのコストは許容範囲にあるでしょう。本質的には、パフォーマンス/メモリがトレードオフの関係にあることを認識する必要があります。通常のシェープを表示すると、先のフレームにおいて効率的な表示を行うために、シェーダーのキャッシュ化とテセレーションを引き起こします。モーフをともなう場合は、シェープにおける、いかなる変化によっても古いメッシュが開放されて新しいメッシュが作成されるため、トレードオフは変化します。
• 最も効率的なアニメーションは、平行移動と回転です。アニメーションのスケーリングは避けるべきです。理由は、それによって再テセレーションが生じるとともに (これによって顕著なパフォーマンスへの負荷が発生する可能性があります)、その結果もたらされるメッシュもより多くのメモリを消費することがあるからです。

テキストとフォント

• テキストグリフのフォントサイズは、フォントキャッシュ マネージャである SlotHeight よりも小さいか、あるいは gfxexport とともに使用することになっているサイズ (デフォルトでは 48 ピクセル) でなければいけません。それよりも大きなフォントが使用された場合は、ベクターが使われることになり、その結果生じる DP のために著しく低速化します。(各ベクターのグリフは 1 つの DP を生成します)。
• 可能な場合は、境界とバックグラウンドを無効にすることによって、1 つの DP を節約します。
• 毎フレームごとにテキストフィールドのコンテンツを更新するのは、パフォーマンスに対して最大の負荷をもたらします。これは簡単に避けることができるはずです。すなわち、テキストフィールドの値は、そのコンテンツが本当に変更した場合に限って変更するか、あるいは、できるだけ低速で変更します。たとえば、秒を表示するタイマーを更新する場合は、30 FPS のフレームレートで更新する必要はありません。すなわち、古い値を記録して、新しい値がその前の値と異なった時にのみ、テキストフィールドの値を再割り当てします。
• テキストフィールドにリンクした変数は使いません (TextField.variableプロパティ)。理由は、テキストフィールドが毎フレームごとに変数を読み込んで比較することでパフォーマンスに影響を与えるからです。
• htmlText プロパティを再割り当てすることによって、テキストの更新を最小にします。HTML をパースする処理は、負荷が比較的大きい。
• -fc、 -fcl、 -fcm オプションを付けて gfxexport を使用することによって、フォントをコンパクト化して glyph シェープにかかるメモリを節約します。(特に、アジア系言語のフォントが埋め込まれている場合)。詳細については、『Font Overview』(フォントの概観) ドキュメントをご覧ください。
• ローカリゼーションが必要な場合は、フォントの必要なシンボルだけを埋め込むか、あるいは、fontlib の機能を利用します。(繰り返しになりますが、『Font Overview』(フォントの概観) ドキュメントをご覧ください)。
• TextField オブジェクトは、必要最小限の数を使用するようにします。そのため、可能な場合は必ず、複数のアイテムを 1 つのアイテムにまとめます。単一のテキストフィールドは、通常 1 つの DP をともなってレンダリングされます。これは、さまざまなカラーとフォントスタイルが使われている場合でも同様です。
• テキストフィールドのスケーリング、および大きなフォントサイズの使用は避けます。あるサイズを超えると、テキストフィールドはベクターグリフに変わり、ベクターグリフはそれぞれ DP になります。クリッピングが必要な場合は (ベクターグリフの部分だけが見えます)、マスクを使用します。マスクは低速で、余分な DP を加えます。ラスタライズされたグリフのクリッピングにはマスクが必要ありません。
• グリフのキャッシュサイズが、使用されているグリフすべて (またはほとんど) を保持するのに充分大きいことを確認します。キャッシュサイズが充分ではない場合は、消滅するグリフが出てきます。あるいは、グリフの頻繁な再ラスタライズが行われ、パフォーマンス上の深刻な負担となります。
• ブラーやドロップシャドウ、ノックアウト フィルターといったテキスト エフェクトを使用すると、フォントのキャッシュに余分なスペースが必要となり、パフォーマンスに影響を及ぼします。テキスト フィルターの使用をできるだけ最小限に抑えます。
• アンダーラインの入ったテキストフィールドの使用は避けます。余分に DP が増えます。