No. UniText no hornea atlas de texturas por fuente en tu build. Los glifos se rasterizan en runtime en un atlas compartido (basado en Texture2DArray) con conteo de referencias por glifo y desalojo LRU. Solo los datos de la fuente van en tu build — nunca los atlas. Además, la compresión de fuentes integrada (Zstd, nivel 22) reduce los datos de fuente hasta ~2.7× para latín/árabe (con CJK es más modesto, ~1.3×).

No. El asset UniTextFont incrusta los bytes de la fuente dentro de sí mismo. La referencia a la fuente de origen es solo para el Editor (envuelta en #if UNITY_EDITOR) — simplemente no existe en un build de player, así que no es una dependencia en runtime y no se arrastrará a un AssetBundle mediante la búsqueda de dependencias. Puedes eliminar el .ttf una vez creado el asset.

No. Puedes crear un UniTextFont a partir de un .ttf ubicado en cualquier lugar de tu disco mediante la ventana de herramientas de UniText (el diálogo de archivos lee los bytes directamente). Importar la fuente al proyecto es opcional.

• WebGL: un build vacío ocupa ≈ 6–10 MB (varía según la versión de Unity y los paquetes instalados); UniText añade sus bibliotecas nativas (HarfBuzz, FreeType). Son las mismas bibliotecas estándar de la industria que incluye el propio Advanced Text Generator del UI Toolkit de Unity — nada exótico (UniText simplemente lleva sus propias copias). • Android: un APK con dos arquitecturas carga ambas — unos +4 MB por arquitectura. Pero cuando publicas un AAB, Google Play entrega un bundle específico para el dispositivo, así que el usuario descarga solo su propia arquitectura (~4 MB), no ambas.

Con TMP en modo de población de atlas Static, hornear el conjunto completo de glifos de una fuente CJK típica infla el build en decenas o cientos de MB (varios atlas de 4096²/8192²; cuenta con ~80–250 MB según la cantidad de glifos y la resolución). El punto clave: el overhead de UniText no escala con la cantidad de glifos — son los mismos pocos MB tanto si distribuyes latín como CJK completo.

Sí — eso corre por cuenta del desarrollador, y UniText no se interpone. Descarga los bytes de la fuente con tu propio código (UnityWebRequest) y crea un UniTextFont a partir de ellos en runtime mediante CreateFontAsset(byte[]). Para recortar una fuente y dejar solo los caracteres que necesitas (subsetting), usa la herramienta de UniText en tiempo de build. El paquete no incluye un cargador automático de CDN — es deliberadamente responsabilidad del proyecto, no del motor.

Sí — SystemFont lee el archivo de fuente directamente del SO en runtime, así que no afecta al tamaño del build (no se hornea nada). La resolución es diferida (en el primer uso), así que no ralentiza el arranque de la app.

No — y es una limitación del navegador, no de UniText. El sandbox del navegador no expone las fuentes del SO. Para WebGL, incrusta una fuente en un asset UniTextFont (o carga los bytes tú mismo — consulta la pregunta sobre CDN más arriba).

Los glifos viven en tiles de tres tamaños — 64, 128, 256 — y el tamaño se elige a partir de la complejidad del contorno (muchos segmentos → 128/256, un contorno simple → 64). • SDF Detail es un multiplicador sobre la estimación de complejidad. Súbelo y un glifo que ya no es trivial tiene más probabilidades de pasar a un tile mayor. (Una forma genuinamente simple se queda en 64 — el multiplicador solo afecta a los glifos por encima del umbral.) • Tile Size Offset es un salto fijo a lo largo de la escala de tamaños (elegido 64 + offset 1 → 128; rango −2..+2).

Ninguno por separado — ambos solo deciden el tamaño final del tile, y el coste lo fija únicamente ese tamaño. Dos combinaciones que resuelven al mismo tamaño de tile cuestan exactamente lo mismo. Apunta al tile más pequeño que aún dé una calidad aceptable.

Solo cuando un glifo no está ya en el atlas — nunca en cada frame. Para “Hello world” rasteriza los glifos únicos H e l o w r d. Una segunda H no hace nada; una a rasteriza solo la a.

El coste es proporcional a la cantidad de glifos únicos, vistos por primera vez, que se rasterizan en ese frame — no a la longitud del texto. En nuestro benchmark, ~2000 glifos únicos en el primer frame son ≈ 1 segundo en un dispositivo Android típico; TMP y UI Toolkit tardan 10+ segundos en el mismo escenario. Reutilizar glifos cacheados es gratis.

UniText apenas depende del Unity Job System en el hot path — por diseño. La rasterización de glifos (nuestro lpSDF / lpMSDF propietario) se ejecuta en la GPU mediante un compute shader por defecto; los jobs de Burst son solo el fallback en CPU cuando compute no está disponible. El multithreading principal — shaping, layout, generación de malla — se ejecuta en el propio pool de hilos del SO de UniText (no en Unity Jobs, por eso no aparecen en el profiler de Jobs). Así que “ningún job de UniText” no significa “los hilos están apagados”: o el trabajo fue a la GPU, o el atlas ya está caliente, o el texto está por debajo del umbral de paralelismo (las etiquetas cortas o individuales se procesan de forma secuencial — así es más barato).

“Update() es lento” es un mito en los release builds. El overhead de la llamada al método mágico desde código nativo es real pero insignificante (~1000 llamadas ≈ 0.16 ms) — no es el cuello de botella. El coste real en código ingenuo es el layout de memoria AoS, no el callback en sí; UniText aplica SoA donde importa (atributos Unicode, métricas, buffers por píxel). (Por eso también es rápido ECS — por SoA, no por “magia de ECS”.) Y UniText está centralizado de todos modos — solo que no como un manager MonoBehaviour: Update() en sí está casi vacío, y el trabajo pesado se agrupa en una única pasada por lotes en los callbacks de render de Canvas (que es también lo que da el paralelismo entre componentes).