Hayır. UniText, yazı tipi başına doku atlaslarını derlemenize gömmez. Glyph'ler çalışma zamanında paylaşılan bir atlasa (Texture2DArray tabanlı) rasterize edilir; glyph başına referans sayımı ve LRU tahliyesi kullanılır. Derlemenize yalnızca yazı tipi verisi girer — atlaslar asla. Bunun üzerine, yerleşik Yazı Tipi Sıkıştırması (Zstd, seviye 22) yazı tipi verisini Latin/Arapça için ~2.7× kadar küçültür (CJK daha mütevazıdır, ~1.3×).

Hayır. UniTextFont varlığı, yazı tipi baytlarını kendi içine gömer. Kaynak yazı tipine yapılan referans yalnızca Editör'de bulunur (#if UNITY_EDITOR içine sarılmıştır) — bir oyuncu derlemesinde hiç yer almaz, dolayısıyla çalışma zamanı bağımlılığı değildir ve bağımlılık aramasıyla bir AssetBundle'a çekilmez. Varlık oluşturulduktan sonra .ttf dosyasını silebilirsiniz.

Hayır. UniText araç penceresi aracılığıyla diskinizin herhangi bir yerinde bulunan bir .ttf dosyasından bir UniTextFont oluşturabilirsiniz (dosya iletişim kutusu baytları doğrudan okur). Yazı tipini projeye aktarmak isteğe bağlıdır.

• WebGL: boş bir derleme ≈ 6–10 MB'dir (Unity sürümüne ve yüklü paketlere göre değişir); UniText kendi yerel kütüphanelerini (HarfBuzz, FreeType) ekler. Bunlar, Unity'nin kendi UI Toolkit Advanced Text Generator bileşeninin gönderdiği aynı endüstri standardı kütüphanelerdir — egzotik hiçbir şey yok (UniText yalnızca kendi kopyalarını taşır). • Android: iki mimarili bir APK her ikisini de taşır — mimari başına yaklaşık +4 MB. Ancak bir AAB yayınladığınızda, Google Play cihaza özel bir paket sunar, böylece kullanıcı her ikisini değil yalnızca kendi mimarisini (~4 MB) indirir.

TMP'yi Static atlas doldurma modunda kullanırken, tipik bir CJK yazı tipinin tam glyph setini derlemeye gömmek, derlemeyi onlarca ila yüzlerce MB şişirir (birkaç 4096²/8192² atlas; glyph sayısına ve çözünürlüğe bağlı olarak ~80–250 MB bekleyin). Kilit nokta: UniText'in ek yükü glyph sayısıyla ölçeklenmez — ister Latin ister tam CJK gönderin, aynı birkaç MB'dir.

Evet — bu geliştiricinin tarafındadır ve UniText engel olmaz. Yazı tipi baytlarını kendi kodunuzla (UnityWebRequest) indirin ve çalışma zamanında CreateFontAsset(byte[]) ile bunlardan bir UniTextFont oluşturun. Bir yazı tipini yalnızca ihtiyacınız olan karakterlere indirgemek için (alt kümeleme), UniText'in derleme zamanı aracını kullanın. Pakette yerleşik bir CDN otomatik yükleyici yoktur — bu bilinçli olarak motorun değil, projenin sorumluluğudur.

Evet — SystemFont, yazı tipi dosyasını çalışma zamanında doğrudan işletim sisteminden okur, dolayısıyla derleme boyutu üzerinde hiçbir etkisi yoktur (hiçbir şey gömülmez). Çözümleme tembeldir (ilk kullanımda gerçekleşir), bu nedenle uygulama başlangıcını yavaşlatmaz.

Hayır — ve bu bir tarayıcı kısıtlamasıdır, UniText'in değil. Tarayıcı korumalı alanı işletim sistemi yazı tiplerini dışa açmaz. WebGL için, bir yazı tipini bir UniTextFont varlığına gömün (veya baytları kendiniz yükleyin — yukarıdaki CDN sorusuna bakın).

Glyph'ler üç boyutta karolarda yaşar — 64, 128, 256 — ve boyut, kontur karmaşıklığından seçilir (çok sayıda segment → 128/256, basit bir kontur → 64). • SDF Detail, karmaşıklık tahmini üzerindeki bir çarpandır. Bunu artırdığınızda, halihazırda önemsiz olmayan bir glyph'in daha büyük bir karoya çıkma olasılığı artar. (Gerçekten basit bir şekil 64'te kalır — çarpan yalnızca eşiğin üzerindeki glyph'leri etkiler.) • Tile Size Offset, boyut merdiveni boyunca sabit bir adımdır (seçilen 64 + ofset 1 → 128; aralık −2..+2).

Tek başına hiçbiri — ikisi de yalnızca nihai karo boyutunu belirler ve maliyet yalnızca o boyuta göre belirlenir. Aynı karo boyutuna çözümlenen iki kombinasyon tam olarak aynı maliyete sahiptir. Yine de kabul edilebilir kalite veren en küçük karo boyutunu hedefleyin.

Yalnızca bir glyph atlasta zaten yoksa — asla kare başına değil. “Hello world” için benzersiz glyph'leri rasterize eder: H e l o w r d. İkinci bir H hiçbir şey yapmaz; bir a yalnızca a'yı rasterize eder.

Maliyet, metnin uzunluğuyla değil — o karede rasterize edilen benzersiz, ilk kez görülen glyph'lerin sayısıyla orantılıdır. Kıyaslamamızda, ilk karedeki ~2000 benzersiz glyph, tipik bir Android cihazda ≈ 1 saniyedir; TMP ve UI Toolkit aynı senaryoda 10+ saniye alır. Önbelleğe alınmış glyph'leri yeniden kullanmak ücretsizdir.

UniText, sıcak yolda Unity Job System'e neredeyse hiç dayanmaz — tasarım gereği. Glyph rasterizasyonu (bize özgü lpSDF / lpMSDF) varsayılan olarak bir compute shader aracılığıyla GPU üzerinde çalışır; Burst işleri yalnızca compute kullanılamadığında devreye giren CPU yedeğidir. Ana çoklu iş parçacığı — şekillendirme, düzen, mesh üretimi — UniText'in kendi işletim sistemi iş parçacığı havuzunda çalışır (Unity Jobs değil, bu yüzden Jobs profiler'ında görünmezler). Yani “UniText işi yok” ifadesi “iş parçacıkları kapalı” anlamına gelmez: ya iş GPU'ya gitti, ya atlas zaten sıcak, ya da metin paralellik eşiğinin altında (kısa veya tek etiketler sırayla işlenir — bu şekilde daha ucuzdur).

“Update() yavaştır” sözü, sürüm derlemeleri için bir efsanedir. Yerel koddan yapılan sihirli metot çağrısının ek yükü gerçektir ama ihmal edilebilir düzeydedir (~1000 çağrı ≈ 0.16 ms) — darboğaz bu değildir. Naif koddaki asıl maliyet, geri çağırmanın kendisi değil, AoS bellek düzenidir; UniText, önemli olan yerlerde SoA uygular (Unicode öznitelikleri, metrikler, piksel başına arabellekler). (ECS'in hızlı olmasının nedeni de budur — “ECS sihri” değil, SoA sayesinde.) Ve UniText zaten merkezileştirilmiştir — yalnızca bir MonoBehaviour yöneticisi olarak değil: Update()'in kendisi neredeyse boştur ve ağır iş, Canvas render geri çağırmalarında tek bir toplu geçişte toplanır (bu da bileşenler arası paralelliği sağlayan şeydir).