GPU’da Net Metin Render Etmek

• Metin render etme kalitesine ilişkin sorunları, özellikle SDF (mesafe alanı) tabanlı yöntemlerin sınırlarını çözmek için yeni bir gerçek zamanlı vektör render tekniği öneriliyor
• Glifler (karakterler) vektör eğrileri halinde doğrudan GPU’ya gönderilip gerçek zamanlı rasterize edilerek sınırsız çözünürlük ve düşük bellek kullanımı sağlanıyor
• Texture atlas ve zaman içinde biriktirme (temporal accumulation) teknikleri kullanılarak yüksek anti-aliasing kalitesi ve verimli önbellekleme elde ediliyor
• OLED, LCD gibi farklı subpixel yapılarına da uyarlanabildiği için fringing (renk saçılması) olmadan yumuşak ve net sonuçlar veriyor
• Gerçek zamanlı metin, UI ve oyunlar gibi alanlarda yüksek kaliteli font render etme için basit ama ölçeklenebilir bir yaklaşım sunuluyor

---

Giriş: metin render etmenin zorlukları

• Gerçek zamanlı metin render etmede aliasing (basamaklanma), büyük texture’lar, derleme süresi, yakınlaştırma/uzaklaştırma, yumuşak hareket gibi çeşitli sorunlar bulunuyor
• Yaygın olarak kullanılan Multi-Channel Signed Distance Fields (SDFs) yöntemi, kalite ve esneklik açısından sınırlamalara sahipti
• Son dönemde OLED monitörlerdeki standart dışı subpixel yapıları ve fringing sorunları, subpixel anti-aliasingi de hesaba katan yeni bir yaklaşım geliştirilmesine neden olmuş

Mevcut SDF yaklaşımının sınırlamaları

Kalite

• SDF yaklaşımında, ince detaylar veya ince çizgiler içeren fontlarda kalite düşüşü ve bilgi kaybı ortaya çıkabiliyor
• Çözünürlük artırılmadığında bazı gliflerde artifact kalabiliyor

Atlas boyutu

• SDF önce çevrimdışı üretilip sonra atlas olarak saklanıyor; bu da çok sayıda glif veya CJK (Çince, Japonca, Korece) fontları için pratikte imkânsız boyutlara ulaşabiliyor
• Aynı anda birden fazla font kullanıldığında bellek tüketimi ve streaming bant genişliği yükü artıyor

Esneklik ve sadelik

• SDF bir ara aşama olduğu için kaynak veriden nihai sonuca kadar tüm akış karmaşık hale geliyor
• Gerçek zamanlı veya dinamik vektör görselleri doğrudan kullanma ya da düzenleme konusunda ciddi kısıtlar oluşuyor

Yeni yöntem: vektör eğrilerini gerçek zamanlı rasterize etmek

• Texture’ı önceden üretmek yerine, ekranda gerçekten görünen gliflerin vektör eğrisi verileri (Bezier eğrileri vb.) doğrudan GPU’ya gönderiliyor ve orada rasterize ediliyor
• Atlas texture içine yalnızca gerektiği kadar glif yerleştiriliyor; kullanım sıklığına göre tutuluyor veya serbest bırakılıyor
• Glif ekranda kaldığı sürece örnek biriktirme (temporal accumulation) ile çok yüksek kaliteli, daha yumuşak (anti-aliased) sonuçlar elde ediliyor
• İşlem her zaman vektör tabanlı olduğu için çözünürlük sınırı olmadan net sonuç sağlanıyor

Font eğrisi verisinin işlenmesi

• FreeType gibi açık kaynak kütüphanelerle farklı font formatları okunup gliflerin eğri bilgisi çıkarılıyor
• Glifler çizgi, ikinci/üçüncü dereceden Bezier eğrileri olarak ayrıştırılıyor ve GPU shader tarafındaki işlemleri basitleştirmek için tüm eğriler ikinci dereceden Bezier eğrilerine dönüştürülüyor
  • Çizgiler, orta kontrol noktası eklenerek ikinci dereceden eğriye dönüştürülüyor
  • Üçüncü dereceden eğriler, ikiye bölünmüş ikinci dereceden eğrilere çevriliyor

Coverage (piksel içi doluluk) hesabı

• Her piksel için yatay yönde (ray) eğrilerle kesişimler hesaplanıyor, winding number (birikimli kesişim sayısı) ile içeride/dışarıda olduğu belirleniyor
• Yüzlerce örnekleme (n kez biriken örnek) toplanıyor; bazı küçük hataların nihai sonuca etkisi yok denecek kadar az oluyor
• Örnek noktası yerleşimi (quasirandom sequence) tekniğiyle her karede farklı konumlardan sonuç biriktiriliyor

Eğri erişiminin optimize edilmesi

• Glifler yatay bantlar (band) halinde bölünüyor, her bantta yalnızca ilgili eğriler test edilerek işlem miktarı azaltılıyor
• Thread yerleşimi ve bant bazlı yineleme ile GPU üzerindeki toplu işlem verimliliği en üst düzeye çıkarılıyor

Atlas paketleme ve yönetimi

• Atlas’ta (paylaşılan texture) her glif görüntüsü için yer ayrılıp yönetiliyor
  • Atlas’ta olmayan glifler için yeni alan ayrılıp rasterize ediliyor, mevcut olanlar yeniden kullanılıyor
  • Aynı glif için bile subpixel konumu ve boyutuna göre farklı sürümler gerekebiliyor
• Z-Order Packing (Morton code vb.) ile tek boyutlu bitset ile 2D alan arasında verimli paketleme yapılıyor
  • Latin dilleri için dikey, Arapça gibi diller için yatay temel alınması gibi dil yapısına göre esnek uygulamalar mümkün
• Glif artık gerekli değilse atlas alanı yeniden tahsis edilerek kullanılabiliyor

Zaman içinde biriktirme (Temporal Accumulation)

• Glif önbellekleme ve örnek biriktirme sayesinde, gösterimin hemen ardından hızlıca yüksek kaliteli örnekler elde edilip sonraki karelerde daha ince düzeltmeler yapılıyor
  • İlk karede 8 örnek/piksel, sonrasında örnek sayısı kademeli olarak azaltılıyor, en fazla 512 birikime kadar çıkılıyor
• Yumuşak glif gösterimi ile kaynak optimizasyonu birlikte sağlanıyor

Subpixel anti-aliasing ve fringing önleme

• Subpixel düzeyinde (RGB gibi her alt bileşeni örnek kabul ederek) render alanı dağıtılarak yatay çözünürlük artışı etkisi sağlanıyor
  • Standart LCD yapısı, OLED/WOLED gibi farklı dizilimler destekleniyor
  • Fringing (renk saçılması) olmadan yumuşak etki tanımlanabiliyor
• Subpixel örnekleri üst üste gelecek şekilde yerleştirildiğinde gerçek monitördeki ışık karışımı etkisi de yansıtılabiliyor
• Piksel sınırları ya da hinting olmadan da doğal ve net çıktı elde etmek mümkün

Ekrana göre subpixel yapı yaklaşımının önemi

• Monitörün subpixel dizilimi bilgisi programatik olarak öğrenilebilirse çok daha hassas render sonuçları elde etmek mümkün
• Bunun donanım sınırından çok yazılım işleme problemi olduğu vurgulanıyor

Sonuç ve kullanım potansiyeli

• İyi metin render etmenin genel kullanılabilirlik ve hizmet kalitesi üzerinde büyük etkisi var
• Özellikle UI/oyun gibi alanlarda yüksek kaliteli font gösterimi, ürün deneyiminde ciddi fark yaratabiliyor
• Sadelik, ölçeklenebilirlik, yüksek kalite ve esneklik ilkelerini gerçekleştirebilen bir çalışma yapısı sunuyor
• Açık kaynak uygulama, farklı subpixel yapılarına uyum gibi özellikleriyle gerçek endüstriyel/üretim kullanımına çok uygun

---

[GN⁺]

Hacker News görüşleri

• Yazının yazarı olarak ben, bu yazının bu kadar ilgi göreceğini beklemiyordum. İlginç tartışmaya katılan herkese teşekkürler
• İlk videoda italik "j" harfinin noktasının neden kaybolduğuna dair soru
• Alt piksel yazı tipi renderingi okunabilirlik için çok önemli diyen bir görüş var. Ancak yazarın da belirttiği gibi, mevcut ekran standartlarıyla doğru piksel düzeni belirtimine ulaşılamaması üzücü
• Bunun yalnızca standart çözünürlüklü ekranlarda gerekli olduğunu düşünüyorum. Aslında vazgeçilmez değil, olsa iyi olur seviyesinde. Artık retina sınıfı ekranlar yaygınlaştığı için alt piksel renderinge gerçekten ihtiyaç duyulmayan bir ortama geldik diyen bir yaklaşım var. Hatta bunun LCD döneminde ortaya çıkan geçici bir yenilik olduğu ve artık devrini geçtiği hissi var. Ekran görüntülerinin alt piksel düzenine bağımlı olması, bitmap’in büyütülememesi gibi epey yan etkisi var. Apple’ın bu yöntemi macOS’tan tamamen kaldırmasının arkasında da bunun olduğunu düşünüyorum
• DisplayID gibi standartların bu düzen bilgisini sağlayacak şekilde tasarlandığına dikkat çekiliyor. Sorun daha çok üreticilerin bunu düzgün uygulamaması ya da veritabanlarına kaydedilmemesi; ama popüler ekran modelleri için donanım bilgi veritabanlarında tutulup kullanılabilir deniyor. DisplayID wiki’ye bakın
• Alt piksel yapılarındaki çeşitliliği onlarca yıldır biliyor olmamıza rağmen bunun üzücü olduğu, ama asıl yazının bunu iyi derlediği söyleniyor. Ayrıca “alt piksel hayvanat bahçesi” diye anılan örnek sayfa da paylaşılıyor: subpixel zoo
• Buna “trajedi” demek fazla abartılı bulunuyor. Her işletim sistemi, eski Windows’taki ClearType ayarlayıcısı gibi, ekran başına ince ayar yapma imkânı verse yeterli olur görüşü var. Monitör bilgiyi yanlış bildirirse diye kullanıcı ayarlarını hatırlamak da gerekli
• Alt piksel renderingin çoğu dil için mutlaka gerekli olmadığı düşünülüyor. Anti-aliasing olmayan bitmap fontlar ya da hinting uygulanmış vektör fontlar da yeterince rahat okunabiliyor. Ancak Çince karakterler veya Japonca gibi karmaşık karakterler kullanan dillerde biraz daha önemli olabilir
• GTK4’ün GPU merkezli renderinge geçerken RGB alt piksel renderingden vazgeçmesinin arkasında GPU teknolojisiyle ilgili nedenler olduğu söyleniyor. Ama asıl yazı bunun GPU’da da mümkün olduğunu gösterdiğine göre, belki başka gerekçeler, dezavantajlar ya da stack entegrasyonunda zorluklar vardı diye tahmin ediliyor
• Cosmic Text’in (Cosmic DE) Swash üzerinden GPU üzerinde alt piksel renderingi destekleme ihtimalinden söz ediliyor
• WebGL/WebGPU üzerinde SDF ve MSDF’nin nasıl uygulanacağıyla ilgileniyorsanız, doğrudan benim yazdığım şu öğreticiye bakmanız öneriliyor: öğretici bağlantısı
• Rust ile yazılmış WebGPU’ya (WGPU) ilgi duyduğunu söyleyen biri, bu öğreticinin daha çok ileri seviye geldiğini, JS örneklerini Rust’a çevirerek öğrenmenin etkili olduğunu paylaşıyor
• Site formatını çok beğendiğini ve GPU ile ilgili öğreticileri kendisinin de böyle hazırlamak istediğini söylüyor; bunun belirli bir şablon mu yoksa bir kursun parçası mı olduğunu merak ediyor
• Slug kütüphanesinin GPU glyph rasterizer uygulayan ticari bir middleware olduğu bilgisi paylaşılıyor: Slug Library
• Slug sitesinde algoritmanın oldukça ayrıntılı biçimde açıklandığı ve bunun ilginç olduğu söyleniyor. Acaba patenti var mı diye soruluyor. cosmic-text ile font parsing/layout kullanarak açık kaynak bir wgpu sürümü yapmak eğlenceli olabilir, ama sonradan Slug tarafından dava edilmek sorun olur diye endişe dile getiriliyor
• Bu alana aşina olmayanlar için SDF metin renderinginin geçmişi ve bugünü özetleniyor. Valve’ın 2007’de SDF tabanlı bir mimari tanıttığı, ardından 2012’de Glyphy’nin (Behdad Esfahbod) GPU tabanlı SDF uygulamasıyla değişim getirdiği, ama ana akım işletim sistemleri ve web tarayıcılarının hâlâ 1990’lar tarzı Truetype yaklaşımında kaldığı söyleniyor. Bu yöntem küçük ve hafif, ancak alt piksel hizalama / rastgele düzenleri desteklemiyor; ayrıca metni büyütme ya da 3D dönüşümlerde ciddi kısıtlar getiriyor. Bu teknolojik ilerleyişin yavaş olmasının nedeni, risk-getiri dengesinin yeterince güçlü olmaması ve yalnızca rendering değil satır sonu kırma gibi karmaşık yerleşim işlemlerinde de GPU/CPU işbirliğinin zor olması olabilir deniyor
• Satır sonu kırma gibi metin yerleşimi işlerinin aslında renderingden neredeyse tamamen ayrı olduğuna dikkat çekiliyor
• Servo’nun Pathfinder projesi, GPU compute shader kullanarak çok daha iyi performanslı GPU metin renderingi gerçekleştirmiş bir örnek olarak tanıtılıyor
• WebKit’in GPU metin renderingi yöntemiyle ilgili şu makale bağlantısı paylaşılıyor. Bugünkü aşamada bile string’den bitmap’e kadar belirli işlemler GPU üzerinde yapılabiliyor, ama beklenen “alt piksel anti-aliasing” GPU tanıtımlarında yer almıyor deniyor
• Sadece Windows’ta değil, Chrome/Firefox’ta da yıllar önce alt piksel anti-aliasing’e kadar GPU hızlandırması olduğu belirtiliyor. Yani yeni teknolojilerin hiç kullanılmadığı düşüncesi bir yanlış anlama diye vurgulanıyor
• Kısa ve öz bir genel bakış sunduğu için teşekkür eden bir yorum da var
• Alt piksel rendering isteniyorsa, ekranın alt piksel ızgarasının doğru biçimde bilinmesi gerektiği ön koşulu vurgulanıyor. Monitör başına ayrı ayar istemenin tek mantıklı UX olduğu görüşü var. İşletim sisteminin ekran döndürme gibi durumları da ele alması gerekir
• Yazarın görüşündeki gibi, ekranın kendi alt piksel yapısını sisteme doğrudan bildirmesi en ideal yöntem olur deniyor
• Sonucun çok etkileyici olduğu söylenirken, alt piksel anti-aliasing’in 2000’lerin başındaki LCD döneminde açık avantajlar sunduğu, ancak yüksek çözünürlüklü retina ekran çağında neredeyse anlamsızlaştığı düşünülüyor. Dezavantajlar olarak yalnızca opak arka planlarda çalışması, sonradan işleme adımlarına (yeniden boyutlandırma, yansıtma, blur vb.) uygun olmaması ve ekran görüntülerinin başka cihazlarda tuhaf görünmesi sayılıyor
• Alt piksel AA kaldırılırsa sadeleşme olur, ama hâlâ düşük çözünürlüklü 96dpi, 1366x768 ekran kullanan çok sayıda masaüstü kullanıcısı olduğuna dair veri olarak Firefox donanım araştırması verisi gösteriliyor
• Yüksek çözünürlüklü ekran kullanan biri olarak, düşük çözünürlüklü kullanıcıları hiç hesaba katmamanın sorumsuzluk olduğunu ekleyen bir görüş de var
• Alt piksel düzeni protokolü gelse bile bazı üreticilerin bunu yanlış uygulayabileceği, bunun da sıradan kullanıcıların anlamakta zorlanacağı rendering sorunlarına yol açabileceği konusunda endişe dile getiriliyor
• El yazısı stilindeki fontu görünce akla gelen ilk şeyin “Böyle berbat bir el yazısı fontunun iyi bir fikir olduğunu kim düşündü acaba?” olduğu yönünde samimi bir yorum var
• El yazısını, özellikle de divit ya da dolma kalem kullanılan dönemde el yazısıyla yazı yazan insanların sevmiş olabileceği açıklanıyor
• Çok mektup yazan insanların cursive kullandığı, internet ve ücretsiz şehirler arası görüşmeler ortaya çıkınca cursive kullanımının azaldığı anlatılıyor
• Kod bağlantısını bulamadığını soran bir yorum var