Nee. UniText bakt geen texture-atlassen per lettertype in je build. Glyphs worden tijdens runtime gerasteriseerd naar een gedeelde atlas (op basis van Texture2DArray) met referentietelling per glyph en LRU-verdringing. Alleen de lettertypedata zit in je build — nooit atlassen. Daar bovenop verkleint de ingebouwde lettertypecompressie (Zstd, niveau 22) de lettertypedata met tot ~2.7× voor Latijn/Arabisch (CJK is bescheidener, ~1.3×).

Nee. Het UniTextFont-asset bedt de lettertypebytes in zichzelf in. De verwijzing naar het bronlettertype bestaat alleen in de Editor (verpakt in #if UNITY_EDITOR) — hij bestaat simpelweg niet in een player-build, dus het is geen runtime-afhankelijkheid en wordt niet via dependency lookup in een AssetBundle meegetrokken. Je kunt de .ttf verwijderen zodra het asset is aangemaakt.

Nee. Je kunt een UniTextFont bouwen uit een .ttf die overal op je schijf staat via het UniText-toolvenster (het bestandsvenster leest de bytes rechtstreeks). Het lettertype in het project importeren is optioneel.

• WebGL: een lege build is ≈ 6–10 MB (dit varieert per Unity-versie en geïnstalleerde packages); UniText voegt zijn native bibliotheken toe (HarfBuzz, FreeType). Dit zijn dezelfde industriestandaard-bibliotheken die Unity's eigen UI Toolkit Advanced Text Generator meelevert — niets exotisch (UniText draagt gewoon zijn eigen kopieën mee). • Android: een APK met twee architecturen bevat beide — ongeveer +4 MB per architectuur. Maar wanneer je een AAB publiceert, levert Google Play een apparaatspecifieke bundel, dus de gebruiker downloadt alleen zijn eigen architectuur (~4 MB), niet beide.

Met TMP in de Static atlas-population-modus blaast het bakken van de volledige glyph-set van een typisch CJK-lettertype de build op met tientallen tot honderden MB (meerdere 4096²/8192²-atlassen; reken op ~80–250 MB afhankelijk van glyph-aantal en resolutie). Het cruciale punt: de overhead van UniText schaalt niet mee met het glyph-aantal — het zijn dezelfde paar MB of je nu Latijn of volledig CJK meelevert.

Ja — dat ligt aan de kant van de ontwikkelaar, en UniText zit niet in de weg. Download de lettertypebytes met je eigen code (UnityWebRequest) en bouw daar tijdens runtime een UniTextFont van via CreateFontAsset(byte[]). Om een lettertype terug te brengen tot alleen de tekens die je nodig hebt (subsetting), gebruik je de build-time tool van UniText. Er zit geen ingebouwde CDN-autoloader in de package — dat is bewust de verantwoordelijkheid van het project, niet van de engine.

Ja — SystemFont leest het lettertypebestand tijdens runtime rechtstreeks vanuit het OS, dus het heeft geen effect op de buildgrootte (er wordt niets gebakken). De resolutie gebeurt lazy (bij eerste gebruik), dus het vertraagt het opstarten van de app niet.

Nee — en dat is een beperking van de browser, niet van UniText. De browser-sandbox stelt de OS-lettertypen niet beschikbaar. Voor WebGL bed je een lettertype in een UniTextFont-asset in (of laad je de bytes zelf — zie de CDN-vraag hierboven).

Glyphs leven in tegels van drie groottes — 64, 128, 256 — en de grootte wordt gekozen op basis van de contourcomplexiteit (veel segmenten → 128/256, een eenvoudige contour → 64). • SDF Detail is een vermenigvuldiger op de complexiteitsschatting. Verhoog hem en een al niet-triviale glyph gaat eerder omhoog naar een grotere tegel. (Een echt eenvoudige vorm blijft op 64 — de vermenigvuldiger beïnvloedt alleen glyphs boven de drempel.) • Tile Size Offset is een harde stap langs de groottetrap (gekozen 64 + offset 1 → 128; bereik −2..+2).

Geen van beide op zichzelf — ze bepalen allebei alleen de uiteindelijke tegelgrootte, en de kosten worden bepaald door die grootte alleen. Twee combinaties die uitkomen op dezelfde tegelgrootte kosten precies hetzelfde. Streef naar de kleinste tegelgrootte die nog acceptabele kwaliteit geeft.

Alleen wanneer een glyph nog niet in de atlas zit — nooit per frame. Voor “Hello world” rasteriseert het de unieke glyphs H e l o w r d. Een tweede H doet niets; een a rasteriseert alleen de a.

De kosten zijn evenredig met het aantal unieke, voor het eerst geziene glyphs dat dat frame wordt gerasteriseerd — niet met de lengte van de tekst. In onze benchmark is ~2000 unieke glyphs op het eerste frame ≈ 1 seconde op een typisch Android-apparaat; TMP en UI Toolkit doen er in hetzelfde scenario 10+ seconden over. Gecachte glyphs hergebruiken is gratis.

UniText leunt op het hot path nauwelijks op het Unity Job System — met opzet. Glyph-rasterisatie (ons eigen lpSDF / lpMSDF) draait standaard op de GPU via een compute shader; Burst-jobs zijn alleen de CPU-fallback wanneer compute niet beschikbaar is. Het belangrijkste multithreading-werk — shaping, lay-out, mesh-generatie — draait op UniText's eigen OS-threadpool (niet Unity Jobs, en daarom verschijnen ze niet in de Jobs-profiler). Dus “geen UniText-job” betekent niet “threads staan uit”: ofwel is het werk naar de GPU gegaan, ofwel is de atlas al warm, ofwel valt de tekst onder de parallellisme-drempel (korte of losse labels worden sequentieel verwerkt — dat is goedkoper).

“Update() is traag” is een mythe voor release-builds. De overhead van de magic-method-aanroep vanuit native code is reëel maar verwaarloosbaar (~1000 aanroepen ≈ 0.16 ms) — het is niet de bottleneck. De echte kosten in naïeve code zijn de AoS-geheugenindeling, niet de callback zelf; UniText past SoA toe waar het ertoe doet (Unicode-attributen, metrics, per-pixel-buffers). (Dit is ook waarom ECS snel is — dankzij SoA, niet “ECS-magie”.) En UniText is sowieso gecentraliseerd — alleen niet als een MonoBehaviour-manager: Update() zelf is vrijwel leeg, en het zware werk wordt verzameld in één gebatchte doorloop op Canvas-render-callbacks (wat ook het parallelisme tussen componenten oplevert).