一般的なUIコンポーネントのパフォーマンス
このセクションでは、大部分のUIコンポーネントが使用するTouchGFXの一般的な描画操作のパフォーマンスについて説明します。
画像描画
ほぼすべてのUIコンポーネントは、ほぼ1つ以上の画像の描画に依存しているので、画像描画はTouchGFXにおける最も重要な描画操作の1つです。 このため、システムが画像を高速かつ効果的な方法で描画できることは、多くの場合に極めて重要です。 画像描画のパフォーマンスに影響する要因は数多くあります。 しかし、ほぼすべてのハードウェア設定において、TouchGFXでの画像描画は他の描画操作に比べて高速であると考えられています。
データ･コピーへのハードウェア･サポート
TouchGFXは、非圧縮の画像データを、選択した画像フォーマット（RGB565、L8、ARGB8888など）で保存します。 非圧縮フォーマットの利点は、ほとんどの場合にTouchGFXが画像を直接使用し、変換なしでフレームバッファに転送できることです。 マイクロコントローラにDMAが搭載されている場合、メモリのコピーにはこの機能が使用されます。転送速度がアップし、マイクロコントローラの負荷が最小化されるからです。
このアプローチに対する制限の1つは、画像フォーマットにアルファ･チャネルが含まれる場合です。 この場合、マイクロコントローラがフレームバッファ･ピクセルによって画像データのピクセル･ブレンディングを実行する必要があるため、通常のDMA転送は使用できません。 ただし、Chrom-ART / DMA2Dなどのグラフィックス･アクセラレーション搭載のSTM32を使用している場合は、これらのタイプの画像にもDMAを利用できます。 この場合は、DMAがデータをコピーするだけでなく、実際にはコピーとブレンディング操作を一気に実行するので、速度が向上し、マイクロコントローラの負荷も大幅に軽減されます。
画像フォーマット
ハードウェアの構成によっては、画像フォーマットも画像描画のパフォーマンスに影響します。 大まかに言うと、転送するデータの量が少ないほど、より早く転送できます。 つまり、ほとんどの場合、RGB565画像の転送は同等のRGB888に比べて早くなります。これは、RGB565画像は同等のRGB888画像の3分の2のサイズであるためです。
画像データへのアクセス
画像データへのアクセスに必要な時間は非常に重要です。画像を描画するたびにアクセスされるからです。 TouchGFXのアプリケーションでは、画像データを、アクセス時間の異なるさまざまなハードウェアに保存できます。
| 画像データの保存場所 | 説明 |
|---|---|
| 外部Flash | 外部Flashの利点は低コストであることとサイズです（大容量であることが多い）。これにより、アプリケーション内で多くの画像を取り扱うことができます。 ただし、アクセス時間が大きく異なります。しかしQSPIやそれと同等のものを選択すれば、高スループットが得られ、画像描画のパフォーマンスが大きく向上します。 |
| 外部RAM | 画像を外部RAMにキャッシュする必要が生じることもあります。 TouchGFXで、画像描画に直接使用できない非メモリ･マップドFlash（NANDやEMMCなど）を使用せざるを得ないケースがよくあります。 この場合、外部RAMへのアクセスは、アプリケーションでの画像描画のパフォーマンスにとって必須の要因になります。 |
| 内部Flash | 内部Flashの容量は非常に制限されてはいますが、画像の一部またはすべてを内部Flashに保存するケースもあります。 アクセスは非常に高速なので、アニメーションに不可欠な画像がいくつかあり、パフォーマンスが問題になる場合（テクスチャ･マッパーで使用される場合など）は、可能であれば内部Flashへの保存を試してみる価値があります。 |
| 内部RAM | 非常に稀ですが、内部RAMから画像を描画するケースがあります。 ストレージ容量は非常に制限されますが、アクセス時間は非常に速いので、（TouchGFX Image Cachingを使用して）ここに保存された画像は非常に高速で描画されます。 |
フレームバッファへのアクセス
画像を描画すると必ずフレームバッファが更新されます。 画像にアルファ･チャネルが含まれる場合、実際にピクセルをブレンディングするために、フレームバッファ内にピクセル･データを書き込むだけでなく、ピクセル･データの読取りも行います。 したがって、フレームバッファの保存用に使用しているRAMへの読取り / 書込みアクセス時間は、優れた画像描画パフォーマンスを得るための鍵になります。
画像解像度
転送が必要なデータ量は画像の解像度に比例するため、必然的に画像解像度は画像描画操作に影響します。
透明度
画像の不透明度は、画像の描画時間に影響します。 アルファ値のある画像は、フレームバッファとのブレンディングが必要になるので、ない画像よりも描画時間が長くなります。 つまり、ブレンディング操作ではフレームバッファからの読取りが必要になりますが、塗りつぶし画像の場合はフレームバッファ内のデータを単純に上書きできます。 これはハードウェア･アクセラレーションを実装している場合でも同じです。 ただし、塗りつぶし画像と半透明の画像の描画の比率は、セットアップごとに異なる可能性があります。
マイクロコントローラ描画
一部のウィジェットはフレームバッファの直接操作に依存しています。 このアプローチでは、無効な領域でピクセルごとに1回以上の計算を実行してから、フレームバッファ内のそのピクセルを更新します。 これはかなり時間がかかる操作で、各ピクセルの計算が複雑な場合は特に低速になります。
マイクロコントローラ描画で多くの計算を実行する場合は、マイクロコントローラの処理能力が不可欠です。 フレームバッファへのアクセス（内部または外部RAMへのアクセス）も影響を与えます。フレームバッファ･データの書込み（および読取りも）が、無効な領域内でピクセルごとにアクセスされるからです。
Canvas Widget（キャンバス･ウィジェット）
Canvas Widgetは、アンチエイリアスされた幾何学形状を描画する、特殊なタイプのTouchGFXウィジェットです。 通常は極めて複雑なので、描画もかなり低速になります。
描画時間は、幾何学形状の無効な部分のサイズと直線的に比例します。
Canvas Widgetには、計算の中間結果を保存するためのメモリ･ブロックが必要です。 このブロックのサイズとパフォーマンスへの影響については、Canvas Widgetのセクションを参照してください。
Tip
circle::updateArc(...)を使用します。この方法ではサークル全体を無効化せずに、変更部分のみを無効化します。 最適なパフォーマンスを得るためには、この種の操作を必ず使用してください。テキスト
テキストの描画は画像を描画することになります。つまり、テキストのセクションで示したように、使用される文字はすべて画像に変換されるからです。 この画像はA4フォーマットで、基本的に画像内のピクセルごとに4ビットのアルファ値が割り当てられます。 このパターンに色を適用すると、アンチエイリアス処理された文字の画像になります。
テキストの描画では1文字ごとに一連の画像描画操作が行われるので、画像描画のパフォーマンス特性がテキストの描画にも適用されます。ここには、Chrom-ART / DMA2Dなどのハードウェア･アクセラレーションを使用したパフォーマンスの向上も含まれます。