開発のヒント

使用できるリソースに限りのある組み込みシステム向けGUIの開発において、メモリ使用量の削減はコストの削減·部品点数の削減の観点から非常に重要です。前編ではフレームバッファの削減方法について紹介しましたが、後編では画像データやフォントデータを格納するFlashメモリ使用量の削減方法を紹介します。

TouchGFXでは、以下にあげる4つのFlashメモリ使用量の削減方法を提供しています。L8画像フォーマット、画像圧縮（L8、RBG）、SVG（スケーラブル·ベクタ·グラフィックス）およびベクタ·フォントです。

L8画像フォーマットは、 256の異なる色からなるカラー·パレットとピクセル当たり1byte（＝カラー·パレットの256色に対応）のピクセル·アレイからなる画像フォーマットです。使用可能な色数は限定されますが、ピクセル当たりのデータ量を色深度24bitの通常のビットマップと比較して1/3に削減できます。描画時には、ピクセル·データを1つずつ読み取り、カラー·パレットで対応する色を見つけてフレームバッファに書き込むという作業を行います。これはChrom-ARTアクセラレータでサポートされるため、描画にかかる時間は通常のビットマップとほぼ同等です。

画像圧縮を行うことで、さらにFlashメモリの使用量を削減できます。画像圧縮は2つの画像フォーマット（L8、RGB）に対して行われ、それぞれ異なるアルゴリズムが適用されます。RFG画像圧縮は、RGB565、RGB888、RGB8888画像に対して適用可能です。圧縮された画像を描画する際には、ソフトウェア的に解凍されたのち、ハードウェア·アクセラレータを使用して描画を行うため、CPUの負荷が大きくなります。このため、すべての画像を圧縮することは推奨されていません。性能に悪影響を及ぼさず、Flashメモリの使用量削減に直結する画像にのみ適用してください。また、圧縮された画像は、スケーラブルなウィジェットや回転可能なウィジェットでは使用できません。画像圧縮についての詳細は、TouchGFXオンライン·ドキュメントのこちらの記事を参照してください。

SVGは、ピクセルの集合体として画像を構成するビットマップ画像とは異なり、元となる少数のデータから長方形や曲線などの幾何学図形を演算によって構成する画像フォーマットです。ほとんどの場合、ビットマップ画像よりデータ·サイズが小さくなります。また、スケーラブルであるため、拡大·縮小を行う際にも画質を保てます。一方、画像の構成時に演算処理が入るため、描画時のCPU負荷が大きくなりますが、NeoChromハードウェア·アクセラレータを使用することで、この処理はハードウェア的にサポートされます。

ベクタ·フォントも、描画の方法としてはSVGと同じです。大きなサイズのフォントや異なるサイズのフォントを使用する場合にも、フォント·データを1回格納するだけで済み、Flashメモリの使用量を削減できます（フォントサイズは、スケーリング·ファクタにより表現されます）。

参考として、以下の画像データ（アイコン付きボタン：色深度32bit、ボタンのサイズ122 x 112ピクセル）に対して、上記のFlashメモリ削減方法（ベクタ·フォントを除く）を適用した際の例を記載します。測定はSTM32U5G9J-DKで行いました。

画像フォーマット	サイズ	描画時間	CPU負荷
ビットマップ	75.4KB	0.414ms	2.4%
L8	19.3KB	0.448ms	2.3%
L8画像圧縮	2.55KB	1.51ms	9.6%
RGB画像圧縮	4.53KB	1.65ms	10.5%
SVG	3.01KB	1.43ms	4.1%

上記からわかるように、画像サイズと描画時間·CPU負荷にはトレードオフがあります。したがって、アプリケーションのボトルネックを特定し、アプリケーションにとって何が重要なのか（パフォーマンスなのか、Flashメモリの使用量なのか）を判断する必要があります。

「TouchGFXにおけるメモリ使用量の削減方法」（1）はこちら

過去の開発のヒントはこちら