No. UniText non incorpora atlas di texture per-font nella tua build. I glifi vengono rasterizzati a runtime in un atlas condiviso (basato su Texture2DArray) con conteggio dei riferimenti per glifo ed eviction LRU. Nella build finiscono solo i dati dei font — mai gli atlas. In più, la Font Compression integrata (Zstd, livello 22) riduce i dati dei font fino a ~2.7× per latino/arabo (per il CJK è più modesta, ~1.3×).

No. L'asset UniTextFont incorpora al suo interno i byte del font. Il riferimento al font sorgente è solo per l'Editor (racchiuso in #if UNITY_EDITOR) — semplicemente non esiste in una build del player, quindi non è una dipendenza a runtime e non verrà trascinato in un AssetBundle tramite la risoluzione delle dipendenze. Puoi eliminare il .ttf una volta creato l'asset.

No. Puoi creare un UniTextFont da un .ttf che si trova in qualsiasi punto del disco tramite la finestra degli strumenti di UniText (la finestra di dialogo dei file ne legge i byte direttamente). Importare il font nel progetto è facoltativo.

• WebGL: una build vuota è ≈ 6–10 MB (varia in base alla versione di Unity e ai pacchetti installati); UniText aggiunge le proprie librerie native (HarfBuzz, FreeType). Sono le stesse librerie standard del settore che l'Advanced Text Generator di UI Toolkit di Unity distribuisce — niente di esotico (UniText porta semplicemente le proprie copie). • Android: un APK con due architetture le contiene entrambe — circa +4 MB per architettura. Ma quando pubblichi un AAB, Google Play consegna un bundle specifico per dispositivo, quindi l'utente scarica solo la propria architettura (~4 MB), non entrambe.

Con TMP in modalità Static atlas-population, il baking dell'intero set di glifi di un tipico font CJK gonfia la build di decine o centinaia di MB (diversi atlas 4096²/8192²; aspettati ~80–250 MB a seconda del numero di glifi e della risoluzione). Il punto chiave: l'overhead di UniText non cresce con il numero di glifi — sono gli stessi pochi MB sia che tu distribuisca latino sia CJK completo.

Sì — è lato sviluppatore, e UniText non si mette in mezzo. Scarica i byte del font con il tuo codice (UnityWebRequest) e creane un UniTextFont a runtime tramite CreateFontAsset(byte[]). Per ridurre un font ai soli caratteri che ti servono (subsetting), usa lo strumento di build-time di UniText. Nel pacchetto non c'è un auto-loader CDN integrato — è deliberatamente responsabilità del progetto, non del motore.

Sì — SystemFont legge il file del font direttamente dal sistema operativo a runtime, quindi non ha alcun effetto sulle dimensioni della build (non viene fatto alcun baking). La risoluzione è lazy (al primo utilizzo), quindi non rallenta l'avvio dell'app.

No — ed è una limitazione del browser, non di UniText. La sandbox del browser non espone i font del sistema operativo. Per WebGL, incorpora un font in un asset UniTextFont (oppure carica tu stesso i byte — vedi la domanda sulla CDN qui sopra).

I glifi risiedono in tile di tre dimensioni — 64, 128, 256 — e la dimensione viene scelta in base alla complessità del contorno (molti segmenti → 128/256, un contorno semplice → 64). • SDF Detail è un moltiplicatore sulla stima della complessità. Aumentalo e un glifo già non banale ha più probabilità di salire a una tile più grande. (Una forma davvero semplice resta a 64 — il moltiplicatore influisce solo sui glifi sopra la soglia.) • Tile Size Offset è uno scatto netto lungo la scala delle dimensioni (scelta 64 + offset 1 → 128; intervallo −2..+2).

Nessuno dei due preso singolarmente — entrambi decidono solo la dimensione finale della tile, e il costo è determinato unicamente da quella dimensione. Due combinazioni che si risolvono nella stessa dimensione di tile costano esattamente uguale. Punta alla tile più piccola che offra comunque una qualità accettabile.

Solo quando un glifo non è già nell'atlas — mai a ogni frame. Per “Hello world” rasterizza i glifi unici H e l o w r d. Una seconda H non fa nulla; una a rasterizza solo la a.

Il costo è proporzionale al numero di glifi unici, visti per la prima volta, rasterizzati in quel frame — non alla lunghezza del testo. Nel nostro benchmark ~2000 glifi unici sul primo frame corrispondono a ≈ 1 secondo su un dispositivo Android tipico; TMP e UI Toolkit impiegano 10+ secondi nello stesso scenario. Riutilizzare i glifi in cache è gratis.

UniText fa affidamento solo minimamente sul Job System di Unity nell'hot path — per scelta progettuale. La rasterizzazione dei glifi (i nostri proprietari lpSDF / lpMSDF) gira di default sulla GPU tramite un compute shader; i job Burst sono solo il fallback su CPU quando il compute non è disponibile. Il multithreading principale — shaping, layout, generazione della mesh — gira sul pool di thread del sistema operativo proprietario di UniText (non sui Job di Unity, ed è per questo che non compaiono nel profiler dei Jobs). Quindi “nessun job UniText” non significa “thread disattivati”: o il lavoro è andato sulla GPU, o l'atlas è già caldo, oppure il testo è sotto la soglia di parallelismo (le etichette brevi o singole vengono elaborate in sequenza — così è più economico).

“Update() è lento” è un mito per le build di release. L'overhead della chiamata al magic method dal codice nativo è reale ma trascurabile (~1000 chiamate ≈ 0.16 ms) — non è il collo di bottiglia. Il vero costo nel codice ingenuo è il layout di memoria AoS, non la callback in sé; UniText applica SoA dove conta (attributi Unicode, metriche, buffer per-pixel). (È anche il motivo per cui ECS è veloce — grazie a SoA, non alla “magia di ECS”.) E UniText è comunque centralizzato — solo non come un manager MonoBehaviour: Update() in sé è quasi vuoto, e il lavoro pesante viene raccolto in un unico passaggio in batch sulle callback di render del Canvas (che è anche ciò che dà il parallelismo tra componenti).