El texto parece trivial hasta que tienes que dibujarlo en una GPU. Un glifo no es un mapa de bits; es un conjunto de contornos vectoriales cerrados —curvas cuadráticas o cúbicas de Bézier más segmentos rectos— rellenos por una regla de barrido. En una CPU rasterizas una vez al tamaño objetivo y ya está. En una GPU quieres miles de glifos por fotograma a escalas arbitrarias, idealmente sin rasterizar nada de nuevo. Esa restricción es donde cada técnica establece su compromiso.
El artículo abre explicando que un glifo es un conjunto de contornos vectoriales cerrados rellenos por una regla de barrido, no un mapa de bits. Este diagrama ilustra ese concepto fundamental con puntos sobre la curva y fuera de ella marcados.
**1. Atlas de texturas (glifos de mapa de bits)** El enfoque más antiguo y aún más común. Rasterizas cada glifo una vez, a un solo tamaño, en un atlas de texturas compartido, y luego dibujas cada carácter como un cuadro texturizado. Es rápido, trivialmente portable y funciona en cualquier dispositivo con unidad de textura. Los problemas aparecen en cuanto escalas: si amplías más allá del tamaño almacenado, el glifo se desenfoca; si lo reduces, los trazos vibran o desaparecen a menos que generes niveles mip. Cada tamaño nítido necesita otro atlas. Para chino, japonés y coreano, con decenas de miles de glifos, generar varios tamaños se convierte en un desastre de memoria. Y un mapa de bits no tiene noción de perspectiva, así que el texto en una superficie 3D se ve suave.
**2. Campos de distancia con signo (SDF)** Chris Green de Valve presentó los SDF en SIGGRAPH 2007. En lugar de píxeles, cada texel almacena la distancia con signo al borde más cercano (positivo dentro, negativo fuera). En el shader muestras el campo y aplicas un umbral en cero. Como la distancia se interpola suavemente, una pequeña textura SDF se escala enormemente con un borde limpio, y el suavizado es barato al suavizar el umbral. Durante una década fue el estándar para texto nítido de interfaz y HUD.
Pero un SDF sigue siendo una textura almacenada a resolución fija, y miente sobre las esquinas. Una esquina afilada es una discontinuidad en el campo de distancia; la interpolación bilineal la redondea. Cada esquina dura —la punta de una «A», la muesca de una «K»— se suaviza. Si amplías lo suficiente, o haces el glifo lo bastante pequeño para que el campo tenga solo unos pocos texeles de ancho, los trazos finos se rompen y los detalles se difuminan.
**3. SDF multicanal (MSDF)** La tesis de 2015 y el artículo de 2018 de Viktor Chlumsky arreglan el problema de las esquinas. En lugar de un canal de distancia, MSDF almacena tres (rojo, verde, azul), cada uno codificando la distancia a un subconjunto distinto de bordes elegido para que las esquinas duras sobrevivan. El shader toma la mediana de los tres canales, reconstruyendo las esquinas casi perfectamente. MSDF es el punto óptimo actual para muchos equipos; `msdfgen` de Chlumsky tiene licencia MIT y está ampliamente adoptado.
Sigue siendo un atlas, eso sí. Almacenas cada glifo a la resolución elegida por adelantado, así que texto dinámico o proporcionado por el usuario y conjuntos enormes de glifos como CJK siguen requiriendo canalizaciones de generación y presupuestos de memoria. La generación es más cara que el SDF simple. A tamaños muy pequeños, muestras muy pocos texeles para guardar detalle fino; a minimización extrema, sigues luchando contra el aliasing. La búsqueda de tres canales cuesta más ancho de banda. MSDF sube el techo de calidad pero mantiene la restricción del atlas.
**4. Teselación y cobertura (Loop–Blinn, NV_path_rendering, Pathfinder, Rive)** Esta familia prescinde totalmente de texturas y convierte el contorno en geometría que la GPU puede rasterizar. Loop–Blinn envía triángulos curvos a la GPU con un shader de descarte por píxel y barrido de stencil. NV_path_rendering usa un enfoque de dos pasos: stencil y luego cobertura. Pathfinder tesela los bordes en micro-triángulos y acumula cobertura en un paso de cálculo. El renderizador de Rive (código abierto en 2024) reduce trayectorias vectoriales suavizadas a parches triangulares únicos y los rasteriza a través de una canalización masivamente paralela con almacenamiento local de píxeles, alcanzando 120 fps en arte vectorial animado.
Estos métodos son genuinamente independientes de la resolución y, para gráficos vectoriales animados, a menudo la respuesta correcta. Los costos son la teselación misma (repetida cuando cambia la geometría), la explosión geométrica para glifos complejos, la dificultad del suavizado analítico y, en algunos casos, dependencia de funciones o extensiones de hardware específicas. Rive en particular solo acepta transformaciones afines 2D; una proyección en perspectiva no es afín, así que su mejor aproximación es exacta en el centro y se desvía hacia los bordes.
**5. Slug: renderizado directamente desde el contorno** Eric Lengyel publicó Slug en 2017, lo patentó en 2019 y dedicó la patente al dominio público el 17 de marzo de 2026. Slug prescinde del atlas y la teselación por fotograma. Mantiene el glifo como una lista de curvas cuadráticas de Bézier y segmentos de recta en un pequeño búfer de GPU, junto con una estructura de aceleración ligera por glifo que divide el glifo en bandas horizontales para que un píxel dado solo considere las pocas curvas cercanas.
La cobertura se resuelve directamente en el shader de fragmentos. Para cada píxel, el shader efectivamente lanza un rayo, encuentra dónde ese rayo cruza las curvas de Bézier cercanas y cuenta esos cruces para calcular el número de barrido y, por tanto, la cobertura. La innovación clave de Lengyel es una prueba de *elegibilidad de raíz*: una regla precisa para decidir qué intersecciones curva-rayo deben contarse, de modo que la matemática de barrido sea exacta en los puntos compartidos donde se encuentran las curvas y donde los enfoques ingenuos producen grietas o dobles conteos. Como el shader resuelve las ecuaciones de la curva analíticamente en lugar de muestrear un campo almacenado, produce cobertura exacta y suavizado limpio a cualquier escala.
No hay resolución almacenada, así que el mismo glifo es afilado a 6 píxeles o a 6.000, y se mantiene nítido bajo transformaciones 2D y 3D arbitrarias, incluida la perspectiva, porque la cobertura se calcula por píxel *después* de la transformación. No hay atlas, así que cien mil glifos CJK cuestan los datos de contorno de una fuente, no un atlas del tamaño de un vídeo. El texto puede cambiar cada fotograma sin coste de generación: exactamente lo que quieres para datos en vivo, entrada de usuario y contenido localizado. Todo ocurre en una sola llamada de dibujo con un shader de fragmentos ordinario, sin extensión de proveedor requerida.
Esto importa cuando no puedes predecir cómo se verá el texto. Atlas, SDF y MSDF almacenan todos una resolución fija por adelantado, asumiendo en silencio un rango acotado de tamaños en pantalla y ángulos de visión. Cuando la relación entre el plano del texto y la cámara no se conoce de antemano —una cámara 3D libre, zoom arbitrario, primer plano o ángulo oblicuo pronunciado—, esas aproximaciones almacenadas fallan: amplías más allá de la resolución almacenada y el atlas se desenfoca mientras SDF y MSDF redondean y difuminan; a ángulos oblicuos, el campo muestreado sufre aliasing. No puedes preasignar suficiente resolución para cada vista posible sin que el almacenamiento explote. Slug calcula la cobertura analíticamente, por píxel, después de la transformación, así que se mantiene exacto sin importar qué tan cerca, lejos u oblicuo esté el espectador. La teselación es la única otra familia que comparte esta propiedad, y la paga en coste de teselación y suavizado más difícil.
**Viendo la diferencia** AlphaPixel renderizó la misma **R** mayúscula con su integración `osgSlug` (Slughorn) junto a SDF de canal único, MSDF, Rive y `osgText` mapa de bits (más su SDF derivado del mapa de bits). Cada panel basado en texturas recibió el mismo presupuesto: 64 texeles por em.
La sección 'Viendo la diferencia' del artículo describe primero una comparación de frente al tamaño almacenado donde cinco de seis renderizadores son prácticamente idénticos, con solo el mapa de bits mostrando sus limitaciones al ampliar.
*Frente al tamaño almacenado:* cinco de seis son prácticamente idénticos —Slughorn, Rive y MSDF reproducen el contorno; el SDF de canal único difiere solo en esquinas ligeramente redondeadas en el pie de la pata. La desviación es el mapa de bits, ampliado ~4×, que no puede recuperar detalle que nunca almacenó.
El artículo explica que bajo perspectiva 3D oblicua, los métodos basados en atlas se desenfocan, SDF/MSDF se mantienen bien, pero la transformación solo afín de Rive hace que el glifo se desvíe hacia los bordes, mientras que el enfoque analítico de Slug se mantiene exacto.
*Inclinado en perspectiva oblicua:* Slughorn y los tres paneles de campo de distancia mantienen la **R** en su lugar con bordes limpios, porque calculan la cobertura por píxel dentro del propio plano del glifo. El mapa de bits se desenfoca al alejarse. La **R** de Rive tiene la forma equivocada —su renderizador solo acepta transformaciones afines 2D, así que una proyección en perspectiva se desvía hacia los bordes.
El artículo describe cómo a magnificación extrema, la evaluación analítica de curvas (Slug, Rive) permanece perfectamente nítida mientras que los campos de distancia muestreados exhiben artefactos de muesca y los mapas de bits pierden toda estructura.
*Ampliado en un solo borde a magnificación extrema:* solo los renderizadores basados en curvas (Slughorn y Rive) siguen produciendo un borde recto y limpio. Los paneles de campo de distancia muestran muescas donde la interpolación entre muestras almacenadas ya no coincide con la curva real. El mapa de bits se disuelve en un único gradiente gris.
**Resumen comparativo**
| Preocupación | Atlas de mapas de bits | SDF | MSDF | Teselación / Rive | Slug | |---|---|---|---|---|---| | Nítido a cualquier escala | No | Parcialmente | Mayormente | Sí | Sí | | Esquinas afiladas | Al tamaño almacenado | No | Sí | Sí | Sí | | Tamaños pequeños | Generar por tamaño | Débil | Mejor | Bueno | Bueno | | Memoria para CJK | Muy alta | Alta | Alta | Baja | Moderada | | Texto dinámico / cambiante | Regenerar | Regenerar | Regenerar | Re-teselar | Gratis | | 3D y perspectiva | Suave | Bien | Bien | Bueno | Excelente | | Arte vectorial animado intenso | No | No | No | Excelente (Rive) | Bueno | | Funciona en GPU de gama baja | Excelente | Excelente | Bueno | Varía | Necesita shader capaz | | Complejidad de implementación | Baja | Baja | Media | Alta | Media-alta |
**¿Cuál deberías usar?** No hay un ganador único —hay la herramienta correcta para cada trabajo.
*Usa Slug (via Slughorn u otra implementación) cuando* necesites texto nítido a cada escala y bajo 3D y perspectiva (VR/AR/XR), cuando tengas conjuntos de glifos enormes o dinámicos, cuando el texto cambie constantemente, o cuando estés renderizando interfaz vectorial mixta en escenas 3D.
*Elige MSDF cuando* necesites texto de interfaz 2D nítido y escalable, puedas aceptar una canalización de almacenamiento de atlas, y quieras el mejor equilibrio actual de calidad, rendimiento y portabilidad en un amplio rango de hardware.
*Elige Rive u otro renderizador de teselación cuando* tu carga principal sea arte vectorial diseñado y animado que se mueva —la canalización de Rive está construida para eso.
*Quédate con un atlas de mapas de bits o SDF cuando* estés en hardware limitado/antiguo, tus tamaños de texto y ángulos de visión estén acotados y sean conocidos de antemano, o necesites la integración más simple posible.
**Nota sobre ajuste fino** Los renderizadores CPU tradicionales como FreeType ajustan las curvas para ajustarlas a la cuadrícula de píxeles a tamaños específicos (ajuste fino por bytecode). La propuesta de Slug es que no requiere pregeneración de glifos por tamaño, así que su salida es efectivamente sin ajuste fino. A medida que los monitores han crecido en densidad, los renderizadores principales han migrado hacia ajuste automático (ignorando el bytecode y derivando ajustes del contorno) o nada de ajuste. Implementaciones como el puerto Zig *Snail* han añadido ajuste automático en GPU para replicar este comportamiento, pero sigue siendo un área abierta para los adoptantes de Slug.
**Compromiso de efectos de shader** SDF/MSDF facilitan añadir contornos, brillos o suavizado en pocas líneas de código de shader porque el valor de distancia indica «qué tan lejos» estás de un borde. La prueba analítica de barrido de Slug solo indica «dentro o fuera». En pantallas de muy alta resolución y tamaños grandes esto es una fortaleza —cobertura exacta sin artefactos de campo de distancia—, pero pierdes los efectos baratos basados en distancia y debes manejar el suavizado por separado.
**Slughorn: una implementación Slug lista para producción** `slughorn` de AlphaPixel es una biblioteca moderna en C++20 que implementa la técnica Slug de dominio público. No hace suposiciones sobre el entorno gráfico (OpenGL, Vulkan, WebGL, WebGPU, DirectX, Metal) y se centra en simplificar la ingestión de datos vectoriales desde múltiples backends —FreeType, NanoSVG, Skia, Cairo, Blend2D— más una API nativa tipo Canvas. Soporta composición de emojis COLRv0/COLRv1, materiales PBR/IBL, gradientes, enmascaramiento, elementos de HUD, y proyecciones 2D ortográficas y 3D en perspectiva. Proyectos complementarios como `osgSlug` ayudan con la integración en OpenSceneGraph/VulkanSceneGraph.