GPU’da Net Metin Render Etmek

• Mevcut Multi-Channel SDF yöntemi; ince çizgiler, büyük atlaslar, küçültme-büyütme ve yumuşak hareketlerde sınırlamalara sahip olduğu için GPU çalışma zamanı rasterizasyonu olarak yeniden uygulandı
• Yeni pipeline, yalnızca o anda görünen gliflerin Bézier eğrisi verilerini GPU’ya gönderiyor; çalışma zamanında bunları atlasa çizip ekranda örnekliyor
• Glif ekranda kalmaya devam ederse atlas önbelleği korunuyor, örnekler biriktirilerek kalite artırılıyor; ilk karede 8 samples-per-pixel ile başlayıp en fazla 512 samples değerine kadar rafine ediliyor
• Önbellek anahtarı font, glyph_index, piksel boyutu ve alt piksel ofsetini içeriyor; 8 bit sabit noktalı gösterimle yakın konum ve boyutlar aynı değere katlanarak yeniden kullanım artırılıyor
• Monitöre özgü RGB alt piksel düzeni örnekleme alanı olarak modellenirse OLED G9 gibi standart dışı dizilimlerde bile renk saçılması azaltılabiliyor; 4K tam ekran metin demosu Radeon 9070 üzerinde yaklaşık 0.1ms tepe maliyet gösteriyor

---

SDF Yerine Çalışma Zamanı Vektör Rasterizasyonunun Seçilme Nedeni

• Önceki uygulama Multi-Channel Signed Distance Fields kullanıyordu ve genel olarak iyi çalışıyordu; ancak gerçek kullanımda bazı kısıtlar devam ediyordu
  • Kalite: İnce çizgilerde veya ayrıntısı çok olan fontlarda özellikler kaybolabiliyor ya da artefaktlar oluşabiliyordu; bazı durumlarda daha yüksek çözünürlüklü SDF gerekebiliyordu
  • Atlas boyutu: SDF çevrimdışı üretildikten sonra atlasta saklandığı için, çok sayıda glife sahip Japonca ve Çince fontları tek bir atlasa pişirmek zordu
  • Esneklik: Küçültme-büyütme sorunları veya alt piksel antialiasing gibi yeni fikirleri uygulamak zordu; çalışma zamanında üretilebilir ve düzenlenebilir vektör görsellere de uygun değildi
  • Basitlik: Orijinal glif eğrilerini ara bir dokuya dönüştürme adımı sistem karmaşıklığını artırıyordu
• Miama gibi Latin fontları bile her glif için 64×64 alan kullanan 4096×1152 bir atlas gerektiriyordu; çalışma zamanında birden fazla font kullanıldığında bellek ve streaming bant genişliği maliyeti büyüyordu
• Yeni yaklaşımın amacı, glif tasarımcısının oluşturduğu Bézier eğrilerini daha doğrudan kullanarak orijinal veriden nihai piksele kadar olan dönüşüm adımlarını azaltmak

Genel Pipeline

• Temel fikir, tüm glifleri çevrimdışında önceden pişirmek yerine yalnızca o anda görünen gliflerin eğrilerini GPU’ya gönderip gerektiği anda rasterize etmek
• İşleme akışı basit
  • Fonttan glif eğrisi verileri yüklenir
  • GPU, çalışma zamanında glifi atlasa rasterize eder
  • Ekran çıktısı sırasında ilgili atlas örneklenir
• Aynı glif sonraki karelerde de kullanılmaya devam ederse atlasta tutulur ve örnekler biriktirilerek yüksek kaliteli alt piksel antialiasing seviyesine kadar rafine edilir
• Vektör gösterimi doğrudan render edildiği için çözünürlük değişikliklerine yanıt vermek kolaydır; yalnızca tüm piksel kapsamasını değil, her alt piksel öğesinin kapsamasını da hesaplamak mümkündür

Glif Eğrilerinin İşlenmesi

• Font yüklemede, desteklenen formatları okumak için FreeType çevrimdışı aracın ara katmanı olarak kullanılır; her glifin eğrileri dolaşılıp özel bir asset formatında saklanır
• Glif eğrileri çizgi, ikinci dereceden Bézier ve üçüncü dereceden Bézier içerebilir; shader’ı basitleştirmek için hepsi ikinci dereceden Bézier’e dönüştürülür
  • Çizgi, iki noktanın ortasına bir kontrol noktası eklenerek ikinci dereceden Bézier’e dönüştürülür
  • Üçüncü dereceden Bézier, iki adet ikinci dereceden Bézier’e bölünür; bu, derece düşüren kayıplı bir dönüşümdür
• Üçüncü dereceden Bézier’i iki ikinci dereceden Bézier’e bölme yöntemi denenen fontların çoğunda iyi çalıştı; ancak hatayı daha da azaltan daha gelişmiş yöntemler de mümkündür
• Daha yüksek kaliteli dönüşüm gerekirse çevrimdışı araçla TrueType .ttf gibi yalnızca ikinci dereceden Bézier içeren bir formata dönüştürülerek bu dönüşümün kendisi önlenebilir
• Desmos grafiğinde girdi üçüncü dereceden Bézier ile ortaya çıkan iki ikinci dereceden Bézier’in şekilleri karşılaştırılabilir

Kapsama Hesabı ve Eğri Erişimi Optimizasyonu

• Kapsama, piksel bazında soldan sağa yatay ışınlar gönderip eğrilerle kesişimleri kontrol ederek winding number biriktirme yöntemiyle hesaplanır
• Matematiksel arka plan ve uygulama için GreenLightning’in GPU Font Rendering çalışmasına ve Sebastian Lague’in Rendering Text videosuna bakılabilir
• Kesişim hesabındaki hatalar belirli yükseklikteki örneklerde ortaya çıkabilir; ancak yüzlerce örnek biriktirildiğinde bir iki hata ortalama alındıktan sonra neredeyse görünmez olur
  • En fazla 512 örnek biriktirildiğinde bir örnek hatalıysa 0 yerine 1/512=0.00195, veya 1 yerine 511/512=0.99804 olur
  • Kapsama uç değerlere yakınken clamp uygulanacak bir eşik de konabilir
• Örnek konumu dağılımında Martin Roberts’ın $R_2$ sequence yöntemi kullanılır; Shadertoy örneğinde dağılımın zamana göre değişimi görülebilir
• Eğri erişim maliyetini azaltmak için glifler birden çok yatay banda ayrılır ve her banda temas eden eğriler bitset olarak saklanır
  • Yalnızca yatay ışınlar izlendiği için her texel’in kontrol edeceği eğri kümesi önemli ölçüde azaltılabilir
  • Wave düzeyinde aynı bant aralığına erişim sağlanırsa eğri döngüleri ve okumaları skalerleştirilebilir
  • Compute shader’da atlasa rasterize ederken thread’ler row-major biçimde yatay paketlenerek wave’in temas ettiği bant aralığı en aza indirilir

Atlas Paketleme ve Önbellek Anahtarı

• Başta doğrudan ekrana rasterize ediliyordu; ancak her karede yüksek kaliteli antialiasing hesaplamanın maliyeti yüksekti
• Metinlerin çoğu birden fazla kare boyunca aynı boyut ve konumda kalır; aynı glif aynı boyutta tekrarlandığından atlas ve zamansal birikim uygundur
• Atlas, gerekli glif yoksa alan ayırıp rasterizasyona başlar; zaten varsa mevcut sonucu aynen kullanır
  • Kare sırasında atlasa ait glifler kontrol edilerek korunup korunmayacağı, daha fazla örneklenip örneklenmeyeceği veya kullanılmadığı için alanın serbest bırakılıp bırakılmayacağı belirlenir
• Atlas anahtarı şu öğeleri içerir
  • font
  • glyph_index
  • quantized_size_in_pixels_x, quantized_size_in_pixels_y
  • quantized_subpixel_offset_x, quantized_subpixel_offset_y
• Alt piksel ofseti frac(pixel_position) değerine karşılık gelir; glif piksel ızgarasına tam oturmadığında veya yumuşak şekilde kaydırıldığında konuma uygun antialiasing sonucu üretmek için gereklidir
• Kayan noktalı değerler doğrudan anahtar olarak kullanılırsa matematiksel olarak aynı olması gereken değerler bile bit düzeyinde farklı olabilir; bu yüzden yakın konum ve boyutlar 8 bit kesir kısmına sahip sabit noktalı gösterimle aynı değere katlanır
• Statik metnin yoğun olduğu bir metin editöründe sabit aralıklı font kullanılıyorsa, karakter aralığı ve satır konumu piksel sınırlarına hizalanarak aynı glifin atlas önbellek isabet oranı artırılabilir

Z-Order Tabanlı Atlas Yerleşimi

• Çalışma zamanı glif yerleşimi Z-Order Packing ve boş hücre bitset’i kullanır
• Morton code tabanlı Z-Order, 2D hücreleri uzun bir 1D dizi gibi ele almayı sağlar; 2’nin kuvveti kadar ardışık hücre ayrıldığında 2D atlasta kare bir alan oluşur
• Temel hücre 16×16 texel’dir ve glif boyutu bir sonraki 2’nin kuvvetine yuvarlanır
  • Örneğin 25×29 bir glif 32×32 chunk ayırır
  • Bu durumda dört adet 16×16 hücre gerektiği için hizalı ardışık 4 bit bulunup kullanılır
• Latin alfabesindeki uzun ve ince glifler çoğunlukla dikey olduğundan, transpoze Z-Order kullanılırsa l, j, i, 1 gibi glifler yarı alan kullanabilir
• Buna karşılık Arapça gibi uzun ve ince gliflerin yatay olduğu durumlarda standart Z-Order daha uygundur

Zamansal Birikimle Kaliteyi Artırma Yöntemi

• Glif atlasta kalmaya devam ederse her karede biraz daha örnek eklenerek sonuç rafine edilebilir
• Varsayılan zamanlama, glifin ilk göründüğü karede 8 samples-per-pixel, sonraki karede 4, bir sonraki karede 2 ve daha sonra her karede 1 ekleyerek toplamda 512 örneğe kadar biriktirir
• İlk kare kalitesinin yüksek tutulmasının nedeni, yumuşak hareket eden veya boyutu değişen gliflerin her karede yeniden başlatılmış gibi davranmasıdır
• Kalite ve performans çeşitli yollarla ayarlanabilir
  • Her karede eklenecek örnek/ışın sayısı
  • Glifin ilk birkaç karesinde örnek artışı yapılıp yapılmayacağı
  • Kare başına toplam örnek sayısı üst sınırı
  • Mevcut glifleri her kare değil, birkaç karede bir güncelleyen time-slicing
  • Glif eğrisi sayısına göre kesişim kontrolü maliyetini sınırlama yöntemi
• Bu uygulamada performans büyük bir sorun olmadı; girişteki tam ekran metin Radeon 9070 üzerinde 4K’da yaklaşık 0.1ms tepe maliyet gösterdi ve glifler maksimum örnek sayısına ulaştığında maliyet hızla 0’a yaklaştı

Alt Piksel Antialiasing ve Renk Saçılması

• Alt piksel antialiasing, monitör pikselindeki kırmızı, yeşil ve mavi öğeleri ayrı ayrı örnekleme alanları olarak görüp render eder
• Geleneksel RGB LCD’nin dikey şerit düzeninde yatay çözünürlük fiilen 3 katına çıkar; 4K için 3840×2160, 3840×6480 gibi ele alınabilir
• OLED G9 gibi monitörlerin standart RGB dikey şeritlerden farklı standart dışı alt piksel düzenine sahip olması sorundur
  • Varsayılan RGB dikey dikdörtgen düzeni varsayılırsa üstte yeşil, altta macenta renk saçılması görülür
  • Örnek konumları monitörün gerçek alt piksel düzenine göre ayarlanırsa renk saçılması neredeyse yok olur ve yumuşak bir sonuç elde edilir
• Subpixel Zoo çeşitli alt piksel düzeni örneklerini gösterir; LG WOLED’in red-white-blue-green yapısı standart sıradan farklı bir örnektir
• Alt piksel öğelerini gerçek fiziksel boyutlarından daha büyük görüp birbirleriyle örtüşecek şekilde ayarlamak daha doğru sonuç verdi
  • Alt piksellerin ışığı doğal olarak karışır ve biraz yayılır; bu nedenle örnekleme alanı fiziksel alt pikselden daha büyükmüş gibi davranır
  • Örnekleme alanı piksel dışına da taşmalı ve komşu piksellerin alt piksel ışığıyla da karışmalıdır
• Evan Wallace’ın Easy Scalable Text Rendering yazısı, alt piksel antialiasing sonrası yatay blur gerektiğini savunur; bu da alt piksel öğelerini daha büyük ve örtüşen alanlar olarak görme yaklaşımıyla fiilen aynı etkiye sahiptir

Yazılımın Ekran Alt Piksel Bilgisini Bilebilmesi Gerekir

• Monitörün rastgele alt piksel düzenine erişim mümkün olursa, genel alt piksel antialiasing ve metin render kalitesi iyileştirilebilir
• Bu bilgi ortak ekran protokolleri üzerinden sağlanırsa, standart dizilimli monitörlerde bile donanıma özgü daha ince ayarlı rendering yapılabilir
• Ekran üreticileri, metin render sorunları nedeniyle daha iyi alt piksel düzenleri üzerinde deneme yapmaktan kaçınmak zorunda kalmaz
• Samsung, QD-OLED’de G8’den G9’a geçerken bu sorunları azaltmak için alt piksel düzenini değiştirdi; LG WOLED ve Samsung QD-OLED’de renk saçılması sıkça dile getiriliyor
• Bu sorunun donanım değişiminden çok yazılım düzeltmesiyle ele alınabilecek yönleri var

Gerçek Zamanlı Glif Render Etmenin Pratik Değeri

• İyi UI ve metin kalitesi, bir ürünün algılanan kalitesini yükseltebilir
• Oyunlarda metin kutuları, menüler, başlıklar ve bildirimler gibi kullanıcının dikkatini çeken öğeler sıkça görünür; metin kalitesindeki düşüş, kötü render edilmiş bir 3D sahne kadar deneyimi etkileyebilir
• Persona serisi, Metaphor: ReFantazio ve Nier: Automata, UI ve metin sunumu açısından iyi örneklerdir
• Gerçek zamanlı glif render kalitesini iyileştirme çabası, hem UI hem de oyun rendering’i için somut değere sahiptir

[GN⁺]

Hacker News yorumları

• İlk videoda italik j’nin noktasına ne olmuş?

• Alt piksel yazı tipi render etme okunabilirlik için önemli, ama yazıda belirtildiği gibi mevcut ekran standartlarından piksel dizilimi bilgisini alamıyor olmak üzücü

  • Bu ancak standart çözünürlüklü ekranlar için geçerliydi; o zaman bile “zorunlu” olmaktan çok olsa iyi olur denecek bir şeydi
    Dünya giderek Retina düzeyi ekranlara geçti ve orada alt piksel render etmenin neredeyse bir gerekçesi yok
    Ekran görüntülerinin belirli bir alt piksel dizilimine bağlı kalması, bitmap büyütme/küçültmenin zorlaşması gibi pek çok sıkıntısı var
    CRT ile Retina arasındaki LCD çağının geçici bir yeniliğiydi; bugün daha çok geriye dönük bir teknoloji gibi. Apple’ın birkaç yıl önce macOS’ten kaldırmasının bir nedeni var
  • EDID’in modern halefi olan DisplayID standardı, https://en.wikipedia.org/wiki/DisplayID#0x0C_Display_device_... adresine göre en azından buna izin vermeyi amaçlıyor gibi görünüyor
    Ekran üreticilerinin mi uygulamadığını merak ediyorum. Her hâlükârda en yaygın ekran modelleri için donanım bilgi veritabanında kolayca çıkarılıp saklanabilecek bir bilgi
  • Bunun neden hâlâ çalışmadığını bilmiyorum. On yıllar önce mümkün olması gereken bir şey gibi geliyor
    Yazı harika ve çeşitli örnekleri gösteren “subpixel zoo”ya da bağlantı veriyor: https://geometrian.com/resources/subpixelzoo/
  • “Trajedi” biraz abartı. Her işletim sistemi eski Windows’taki ClearType ayarlayıcısına denk bir özellik sunup sonucu ekran ya da monitör modeline göre hatırlasa yeter
    Monitörün yanlış dizilimi bildirdiği kaçınılmaz durumlarda da böyle bir yöntem gerekli
  • Alt piksel render etme çoğu dil için gerekli değil
    Anti-aliasing’siz bitmap yazı tipleri ya da hinting uygulanmış vektör yazı tipleriyle de okunabilirlik çok iyi
    Ancak Çince veya Japonca gibi karakterleri çok karmaşık ayrıntılar içeren dillerde önemli hâle geliyor

• GTK4, render işlemini GPU’ya taşırken RGB alt piksel render etmeyi bıraktı
  GPU odaklı kararlar yüzünden RGB alt piksel render etmeyi sürdürmenin zorlaştığını duymuştum, ama yazı bunun mümkün olduğunu gösteriyor
  O hâlde GTK’nin gerekçesi başka bir yerde olabilir, ya da sunulan çözümün dezavantajları vardır veya mevcut yığına iyi entegre olmuyordur

  • Cosmic Text(Cosmic DE), swash üzerinden bunu GPU’da yapabiliyor olabilir. Alt piksel render etmeyi destekliyor

• WebGL / WebGPU’da SDF ve MSDF uygulamakla ilgileniyorsanız, yazdığım öğreticiye bakabilirsiniz: https://infinitecanvas.cc/guide/lesson-015#msdf

  • İyi görünüyor. Rust’ın WebGPU uygulaması olan WGPU ile ilgileniyorum; bu öğretici kendini öyle pazarlamasa da fiilen ileri seviye bir kurs gibi görünüyor
    JavaScript örneklerini Rust’a taşımayı denemiştim; doğrudan kopyala/yapıştır yapamıyorsunuz ama API yeterince benzer olduğu için port etmek kolay ve öğrenmek için ideal
    WGPU belgelerini rahat kullanmaya başlamaya da vesile oluyor
  • Sitenin biçimi gerçekten iyi
    GPU ile ilgili öğreticiler hazırlamayı seviyorum ve bunları böyle yapılandırmak isterim; mevcut bir şablon mu, yoksa bir dersin parçası mı merak ediyorum

• Slug kütüphanesi, bu tür bir GPU glif rasterizer’ı uygulayan ticari bir middleware
  [1]: https://sluglibrary.com/

  • Web sitesinde algoritmayı epey ayrıntılı biçimde kendileri açıklamışlar; patent var mı merak ediyorum
    cosmic-text’in yazı tipi ayrıştırma ve düzenleme kısımlarını kullanarak açık kaynak bir wgpu sürümü yapmak eğlenceli olurdu, ama sonunda Slug tarafından dava edilmek hiç eğlenceli olmaz

• GPU sanki fiilen sınırsız vertex/piksel çizme gücüne sahipmiş gibi görünüyor; bu yüzden metni neden çevrimdışı render edip atlas içinde saklamak ve SDF gibi numaralar kullanmak gerektiğini hâlâ anlamıyorum
  Yazıda da glif eğrilerinin atlasa yazıldığını söylüyor; shader’ın metni doğrudan render etmemesi için bir neden mi var, merak ediyorum
  Bezier’i üçgen mesh’e dönüştürmenin mutlaka bir yolu vardır. CAD uygulaması için bir GPU metin renderer’ı yapmaya yeni başlıyorum; umarım yakında nedenini öğrenirim

  • Aynı glifi tekrar tekrar render ederken sonucu cachelemek çoğu zaman daha ucuzdur
    GPU hızlıdır ama sonsuz hızlı değildir; önceden render edilmiş dokuları örneklemede çok güçlüdür
    Bu yalnızca hız meselesi değil, güç tüketimi meselesi de. Zaten monitörün yenileme hızına ulaştıysanız ek performans artışı tepki hızını yükseltmez, ama pil ömrünü uzatabilir
    Render etmede “yeterince hızlı” diye bir nokta yoktur; daha hızlı olmak her zaman kazanç sağlar
  • En temel yazı tiplerinde bile tipik görüntüleme boyutlarında üçgen yoğunluğu muazzamdır
    Modern GPU mimarilerinin hiçbiri yüksek yoğunluklu geometri işlemeyi iyi yapmaz. Böyle durumlarda üçgenleri GPU’ya olduğu gibi yığmak, atlas veya başka tekniklere göre çok verimsizdir
    Çoğu GPU piksel shader’larını 4’lü gruplar hâlinde dispatch eder. Üçgenlerin hepsi 1 piksel boyutundaysa shader thread’lerinin 3’ü görsel çıktıya katkı sağlamaz
    Buna quad overdraw denir. Üstelik gerçek bir neden yokken vertex işlemeye de çok zaman harcanır
  • GPU’nun sınırsız vertex/piksel çizme gücü yok. Metni doğrudan render etmek basitçe daha pahalı
    Mümkün, ama kayda değer bir kazanç olmadan frame bütçesinin bir kısmından vazgeçip güç tüketimini artırmış olursunuz
  • Üçgenler yanlış seçim, ama genel yöndeki itiraz doğru
    Yazar, piksel başına en fazla 512 örnekle Bezier eğrilerini supersampling yaptığı için atlas kullanıyor; bu çok pahalı
    Bunun yerine Bezier eğrisi alanı ile alt piksel alanının kesişim integralini hesaplayan bir formül çok daha hızlı olabilir ve atlas olmadan gerçek zamanlı çalışıp supersampling’den daha doğru sonuç verebilir gibi geliyor
  • GPU çok hızlıdır ama sınırsız değildir. GPU zamanını metne harcarsanız başka yerde kullanamazsınız
    Ve neredeyse her zaman o zamanı başka bir yerde kullanmak istersiniz
    Daha fazla GPU zamanı gerektikçe minimum donanım gereksinimleri de daha hızlı yükselmek zorunda kalır. Metin havalı ve önemlidir, ama kullanıcı ya da müşteri kaybettirecek kadar önemli olmayabilir

• “Yeni OLED’ler görüntü olarak iyi ama standart dışı alt piksel yapısı yüzünden renk taşması sorunu var” demekten daha kötü görünüyor
  Anladığım kadarıyla mesele yalnızca standart dışı olmaları değil; OLED’lerde birbiriyle uyumlu olmayan birden fazla alt piksel dizilimi var
  Bu yüzden FreeType OLED için alt piksel render etmeyi uygulamadı ve metinle çalışmak gerekiyorsa OLED’den kaçınmak için bir neden haline geliyor
  Bu yalnızca FreeType’ın sorunu da değil; Qt, GTK gibi GUI araç takımlarının da buna uyum sağlaması gerekiyor. Çözümde ilerleme var mı pek bilmiyorum
  Herhangi bir monitörün alt piksel yapısına erişebilmek iyi olurdu; belki de bu bilgi EDID ile iletilmeli

  • Bir ölçüde standart alt piksel dizilimine sahip OLED’ler de var
    Örneğin benim dizüstüm dikey BGR dizilimine sahip ve FreeType ile KDE bunu iyi destekliyor
    Tuhaf dizilimler çoğu zaman HDR ekranlarda belirli renklerin, özellikle mavinin, çok hızlı yanmasını önlemek için her renkte farklı boyutlar kullanma gereğinden kaynaklanıyor gibi görünüyor
  • Teorik olarak doğru ama pratikte 4K OLED ekranda kod yazıyorum ve herhangi bir artefakt hissetmedim

• Çok etkileyici bir çalışma
  Bu alana aşina olmayanlar için ekleyeyim: Valve oyunlar için SDF metin render etme tekniğini geliştirdi ve 2007’de bu konuda çığır açıcı bir makale yayımladı
  Bugün de video oyunlarında neredeyse değiştirilmeden çok yaygın kullanılan bir teknik
  2012’de Behdad Esfahbod, OpenGL ES ile GPU’da çalışan bir SDF uygulaması olan Glyphy’yi yaptı; performansı ve hızlı metin dönüşümü gibi yeni özellikleri sayesinde geniş kabul gördü ama yaygın kullanım kazanmadı
  Modern işletim sistemleri ve web tarayıcıları bu tür teknikler yerine 1990’lar tarzı TrueType rasterleştirmeye dayanmayı tercih ediyor
  Hafif ve etkili bir yaklaşım ama yazıda görüldüğü gibi alt piksel hizalama ya da keyfi alt piksel dizilimi yapılamıyor; yakınlaştırma/uzaklaştırma performans maliyeti getiriyor ve eğme, döndürme, 3D dönüşüm gibi karmaşık dönüşümler de metin render motorunun içinde yapılamıyor
  Döndürülmüş ya da deforme edilmiş metin gerekiyorsa bitmap’i yeniden örneklemek zorundasınız; bu da okunabilirliği sağlayan küçük özelliklerin hepsini bozup kötü görünmesine neden oluyor
  İlerlemenin yavaş olmasının nedeni, kazanıma kıyasla iş yükü ve riskin çok büyük olması olabilir. Modern bir web tarayıcısı motorunu GPU hızlandırmalı metin render etme için yeniden yazmayı hayal etmek bile kolay değil
  Glif render etme bunun yalnızca bir parçası; satır kırma işlemi ise ayrı bir sorun. CPU ile GPU arasında çok iletişim gerekebilir ve bu yavaş olabilir; yazılım ile GPU’nun derin entegrasyonu da zordur

  • Metin şekillendirme ve yerleşim, satır kırma dahil olan kısım render etmeyle neredeyse tamamen ayrı; neden böyle söylendiğini pek anlamıyorum
  • https://github.com/servo/pathfinder bu işi GPU compute shader’larıyla yapıyor
    Bu yöntem, SDF gibi donanımın 3D render pipeline’ına zorla uydurmaya çalışmaktan çok daha yüksek performanslı
  • Kayıt düşmek gerekirse, alt piksel anti-aliasing dahil metin render etme Windows’ta uzun zamandır GPU hızlandırmalıydı; Chrome/Firefox’ta da uzun zamandır GPU hızlandırmalı
    Safari’de de muhtemelen öyledir ama doğrudan doğrulayarak söyleyemem
    En güncel teknoloji seviyesinin ya da kullanıcılara dağıtılan uygulamaların gelişmediği düşüncesi yanlış
  • SDF her derde deva değil
    SDF, belirli bir pikselden harfin kenarına kadar olan yerel mesafeyi (Distance), verinin iki boyutlu dizisi olan bir alan (Field) olarak kodlar; bu mesafenin harfin içinde mi dışında mı olduğunu da işaret (Sign) bitiyle gösterir
    Her harfin küçük bir veri haritası vardır; bunlar GPU dostu bir görüntü dosyası biçiminde birlikte paketlenir ve her harfin alt görüntüsünün nerede bulunacağını söyleyen bir açıklama dosyasıyla birlikte SDF render shader’ı tarafından kullanılır
    Bu tür harf tanımları, alan değerleri arasındaki doğrusal interpolasyona karşı çok dayanıklıdır; bu yüzden görece düşük çözünürlüklü haritalarla bile neredeyse kusursuz büyütme yapılabilir. GPU’lar da haritadaki piksel değerlerini interpolate etmede iyidir
    Ancak önemli nokta, bu haritaların geliştirme sırasında, mevcut yazı tipi sisteminden render etmek istediğiniz tüm karakterler için önceden işlenmesi gerektiğidir. Yazı tipinin desteklediği her karakter için gerekir
    Tüm karakterleri yüksek çözünürlüklü bitmap yazı tipi olarak render etmeye göre veri miktarı çok daha azdır ama yazı tipi kontur tanımının kendisinden çok daha fazladır
    İşletim sistemleri ya da tarayıcılar gibi dünya çapında mümkün olan tüm metinleri desteklemek isteyen sistemler SDF’yi metin render sistemi olarak kullanamaz. Tüm Unicode karakter kümesi için SDF haritaları gerekir ve bu çok büyük olur
    Oyunlara genelde iyi uyar; çünkü çoğunlukla yerelleştirmenin yeterince iyi olmaması sorun edilmeyebilir ya da tamamen keyfi metin göstermeleri gerekmez
    Orijinal SDF emoji de destekleyemez. Yalnızca glif kenarına kadar olan mesafeyi kodlar, glifin içindeki renk bilgisini içermez
    Birden çok rengi destekleyen geliştirilmiş sürüm Multichannel SDF vardır ama toplam renk sayısında sınır bulunur
    Pratikte oyun içi metinde SDF kullanan ve tüm dünyadan toplulukların etkileştiği bir sohbet sistemi de olan oyunlara yakından bakarsanız, oyun içi metin ile sohbet sistemindeki metin render etmenin farklı olma ihtimali yüksektir
  • Modern bir web tarayıcısı motorunu GPU hızlandırmalı metin render etme için yeniden yazmak zor ama bunun zaten kısmen yapıldığını sanıyordum
    https://keithclark.co.uk/articles/gpu-text-rendering-in-webk... (2014) şöyle diyor: “Chrome, Safari veya Opera’nın mevcut sürümlerinde bir öğe GPU’ya yükseltildiğinde alt piksel anti-aliasing’i kaybeder ve metin gri tonlamalı yöntemle render edilir”
    Öyleyse eksik olanın ne olduğunu merak ediyorum. Bu cümleye göre en azından UTF-8 dizgesinden bitmap’e giden aşamanın bir kısmı GPU’da yapılabiliyor olmalı gibi geliyor

• Etkileyici bir iş
  Ancak alt piksel kenar yumuşatmaın kişisel olarak pek bir anlamı olmadığını düşünüyorum. 72 dpi monitörlerin kullanıldığı 2000’lerde iyi bir hack’ti, ama modern Retina ekranlarda fark edilmesi zor ve çok küçük bir iyileştirme uğruna birçok dezavantaj getiriyor
  Yalnızca opak arka planlar üzerinde çalışıyor; rasterleştirilmiş sonuca yeniden boyutlandırma, aynalama, blur gibi efektler uygulanamıyor ve ekran görüntüleri başka bir ekranda bakıldığında kötüleşiyor

  • Alt piksel kenar yumuşatmayı kaldırmak büyük ölçüde basitleştirme sağlar, ama hâlâ birçok masaüstü kullanıcısı düşük DPI monitör kullanıyor
    Firefox donanım araştırmasına [1] göre kullanıcıların %16’sı 1366x768 çözünürlüklü ekran kullanıyor
    Bu yalnızca basitçe eski donanım meselesi değil; 96 dpi monitörler ve dizüstü bilgisayarlar hâlâ üretiliyor
    [1]: https://data.firefox.com/dashboard/hardware
  • Sonuçta “Ben yüksek DPI ekran kullanıyorum, kullanmayanları umursamam” demek gibi geliyor
    Diğer argümanlar, uygulanabildiği yerlerde alt piksel render etmenin verdiği daha iyi sonuçlarla karşılaştırıldığında pek önemli değil
  • Yazarın istediği gibi ekranın alt piksel dizilimini öğrenmeye yarayan bir protokol ortaya çıkıp yaygın biçimde benimsense bile, bazı üreticilerin bunu yanlış uygulayıp son kullanıcıların anlamasının çok zor olacağı render sorunları yaratma ihtimali yüksek

• SDF, en yakın kenara olan piksel mesafesini hesaplar; geleneksel yazı tipi renderer’larının ise piksel kapsamasını hesaplaması önemli bir farktır
  Piksel kapsaması optimaldir. Küçük yazı tiplerinde, kenarların birleştiği yerlerde SDF kötü görünebilir
  Yüksek PPI ekranlarda bu daha az sorun olabilir. Kendi SDF renderer’ımı uyguladım, ama FreeType’tan daha kötü görünüyordu

  • Kapsama ile mesafe arasındaki ayrım asıl mesele değil. Mesafe alanı renderer’larında da kapsama çok kolay hesaplanabilir
    Ancak kesişim noktalarında, ya da genel olarak keskin köşelerde mesafe alanının sorun çıkardığı tespiti doğru
    Birden fazla mesafe alanı kullanıp bunların kesişimini render etmek bunu bir ölçüde hafifletebilir. Örneğin https://github.com/Chlumsky/msdfgen var