Tidak. UniText tidak memanggang texture atlas per-font ke dalam build Anda. Glyph dirasterisasi saat runtime ke dalam atlas bersama (berbasis Texture2DArray) dengan penghitungan referensi per-glyph dan penggusuran LRU. Hanya data font yang disertakan dalam build Anda — tidak pernah atlas. Selain itu, Kompresi Font bawaan (Zstd, level 22) memperkecil data font hingga ~2.7× untuk Latin/Arab (CJK lebih moderat, ~1.3×).

Tidak. Aset UniTextFont menyematkan byte font di dalam dirinya sendiri. Referensi ke font sumber bersifat khusus Editor (dibungkus dalam #if UNITY_EDITOR) — referensi itu sama sekali tidak ada di build player, jadi bukan dependensi runtime dan tidak akan ikut tertarik ke dalam AssetBundle melalui pencarian dependensi. Anda dapat menghapus file .ttf setelah aset dibuat.

Tidak. Anda dapat membangun UniTextFont dari file .ttf yang berada di mana saja pada disk Anda melalui jendela tool UniText (dialog file membaca byte-nya secara langsung). Mengimpor font ke dalam proyek bersifat opsional.

• WebGL: build kosong berukuran ≈ 6–10 MB (bervariasi menurut versi Unity dan paket yang terpasang); UniText menambahkan library native-nya (HarfBuzz, FreeType). Ini adalah library standar industri yang sama yang disertakan oleh Advanced Text Generator milik UI Toolkit Unity sendiri — tidak ada yang eksotis (UniText hanya membawa salinannya sendiri). • Android: APK dengan dua arsitektur membawa keduanya — sekitar +4 MB per arsitektur. Tetapi saat Anda mempublikasikan AAB, Google Play mengirimkan bundle khusus perangkat, sehingga pengguna hanya mengunduh arsitektur mereka sendiri (~4 MB), bukan keduanya.

Dengan TMP dalam mode Static atlas-population, memanggang set glyph lengkap dari font CJK tipikal membengkakkan build hingga puluhan sampai ratusan MB (beberapa atlas 4096²/8192²; perkirakan ~80–250 MB tergantung jumlah glyph dan resolusi). Poin utamanya: overhead UniText tidak membesar seiring jumlah glyph — tetap beberapa MB yang sama entah Anda merilis Latin atau CJK penuh.

Ya — itu ada di sisi developer, dan UniText tidak menghalangi. Unduh byte font dengan kode Anda sendiri (UnityWebRequest) dan bangun UniTextFont darinya saat runtime via CreateFontAsset(byte[]). Untuk memangkas font menjadi hanya karakter yang Anda butuhkan (subsetting), gunakan tool build-time UniText. Tidak ada auto-loader CDN bawaan dalam paket ini — itu memang sengaja menjadi tanggung jawab proyek, bukan mesin.

Ya — SystemFont membaca file font langsung dari OS saat runtime, jadi tidak berpengaruh pada ukuran build (tidak ada yang dipanggang). Resolusi bersifat lazy (pada penggunaan pertama), jadi tidak memperlambat startup aplikasi.

Tidak — dan itu keterbatasan browser, bukan keterbatasan UniText. Sandbox browser tidak mengekspos font OS. Untuk WebGL, sematkan font dalam aset UniTextFont (atau muat byte-nya sendiri — lihat pertanyaan CDN di atas).

Glyph berada dalam tile berukuran tiga macam — 64, 128, 256 — dan ukurannya dipilih berdasarkan kompleksitas kontur (banyak segmen → 128/256, kontur sederhana → 64). • SDF Detail adalah pengali (multiplier) terhadap estimasi kompleksitas. Naikkan dan glyph yang sudah tidak sepele lebih mungkin naik ke tile yang lebih besar. (Bentuk yang benar-benar sederhana tetap di 64 — pengali hanya memengaruhi glyph di atas ambang batas.) • Tile Size Offset adalah langkah tetap sepanjang tangga ukuran (dipilih 64 + offset 1 → 128; rentang −2..+2).

Tidak keduanya secara terpisah — keduanya hanya menentukan ukuran tile akhir, dan biayanya ditetapkan oleh ukuran itu saja. Dua kombinasi yang menghasilkan ukuran tile yang sama akan berbiaya persis sama. Targetkan ukuran tile terkecil yang masih memberikan kualitas yang dapat diterima.

Hanya saat sebuah glyph belum ada di atlas — tidak pernah per frame. Untuk “Hello world” ia merasterisasi glyph unik H e l o w r d. H kedua tidak melakukan apa pun; sebuah a hanya merasterisasi a itu.

Biayanya sebanding dengan jumlah glyph unik yang pertama kali terlihat dan dirasterisasi pada frame itu — bukan dengan panjang teksnya. Dalam benchmark kami ~2000 glyph unik pada frame pertama sekitar ≈ 1 detik pada perangkat Android tipikal; TMP dan UI Toolkit memakan 10+ detik dalam skenario yang sama. Menggunakan kembali glyph yang telah di-cache tidak berbiaya.

UniText nyaris tidak mengandalkan Unity Job System pada hot path — memang disengaja. Rasterisasi glyph (lpSDF / lpMSDF milik kami) berjalan di GPU via compute shader secara bawaan; job Burst hanya menjadi fallback CPU saat compute tidak tersedia. Multithreading utama — shaping, layout, pembuatan mesh — berjalan pada pool thread OS milik UniText sendiri (bukan Unity Jobs, itulah sebabnya mereka tidak muncul di profiler Jobs). Jadi “tidak ada job UniText” bukan berarti “thread mati”: entah pekerjaannya masuk ke GPU, atau atlasnya sudah hangat, atau teksnya di bawah ambang paralelisme (label pendek atau tunggal diproses secara berurutan — memang lebih murah begitu).

“Update() lambat” adalah mitos untuk build rilis. Overhead dari pemanggilan magic-method dari kode native memang nyata tetapi dapat diabaikan (~1000 pemanggilan ≈ 0.16 ms) — itu bukan bottleneck. Biaya sebenarnya pada kode naif adalah tata letak memory AoS, bukan callback-nya sendiri; UniText menerapkan SoA di tempat yang penting (atribut Unicode, metrik, buffer per-piksel). (Ini juga alasan ECS cepat — karena SoA, bukan “sihir ECS”.) Dan UniText tetap tersentralisasi — hanya saja bukan sebagai manager MonoBehaviour: Update() sendiri hampir kosong, dan pekerjaan berat dikumpulkan ke dalam satu lintasan batch tunggal pada callback render Canvas (yang juga memberikan paralelisme lintas komponen).