Merender Teks yang Tajam di GPU

 (osor.io)
1 poin oleh GN⁺ 2025-06-14 | 1 komentar | Bagikan ke WhatsApp
  • Pendekatan Multi-Channel SDF yang ada masih memiliki keterbatasan pada goresan tipis, atlas besar, pengecilan·pembesaran, dan pergerakan halus, sehingga diimplementasikan ulang sebagai rasterisasi runtime di GPU
  • Pipeline baru hanya mengirim data kurva Bézier dari glyph yang sedang terlihat ke GPU, menggambarnya ke atlas saat runtime, lalu mengambil sampel dari atlas itu di layar
  • Jika glyph tetap berada di layar, cache atlas dipertahankan sambil mengakumulasi sampel untuk meningkatkan kualitas; dimulai dari 8 samples-per-pixel pada frame pertama dan disempurnakan hingga maksimum 512 samples
  • Kunci cache mencakup font, glyph_index, ukuran piksel, dan offset subpiksel; nilai posisi dan ukuran yang berdekatan dilipat menjadi nilai yang sama dengan fixed-point 8-bit untuk meningkatkan reuse
  • Dengan memodelkan struktur subpiksel RGB per monitor sebagai area sampel, color fringing dapat dikurangi bahkan pada susunan nonstandar seperti OLED G9, dan demo teks layar penuh 4K menunjukkan biaya puncak sekitar 0,1 ms pada Radeon 9070

Alasan memilih rasterisasi vektor runtime alih-alih SDF

  • Implementasi sebelumnya menggunakan Multi-Channel Signed Distance Fields dan secara umum bekerja dengan baik, tetapi dalam penggunaan nyata masih ada beberapa batasan
    • Kualitas: pada font dengan goresan tipis atau banyak detail, fitur bisa hilang atau muncul artefak, dan kadang diperlukan SDF beresolusi lebih tinggi
    • Ukuran atlas: karena SDF dibuat offline lalu disimpan dalam atlas, font Jepang·Tionghoa dengan banyak glyph sulit dipanggang ke satu atlas
    • Fleksibilitas: sulit menerapkan ide baru seperti masalah pengecilan·pembesaran atau subpixel antialiasing, dan tidak cocok untuk gambar vektor yang dapat dibuat·diedit saat runtime
    • Kesederhanaan: tahap mengubah kurva glyph asli menjadi tekstur perantara menambah kompleksitas sistem
  • Bahkan font Latin seperti Miama membutuhkan atlas 4096×1152 yang memakai area 64×64 untuk tiap glyph; jika beberapa font dipakai saat runtime, biaya memori dan bandwidth streaming menjadi besar
  • Tujuan pendekatan baru ini adalah menggunakan kurva Bézier yang dibuat pembuat glyph secara lebih langsung, sehingga mengurangi tahap transformasi dari data asli ke piksel akhir

Pipeline keseluruhan

  • Intinya adalah, alih-alih memanggang semua glyph terlebih dahulu secara offline, hanya kurva dari glyph yang sedang terlihat yang dikirim ke GPU dan dirasterisasi pada saat dibutuhkan
  • Alur pemrosesannya sederhana
    • Memuat data kurva glyph dari font
    • GPU merasterisasi glyph ke atlas saat runtime
    • Saat output ke layar, atlas tersebut disampling
  • Jika glyph yang sama terus digunakan pada frame berikutnya, glyph dibiarkan di atlas dan sampel diakumulasi untuk menyempurnakannya hingga menjadi subpixel antialiasing berkualitas tinggi
  • Karena representasi vektor dirender secara langsung, perubahan resolusi lebih mudah ditangani, dan bukan hanya coverage seluruh piksel, tetapi juga coverage tiap elemen subpiksel dapat dihitung

Pemrosesan kurva glyph

  • Untuk pemuatan font, FreeType digunakan sebagai lapisan perantara pada tool offline untuk membaca format yang didukung, lalu kurva tiap glyph ditelusuri dan disimpan ke format aset sendiri
  • Kurva glyph dapat mencakup garis, Bézier kuadratik, dan Bézier kubik; agar shader lebih sederhana, semuanya dikonversi menjadi Bézier kuadratik
    • Garis dibuat menjadi Bézier kuadratik dengan menambahkan satu titik kontrol di tengah dua titik
    • Bézier kubik dibagi menjadi dua Bézier kuadratik, dan ini adalah konversi lossy yang menurunkan derajatnya
  • Cara membagi Bézier kubik menjadi dua Bézier kuadratik bekerja baik pada sebagian besar font yang dicoba, tetapi metode yang lebih canggih untuk mengurangi error juga memungkinkan
  • Jika dibutuhkan konversi berkualitas lebih tinggi, tool offline dapat mengubahnya ke format yang hanya memiliki Bézier kuadratik, seperti TrueType .ttf, sehingga konversi ini sendiri bisa dihindari
  • Di grafik Desmos, bentuk Bézier kubik input dan dua Bézier kuadratik hasilnya dapat dibandingkan

Perhitungan coverage dan optimisasi akses kurva

  • Coverage dihitung per piksel dengan menembakkan ray horizontal dari kiri ke kanan, memeriksa perpotongan dengan kurva, lalu mengakumulasi winding number
  • Latar matematika dan implementasinya dapat merujuk ke GPU Font Rendering dari GreenLightning dan video Rendering Text dari Sebastian Lague
  • Ketidakakuratan perhitungan perpotongan dapat terjadi pada sampel di ketinggian tertentu, tetapi jika ratusan sampel diakumulasi, satu atau dua error nyaris tidak terlihat setelah dirata-ratakan
    • Saat mengakumulasi maksimum 512 sampel, jika satu sampel salah, hasilnya menjadi 1/512=0.00195 alih-alih 0, atau 511/512=0.99804 alih-alih 1
    • Ambang clamp juga dapat ditetapkan saat coverage mendekati nilai ekstrem
  • Untuk distribusi posisi sampel digunakan $R_2$ sequence dari Martin Roberts, dan distribusinya dari waktu ke waktu dapat dilihat pada contoh Shadertoy
  • Untuk mengurangi biaya akses kurva, glyph dibagi menjadi beberapa band horizontal, dan hanya kurva yang menyentuh tiap band yang disimpan sebagai bitset
    • Karena hanya ray horizontal yang dilacak, himpunan kurva yang perlu diperiksa tiap texel dapat dikurangi secara signifikan
    • Jika rentang band yang sama diakses pada level wave, iterasi dan pembacaan kurva dapat diskalarkan
    • Saat merasterisasi ke atlas di compute shader, thread dipacking secara horizontal dalam urutan row-major untuk meminimalkan rentang band yang disentuh wave

Packing atlas dan kunci cache

  • Awalnya rasterisasi dilakukan langsung ke layar, tetapi biaya menghitung antialiasing berkualitas tinggi setiap frame terlalu besar
  • Sebagian besar teks tetap berada pada ukuran dan posisi yang sama selama beberapa frame, dan glyph yang sama berulang pada ukuran yang sama, sehingga atlas dan akumulasi temporal cocok digunakan
  • Jika glyph yang dibutuhkan belum ada, atlas mengalokasikan ruang dan memulai rasterisasi; jika sudah ada, hasil yang ada langsung digunakan
    • Selama frame, glyph di atlas diperiksa untuk menentukan apakah akan tetap dipertahankan, disampling lebih lanjut, atau dilepas ruangnya karena tidak dipakai
  • Kunci atlas mencakup elemen berikut
    • font
    • glyph_index
    • quantized_size_in_pixels_x, quantized_size_in_pixels_y
    • quantized_subpixel_offset_x, quantized_subpixel_offset_y
  • Offset subpiksel setara dengan frac(pixel_position), dan diperlukan untuk menghasilkan antialiasing yang sesuai posisi ketika glyph tidak tepat sejajar dengan grid piksel atau saat discroll halus
  • Jika nilai floating-point digunakan apa adanya sebagai kunci, nilai yang secara matematis seharusnya sama bisa berbeda pada level bit, sehingga posisi dan ukuran yang berdekatan dilipat menjadi nilai yang sama dengan fixed-point pecahan 8-bit
  • Pada editor teks dengan banyak teks statis yang memakai font monospace, jarak karakter dan posisi baris dapat diselaraskan ke batas piksel untuk meningkatkan hit rate cache atlas dari glyph yang sama

Penempatan atlas berbasis Z-Order

  • Penempatan glyph saat runtime menggunakan Z-Order Packing dan bitset sel kosong
  • Z-Order berbasis Morton code memungkinkan sel 2D diperlakukan seperti array 1D panjang, dan jika sel berurutan dialokasikan sebanyak pangkat dua, hasilnya menjadi area persegi pada atlas 2D
  • Sel dasar berukuran 16×16 texel, dan ukuran glyph dibulatkan naik ke pangkat dua berikutnya
    • Misalnya glyph 25×29 mengalokasikan chunk 32×32
    • Dalam kasus ini diperlukan 4 sel 16×16, sehingga dicari dan digunakan 4 bit berurutan yang selaras
  • Glyph alfabet Latin yang panjang dan tipis kebanyakan berbentuk vertikal, sehingga dengan memakai Z-Order yang ditransposisikan, glyph seperti l, j, i, 1 dapat memakai hanya setengah ruang
  • Sebaliknya, untuk kasus glyph panjang dan tipis berbentuk horizontal seperti bahasa Arab, Z-Order standar lebih cocok

Cara meningkatkan kualitas dengan akumulasi temporal

  • Jika glyph tetap berada di atlas, sampel dapat ditambahkan sedikit demi sedikit setiap frame untuk menyempurnakan hasilnya
  • Jadwal dasar dimulai dengan 8 samples-per-pixel pada frame pertama saat glyph muncul, lalu 4 pada frame berikutnya, 2 pada frame setelahnya, kemudian menambahkan 1 sampel per frame hingga total 512
  • Alasan menetapkan kualitas frame pertama cukup tinggi adalah karena glyph yang bergerak halus atau berubah ukuran seolah diinisialisasi ulang setiap frame
  • Kualitas dan performa dapat diatur dengan berbagai cara
    • Jumlah sampel·ray yang ditambahkan tiap frame
    • Apakah sampel dinaikkan pada beberapa frame awal glyph
    • Batas atas total sampel per frame
    • Time-slicing yang memperbarui glyph lama setiap beberapa frame, bukan setiap frame
    • Cara membatasi biaya pemeriksaan perpotongan berdasarkan jumlah kurva glyph
  • Dalam implementasi ini performa tidak menjadi masalah besar; teks layar penuh pada bagian awal menunjukkan puncak sekitar 0,1 ms pada 4K di Radeon 9070, dan setelah glyph mencapai jumlah sampel maksimum, biayanya cepat mendekati 0

Subpixel antialiasing dan color fringing

  • Subpixel antialiasing merender elemen merah·hijau·biru di dalam piksel monitor sebagai area sampel masing-masing
  • Pada struktur garis vertikal RGB LCD tradisional, resolusi horizontal secara efektif menjadi 3 kali lipat, sehingga pada 4K 3840×2160 dapat diperlakukan seperti 3840×6480
  • Masalahnya, monitor seperti OLED G9 memiliki struktur subpiksel nonstandar yang berbeda dari garis vertikal RGB standar
    • Jika diasumsikan sebagai struktur persegi panjang vertikal RGB dasar, color fringing hijau terlihat di bagian atas dan magenta di bagian bawah
    • Jika posisi sampel diatur sesuai struktur subpiksel monitor yang sebenarnya, color fringing hampir tidak ada dan hasilnya halus
  • Subpixel Zoo menunjukkan berbagai contoh struktur subpiksel, dan struktur red-white-blue-green pada LG WOLED adalah contoh yang berbeda dari urutan standar
  • Hasil yang lebih akurat didapat dengan menganggap elemen subpiksel lebih besar dari ukuran fisiknya dan mengaturnya agar saling tumpang tindih
    • Cahaya subpiksel bercampur secara alami dan sedikit menyebar, sehingga area sampel berperilaku seolah lebih besar daripada subpiksel fisik
    • Area sampel juga harus menyebar ke luar piksel, dan bercampur dengan cahaya subpiksel dari piksel sekitar
  • Easy Scalable Text Rendering dari Evan Wallace berpendapat bahwa blur horizontal diperlukan setelah subpixel antialiasing, yang pada dasarnya memiliki efek yang sama dengan menganggap elemen subpiksel lebih besar dan saling tumpang tindih

Perangkat lunak perlu mengetahui informasi subpiksel display

  • Jika struktur subpiksel arbitrer pada monitor dapat diakses, kualitas subpixel antialiasing dan rendering teks secara umum dapat ditingkatkan
  • Jika informasi seperti ini disediakan melalui protokol display umum, rendering yang lebih rinci per hardware juga dimungkinkan bahkan pada monitor dengan susunan standar
  • Produsen display tidak perlu menghindari eksperimen struktur subpiksel yang lebih baik karena masalah rendering teks
  • Samsung mengubah struktur subpiksel dari G8 ke G9 pada QD-OLED untuk mengurangi masalah ini, dan color fringing sering disebut pada LG WOLED dan Samsung QD-OLED
  • Masalah ini masih punya ruang untuk ditangani dengan koreksi perangkat lunak, bukan penggantian hardware

Nilai praktis rendering glyph real-time

  • UI yang baik dan kualitas teks dapat meningkatkan kualitas produk yang dirasakan pengguna
  • Dalam game, elemen seperti kotak teks, menu, judul, dan notifikasi yang menarik perhatian pengguna sering muncul; penurunan kualitas teks dapat memengaruhi pengalaman sama seperti adegan 3D dengan rendering buruk
  • Seri Persona, Metaphor: ReFantazio, dan Nier: Automata adalah contoh yang baik dalam ekspresi UI dan teks
  • Upaya meningkatkan kualitas rendering glyph real-time memiliki nilai nyata baik untuk UI maupun rendering game

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-14
Komentar Hacker News

  • Apa yang terjadi dengan titik pada huruf j miring di video pertama?

  • Rendering font subpiksel penting untuk keterbacaan, tetapi seperti disorot dalam tulisan itu, sayang sekali kita tidak bisa mendapatkan spesifikasi susunan piksel dari standar display yang ada

    • Itu hanya berlaku untuk display beresolusi standar, dan bahkan saat itu pun lebih seperti sesuatu yang bagus jika ada, bukan “wajib”
      Dunia makin bergeser ke display kelas Retina, dan di sana hampir tidak ada alasan untuk rendering subpiksel
      Banyak masalahnya: screenshot menjadi terikat pada susunan subpiksel tertentu, dan pembesaran/pengecilan bitmap juga sulit
      Itu adalah inovasi sementara pada era LCD di antara CRT dan Retina, dan sekarang lebih mirip teknologi yang melihat ke belakang. Ada alasan yang masuk akal mengapa Apple menghapusnya dari macOS beberapa tahun lalu
    • Standar DisplayID, yaitu penerus modern EDID, menurut https://en.wikipedia.org/wiki/DisplayID#0x0C_Display_device_... setidaknya tampaknya memang dimaksudkan untuk memungkinkan hal ini
      Saya penasaran apakah produsen display tidak mengimplementasikannya. Bagaimanapun, untuk model display yang paling umum, ini adalah informasi yang bisa dengan mudah disimpulkan dan disimpan dalam database informasi hardware
    • Saya tidak tahu kenapa ini masih belum bisa. Rasanya ini sesuatu yang sudah mungkin sejak puluhan tahun lalu
      Tulisannya bagus, dan juga menautkan “subpixel zoo” yang menunjukkan berbagai contoh: https://geometrian.com/resources/subpixelzoo/
    • Menyebutnya “tragedi” agak berlebihan. Setiap sistem operasi cukup menyediakan fitur yang setara dengan ClearType tuner lama di Windows, lalu mengingat hasilnya per layar atau per model monitor
      Pendekatan seperti ini tetap diperlukan bahkan untuk kasus yang tak terhindarkan ketika monitor melaporkan susunan yang salah
    • Rendering subpiksel tidak diperlukan untuk sebagian besar bahasa
      Font bitmap tanpa antialiasing atau font vektor yang di-hint saja sudah sangat mudah dibaca
      Ini baru menjadi penting untuk bahasa seperti Mandarin atau Jepang, yang karakternya memiliki detail sangat kompleks

  • GTK4 meninggalkan rendering subpiksel RGB saat memindahkan rendering ke GPU
    Saya pernah dengar keputusan yang berpusat pada GPU membuat rendering subpiksel RGB sulit dipertahankan, tetapi tulisan ini menunjukkan bahwa hal itu mungkin
    Kalau begitu, mungkin alasan GTK ada di tempat lain, atau solusi yang diajukan punya kekurangan, atau tidak terintegrasi dengan baik ke stack yang ada

    • Cosmic Text (Cosmic DE) mungkin bisa melakukan ini di GPU lewat swash. Ia mendukung rendering subpiksel

  • Jika tertarik pada cara mengimplementasikan SDF dan MSDF di WebGL / WebGPU, lihat tutorial yang saya tulis sendiri: https://infinitecanvas.cc/guide/lesson-015#msdf

    • Kelihatannya bagus. Saya tertarik pada WGPU, implementasi WebGPU di Rust, dan meski tutorial ini tidak mempromosikan diri seperti itu, sebenarnya terlihat seperti kursus tingkat lanjut
      Saya pernah mencoba memindahkan contoh JavaScript ke Rust; tidak bisa sekadar copy/paste, tetapi API-nya cukup mirip sehingga mudah di-port, cocok untuk belajar
      Itu juga jadi pemicu untuk makin terbiasa memakai dokumentasi WGPU
    • Format situsnya benar-benar bagus
      Saya suka membuat tutorial terkait GPU dan ingin menyusunnya seperti ini; penasaran apakah ini template yang sudah ada atau bagian dari suatu kuliah

  • Library Slug adalah middleware komersial yang mengimplementasikan rasterizer glif GPU seperti ini
    [1]: https://sluglibrary.com/

    • Di situsnya mereka menjelaskan sendiri cukup banyak tentang algoritmanya, jadi saya penasaran apakah ada paten
      Akan menarik membuat versi wgpu open source dengan memakai sebagian parsing font dan layout dari cosmic-text, tetapi sama sekali tidak akan menyenangkan kalau ujung-ujungnya dituntut oleh Slug

  • GPU tampak seolah memiliki kemampuan menggambar vertex/piksel yang praktis tak terbatas, jadi saya masih belum paham mengapa teks harus dirender offline, disimpan dalam atlas, bahkan memakai trik seperti SDF
    Tulisan itu juga mengatakan kurva glif ditulis ke atlas, tetapi saya penasaran kenapa shader tidak merender teks secara langsung saja
    Pasti ada cara mengubah Bézier menjadi mesh segitiga. Saya baru akan mulai membuat renderer teks GPU untuk aplikasi CAD, jadi semoga segera tahu alasannya

    • Saat merender glif yang sama berulang kali, biasanya lebih murah untuk men-cache hasilnya
      GPU memang cepat, tetapi tidak cepat tanpa batas, dan sangat kuat dalam mengambil sampel dari tekstur yang sudah dirender sebelumnya
      Ini bukan hanya soal kecepatan, melainkan juga konsumsi daya. Jika sudah mencapai refresh rate monitor, peningkatan performa tambahan tidak akan meningkatkan responsivitas, tetapi bisa memperpanjang daya tahan baterai
      Dalam rendering tidak ada yang namanya “cukup cepat”; kalau bisa lebih cepat, selalu ada manfaatnya
    • Bahkan font dasar pun memiliki kepadatan segitiga yang sangat tinggi pada ukuran tampilan umum
      Semua arsitektur GPU modern tidak menangani geometri padat dengan baik. Dalam kasus seperti ini, sekadar mendorong segitiga ke GPU sangat tidak efisien dibanding atlas atau teknik lain
      Sebagian besar GPU mendispatch pixel shader dalam unit 4. Jika semua segitiga berukuran 1 piksel, tiga thread shader tidak akan berkontribusi pada keluaran visual
      Ini disebut quad overdraw. Selain itu, banyak waktu juga dihabiskan untuk pemrosesan vertex tanpa alasan nyata
    • GPU tidak memiliki kemampuan menggambar vertex/piksel yang tak terbatas. Merender teks secara langsung sekadar lebih mahal
      Memang bisa, tetapi itu berarti mengorbankan sebagian anggaran frame dan meningkatkan penggunaan daya tanpa banyak keuntungan
    • Segitiga adalah pilihan yang salah, tetapi arah besar pertanyaannya tepat
      Penulis memakai atlas karena ia melakukan supersampling kurva Bézier hingga 512 sampel per piksel, dan itu sangat mahal
      Sebagai gantinya, menghitung integral perpotongan antara area kurva Bézier dan area subpiksel bisa jauh lebih cepat, dan tampaknya bisa berjalan real-time tanpa atlas sekaligus lebih akurat daripada supersampling
    • GPU sangat cepat, tetapi tidak tak terbatas. Jika waktu GPU dipakai untuk teks, waktu itu tidak bisa dipakai di tempat lain
      Dan hampir selalu kita ingin memakai waktu itu untuk hal lain
      Semakin banyak waktu GPU yang dibutuhkan, semakin cepat pula hardware minimum yang disyaratkan. Teks memang keren dan penting, tetapi mungkin tidak cukup penting sampai layak kehilangan pengguna atau pelanggan

  • Kelihatannya lebih buruk daripada sekadar “OLED baru memang enak dilihat, tetapi punya masalah color fringing karena struktur subpiksel yang tidak standar”
    Sejauh yang saya pahami, masalahnya bukan hanya tidak standar; pada OLED ada beberapa susunan subpiksel yang tidak saling kompatibel
    Karena itu FreeType tidak mengimplementasikan rendering subpiksel untuk OLED, dan ini menjadi alasan untuk menghindari OLED jika perlu bekerja dengan teks
    Ini juga bukan hanya masalah FreeType; toolkit GUI seperti Qt dan GTK juga harus ikut menyesuaikan. Saya tidak tahu pasti apakah ada kemajuan dalam penyelesaiannya
    Akan bagus kalau kita bisa mengakses struktur subpiksel monitor secara arbitrer, dan mungkin informasi semacam ini seharusnya disampaikan lewat EDID

    • Ada juga OLED yang memiliki susunan subpiksel yang cukup standar
      Misalnya laptop saya memakai susunan BGR vertikal, dan FreeType serta KDE mendukungnya dengan baik
      Susunan yang aneh tampaknya sering muncul pada display HDR karena tiap warna perlu memakai ukuran berbeda agar warna tertentu, terutama biru, tidak burn-in terlalu cepat
    • Secara teori itu benar, tetapi dalam praktiknya saya menulis kode di display OLED 4K dan tidak merasakan artefak apa pun

  • Ini pekerjaan yang sangat mengesankan
    Sebagai tambahan bagi yang tidak akrab dengan bidang ini, Valve membuat rendering teks SDF untuk game dan menerbitkan makalah terobosan tentang topik ini pada 2007
    Hingga kini teknik ini masih sangat luas dipakai di video game, hampir tanpa perubahan
    Pada 2012 Behdad Esfahbod membuat Glyphy, implementasi SDF yang berjalan di GPU dengan OpenGL ES, dan mendapat banyak pengakuan karena performa serta fitur baru seperti transformasi teks yang cepat, tetapi tidak dipakai secara luas
    Sistem operasi modern dan browser web lebih memilih bergantung pada rasterisasi TrueType ala 1990-an ketimbang teknik seperti ini
    Itu pendekatan yang ringan dan efektif, tetapi seperti terlihat di tulisan tersebut, tidak bisa melakukan penyelarasan subpiksel atau susunan subpiksel arbitrer; zoom in/out punya biaya performa besar; dan transformasi kompleks seperti skew, rotasi, atau transformasi 3D juga tidak bisa dilakukan di dalam mesin rendering teks
    Jika perlu teks yang diputar atau ditransformasikan, bitmap harus di-resample, yang merusak semua detail kecil pembentuk keterbacaan sehingga hasilnya tidak bagus
    Alasan kemajuannya lambat mungkin karena beban kerja dan risikonya terlalu besar dibanding manfaatnya. Membayangkan menulis ulang mesin browser web modern dengan rendering teks berakselerasi GPU saja sudah tidak mudah
    Rendering glyph hanyalah satu bagian, sedangkan pemrosesan line breaking adalah masalah lain. Ini bisa lambat karena perlu banyak komunikasi antara CPU dan GPU, dan integrasi mendalam antara software dan GPU juga sulit

    • Bagian yang mencakup text shaping, layout, sampai line breaking itu hampir sepenuhnya terpisah dari rendering, jadi saya kurang paham kenapa dikatakan begitu
    • https://github.com/servo/pathfinder melakukan pekerjaan ini dengan compute shader GPU
      Cara ini performanya jauh lebih baik daripada memaksakannya masuk ke pipeline rendering 3D hardware seperti SDF
    • Sebagai catatan, rendering teks termasuk antialiasing subpiksel sudah lama diakselerasi GPU di Windows, dan juga sudah lama diakselerasi GPU di Chrome/Firefox
      Safari mungkin juga begitu, tetapi saya tidak bisa memastikannya sendiri
      Anggapan bahwa tingkat teknologi terbaru atau implementasi yang dikirimkan ke pengguna tidak berkembang itu keliru
    • SDF bukan solusi serba bisa
      SDF mengenkode jarak lokal (Distance) dari suatu piksel ke tepi huruf sebagai medan (Field), yaitu array data dua dimensi, dan menandai apakah jarak itu berada di dalam atau di luar huruf dengan bit tanda (Sign)
      Setiap huruf memiliki peta data kecil; peta-peta itu dipaketkan bersama dalam bentuk file gambar yang ramah GPU, lalu digunakan oleh shader rendering SDF bersama file deskripsi yang memberi tahu di mana subgambar tiap huruf bisa ditemukan
      Definisi huruf seperti ini sangat kuat terhadap interpolasi linear di antara nilai-nilai field, sehingga peta beresolusi relatif rendah pun memungkinkan pembesaran yang nyaris sempurna. GPU juga piawai menginterpolasi nilai piksel pada peta
      Namun yang penting adalah peta-peta ini harus dipraproses selama pengembangan untuk semua karakter yang ingin dirender dari sistem font yang ada. Ini diperlukan untuk setiap karakter yang didukung font
      Datanya memang jauh lebih sedikit daripada merender semua karakter sebagai font bitmap resolusi tinggi, tetapi jauh lebih banyak daripada definisi outline font itu sendiri
      Sistem seperti sistem operasi atau browser, yang ingin mendukung semua teks yang mungkin ada di seluruh dunia, tidak bisa memakai SDF sebagai sistem rendering teks. Mereka akan membutuhkan peta SDF untuk seluruh himpunan karakter Unicode, sehingga ukurannya menjadi terlalu besar
      Game cocok dengan pendekatan ini karena umumnya tidak harus memiliki lokalisasi yang benar-benar menyeluruh, atau tidak perlu menampilkan teks yang sepenuhnya arbitrer
      SDF asli juga tidak bisa mendukung emoji. Ia hanya mengenkode jarak ke tepi glyph dan tidak memuat informasi warna di dalam glyph
      Memang ada versi perbaikan bernama Multichannel SDF yang mendukung beberapa warna, tetapi jumlah total warnanya tetap terbatas
      Dalam praktiknya, jika mengamati game yang memakai SDF untuk teks di dalam game sekaligus memiliki sistem chat tempat komunitas global saling berinteraksi, kemungkinan besar rendering teks di dalam game dan rendering teks pada sistem chat berbeda
    • Menulis ulang mesin browser web modern dengan rendering teks berakselerasi GPU memang rumit, tetapi saya kira sebagian sudah dilakukan
      Menurut https://keithclark.co.uk/articles/gpu-text-rendering-in-webk... (2014), “ketika sebuah elemen dipromosikan ke GPU di versi Chrome, Safari, atau Opera saat ini, ia kehilangan antialiasing subpiksel dan teks dirender dengan metode grayscale”
      Kalau begitu, saya penasaran apa yang masih kurang. Jika mengikuti kalimat itu, setidaknya sebagian tahap dari string UTF-8 menjadi bitmap tampaknya bisa dilakukan di GPU

  • Ini pekerjaan yang mengesankan
    Namun, secara pribadi saya merasa subpixel antialiasing tidak terlalu berarti. Pada era 2000-an saat orang masih memakai monitor 72dpi, ini adalah trik yang lumayan, tetapi di layar Retina modern sulit dibedakan, dan demi peningkatan yang sangat kecil kita mendapat berbagai kelemahan
    Ini hanya berfungsi di atas latar belakang opak, hasil rasterisasinya tidak bisa diberi efek seperti perubahan ukuran, mirroring, atau blur, dan screenshot akan terlihat buruk jika dilihat di display lain

    • Menghilangkan subpixel antialiasing memang akan sangat menyederhanakan, tetapi masih banyak pengguna desktop yang memakai monitor DPI rendah
      Menurut survei hardware Firefox [1], 16% pengguna memakai display beresolusi 1366x768
      Ini bukan sekadar masalah hardware lama; monitor dan laptop 96dpi pun masih diproduksi hingga sekarang
      [1]: https://data.firefox.com/dashboard/hardware
    • Pada akhirnya terdengar seperti mengatakan, “Saya memakai layar DPI tinggi, jadi saya tidak peduli pada orang yang tidak”
      Argumen lainnya tidak terlalu penting dibandingkan hasil yang lebih baik dari subpixel rendering di tempat yang memang bisa diterapkan
    • Sekalipun protokol untuk mengetahui susunan subpixel display, seperti yang diharapkan penulis, dibuat dan diadopsi luas, besar kemungkinan sebagian produsen akan mengimplementasikannya secara keliru dan menciptakan masalah rendering yang sangat sulit dipahami pengguna akhir

  • Yang penting tentang SDF adalah ia menghitung jarak piksel ke tepi terdekat, sedangkan renderer font tradisional menghitung cakupan piksel
    Cakupan piksel adalah yang optimal. Pada font kecil, SDF bisa terlihat buruk di bagian tempat tepi-tepi bertemu
    Di display PPI tinggi mungkin ini tidak terlalu bermasalah. Saya pernah mengimplementasikan renderer SDF sendiri, dan hasilnya tampak lebih buruk daripada FreeType

    • Perbedaan antara cakupan dan jarak bukanlah inti masalahnya. Pada renderer distance field pun cakupan bisa dihitung dengan sangat mudah
      Namun, benar bahwa distance field menimbulkan masalah pada titik perpotongan, atau secara umum pada sudut yang tajam
      Ini bisa dikurangi sampai batas tertentu dengan memakai beberapa distance field dan merender perpotongannya. Contohnya ada https://github.com/Chlumsky/msdfgen