Slughorn libera Slug de Lengyel en C++20 y reta a MSDF

Cómo se renderiza texto en una GPU (y por qué es más difícil de lo que parece)

Dibujar una letra en pantalla parece trivial hasta que intentas hacerlo bien. Una letra no es una imagen: es un conjunto de contornos, lazos cerrados de líneas rectas y curvas Bézier, que se rellenan según una regla de winding. Rasterizar eso en CPU está resuelto desde hace décadas. En GPU, mantenerlo nítido a cualquier tamaño, bajo cualquier transformación 3D, mientras el texto cambia cada frame, todavía no lo está.

El problema central es que las GPU quieren triángulos y texturas, no curvas. Cada técnica de render de texto que existe hoy hace un trade-off distinto: o aceptas una resolución fija pre-horneada (atlas), o aceptas que las esquinas se redondeen (SDF), o pagas un teselado caro cada vez que algo se mueve (Rive/Pathfinder). El algoritmo Slug, publicado por Eric Lengyel en 2017 y dedicado al dominio público en marzo de 2026 según la fuente, evita los tres compromisos a la vez.

El atlas de texturas: la opción clásica que aún domina

La técnica más vieja y más usada sigue siendo hornear cada glifo en un atlas de texturas y dibujarlo como un quad texturizado. Es rápida, portable y funciona en cualquier GPU que tenga una unidad de texturas. Por eso está en todas partes.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El problema aparece al escalar. Si amplias más allá del tamaño al que se horneó, la letra se vuelve borrosa porque estás magnificando un bitmap. Si reduces, aparecen parpadeos y tallos desaparecidos a menos que hornear mip levels. Cada tamaño nítido requiere otro atlas. Y los conjuntos de glifos enormes —chino, japonés, coreano— convierten esto en un desastre de memoria: hornear decenas de miles de glifos a varios tamaños cada uno.

SDF: distance fields para texto escalable

Chris Green, de Valve, presentó en SIGGRAPH 2007 el paper Improved Alpha-Tested Magnification for Vector Textures and Special Effects que cambió la industria durante una década. La idea: en lugar de guardar el píxel del glifo, guardar un campo de distancias —cada texel tiene la distancia al borde más cercano, positiva dentro, negativa fuera—. En el shader se muestrea el campo y se umbraliza a cero. Como la distancia interpola suavemente, puedes escalar una textura SDF pequeña sin perder definición y obtienes antialiasing gratis ablandando el umbral.

El SDF sigue siendo una textura horneada a una resolución fija, y miente sobre las esquinas. Una esquina afilada es una discontinuidad en el campo de distancias, y la interpolación bilineal la redondea. Cada pico de «A» o muesca de «K» se suaviza. A tamaños muy pequeños el campo tiene tan pocos texeles que los tallos finos se rompen.

MSDF: tres canales para preservar esquinas

Viktor Chlumsky, en su tesis de 2015 y luego en el paper Improved Corners with Multi-Channel Signed Distance Fields de 2018, resolvió el problema de las esquinas. En vez de un canal de distancia, MSDF guarda tres —rojo, verde y azul— cada uno codificando distancia a un subconjunto distinto de bordes elegido para que las esquinas afiladas sobrevivan. En el shader se toma la mediana de los tres canales, y el truco reconstruye las esquinas casi perfectamente.

MSDF sigue siendo un atlas. Hay que hornear cada glifo a una resolución elegida por adelantado, así que texto dinámico o del usuario, y conjuntos enormes como CJK, siguen significando pipelines de horneado y presupuestos de memoria. La generación es más cara que SDF simple. A tamaños muy chicos se siguen muestreando muy pocos texeles para capturar el detalle fino, y los tres canales consumen más ancho de banda que uno. MSDF sube el techo de calidad pero sigue atado al atlas.

Slug: render directo desde el contorno, sin atlas ni teselado

Eric Lengyel publicó Slug en 2017 en el Journal of Computer Graphics Techniques. El algoritmo guarda el glifo como una lista de curvas Bézier cuadráticas y segmentos de línea en un buffer pequeño de GPU. Junto a eso, Slug construye una estructura de aceleración por glifo que lo divide en bandas horizontales, así un pixel solo evalúa las pocas curvas cercanas en lugar del contorno entero.

En el fragment shader, para cada pixel se lanza un rayo, se encuentran los cruces con las curvas Bézier cercanas y se cuentan para calcular el winding number y por tanto la cobertura. La pieza clave, según describe la fuente, es un test que Lengyel llama root eligibility: una regla precisa para decidir qué intersecciones cuentan, así el cálculo de winding es exacto en los puntos donde las curvas se encuentran y donde los métodos ingenuos producen grietas o doble conteo. Como el shader resuelve las ecuaciones de la curva analíticamente en lugar de muestrear un campo horneado, la cobertura es exacta y el antialiasing limpio a cualquier escala.

No hay resolución horneada, así el mismo glifo se ve nítido a 6 píxeles o 6000, y se mantiene nítido bajo cualquier transformación 2D o 3D, incluida la perspectiva, porque la cobertura se calcula por píxel después del transform. No hay atlas, así que cien mil glifos CJK cuestan el equivalente a los datos del contorno de la fuente, no un atlas del tamaño de un video. El texto puede cambiar cada frame sin coste de horneado, justo lo que quieres para datos en vivo, input del usuario y contenido localizado.

Slughorn: la implementación C++20 que AlphaPixel libera en GitHub

AlphaPixel publicó Slughorn como librería C++20 con licencia MIT, disponible en GitHub según el repositorio verificado. Es una implementación del algoritmo Slug de Lengyel, que pasó al dominio público en marzo de 2026, y hace el trabajo pesado una sola vez en build time: los datos del contorno y la estructura de bandas se preparan por adelantado y el shader solo evalúa cobertura.

Slughorn no es un renderer: no intenta adueñarse de tu scene graph, swap chain, cámara ni material system. Es una capa de adaptación: tú le pasas datos vectoriales —de un backend que produzca curvas Bézier, o a través de una API estilo HTML canvas directamente en código— y prepara datos compatibles con Slug que tu propio pipeline de GPU sube y dibuja. Esto le permite integrarse con OpenGL, Vulkan, WebGL, WebGPU, Direct3D y Metal, según la documentación del proyecto.

Los backends soportados incluyen FreeType, NanoSVG, Skia, Cairo y Blend2D. Para OpenSceneGraph, AlphaPixel mantiene el proyecto compañero osgSlug que conecta Slughorn a una escena OSG. El README del repositorio, actualizado al 27 de septiembre de 2026, lista como trabajo en curso el soporte de strokes en GPU, reducciones de memoria de texturas, soporte completo de Porter-Duff y empaquetado CI/CD para el binding de Python.

¿Qué significa esto para tu startup?

Si estás construyendo un producto con render de texto exigente —juegos, simuladores, herramientas CAD, gemelos digitales, apps AR/VR, instrumentación, GIS, cockpits, medical imaging— Slughorn cambia tres ecuaciones que antes estaban cerradas:

Coste de memoria predecible para CJK y sets grandes. Antes, soportar chino, japonés o coreano bien implicaba hornear múltiples atlas por tamaño. Con Slughorn los datos son el contorno de la fuente, sin multiplicar por tamaños. Si tu mercado objetivo incluye Asia, ese coste de memoria cae a una fracción.
Cero horneado en tiempo de ejecución. El texto puede cambiar cada frame —cotizaciones en vivo, posiciones de etiquetas en un mapa, datos del usuario, localización dinámica— sin disparar un pipeline de baking. Esto habilita diseños de producto donde la latencia del bake antes era el cuello de botella.
Legibilidad bajo perspectiva arbitraria. Si tu cámara 3D es libre (un walkthrough, un AR overlay, un HUD en movimiento, un visualizador CAD), el texto se mantiene nítido sin importar el ángulo ni el zoom. No hay que pre-reservar resolución para todos los ángulos posibles.

Dos acciones concretas que puedes dar esta semana:

Evalúa Slughorn en tu pipeline actual. El proyecto es MIT y renderer-agnóstico. Si ya usas OpenSceneGraph o VulkanSceneGraph, el camino más corto es probar osgSlug. Si usas otro engine, el camino es importar Slughorn como capa de datos y dibujar las curvas con tu propio backend gráfico. El repo en GitHub incluye una guía de usuario y demos con PBR, IBL, emoji COLRv1 y máscaras MSDF.
Audita dónde tu render de texto está pagando el coste equivocado. Inventaría los lugares de tu producto donde el texto se ve mal al hacer zoom o rotar en 3D, dónde hornear otro atlas dejó de ser viable por memoria, o dónde el texto cambia cada frame y el bake te frena. Esos son exactamente los puntos donde Slug gana según la tabla comparativa de la fuente, y donde una migración bien hecha tiene retorno inmediato en calidad percibida y libertad de diseño.