GPUで鮮明なテキストをレンダリングする

• テキストレンダリングの品質問題、特にSDF（距離場）ベース方式の限界を解決するため、新しいリアルタイムベクターレンダリング手法を提案
• グリフ（文字）をベクター曲線の形でGPUに直接送信し、リアルタイムでラスタライズすることで、無制限の解像度と少ないメモリ使用量を実現
• テクスチャアトラスおよび時間的蓄積（temporal accumulation）手法を活用し、高いアンチエイリアシング品質と効率的なキャッシュを実現
• さまざまなサブピクセル構造（例：OLED、LCDなど）にも最適化して適用でき、フリンジング（色にじみ）の問題なく滑らかで鮮明な結果を提供
• リアルタイムテキスト、UI、ゲームなどにおける高品質なフォントレンダリングのための、シンプルで拡張性の高いアプローチを提示

---

はじめに: テキストレンダリングの課題

• リアルタイムテキストレンダリングでは、エイリアシング（ジャギー）、大型テクスチャ、ビルド時間、拡大・縮小、滑らかな移動など、さまざまな問題が存在
• 従来よく使われるMulti-Channel Signed Distance Fields（SDFs）方式には、品質および柔軟性の面で限界があった
• 近年のOLEDモニターにおける非標準サブピクセル構造とフリンジング問題をきっかけに、サブピクセルアンチエイリアシングまで考慮した新しいアプローチを開発

既存のSDF方式の限界

品質

• SDF方式では、細かなディテールや細いストロークが多いフォントで、品質低下や情報損失の問題が発生
• 解像度を上げない限り、特定のグリフでアーティファクトが残る

アトラスサイズ

• SDFは最初にオフラインで生成してアトラスを保存するため、多数のグリフやCJK（中国語、日本語、韓国語）フォントでは現実的でないほど巨大になる
• 複数フォントを同時に使う場合、メモリ消費とストリーミング帯域の負担が大きくなる

柔軟性と単純さ

• SDFという中間段階を経由するため、ソースデータから最終結果までの全体フローが複雑になる
• リアルタイムあるいは動的なベクター画像を直接活用したり編集したりするには制約が大きい

新方式: ベクター曲線のリアルタイムラスタライズ

• テクスチャを事前生成する代わりに、画面に実際に表示されるグリフのベクター曲線データ（ベジエ曲線など）を直接GPUへ送信し、その場でラスタライズ
• アトラステクスチャには必要な分だけグリフを入れ、使用頻度に応じて保持または解放
• グリフが画面上に残っている間、サンプルの蓄積（temporal accumulation）によって非常に高品質でより滑らかな（アンチエイリアスされた）結果を実現
• 常にベクターベースで処理するため、解像度の制限なく鮮明な結果を提供

フォント曲線データの処理

• FreeTypeなどのオープンソースライブラリでさまざまなフォントフォーマットを読み込み、グリフの曲線情報を抽出
• グリフをライン、2次/3次ベジエ曲線として解析し、すべての曲線を2次ベジエ曲線に変換してGPUシェーダーでの処理を単純化
  • ラインは中間制御点を追加して2次曲線に変換
  • 3次曲線は2つに分割した2次曲線に変換

カバレッジ（ピクセル内部の塗り）計算

• 各ピクセルごとに水平方向（ray）への曲線との交点を計算し、winding number（累積交差数）によって内側/外側を判定
• **数百回のサンプル（n回の累積サンプル）**を合算し、一部の微小な誤差は最終結果にほとんど影響しない
• **サンプルポイント配置（quasirandom sequence）**手法により、各フレームで異なる位置から結果を蓄積

曲線アクセスの最適化

• グリフを水平バンド（band）単位に分割し、バンドごとに関連する曲線だけをテストして計算量を削減
• スレッド配置とバンド単位の反復によって、GPUでのバルク演算効率を最大化

アトラスのパッキングと管理

• アトラス（共有テクスチャ）に各グリフ画像を割り当てて管理
  • 存在しないグリフは新たに領域を割り当ててラスタライズし、すでにあるグリフは再利用
  • 参考までに、同じグリフでもサブピクセル位置やサイズによって異なるバージョンが必要になる場合がある
• Z-Order Packing（Morton codeなど）により、1次元ビットセットと2D空間の間で効率的なパッキングを実装
  • ラテン系は縦基準、アラビア語系は横基準など、言語構造ごとに柔軟な応用が可能
• グリフが不要になれば、アトラス空間を再割り当てして使用

時間的蓄積（Temporal Accumulation）

• グリフキャッシュとサンプル蓄積方式により、表示直後は素早く高品質サンプルを確保し、その後のフレームでさらに精密に補正
  • 最初のフレームは8サンプル/ピクセル、その後は徐々にサンプル数を減らし、最大512回まで蓄積
• 滑らかなグリフ表示とリソース最適化を両立

サブピクセルアンチエイリアシングとフリンジング（Fringing）防止

• サブピクセル（RGBなど各素子をサンプルとみなす）単位でレンダリング領域を配分し、水平方向の解像度向上効果を実現
  • LCD標準構造、OLED/WOLEDなど多様な配列に対応
  • フリンジング（色にじみ）のない滑らかな効果を指定可能
• サブピクセルサンプルが重なる（Overlapping）ように配置することで、実際のモニターの光の混合効果まで反映
• ピクセル境界やヒンティング（hinting）がなくても、自然で鮮明な出力が可能

ディスプレイごとのサブピクセル構造への対応の重要性

• モニターのサブピクセル配列情報をプログラムから確認できるなら、はるかに精密なレンダリングが可能
• これはハードウェアの限界ではなく、ソフトウェア処理の問題であることを強調

まとめと活用の展望

• 優れたテキストレンダリングが全体の使いやすさやサービス品質に与える影響は大きい
• 特にUI/ゲームなどでは、高品質なフォント表現が製品体験に大きな違いをもたらし得る
• シンプルさ・拡張性・高品質・柔軟性という原則を実現できる作業構造
• オープンソース実装、多様なサブピクセル対応など、実際の産業/プロダクション利用に非常に適している

---

[GN⁺]

Hacker Newsのコメント

• 筆者本人だが、ここまで記事が話題になるとは思っていなかった。興味深い議論に参加してくれた皆さんに感謝
• 最初の動画でイタリック体の "j" の点が消えている理由についての質問
• サブピクセルフォントレンダリングは可読性にとても重要だという意見。しかし筆者が指摘したように、現行のディスプレイ標準では正確なピクセルレイアウト仕様を取得できず、残念だという考え
• これは標準解像度ディスプレイでのみ必要な要素だと思う。実際には必須というほどではなく、あれば望ましい程度だという感覚。今ではRetina級ディスプレイが一般化し、あえてサブピクセルレンダリングを必要としない環境になったという立場。むしろLCD時代に登場した一時的な革新であり、今では時代遅れに感じる。スクリーンショットがサブピクセルレイアウトに依存すること、ビットマップを拡大できないことなど副作用もかなり多い。Appleがこの方式をmacOSから完全に削除した背景もそこにあると思う
• DisplayID のような標準は、こうしたレイアウト情報を提供するよう設計されているという指摘。メーカーがうまく実装していない、あるいはDBに保存されていないだけで、人気の高いディスプレイモデルならハードウェア情報DBに記録して活用できるはずだという立場。DisplayID のWikiを参照
• サブピクセル構造の多様性を何十年も前から知っていたのに、という残念さと、原文がそれをうまく整理してくれた点への評価。そして「サブピクセル動物園」と呼ばれる例示ページを共有 subpixel zoo
• 「悲劇」とまでは言い過ぎだと思う。各OSが昔のWindowsのClearTypeチューナーのように、ディスプレイごとに細かな調整ができる機能を入れてくれれば十分だと考える。モニターが情報を誤って報告する場合に備えたユーザー設定の記憶も必要
• サブピクセルレンダリングは大半の言語で必須ではないという立場。アンチエイリアスなしのビットマップフォントやヒンティングされたベクターフォントだけでも十分読みやすい。ただし漢字や日本語のように複雑な文字を使う言語では、もう少し重要性がある
• GTK4 が GPU 中心のレンダリングへ移行する際に RGB サブピクセルレンダリングを放棄した背景は GPU 技術と関係していたという話。しかし原文で GPU でも可能だと示された以上、もしかすると別の理由や欠点、あるいはスタック統合の難しさがあったのではないかという推測
• Cosmic Text（Cosmic DE）が Swash を通じて GPU 上でサブピクセルレンダリングをサポートできる可能性への言及
• WebGL/WebGPU で SDF と MSDF を実装する方法に興味があるなら、自分で書いたチュートリアルを参照するとよいという勧め チュートリアルのリンク
• Rust で実装された WebGPU（WGPU）に興味があると言及。このチュートリアルは上級者向けに近いと感じ、JS の例を Rust に書き換えながら学ぶのが効果的だったという経験の共有
• サイトのフォーマットがとても気に入ったので、自分も GPU 関連チュートリアルをこのように作りたいと述べる。これが特定のテンプレートなのか、コースの一部なのか気になる
• Slug ライブラリは GPU グリフラスタライザを実装した商用ミドルウェアだという情報共有 Slug Library
• Slug のWebサイトではかなり詳しくアルゴリズムを公開していて興味深い。特許があるのか気になる。Cosmic-text でフォント解析やレイアウトを活用してオープンソースの wgpu 版を作れたら面白そうだが、後で Slug に訴えられたら困るという懸念
• この分野に詳しくない人向けに、SDF テキストレンダリングの歴史と現状を要約。Valve が 2007 年に SDF ベースのアーキテクチャを披露し、その後 2012 年に Glyphy（ベーダード・エスパーボード）が GPU ベースの SDF 実装を出して変化はあったが、主流の OS や Web ブラウザは依然として 1990 年代式の Truetype 方式にとどまっている。この方式は小さく軽量だが、サブピクセル整列や arbitrary layout をサポートせず、テキストの拡大や 3D 変形にも大きな制約がある。こうした技術進化が遅いのは、リスクに対して得られる利点が大きくなく、レンダリングだけでなく改行など複雑なレイアウト処理まで GPU/CPU 協調が難しいからではないかという考え
• 改行などのテキストレイアウト処理は、実際にはレンダリングとはほぼ別物だという指摘
• Servo の Pathfinder は GPU コンピュートシェーダーを使って、はるかに優れた性能の GPU テキストレンダリングをすでに実装した例だという紹介
• WebKit の GPU テキストレンダリング方式に関する 記事リンク。現段階でも文字列からビットマップまである程度 GPU 上で処理できるが、期待される「サブピクセルアンチエイリアシング」は GPU の宣伝では抜け落ちがちだという指摘
• 実際には Windows だけでなく Chrome/Firefox でも、すでに何年も前からサブピクセルアンチエイリアシングまで GPU アクセラレーションが入っていたという事実への言及。最新技術が使われていないというのは誤解だと強調
• 簡潔な概要をうまく整理してくれてありがとう、というコメント
• サブピクセルレンダリングを望むなら、ディスプレイのサブピクセルグリッドを正確に把握しなければならないという前提。モニターごとに個別設定を求めるのが唯一合理的な UX だという意見。OS は画面回転などまで扱う必要がある
• 筆者の意見どおり、ディスプレイが自分のサブピクセル構造をシステムに直接知らせる方式が最も理想的だと思う
• 素晴らしい結果だという評価とともに、サブピクセルアンチエイリアシングは 2000 年代初頭の LCD 時代には明確な利点があったが、高解像度の Retina ディスプレイ時代にはほとんど無意味だという判断。欠点として、不透明背景にしか適用できないこと、後処理（リサイズ、ミラーリング、ブラーなど）ができないこと、スクリーンショットが別の機器では不自然に見えることなどを挙げる
• サブピクセル AA をなくせば単純化は進むが、いまだに低解像度 96dpi・1366x768 ディスプレイベースのデスクトップユーザーも多いというデータ（Firefox ハードウェア調査 資料）を提示
• 高解像度画面の利用者として、低解像度ユーザーまで考慮しないのは無責任だという意見も付け加える
• サブピクセルレイアウトのプロトコルが導入されても、一部メーカーが誤実装し、一般ユーザーには理解しづらいレンダリング問題が発生するかもしれないという懸念
• 筆記体を見た第一印象が「いったい誰がこんな筆記体を良いアイデアだと思ったんだ？」だった、という率直な感想
• 手書き、とくに羽ペンや万年筆を使っていた時代に手書きをしていた人たちは好んだだろう、という説明
• 手紙をたくさん書いていた人たちが筆記体を使っており、インターネットと長距離無料通話の登場によって筆記体の使用が減ったという解説
• コードへのリンクが見つからない、という質問