Scharfe Textdarstellung auf der GPU

• Um Qualitätsprobleme beim Text-Rendering, insbesondere die Grenzen SDF-(Distance-Field-)basierter Verfahren, zu lösen, wird eine neue Echtzeit-Vektor-Rendering-Technik vorgeschlagen
• Glyphen (Zeichen) werden in Form von Vektorkurven direkt an die GPU übertragen und dort in Echtzeit rasterisiert, wodurch unbegrenzte Auflösung und geringer Speicherverbrauch erreicht werden
• Mithilfe von Texture-Atlases und temporal accumulation werden hohe Antialiasing-Qualität und effizientes Caching realisiert
• Die Methode lässt sich auch auf verschiedene Subpixel-Strukturen (z. B. OLED, LCD usw.) anpassen und liefert glatte, scharfe Ergebnisse ohne Fringing (Farbsäume)
• Sie präsentiert einen einfachen, zugleich gut skalierbaren Ansatz für hochwertiges Font-Rendering in Echtzeit-Text, UI und Spielen

---

Einleitung: Die Herausforderungen des Text-Renderings

• Beim Echtzeit-Text-Rendering gibt es verschiedene Probleme wie Aliasing (Treppeneffekte), große Texturen, Build-Zeiten, Zooming/Scaling und flüssige Bewegung
• Das häufig verwendete Verfahren mit Multi-Channel Signed Distance Fields (SDFs) hatte Grenzen bei Qualität und Flexibilität
• Angestoßen durch die nicht standardisierten Subpixel-Strukturen moderner OLED-Monitore und das Problem des Fringing wurde ein neuer Ansatz entwickelt, der auch Subpixel-Antialiasing berücksichtigt

Grenzen des bisherigen SDF-Verfahrens

Qualität

• Beim SDF-Verfahren kommt es bei Schriftarten mit vielen feinen Details oder dünnen Strichen zu Qualitätsverlusten und Informationsverlust
• Wenn die Auflösung nicht erhöht wird, bleiben bei bestimmten Glyphen Artefakte zurück

Atlas-Größe

• SDFs werden zunächst offline erzeugt und dann als Atlas gespeichert; bei vielen Glyphen oder CJK-Schriftarten (Chinesisch, Japanisch, Koreanisch) wird das praktisch unrealistisch groß
• Werden mehrere Schriftarten gleichzeitig verwendet, steigen Speicherverbrauch und Streaming-Bandbreite stark an

Flexibilität und Einfachheit

• Durch die Zwischenstufe mit SDF wird der gesamte Ablauf vom Quelldatensatz bis zum Endergebnis komplex
• Die direkte Nutzung oder Bearbeitung von Echtzeit- oder dynamischen Vektorgrafiken ist stark eingeschränkt

Neuer Ansatz: Echtzeit-Rasterisierung von Vektorkurven

• Statt Texturen im Voraus zu erzeugen werden die Vektorkurvendaten der tatsächlich sichtbaren Glyphen (z. B. Bézier-Kurven) direkt an die GPU übertragen und dort sofort rasterisiert
• In einen Atlas-Texture werden nur so viele Glyphen eingefügt wie nötig; je nach Nutzungshäufigkeit werden sie beibehalten oder wieder freigegeben
• Solange eine Glyphe auf dem Bildschirm verbleibt, wird durch Akkumulation von Samples (temporal accumulation) ein sehr hochwertiges, noch glatteres antialiasiertes Ergebnis erzeugt
• Da die Verarbeitung stets vektorbasiert erfolgt, entstehen scharfe Ergebnisse ohne Auflösungsgrenze

Verarbeitung der Font-Kurvendaten

• Mit Open-Source-Bibliotheken wie FreeType werden verschiedene Font-Formate eingelesen und die Kurveninformationen der Glyphen extrahiert
• Glyphen werden als Linien sowie quadratische/kubische Bézier-Kurven geparst; alle Kurven werden in quadratische Bézier-Kurven umgewandelt, um die Verarbeitung im GPU-Shader zu vereinfachen
  • Linien werden durch Hinzufügen eines mittleren Kontrollpunkts in quadratische Kurven umgewandelt
  • Kubische Kurven werden in zwei geteilte quadratische Kurven umgewandelt

Berechnung der Coverage (Füllung innerhalb eines Pixels)

• Für jedes Pixel werden Schnittpunkte der Kurven mit einem horizontalen Strahl berechnet; über die Winding Number (akkumulierte Zahl der Schnittpunkte) wird entschieden, ob ein Punkt innen oder außen liegt
• Hunderte von Samples (n-fach akkumulierte Samples) werden aufsummiert; kleine Fehler haben auf das Endergebnis kaum Einfluss
• Mit einer Technik zur Platzierung von Sample-Punkten (quasirandom sequence) werden in jedem Frame Ergebnisse von unterschiedlichen Positionen aus akkumuliert

Optimierung des Kurvenzugriffs

• Glyphen werden in horizontale Bänder (bands) aufgeteilt; pro Band werden nur die relevanten Kurven getestet, um den Rechenaufwand zu reduzieren
• Durch Thread-Anordnung und bandweises Iterieren wird die Effizienz der GPU bei Bulk-Berechnungen maximiert

Atlas-Packing und -Verwaltung

• Jedes Glyphenbild wird einem Atlas (gemeinsam genutzte Textur) zugewiesen und dort verwaltet
  • Fehlende Glyphen erhalten neu zugewiesenen Platz und werden rasterisiert; vorhandene Glyphen werden wiederverwendet
  • Zur Einordnung: Selbst dieselbe Glyphe kann je nach Subpixel-Position und Größe in unterschiedlichen Versionen benötigt werden
• Mit Z-Order Packing (Morton-Code usw.) wird effizientes Packing zwischen einem eindimensionalen Bitset und 2D-Raum umgesetzt
  • Je nach Sprachstruktur flexibel anpassbar, z. B. vertikal für lateinische Schriften, horizontal für arabische Schriften
• Wenn Glyphen nicht mehr benötigt werden, wird der Platz im Atlas erneut zugewiesen und weiterverwendet

Temporal Accumulation

• Durch Glyphen-Caching und Sample-Akkumulation werden direkt nach der Anzeige schnell hochwertige Samples gesichert und in späteren Frames weiter verfeinert
  • Im ersten Frame 8 Samples/Pixel, danach schrittweise weniger Samples, bis zu maximal 512 akkumulierte Durchläufe
• So werden glatte Glyphendarstellung und Ressourcenoptimierung gleichzeitig erreicht

Subpixel-Antialiasing und Vermeidung von Fringing

• Das Rendering wird auf Subpixel-Ebene (RGB usw. als einzelne Samples) aufgeteilt, wodurch eine höhere horizontale Auflösung erreicht wird
  • Unterstützung für Standard-LCD-Strukturen sowie verschiedene Anordnungen wie OLED/WOLED
  • Glatter Effekt ohne Fringing (Farbsäume)
• Wenn Subpixel-Samples überlappend angeordnet werden, lässt sich sogar der tatsächliche Lichtmischungseffekt des Monitors berücksichtigen
• Auch ohne Pixelgrenzen oder Hinting sind natürliche und scharfe Ausgaben möglich

Warum der Ansatz pro Display-Subpixel-Struktur wichtig ist

• Wenn sich die Subpixel-Anordnung eines Monitors programmatisch ermitteln lässt, ist deutlich präziseres Rendering möglich
• Es wird betont, dass dies keine Hardware-Grenze, sondern ein Problem der Softwareverarbeitung ist

Fazit und Ausblick auf den Einsatz

• Gutes Text-Rendering hat großen Einfluss auf die gesamte Nutzbarkeit und Servicequalität
• Gerade in UI und Spielen kann eine hochwertige Schriftdarstellung einen erheblichen Unterschied im Produkterlebnis machen
• Die Arbeitsstruktur setzt die Prinzipien Einfachheit, Skalierbarkeit, hohe Qualität und Flexibilität um
• Mit Open-Source-Implementierung und Unterstützung für verschiedene Subpixel-Strukturen ist der Ansatz sehr gut für den realen industriellen bzw. produktiven Einsatz geeignet

---

[GN⁺]

Hacker-News-Kommentare

• Ich als Autor des Beitrags hätte nicht gedacht, dass der Artikel so viel Aufmerksamkeit bekommt. Vielen Dank an alle, die sich an der interessanten Diskussion beteiligt haben
• Frage, warum im ersten Video der Punkt des kursiven „j“ verschwunden ist
• Die Meinung, dass Subpixel-Fontrendering für die Lesbarkeit sehr wichtig ist. Gleichzeitig schade, dass man, wie der Autor anmerkt, mit den aktuellen Display-Standards keine exakten Spezifikationen des Pixel-Layouts bekommen kann
• Die Ansicht, dass das nur bei Displays mit Standardauflösung relevant ist. Eigentlich nicht unverzichtbar, eher ein nettes Extra. Da Retina-Displays inzwischen weit verbreitet sind, sei man in einer Umgebung angekommen, in der Subpixel-Rendering nicht mehr wirklich nötig ist. Eher eine vorübergehende Innovation aus der LCD-Ära, die inzwischen etwas aus der Zeit gefallen wirkt. Es gibt auch etliche Nebenwirkungen, etwa die Abhängigkeit von der Subpixel-Anordnung bei Screenshots oder dass sich Bitmaps nicht gut skalieren lassen. Darin liege wohl auch der Hintergrund, warum Apple diese Methode in macOS komplett entfernt hat
• Hinweis darauf, dass Standards wie DisplayID genau dafür ausgelegt wurden, solche Layout-Informationen bereitzustellen. Das Problem sei nur, dass Hersteller das oft nicht sauber implementieren oder die Daten nicht in Datenbanken landen. Für populäre Display-Modelle könne man diese Informationen aber durchaus in Hardware-Datenbanken erfassen und nutzen. Siehe DisplayID-Wiki
• Bedauern darüber, dass die Vielfalt der Subpixel-Strukturen seit Jahrzehnten bekannt ist, und Lob dafür, dass der Originalartikel das gut zusammenfasst. Dazu wurde eine Beispielseite geteilt, die als „Subpixel-Zoo“ bekannt ist: subpixel zoo
• „Tragödie“ sei wohl zu stark formuliert. Es würde schon reichen, wenn jedes OS eine Feineinstellung pro Display anböte, ähnlich wie früher der ClearType-Tuner unter Windows. Außerdem brauche es eine gespeicherte Benutzereinstellung für Fälle, in denen ein Monitor falsche Informationen meldet
• Die Position, dass Subpixel-Rendering für die meisten Sprachen nicht zwingend nötig ist. Auch Bitmap-Fonts ohne Anti-Aliasing oder gehintete Vektorfonts seien gut lesbar. Für Sprachen mit komplexen Zeichen wie Chinesisch oder Japanisch sei es allerdings wichtiger
• Dass GTK4 bei der Umstellung auf GPU-zentriertes Rendering RGB-Subpixel-Rendering aufgegeben hat, hänge wohl mit der GPU-Technik zusammen. Da der Originalartikel aber zeigt, dass es auch auf der GPU möglich ist, wird spekuliert, ob es nicht andere Gründe, Nachteile oder Schwierigkeiten bei der Integration in den Stack gab
• Erwähnung der Möglichkeit, dass Cosmic Text (Cosmic DE) über Swash Subpixel-Rendering auf der GPU unterstützen könnte
• Wer sich dafür interessiert, wie man SDF und MSDF in WebGL/WebGPU implementiert, dem sei ein von mir selbst geschriebenes Tutorial empfohlen: Tutorial-Link
• Es wurde erwähnt, dass Interesse an Rust-basierter WebGPU (WGPU) besteht. Das Tutorial wirke eher fortgeschritten, und es habe beim Lernen geholfen, die JS-Beispiele nach Rust zu übertragen
• Das Format der Website gefalle ausgesprochen gut, und man würde gern selbst GPU-bezogene Tutorials in dieser Form erstellen. Es wurde gefragt, ob das auf einer bestimmten Vorlage basiert oder Teil eines Kurses ist
• Die Information, dass die Slug Library kommerzielle Middleware ist, die einen GPU-Glyph-Rasterizer implementiert: Slug Library
• Die Slug-Website lege den Algorithmus recht detailliert offen, was interessant sei. Es kam die Frage auf, ob Patente existieren. Ein Open-Source-wgpu-Port mit Font-Parsing/Layout über cosmic-text wäre spannend, aber es wäre problematisch, später von Slug verklagt zu werden
• Für Menschen, die mit dem Thema nicht vertraut sind, eine Zusammenfassung der Geschichte und des aktuellen Standes von SDF-Text-Rendering. Valve stellte 2007 eine SDF-basierte Architektur vor, und später brachte Glyphy 2012 eine GPU-basierte SDF-Implementierung heraus, was einiges veränderte. Mainstream-OS und Webbrowser hängen aber weiterhin an TrueType-Verfahren aus den 1990ern. Diese sind klein und leichtgewichtig, unterstützen aber weder Subpixel-Ausrichtung noch beliebige Layouts und haben auch beim Skalieren von Text oder bei 3D-Transformationen deutliche Einschränkungen. Dass sich diese Technik nur langsam weiterentwickelt, liege womöglich daran, dass der Nutzen im Verhältnis zum Risiko nicht groß genug ist und dass die Zusammenarbeit zwischen GPU und CPU nicht nur beim Rendering, sondern auch bei komplexem Layout wie Zeilenumbrüchen schwierig ist
• Der Hinweis, dass Textlayout-Aufgaben wie Zeilenumbrüche in der Praxis fast vollständig vom eigentlichen Rendering getrennt sind
• Einführung zu Pathfinder von Servo als Beispiel dafür, dass GPU-Text-Rendering mit deutlich besserer Performance bereits per GPU-Compute-Shader umgesetzt wurde
• Artikel-Link zur GPU-Text-Rendering-Methode von WebKit. Schon im aktuellen Stand lasse sich ein Teil der Verarbeitung von der Zeichenkette bis zur Bitmap auf der GPU erledigen, aber genau das erwartete „Subpixel-Anti-Aliasing“ fehle in solchen GPU-Demos oft
• Der Hinweis, dass es nicht nur unter Windows, sondern auch in Chrome/Firefox bereits seit Jahren GPU-Beschleunigung einschließlich Subpixel-Anti-Aliasing gibt. Die Annahme, moderne Technik werde hier nicht genutzt, sei also ein Missverständnis
• Ein Kommentar mit Dank dafür, dass die kompakte Übersicht so gut aufbereitet wurde
• Wenn man Subpixel-Rendering will, müsse man die Subpixel-Matrix des Displays exakt kennen. Die einzig vernünftige UX sei daher, pro Monitor eine eigene Einstellung zu verlangen. Das OS müsse außerdem Dinge wie Bildschirmrotation berücksichtigen
• Die Ansicht, dass es am besten wäre, wenn das Display dem System seine Subpixel-Struktur direkt selbst mitteilt, wie vom Autor vorgeschlagen
• Lob für das hervorragende Ergebnis und die Einschätzung, dass Subpixel-Anti-Aliasing in der LCD-Zeit der frühen 2000er klare Vorteile hatte, im Zeitalter hochauflösender Retina-Displays aber fast bedeutungslos geworden ist. Als Nachteile wurden genannt: nur auf undurchsichtigen Hintergründen anwendbar, ungeeignet für Nachbearbeitung wie Skalierung, Spiegelung oder Blur, und Screenshots sehen auf anderen Geräten oft seltsam aus
• Der Hinweis, dass das Abschaffen von Subpixel-AA zwar vereinfacht, es aber noch viele Desktop-Nutzer mit niedrig auflösenden 96-dpi- oder 1366x768-Displays gibt, belegt durch Daten aus der Firefox-Hardware-Umfrage Daten
• Zusätzlich die Meinung, dass es verantwortungslos wäre, als Nutzer hochauflösender Displays die Nutzer mit niedriger Auflösung nicht mitzudenken
• Die Sorge, dass selbst bei Einführung eines Subpixel-Layout-Protokolls manche Hersteller es fehlerhaft implementieren könnten, was zu Rendering-Problemen führen würde, die für normale Nutzer schwer zu verstehen sind
• Beim Anblick der Handschrift- bzw. Kursivschrift war der erste Gedanke die ehrliche Reaktion: „Wer zum Teufel hielt diese Art von Schreibschrift eigentlich für eine gute Idee?“
• Erklärung, dass sie wohl Menschen gefiel, die viel von Hand schrieben, besonders in Zeiten von Federkiel und Füllfederhalter
• Erläuterung, dass Menschen, die viele Briefe schrieben, Kursivschrift nutzten und dass ihre Verwendung mit dem Aufkommen des Internets und kostenloser Ferngespräche zurückging
• Frage, dass kein Link zum Code zu finden sei