概要¶

グラフィックスのアーキテクチャを設計する¶

このガイドでは、SF32デバイスで応答性の高いグラフィカルユーザーインターフェースを構築する方法を説明します。ディスプレイの選定、フレームバッファーの構成、LVGLの統合、ePicassoによるハードウェアアクセラレーション、メモリー配置、画面の更新動作など、実製品に関わる設計判断を取り上げます。

SF32デバイスは、消費電力、メモリー、基板面積に厳しい制約がある小型AIoT機器やウェアラブル製品を想定しています。そうした製品では、システム要件を満たしながら、滑らかなUIを実現する必要があります。グラフィックス処理では、リソースの読み込み、ピクセルの合成、必要に応じたフレームバッファーの圧縮、パネルへの出力をそれぞれ分けて考えます。各処理の役割を理解しておくと、適切な最適化を選びやすくなります。

パネルとインターフェース、フレームバッファーの構成、色深度、透過、リソースの配置、画面更新の方針など、後から変更しにくいUIアーキテクチャを検討する際に活用してください。関連する各記事では、処理の個々の部分について実装方法を説明しています。

SF32グラフィックスフロー¶

グラフィックスリソースからパネルに表示されるまでの典型的な処理の流れを示します。

画像・フォント・アニメーション素材
        │
        ▼
GraphicsToolで、対応リソースをeZipまたはeZip-A形式に変換
        │
        ▼
圧縮リソースをNOR Flash、PSRAM、NAND、またはファイルストレージに保存
        │
        ▼
必要に応じてeZipハードウェアデコーダでリソースを展開
        │
        ▼
LVGLなどのUIフレームワークとグラフィックス／ディスプレイドライバー
        │
        ├── CPUによるフォールバックレンダリング
        │
        └── ePicassoによるピクセル処理の高速化
        │
        ▼
最終的な描画結果を描画バッファまたはフレームバッファに格納
        │
        ├── 非圧縮の表示経路
        │
        └── 任意：extDMAでTurboPixel形式に圧縮
                    │
                    ▼
             TurboPixel形式のフレームバッファをPSRAMに格納
        │
        ▼
ディスプレイコントローラーがピクセルをパネルへ転送
        │
        ▼
SPI / QSPI / 8080 / RGB / MIPI DSI / EPD / JDIパネル

この処理経路は構成可能で、すべての製品に必須というわけではありません。eZip、ePicasso、TurboPixelや画面全体のフレームバッファーを使わない構成もあります。各機能の対応状況と接続方法は、デバイス、SDK、ディスプレイインターフェース、パネル、ドライバーの構成によって異なります。現行のOpenSiFli LCDCヘッダーは、HAL_EXTDMA_MODULE_ENABLEDが有効で、チップ系列の条件を満たす場合にLCDC_SUPPORTED_COMPRESSED_LAYERを定義します。SF32LB52xとSF32LB57xは対象外です。また、ソースのコメントにはLCPU側では有効化されていないとの記載があります。公開SDKのLCDC機能表ではSF32LB55xの圧縮レイヤー展開が非対応とされているため、55xは実機での一連の動作が確認済みの対応ではなく、条件付きと考えてください。SDKの版、コア、ビルド設定、実機で経路全体を検証してください。詳しくはTurboPixelを参照してください。

アプリケーションコードはUIの状態と動作を記述し、UIフレームワークはウィジェット、再描画領域、描画処理を管理します。グラフィックス／ディスプレイドライバーはCPUとePicassoのどちらで処理するかを選び、バッファーを調整します。ディスプレイコントローラーはパネルへの転送を担当します。各機能の実装については、ePicasso、eZip、TurboPixelを参照してください。

まずディスプレイを選ぶ¶

ディスプレイの選択は、ほぼすべてのグラフィックス上の判断に影響します。コードを最適化する前に、パネル要件を明確に定義してください。

• 解像度。
• 色深度。
• リフレッシュレート。
• インターフェースの種類。
• タッチコントローラーの要件。
• バックライトやディスプレイの電源要件。
• 部分リフレッシュがサポートされているかどうか。
• パネルが内部GRAMを持つかどうか。
• 低消費電力の常時表示が必要かどうか。

小さなSPIまたはQSPI AMOLEDは、RGBパネル、MIPI DSIパネル、JDIメモリーディスプレイ、EPDパネルとは非常に異なる挙動を示します。同じUIフレームワークが多くのディスプレイタイプを対象にできますが、最良のバッファー戦略とリフレッシュポリシーは変わります。

インターフェース選定、描画データ転送経路の設計、パネルの立ち上げについては、ディスプレイコントローラーを参照してください。

検証済みのLVGL例から始める¶

画面を作り込む前に、製品のグラフィックス処理で最もリスクが高い部分を検証できるSDKの例を選んでください。LVGL SDKの例では、公式の基本例、デザインツール、ウィジェット、圧縮アセット、アニメーションとメディア、コンパス、ゲーム、時計インターフェースを、検証できる設計課題ごとに整理しています。製品へ移植する際に再検証が必要なボード、バージョン、ディスプレイ、メモリー、性能の前提条件も確認できます。

適切なSF32デバイスを選ぶ¶

CPU周波数だけでなく、ディスプレイとUIのワークロードに基づいてチップを選んでください。

最も重要な制約は、ディスプレイインターフェース、解像度、メモリー容量、グラフィックスアクセラレーターの世代、利用可能なピン、電力予算です。

フレームバッファーと帯域幅の計算¶

パネルやアニメーションスタイルを選ぶ前に、メモリーと転送コストを見積もってください。

framebuffer bytes = width x height x bytes_per_pixel
raw full-frame bandwidth = framebuffer bytes x frames_per_second

例:

バッファー容量はKiB（1,024バイト）、帯域幅は十進のMB/s（1,000,000バイト/秒）で示しています。これらは生のピクセルデータ量であり、コマンドのオーバーヘッド、アラインメント、キャッシュメンテナンス、リソースの読み出し、ブレンディング、システム内のその他のデータ転送量は含みません。BluetoothオーディオやAIを動作させたり、外部PSRAMをほかの用途で使ったりする製品では、さらに余裕を見込んでください。

バッファーを理解する¶

UIは最終的にメモリー上のピクセルです。主なバッファータイプは次の通りです。

画面全体のフレームバッファーは扱いやすい一方、大型パネルではSRAMを使いすぎることがあります。454 × 454のRGB565バッファーは412,232バイト（約412 kB、約403 KiB）で、ダブルバッファーではその2倍の容量が必要です。色深度や画面サイズを上げると、必要な容量は急速に増えます。

メモリーが限られている場合は、部分描画バッファーを使い、変更された領域だけを更新してください。アニメーションが重要でメモリーに余裕がある場合は、画面全体のバッファーやダブルバッファーを使うと、UIが滑らかになることがあります。

色深度を慎重に選ぶ¶

色深度は、視覚品質、メモリー使用量、バス帯域幅に影響します。

多くのウェアラブル製品や小型HMIでは、パネルや画質要件から高い色深度が必要でない限り、RGB565を標準候補にできます。

透過性、アルファ、レイヤー合成¶

透過性はアルファ係数によって表現されます。これは、前景ピクセルが背景ピクセルの上に描画されるときに、どれだけ強く寄与するかを指定する値です。アルファはRGBカラーチャンネルとは独立しています。不透明なピクセルはアルファ1（または8ビットアルファチャンネルでは255）を持ち、完全に透明なピクセルはアルファ0を持ちます。

背景が完全に不透明で、前景のRGB値がストレートアルファ（乗算済みではない色値）で表され、アルファが0～1に正規化されている場合、source-over合成の各出力RGBチャンネルは次式で計算できます。この簡略式では、透明な描画先の出力アルファは求められません。

output = foreground × alpha + background × (1 − alpha)

例えば、50%のアルファを持つアイコンのピクセルは、その色の半分を寄与させ、背景の半分を見えるままにします。この演算を繰り返すことで、背景、画像、テキスト、半透明のコントロール、影、アニメーションレイヤーといったUIの視覚的な重なりが生成されます。最終的に合成されたビットマップは、その後上記に示したフレームバッファーとディスプレイコントローラーの段階を経て進みます。

RGB565にはアルファチャンネルが含まれていないため、通常は不透明な描画対象と最終フレームバッファーに使用されます。アルファを必要とするソースアセットや中間レイヤーは、一般的にARGB8888のようなアルファチャンネルを持つフォーマット、あるいはカラー画像と別のアルファマスクの組み合わせを使用します。ドライバーは、SDK、ディスプレイパス、選択したアクセラレーターが実際にサポートするフォーマットを使用しなければなりません。

一般的なアルファ表現は2つあります。ストレートアルファでは、RGBは元の色を表し、アルファはブレンディング時に適用されます。プリマルチプライドアルファでは、RGBはすでにアルファが乗算されており、source-overの式はoutput = premultiplied_foreground + background × (1 − alpha)になります。この2つの表現を混在させないでください。ストレートアルファのデータをプリマルチプライドとして扱う、あるいはその逆を行うと、エッジ周りに暗いまたは明るいハローが生じます。

アルファ混合では、前景と描画先のピクセルを読み取って結果を書き込むため、単純な不透明コピーや塗りつぶしよりメモリーアクセスが増えます。選択した混合処理とピクセル形式をドライバーがサポートしている場合はePicassoを使い、未対応の場合に備えてCPU処理も残してください。PSRAMの帯域幅や消費電力に余裕がない場合は、画面全体にわたる半透明レイヤーを減らし、更新が必要な領域だけを描画して、中間サーフェスの使用も抑えてください。

LVGLの統合¶

LVGLは、ウィジェット、スタイル、入力処理、アニメーション、再描画領域の管理、ディスプレイドライバーとの接続機能を備えており、SF32デバイスで実用的なUIフレームワークです。

典型的なLVGL統合には次のものが必要です。

• ディスプレイドライバーの転送（flush）コールバック。
• 1つ以上の描画バッファー。
• LVGLのタイミング用のティックソース。
• タッチ、ボタン、エンコーダー、またはジェスチャー用の入力デバイスドライバー。
• 画像とフォントのためのアセット処理。
• ePicasso用の任意のハードウェアアクセラレーションフック。

ディスプレイの転送コールバックは、描画と出力をつなぐ境界です。コントローラーやDMAの動作については、ディスプレイコントローラーを参照してください。

LVGLポーティングの判断¶

画面の仕上げに入る前に、次のLVGL統合の詳細を確定してください。

適切に移植できていれば、画面側のコードは宣言的に保ちつつ、転送、同期、アクセラレーション、キャッシュの処理をドライバーに任せられます。

ePicassoアクセラレーションの利用¶

UIで同じようなピクセル演算を大量に行う場合、ePicassoが役立ちます。代表的な処理は次のとおりです。

• 矩形の塗りつぶし。
• 画像のコピーやblit。
• アルファブレンディング。
• 画像のスケーリング。
• サポートされる画像領域の回転または変換。
• レイヤー合成。
• ドライバーがサポートする場合のピクセルフォーマット変換。

移植時は、よく使う処理を高速化しつつ、未対応の処理にはCPUでの代替経路を残してください。LVGLのスタイル効果やウィジェットがすべてハードウェアで処理できるとは限りません。製品で実際に使う画面を測定して判断しましょう。

アクセラレーションが最も役立つ場合¶

ePicassoは通常、次のような場合に最も役立ちます。

• 大きな領域が塗りつぶされ、コピーされ、ブレンドされ、スケーリングされ、または変換される場合。
• UIが透明なアイコン、テキストマスク、影、オーバーレイ、アニメーション遷移を使用する場合。
• そうでなければCPUが各フレームの大部分をピクセルループの実行に費やすことになる場合。
• メモリー配置とピクセルフォーマットが、アクセラレーターが効率的に処理できるものと一致している場合。

アクセラレーションがあまり役立たない場合¶

次のような場合は、ハードウェアアクセラレーションの効果が限られることがあります。

• 更新される領域が非常に小さい場合。
• ボトルネックがレンダリングではなくパネル転送の帯域幅である場合。
• アセットがサポートされていないフォーマットやコストの高い変換を必要とする場合。
• バッファーが十分な帯域幅のない低速メモリーに配置されている場合。
• キャッシュメンテナンスのオーバーヘッドが演算を支配している場合。

メモリー配置戦略¶

グラフィックス性能は、メモリー間のデータ転送がボトルネックになることも少なくありません。用途に応じてバッファーの配置を決めてください。

• 頻繁にアクセスする描画バッファーは、可能であれば高速SRAMに置く。
• SRAMが不十分な場合にのみ、大きなフレームバッファーをPSRAMに保持する。
• 大きな画像とフォントはFlashまたはPSRAMに保存するが、アクセスレイテンシを考慮する。
• 実行時にアセットを繰り返し変換することを避ける。
• SDKのガイダンスに従って、DMAがアクセスするバッファーをアラインメントする。
• 全体のデータ転送量とデコードコストを削減できる場合は、圧縮形式やインデックスカラー形式のアセットを使う。

CPUとグラフィックス／表示ハードウェアがバッファーを共有する場合は、SDKのキャッシュ管理とバッファー所有権の規則に従ってください。CPUが書いたデータをハードウェアが読む前に、該当するキャッシュラインをcleanし、必要な同期を完了させます。ハードウェアがバッファーへ書く前には、CPUのダーティなキャッシュラインが後から書き戻され、結果を上書きしないよう準備します。転送完了を待ち、CPUが結果を読む前に古いキャッシュラインをinvalidateします。キャッシュラインのアラインメントと隣接データに注意し、ハードウェアが所有しているバッファーは変更しないでください。SDKの対応APIを使い、cleanとinvalidateを同じ操作として扱わないでください。

部分リフレッシュ、パネル固有の挙動、段階的な立ち上げシーケンスについては、ディスプレイコントローラーを参照してください。

アセットの準備¶

リソースを適切に準備しておけば、コードを最適化する前からUIを軽くできます。

以下の経験則を使用してください。

• 画像の寸法を実際の画面上のサイズに合わせる。
• 大きな画像を毎フレームスケーリングすることを避ける。
• 可能な場合は複雑な影、グラデーション、背景を事前レンダリングする。
• 透過性が必要な場所でのみアルファを使用する。
• 共有のアイコンセットとフォントサブセットを優先する。
• フォントから未使用のグリフを削除する。
• 頻繁に使用されるアセットは、グラフィックスパスが効率的にサポートするフォーマットに保つ。

多言語製品では、フォントのメモリーがUI予算を支配することがあります。フォントのフォールバック、グリフサブセット、テキストレイアウトを早期に計画してください。

アニメーション戦略¶

アニメーションの滑らかさは、フレーム時間の予算、パネル帯域幅、描画コスト、消費電力に左右されます。

実践的なアプローチ:

• ユーザーが気づくものだけをアニメーション化する。
• アニメーションする領域を小さく保つ。
• アクセラレーションにうまくマッピングされる変換や不透明度の変化を優先する。
• 毎フレーム、コストの高い全画面ブラー、影、透過性の効果を避ける。
• 重要でない効果はフレームレートを下げる。
• 画面が暗くなったり、別の画面に覆われたり、非アクティブになったりしたらアニメーションを停止する。

ウェアラブルUIのすべてにデスクトップのようなアニメーションが必要なわけではありません。消費電力を増やしたりフレーム落ちを招いたりする効果を多用するより、短く分かりやすい画面遷移を少数取り入れる方が、快適に感じられることが多いでしょう。

グラフィックス検証マトリクス¶

主観的な「十分に滑らか」というチェックの代わりに、再現可能な画面を使用してください。

画面ごとに描画時間、転送時間、CPU負荷、消費電力を記録してください。フレーム全体の所要時間しか測っていないと、ボトルネックがLVGL、ePicasso、メモリー、パネルインターフェースのどこにあるのか特定しにくくなります。

グラフィックス性能のデバッグ¶

UIが遅い場合は、設計を変更する前にボトルネックを特定してください。

これらを個別に測定してください。

• LVGLのレンダリング時間。
• ePicassoの演算時間。
• ディスプレイの転送時間。
• CPU負荷。
• メモリー帯域幅への圧力。
• アクティブ、アイドル、スリープ状態での消費電力。

よくある間違い¶

早期にこれらを避けてください。後で修正するとコストが高くなります。

• 帯域幅を見積もる前にパネルインターフェースを選んでしまう。
• 小さなUI変更のたびに画面全体を再描画する。
• 性能を測定せずに、すべてのUIリソースを低速メモリーに置く。
• RGB565で十分な場合にRGB888を使用してしまう。
• 大きな画像を毎フレームスケーリングしてしまう。
• ハードウェアと共有されるバッファーのキャッシュメンテナンスを忘れてしまう。
• ePicassoがすべてのUI演算を自動的に高速化すると想定してしまう。
• タイマーやアニメーションを使いすぎて、CPUをスリープさせられなくなる。
• フレームレートだけを最適化し、タッチのレイテンシを無視してしまう。
• パネル初期化の検証をPCB立ち上げまで待ってしまう。

立ち上げチェックリスト¶

新しいSF32グラフィックスプロジェクトを始める際は、次の項目を確認してください。

• ディスプレイの解像度、色深度、インターフェース、パネルドライバーICを確認する。
• 選択したSF32デバイスが必要なディスプレイインターフェースをサポートしていることを確認する。
• フレームバッファーと描画バッファーのメモリー要件を見積もる。
• 全画面か部分更新か、シングルバッファーかダブルバッファーかを決める。
• パネルのリセット、電源、バックライト、初期化シーケンスを検証する。
• LVGLのtick、ディスプレイ転送コールバック、入力ドライバーを実装する。
• 基本的な塗りつぶし、画像、テキスト、タッチの挙動を検証する。
• SDKとドライバーがサポートする場合はePicassoアクセラレーションを有効化する。
• 共有バッファーのキャッシュクリーン/無効化の挙動を検証する。
• 描画時間、転送時間、CPU負荷、消費電力を測定する。
• 最悪条件の画面、アニメーション、Bluetooth通信、スリープと復帰の経路をテストする。

要点のまとめ¶

• グラフィックス設計は、ディスプレイインターフェース、解像度、色深度、リフレッシュ要件から始めてください。
• ウィジェット、再描画領域、描画、入力の管理にはLVGLなどのフレームワークを使ってください。
• 一般的なピクセル演算の高速化にはePicassoを使用しますが、CPUフォールバックパスを維持してください。
• メモリー配置とバッファー戦略は、レンダリングコードと同じくらい慎重に最適化してください。
• 帯域幅が限られたパネルや静的なウェアラブル画面には部分リフレッシュを優先してください。
• UIの性能は、CPU、ePicasso、メモリー、ディスプレイコントローラー、パネルインターフェース、タッチ入力、電源管理が関わるシステム全体の問題として捉えてください。

最終更新: 2026-10-19