GPUで鮮明なテキストをレンダリングする
(osor.io)- 従来の Multi-Channel SDF 方式には、細いストローク、大きなアトラス、縮小・拡大、滑らかな移動に限界があり、GPUランタイムラスタライズとして再実装した
- 新しいパイプラインは、現在見えているグリフの Bézier 曲線データだけを GPU に送り、ランタイムでアトラスに描画してから画面上でサンプリングする
- グリフが画面に残っている間はアトラスキャッシュを維持しつつサンプルを蓄積して品質を高め、最初のフレームでは 8 samples-per-pixel から始めて最大 512 samples まで精製する
- キャッシュキーには font、glyph_index、ピクセルサイズと サブピクセルオフセット が含まれ、8ビット固定小数点で近い位置とサイズを同じ値に畳み込んで再利用性を高める
- モニターごとの RGB サブピクセル構造をサンプル領域としてモデル化すれば、OLED G9 のような非標準配列でも色にじみを減らせ、4K フルスクリーンのテキストデモは Radeon 9070 基準で約 0.1ms のピークコストを示した
SDF の代わりにランタイムのベクターラスタライズを選んだ理由
- 既存実装では Multi-Channel Signed Distance Fields を使っており、概ねうまく動作していたが、実運用ではいくつかの制約が残っていた
- 品質: 細いストロークや細部の多いフォントでは特徴が失われたりアーティファクトが出たりし、より高解像度の SDF が必要になる場合があった
- アトラスサイズ: SDF はオフライン生成後にアトラスへ保存するため、グリフ数の多い日本語・中国語フォントは単一アトラスに焼き込むのが難しい
- 柔軟性: 縮小・拡大の問題やサブピクセルアンチエイリアシングのような新しいアイデアを適用しづらく、ランタイム生成・編集可能なベクター画像にも向いていなかった
- 単純さ: 元のグリフ曲線を中間テクスチャに変換する段階がシステムの複雑さを増していた
- Miama のようなラテンフォントでも、グリフごとに
64×64領域を使う4096×1152アトラスが必要で、複数フォントをランタイムで使うとメモリとストリーミング帯域幅のコストが大きくなる - 新しいアプローチの目標は、グリフ制作者が作った Bézier 曲線をより直接的に使い、元データから最終ピクセルまでの変換段階を減らすことにある
全体パイプライン
- 核心は、オフラインですべてのグリフを事前に焼き込む代わりに、現在見えているグリフ の曲線だけを GPU に送り、必要な瞬間にラスタライズする方式である
- 処理の流れは単純
- フォントからグリフ曲線データを読み込む
- GPU がランタイムでグリフをアトラスにラスタライズする
- 画面出力時にそのアトラスをサンプリングする
- 同じグリフが以後のフレームでも使われ続ける場合はアトラスに残し、サンプルを蓄積して 高品質なサブピクセルアンチエイリアシング まで精製する
- ベクター表現を直接レンダリングするため、解像度変化への対応が容易で、ピクセル全体のカバレッジだけでなく各サブピクセル要素のカバレッジまで計算できる
グリフ曲線処理
- フォント読み込みには FreeType をオフラインツールの中間層として使い、対応フォーマットを読み込み、各グリフの曲線を走査して独自アセット形式で保存する
- グリフ曲線には 線分、2次 Bézier、3次 Bézier が含まれうるが、シェーダーを単純化するため、すべて 2次 Bézier に変換する
- 線分は 2点の中間に制御点を 1 つ追加して 2次 Bézier にする
- 3次 Bézier は 2つの 2次 Bézier に分割する。これは次数を下げる損失変換である
- 3次 Bézier を 2つの 2次 Bézier に分割する方式は、試したフォントの大半で十分うまく機能したが、誤差をさらに減らすより精巧な方法も考えられる
- より高品質な変換が必要なら、オフラインツールで TrueType
.ttfのような 2次 Bézier のみを持つ形式 に変換し、この変換自体を避けることもできる - Desmos グラフ では、入力の 3次 Bézier と変換後の 2つの 2次 Bézier の形状を比較できる
カバレッジ計算と曲線アクセス最適化
- カバレッジはピクセル単位で水平レイを左から右へ飛ばし、曲線との交差を調べて winding number を蓄積する方式で計算する
- 数学的背景と実装については GreenLightningの GPU Font Rendering と Sebastian Lague の Rendering Text 動画 を参照できる
- 交差計算の不正確さは特定の高さのサンプルで発生しうるが、数百サンプルを蓄積すれば 1〜2 個の誤差は平均化後ほとんど見えない
- 最大 512 サンプルを蓄積する際に 1 サンプルが誤ると、
0の代わりに1/512=0.00195、または1の代わりに511/512=0.99804になる - カバレッジが極値に近い場合にクランプする閾値を設けることもできる
- 最大 512 サンプルを蓄積する際に 1 サンプルが誤ると、
- サンプル位置の分布には Martin Roberts の $R_2$ sequence を用い、Shadertoy の例 で時間に応じた分布を確認できる
- 曲線アクセスコストを減らすため、グリフを複数の 水平バンド に分け、各バンドに触れる曲線だけをビットセットで保存する
- 水平レイだけを追跡するため、各ピクセルが調べる曲線集合を大きく減らせる
- wave 単位で同じバンド範囲にアクセスさせると、曲線の反復と読み出しをスカラー化できる
- compute シェーダーでアトラスへラスタライズする際、スレッドを row-major で水平パッキングし、wave が触れるバンド範囲を最小化する
アトラスパッキングとキャッシュキー
- 当初は画面に直接ラスタライズしていたが、毎フレーム高品質アンチエイリアシングを計算するコストが大きかった
- ほとんどのテキストは複数フレームにわたり同じサイズと位置に留まり、同じグリフが同じサイズで繰り返されるため、アトラスと時間的蓄積 が適している
- アトラスは必要なグリフがなければ領域を割り当ててラスタライズを始め、すでに存在するなら既存結果をそのまま使う
- フレーム中にアトラス内のグリフを調べ、維持するか、さらにサンプリングするか、使われていないので領域を解放するかを決める
- アトラスキーには次の要素が含まれる
fontglyph_indexquantized_size_in_pixels_x,quantized_size_in_pixels_yquantized_subpixel_offset_x,quantized_subpixel_offset_y
- サブピクセルオフセット は
frac(pixel_position)に相当し、グリフがピクセルグリッドに正確に揃っていない場合や滑らかにスクロールする場合に、位置に応じたアンチエイリアシング結果を作るために必要となる - 浮動小数点値をそのままキーに使うと、数学的には同じであるべき値でもビット単位で異なることがあるため、8ビット小数部の固定小数点で近い位置とサイズを同じ値に畳み込む
- 静的テキストの多いテキストエディタで等幅フォントを使うなら、文字間隔と行位置をピクセル境界に合わせて、同じグリフのアトラスキャッシュヒット率を高められる
Z-Order ベースのアトラス配置
- ランタイムのグリフ配置には Z-Order Packing と空きセルのビットセットを使う
- Morton code ベースの Z-Order は 2D セルを長い 1D 配列のように扱えるようにし、2 のべき乗個の連続セルを割り当てると 2D アトラスでは正方形領域になる
- 基本セルは
16×16texel で、グリフサイズは次の 2 のべき乗に切り上げられる- 例えば
25×29グリフには32×32チャンクを割り当てる - この場合は
16×16セルが 4 つ必要なので、整列した連続 4 ビットを見つけて使う
- 例えば
- ラテンアルファベットの細長いグリフは縦長が多いため、転置した Z-Order を使えば
l、j、i、1のようなグリフは半分の領域で済む - 逆にアラビア語のように細長いグリフが横長である場合は、標準の Z-Order の方が適している
時間的蓄積で品質を高める方法
- グリフがアトラスに残っていれば、毎フレーム少しずつサンプルを追加して結果を精製できる
- 基本スケジュールは、グリフが最初に現れたフレームで 8 samples-per-pixel、次のフレームで 4、その次で 2、その後は毎フレーム 1 ずつ追加して合計 512 まで蓄積するというもの
- 最初のフレームの品質を高めにしているのは、滑らかに移動したりサイズが変化したりするグリフは、実質的に毎フレーム新しく初期化されるのと同じだからである
- 品質と性能はさまざまな方法で調整できる
- 毎フレーム追加するサンプル数・レイ数
- グリフ出現後の最初の数フレームでサンプルを増やすかどうか
- フレームあたり総サンプル数の上限
- 既存グリフを毎フレームではなく数フレームごとに更新する time-slicing
- グリフ曲線数に応じて交差判定コストを制限する方法
- この実装では性能は大きな問題ではなく、冒頭のフルスクリーンテキストは Radeon 9070 で 4K 時約 0.1ms のピークを示し、グリフが最大サンプル数に達するとコストはすぐ 0 に近づく
サブピクセルアンチエイリアシングと色にじみ
- サブピクセルアンチエイリアシングは、モニターピクセル内の赤・緑・青の各要素をそれぞれサンプル領域と見なしてレンダリングする
- 従来の RGB LCD の縦縞構造では水平方向の解像度が実質 3 倍となり、4K では
3840×2160を3840×6480のように扱える - OLED G9 のようなモニターは、標準的な RGB 縦縞とは異なる 非標準サブピクセル構造 を持つことが問題になる
- 基本的な RGB の縦長長方形構造を仮定すると、上側に緑、下側にマゼンタの色にじみが見える
- モニターの実際のサブピクセル構造に合わせてサンプル位置を設定すれば、色にじみはほぼなくなり、滑らかな結果になる
- Subpixel Zoo はさまざまなサブピクセル構造の例を示しており、LG WOLED の red-white-blue-green 構造 は標準順序と異なる例である
- サブピクセル要素を実際の物理サイズより大きく見なし、互いに 重なり合う ように設定すると、より正確な結果が得られた
- サブピクセルの光は自然に混ざり、わずかに拡散するため、サンプル領域は物理的なサブピクセルより大きいかのように振る舞う
- サンプル領域はピクセル外にも広がる必要があり、周辺ピクセルのサブピクセル光とも混ざる
- Evan Wallace の Easy Scalable Text Rendering はサブピクセルアンチエイリアシング後に水平ブラーが必要だと述べており、これはサブピクセル要素をより大きく重ねて見る方式と実質的に同じ効果である
ディスプレイのサブピクセル情報をソフトウェアが知る必要がある
- モニターの任意のサブピクセル構造にアクセスできれば、一般的なサブピクセルアンチエイリアシングとテキストレンダリング品質を改善できる
- 共通ディスプレイプロトコルを通じてこうした情報が提供されれば、標準配列のモニターでもハードウェアごとにより精密なレンダリングが可能になる
- ディスプレイメーカーは、テキストレンダリングの問題を理由に、より良いサブピクセル構造の実験を避ける必要がなくなる
- Samsung は QD-OLED で G8 から G9 にかけてこの問題を減らすためにサブピクセル構造を変更しており、LG WOLED と Samsung QD-OLED では色にじみがしばしば指摘される
- この問題には、ハードウェア交換よりも ソフトウェア補正 で対処できる余地がある
リアルタイムグリフレンダリングの実用的価値
- 優れた UI とテキスト品質は、製品の体感品質を引き上げられる
- ゲームでは、テキストボックス、メニュー、タイトル、通知のようにユーザーの視線が集まる要素が頻繁に現れ、テキスト品質の低下は、レンダリングの悪い 3D シーンと同じくらい体験に影響しうる
- Persona シリーズ、Metaphor: ReFantazio、Nier: Automata は UI とテキスト表現の好例である
- リアルタイムグリフレンダリングの品質改善を目指す試みは、UI とゲームレンダリングの両方で実質的な価値がある
1件のコメント
Hacker News のコメント
最初の動画で、イタリック体の j の点はどうなっているのでしょうか？
サブピクセルフォントレンダリングは可読性に重要ですが、記事で指摘されているように、既存のディスプレイ標準からピクセル配置の仕様を取得できないのは残念です
世の中はますます Retina級ディスプレイへ移行しており、そこではサブピクセルレンダリングの理由はほとんどありません
スクリーンショットが特定のサブピクセル配置に縛られたり、ビットマップの拡大縮小も難しくなったりと、厄介な点が多いです
CRT と Retina の間にあった LCD 時代の一時的な革新で、今では後ろ向きの技術に近いものです。Apple が数年前に macOS から削除したのには、それなりの理由があります
ディスプレイメーカーが実装していないのか気になります。いずれにせよ、最も一般的なディスプレイモデルについては、ハードウェア情報データベースに容易に推測して保存できる情報です
記事は素晴らしく、さまざまな例を示す「subpixel zoo」もリンクしています: https://geometrian.com/resources/subpixelzoo/
モニターが誤った配置を報告する避けられないケースでも、この方式は必要になります
アンチエイリアシングなしのビットマップフォントや、ヒンティングされたベクターフォントだけでも可読性は非常に高いです
中国語や日本語のように、文字が非常に複雑な細部を持つ言語でのみ重要になります
GTK4 はレンダリングを GPU に移行する際、RGB サブピクセルレンダリングを諦めました
GPU 中心の判断のせいで RGB サブピクセルレンダリングを続けるのが難しくなったと聞きましたが、この記事は可能であることを示しています
だとすれば、GTK の理由は別のところにあったか、提示された解法に欠点があるか、既存スタックにうまく統合できないのかもしれません
WebGL / WebGPU で SDF と MSDF を実装する方法に関心があるなら、私が書いたチュートリアルを見るとよいです: https://infinitecanvas.cc/guide/lesson-015#msdf
JavaScript の例を Rust に移植してみたことがありますが、単にコピー＆ペーストはできない一方で、API は十分に似ていて移植しやすく、学習には理想的でした
WGPU のドキュメントを使い慣れるきっかけにもなります
GPU 関連のチュートリアルを作るのが好きなので、このように構成したいのですが、既存のテンプレートなのか、何らかの講義の一部なのか気になります
Slug ライブラリは、このような GPU グリフラスタライザを実装した商用ミドルウェアです
[1]: https://sluglibrary.com/
cosmic-text のフォント解析とレイアウトの一部を使ってオープンソースの wgpu 版を作ると面白そうですが、最後に Slug に訴えられるなら全く面白くありません
GPU は実質的に無限の頂点/ピクセル描画能力を持っているように見えるのに、なぜテキストをオフラインでレンダリングしてアトラスに保存し、SDF のようなトリックまで使う必要があるのか、まだ理解できません
記事でもグリフ曲線をアトラスに書き込むと言っていますが、シェーダがテキストを直接レンダリングしてはいけない理由が気になります
ベジェを三角形メッシュに変換する方法は確かにありそうです。CAD アプリ向けの GPU テキストレンダラーを始めたばかりなので、近いうちに理由が分かることを願っています
GPU は高速ですが無限に速いわけではなく、事前にレンダリングされたテクスチャをサンプリングするのが非常に得意です
速度だけの問題ではなく、消費電力の問題でもあります。すでにモニターのリフレッシュレートに達しているなら、追加の性能向上は応答性を高めませんが、バッテリー持続時間は延ばせるかもしれません
レンダリングに「十分速い」というものはなく、速くなれば常に利点があります
現代の GPU アーキテクチャはいずれも、高密度ジオメトリ処理が得意ではありません。このような場合、三角形をそのまま GPU に流し込む方式は、アトラスや他の手法より非常に非効率です
ほとんどの GPU はピクセルシェーダを 4 個単位でディスパッチします。三角形がすべて 1 ピクセルサイズなら、シェーダスレッド 3 個は視覚的な出力に寄与できません
これはクアッドオーバードローと呼ばれます。さらに、実際には理由もなく頂点処理にも多くの時間を使います
可能ではありますが、大した利点もなくフレーム予算の一部を手放し、消費電力を増やすことになります
筆者はピクセルあたり最大 512 サンプルでベジェ曲線をスーパーサンプリングしているためアトラスを使っていますが、これは非常に高コストです
代わりに、ベジェ曲線領域とサブピクセル領域の交差積分を計算する方式なら、はるかに高速にでき、アトラスなしでリアルタイムに動作しつつ、スーパーサンプリングより正確になりそうです
そしてほとんどの場合、その時間は他のことに使いたくなります
より多くの GPU 時間が必要になるほど、最低要求ハードウェアもより高速でなければならなくなります。テキストは見栄えがよく重要ですが、ユーザーや顧客を失うほど重要ではないかもしれません
「新しいOLEDは見た目は良いが、非標準のサブピクセル構造のために色にじみの問題がある」という程度より、さらに悪く見える
理解したところでは、単に非標準なのではなく、OLEDには相互に互換性のない複数のサブピクセル配列がある
そのためFreeTypeはOLED向けのサブピクセルレンダリングを実装しておらず、テキスト作業が必要ならOLEDを避けるべき理由になっている
FreeTypeだけの問題でもなく、QtやGTKのようなGUIツールキットも合わせて対応する必要がある。解決が進んでいるのかはよく分からない
任意のモニターのサブピクセル構造にアクセスできるとよいし、こうした情報はEDIDで伝えられるべきなのかもしれない
例えば自分のノートPCは縦方向のBGR配列だが、FreeTypeとKDEがうまく対応している
奇妙な配列は、HDRディスプレイで特定の色、特に青があまり早く焼き付かないように、色ごとに異なるサイズを使う必要があるために生じることが多いように思う
非常に印象的な仕事だ
この分野に詳しくない人のために補足すると、Valveはゲーム向けのSDFテキストレンダリングを作り、2007年にこのテーマの画期的な論文を発表した
今でもビデオゲームで、ほとんど変形されずに非常に広く使われている手法だ
2012年にBehdad Esfahbodは、OpenGL ESでGPU上で動作するSDF実装であるGlyphyを作った。性能や高速なテキスト変換といった新機能のため広く評価されたが、広範には使われなかった
現代のOSやWebブラウザは、こうした手法の代わりに1990年代式のTrueTypeラスタライズに依存することを好んでいる
軽量で効果的なアプローチだが、記事で見られるようにサブピクセル整列や任意のサブピクセル配列には対応できず、拡大・縮小には性能コストが大きく、傾斜・回転・3D変換のような複雑な変換もテキストレンダリングエンジン内ではできない
回転または変形されたテキストが必要な場合はビットマップを再サンプリングする必要があるが、可読性を生む細かな特徴をすべて壊してしまい、見栄えが悪くなる
進展が遅い理由は、得られる利益に比べて作業量とリスクが大きすぎるためかもしれない。現代のWebブラウザエンジンをGPUアクセラレーション付きテキストレンダリングで書き直すと想像すると、簡単ではない
グリフレンダリングは一部分にすぎず、改行処理はまた別の問題だ。CPUとGPU間の通信が多く必要になって遅くなる可能性があり、ソフトウェアとGPUの深い統合も難しい
この方式は、SDFのようにハードウェアの3Dレンダリングパイプラインに無理に合わせるより、性能がはるかに良い
Safariもおそらくそうだと思うが、直接確認して言うことはできない
最新技術の水準やユーザーに配布される実装が進歩していないという考えは間違っている
SDFは、与えられたピクセルから文字のエッジまでの局所距離（Distance）をデータの2次元配列である場（Field）としてエンコードし、その距離が文字の内側か外側かを符号（Sign）ビットで示す
各文字は小さなデータマップを持ち、GPUフレンドリーな画像ファイル形式でまとめてパックされ、各文字の部分画像をどこで見つけるかを示す説明ファイルとともにSDFレンダリングシェーダーが使用する
こうした文字定義はフィールド値間の線形補間に非常に強く、比較的低解像度のマップでもほぼ完璧な拡大が可能になる。GPUもマップのピクセル値を補間するのが得意だ
ただし重要なのは、これらのマップを開発中に、既存のフォントシステムからレンダリングしたいすべての文字について事前処理しておかなければならない点だ。フォントが対応するすべての文字ごとに必要になる
高解像度ビットマップフォントで全文字をレンダリングするよりはデータ量がはるかに少ないが、フォントのアウトライン定義そのものよりははるかに多い
OSやブラウザのように世界中のあらゆるテキストをサポートしようとするシステムは、SDFをテキストレンダリングシステムとして使うことはできない。Unicode文字集合全体に対するSDFマップが必要になり、大きすぎる
ゲームは概して、ローカライズが十分に行き届かなくてもよい場合や、完全に任意のテキストを表示しなくてもよい場合があるため、うまく合う
そもそもSDFは絵文字もサポートできない。グリフのエッジまでの距離だけをエンコードし、グリフ内部の色情報は含まないからだ
複数色をサポートする改良版のMultichannel SDFもあるが、総色数には制限がある
実際にゲーム内テキストにSDFを使いながら、世界中のコミュニティが相互作用するチャットシステムも持つゲームを詳しく見ると、ゲーム内テキストとチャットシステムのテキストレンダリングは異なっている可能性が高い
https://keithclark.co.uk/articles/gpu-text-rendering-in-webk...（2014）によると、「現在のバージョンのChrome、Safari、またはOperaで要素がGPUに昇格されると、サブピクセルアンチエイリアシングを失い、テキストはグレースケール方式でレンダリングされる」という
だとすると、何が欠けているのか気になる。その文面どおりなら、少なくともUTF-8文字列からビットマップへ至る段階の一部はGPUでできるのではないかと思う
印象的な取り組みだと思う
ただし、サブピクセル・アンチエイリアシングは個人的にはあまり意味がないと思う。72dpi のモニターを使っていた 2000 年代には悪くないハックだったが、現代の Retina ディスプレイでは判別しにくく、ごく小さな改善のためにいくつもの欠点を抱えることになる
不透明な背景の上でしか機能せず、ラスタライズ済みの結果にサイズ変更・ミラーリング・ぼかしのような効果を適用できず、スクリーンショットを別のディスプレイで見ると見栄えが悪くなる
Firefox のハードウェア調査 [1] によると、ユーザーの 16% が 1366x768 解像度のディスプレイを使用している
単なる旧式ハードウェアだけの問題ではなく、96dpi のモニターやノート PC は今でも製造されている
[1]: https://data.firefox.com/dashboard/hardware
ほかの論点は、適用できる場面でサブピクセルレンダリングがもたらすより良い結果に比べれば、あまり重要ではない
SDF は最も近いエッジまでのピクセル距離を計算するが、従来のフォントレンダラーはピクセルカバレッジを計算する、という点が重要
ピクセルカバレッジが最適である。小さなフォントでは、エッジが交わる部分で SDF が見栄え悪くなることがある
高 PPI ディスプレイでは問題が少ないかもしれない。自分で SDF レンダラーを実装したことがあるが、FreeType より見栄えが悪かった
ただし、交点、あるいは一般に鋭い角で距離場が問題を起こすという指摘は正しい
複数の距離場を用意してその交差をレンダリングすれば、ある程度緩和できる。例として https://github.com/Chlumsky/msdfgen がある