Ne. UniText nepeče texturové atlasy pro jednotlivá písma do vašeho buildu. Glyfy se rasterizují za běhu do sdíleného atlasu (založeného na Texture2DArray) s počítáním referencí na glyf a vyřazováním LRU. Ve vašem buildu se dodávají pouze data písem — nikdy atlasy. Navíc vestavěná komprese písem (Zstd, úroveň 22) zmenší data písem až ~2.7× u latinky/arabštiny (u CJK je to skromnější, ~1.3×).

Ne. Asset UniTextFont vkládá bajty písma přímo do sebe. Odkaz na zdrojové písmo existuje pouze v Editoru (obalený v #if UNITY_EDITOR) — v player buildu prostě neexistuje, takže není závislostí za běhu a nebude vtažen do AssetBundle přes vyhledávání závislostí. Soubor .ttf můžete po vytvoření assetu smazat.

Ne. UniTextFont můžete sestavit ze souboru .ttf umístěného kdekoli na disku přes okno nástroje UniText (dialog souboru čte bajty přímo). Import písma do projektu je nepovinný.

• WebGL: prázdný build má ≈ 6–10 MB (liší se podle verze Unity a nainstalovaných balíčků); UniText přidává své nativní knihovny (HarfBuzz, FreeType). Jsou to tytéž knihovny odpovídající průmyslovým standardům, které dodává i vlastní Advanced Text Generator v UI Toolkit od Unity — nic exotického (UniText si jen nese vlastní kopie). • Android: APK se dvěma architekturami nese obě — přibližně +4 MB na architekturu. Ale když publikujete AAB, Google Play doručí balíček specifický pro dané zařízení, takže si uživatel stáhne pouze svou vlastní architekturu (~4 MB), ne obě.

S TMP v režimu Static (naplňování atlasu) nafoukne zapečení kompletní sady glyfů typického CJK písma build o desítky až stovky MB (několik atlasů 4096²/8192²; počítejte s ~80–250 MB podle počtu glyfů a rozlišení). Klíčový bod: režie UniText neškáluje s počtem glyfů — je to stejných pár MB, ať dodáváte latinku nebo plné CJK.

Ano — to je na straně vývojáře a UniText v tom nebrání. Bajty písma stáhněte vlastním kódem (UnityWebRequest) a za běhu z nich sestavte UniTextFont přes CreateFontAsset(byte[]). Chcete-li písmo osekat jen na znaky, které potřebujete (subsetting), použijte nástroj UniText pro build-time. V balíčku není žádný vestavěný automatický načítač z CDN — to je záměrně odpovědnost projektu, ne enginu.

Ano — SystemFont čte soubor písma přímo z OS za běhu, takže nemá vliv na velikost buildu (nic se nepeče). Rozlišení je líné (při prvním použití), takže nezpomaluje spuštění aplikace.

Ne — a to je omezení prohlížeče, ne UniText. Sandbox prohlížeče neposkytuje přístup k písmům OS. Pro WebGL vložte písmo do assetu UniTextFont (nebo si bajty načtěte sami — viz otázka o CDN výše).

Glyfy žijí v dlaždicích tří velikostí — 64, 128, 256 — a velikost se volí podle složitosti obrysu (mnoho segmentů → 128/256, jednoduchý obrys → 64). • SDF Detail je násobitel odhadu složitosti. Zvyšte jej a už tak netriviální glyf se s větší pravděpodobností posune na větší dlaždici. (Skutečně jednoduchý tvar zůstane na 64 — násobitel ovlivňuje jen glyfy nad prahem.) • Tile Size Offset je pevný krok po žebříčku velikostí (zvolená 64 + offset 1 → 128; rozsah −2..+2).

Ani jednomu samostatně — oba jen určují výslednou velikost dlaždice a náklady jsou dané pouze touto velikostí. Dvě kombinace, které vedou ke stejné velikosti dlaždice, stojí přesně totéž. Miřte na nejmenší velikost dlaždice, která ještě dává přijatelnou kvalitu.

Pouze když glyf ještě není v atlasu — nikdy každý snímek. U „Hello world“ rasterizuje unikátní glyfy H e l o w r d. Druhé H neudělá nic; a rasterizuje jen a.

Náklady jsou úměrné počtu unikátních, poprvé viděných glyfů rasterizovaných v daném snímku — ne délce textu. V našem benchmarku představuje ~2000 unikátních glyfů v prvním snímku ≈ 1 sekundu na typickém zařízení s Androidem; TMP a UI Toolkit potřebují ve stejném scénáři 10+ sekund. Opětovné použití glyfů z cache je zdarma.

UniText se na horké cestě téměř nespoléhá na Unity Job System — záměrně. Rasterizace glyfů (naše proprietární lpSDF / lpMSDF) běží ve výchozím nastavení na GPU přes compute shader; Burst úlohy jsou jen záložní řešení na CPU, když compute není k dispozici. Hlavní vícevláknové zpracování — shaping, rozložení, generování meshe — běží na vlastním fondu OS vláken UniText (ne na Unity Jobs, proto se neobjevují v profileru Jobs). Takže „žádná úloha UniText“ neznamená „vlákna jsou vypnutá“: buď práce šla na GPU, nebo je atlas už zahřátý, nebo je text pod prahem paralelizace (krátké nebo jednotlivé popisky se zpracovávají sekvenčně — je to tak levnější).

„Update() je pomalý“ je pro release buildy mýtus. Režie volání magické metody z nativního kódu je reálná, ale zanedbatelná (~1000 volání ≈ 0.16 ms) — není to úzké hrdlo. Skutečné náklady v naivním kódu tvoří paměťové rozložení AoS, ne samotný callback; UniText používá SoA tam, kde na tom záleží (atributy Unicode, metriky, bufery po pixelech). (To je také důvod, proč je ECS rychlé — kvůli SoA, ne kvůli „magii ECS“.) A UniText je stejně centralizovaný — jen ne jako MonoBehaviour manažer: samotný Update() je téměř prázdný a těžká práce se shromažďuje do jediného dávkového průchodu na render callbacích Canvas (což je také to, co dává paralelismus napříč komponentami).