Renderizar texto nítido en la GPU

• Para resolver los problemas de calidad del renderizado de texto, especialmente las limitaciones de los métodos basados en SDF (campos de distancia), se propone una nueva técnica de renderizado vectorial en tiempo real
• Al enviar directamente a la GPU los glifos (caracteres) en forma de curvas vectoriales y rasterizarlos en tiempo real, se logra resolución ilimitada y bajo uso de memoria
• Mediante el uso de atlas de texturas y la técnica de acumulación temporal (temporal accumulation), se consigue una alta calidad de antialiasing y un caché eficiente
• Puede adaptarse a distintas estructuras de subpíxeles (por ejemplo, OLED, LCD, etc.), ofreciendo resultados suaves y nítidos sin problemas de fringing (sangrado de color)
• Presenta un enfoque simple pero altamente escalable para el renderizado tipográfico de alta calidad en texto en tiempo real, UI y juegos

---

Introducción: los desafíos del renderizado de texto

• En el renderizado de texto en tiempo real existen varios problemas, como aliasing (efecto escalonado), texturas grandes, tiempo de build, zoom y desplazamiento suave
• El método ampliamente usado de Multi-Channel Signed Distance Fields (SDFs) tenía limitaciones en calidad y flexibilidad
• A partir de los subpíxeles no estándar en monitores OLED recientes y del problema del fringing, se desarrolló un nuevo enfoque que también contempla el antialiasing por subpíxel

Limitaciones del enfoque SDF tradicional

Calidad

• En el caso de SDF, en tipografías con detalles finos o muchos trazos delgados, aparecen problemas de pérdida de calidad y de información
• Si no se aumenta la resolución, permanecen artefactos en ciertos glifos

Tamaño del atlas

• SDF se genera primero de forma offline y luego se almacena en un atlas, pero con muchos glifos o fuentes CJK (chino, japonés, coreano) el tamaño puede volverse imprácticamente grande
• Si se usan varias fuentes al mismo tiempo, aumentan mucho el consumo de memoria y la carga del ancho de banda de streaming

Flexibilidad y simplicidad

• Como pasa por una etapa intermedia llamada SDF, todo el flujo entre los datos de origen y el resultado final se vuelve más complejo
• Hay muchas limitaciones para usar o editar directamente imágenes vectoriales en tiempo real o de forma dinámica

Nuevo enfoque: rasterización en tiempo real de curvas vectoriales

• En lugar de crear texturas por adelantado, se envían directamente a la GPU los datos de curvas vectoriales de los glifos visibles en pantalla (como curvas Bézier) y se rasterizan en ese momento
• Solo se colocan en la textura atlas los glifos necesarios, manteniéndolos o liberándolos según su frecuencia de uso
• Mientras el glifo permanece en pantalla, se implementa un resultado mucho más suave y de muy alta calidad (anti-aliased) mediante la acumulación de muestras (temporal accumulation)
• Como siempre se procesa de forma vectorial, se obtienen resultados nítidos sin límite de resolución

Procesamiento de datos de curvas tipográficas

• Con bibliotecas open source como FreeType se leen distintos formatos de fuentes y se extrae la información de curvas de los glifos
• Los glifos se parsean como líneas y curvas Bézier cuadráticas/cúbicas, y todas las curvas se convierten a Bézier cuadráticas para simplificar el procesamiento en el shader de GPU
  • Las líneas se convierten en curvas cuadráticas añadiendo un punto de control intermedio
  • Las curvas cúbicas se convierten en 2 curvas cuadráticas divididas

Cálculo de cobertura (relleno dentro del píxel)

• En cada píxel se calculan las intersecciones entre la curva y un rayo horizontal, y se determina interior/exterior mediante el winding number (número acumulado de cruces)
• Se suman cientos de muestras (n muestras acumuladas), y algunos errores pequeños casi no afectan el resultado final
• Con una técnica de distribución de puntos de muestreo (quasirandom sequence), en cada frame se acumulan resultados desde distintas posiciones

Optimización del acceso a curvas

• El glifo se divide en bandas horizontales, y solo se prueban las curvas relevantes para cada banda para reducir la carga computacional
• Mediante distribución de hilos e iteración por bandas, se maximiza la eficiencia de procesamiento masivo en la GPU

Empaquetado y gestión del atlas

• Se asigna y administra cada imagen de glifo en un atlas (textura compartida)
  • Si un glifo no existe, se asigna espacio nuevo y se rasteriza; si ya existe, se reutiliza
  • Como referencia, incluso el mismo glifo puede requerir versiones distintas según la posición de subpíxel y el tamaño
• Con Z-Order Packing (Morton code, etc.) se implementa un empaquetado eficiente entre un bitmap unidimensional y un espacio 2D
  • Puede aplicarse con flexibilidad según la estructura del idioma, por ejemplo, vertical para alfabetos latinos y horizontal para familias como el árabe
• Cuando un glifo deja de ser necesario, el espacio del atlas se reasigna para volver a usarse

Acumulación temporal (Temporal Accumulation)

• A través del caché de glifos y del método de acumulación de muestras, justo después de mostrarse se obtiene rápidamente un muestreo de alta calidad, y luego se refina con más precisión en frames posteriores
  • El primer frame usa 8 muestras por píxel; después la cantidad de muestras disminuye gradualmente, con un máximo de 512 acumulaciones
• Se logra un equilibrio entre visualización suave de glifos y optimización de recursos

Antialiasing por subpíxel y prevención de fringing

• Se asigna el área de renderizado por unidad de subpíxel (tratando cada elemento como muestra, como RGB) para aumentar de forma efectiva la resolución horizontal
  • Compatible con la estructura estándar de LCD y con arreglos variados como OLED/WOLED
  • Permite definir un efecto suave sin fringing (sangrado de color)
• Al disponer las muestras de subpíxel de forma que se superpongan (overlapping), también se refleja el efecto real de mezcla de luz del monitor
• Se puede obtener una salida natural y nítida incluso sin bordes de píxel ni hinting

La importancia de abordar la estructura de subpíxeles según cada pantalla

• Si la información sobre la disposición de subpíxeles del monitor puede verificarse por software, es posible lograr un renderizado mucho más preciso
• Se enfatiza que no es una limitación del hardware, sino un problema de procesamiento por software

Cierre y perspectivas de uso

• Un buen renderizado de texto influye mucho en la usabilidad general y en la calidad del servicio
• Especialmente en UI/juegos, una representación tipográfica de alta calidad puede marcar una gran diferencia en la experiencia del producto
• Es una estructura de trabajo que puede materializar los principios de simplicidad, escalabilidad, alta calidad y flexibilidad
• Una implementación open source y la compatibilidad con diversos subpíxeles la hacen muy adecuada para uso real en industria/producción

---

[GN⁺]

Comentarios en Hacker News

• Yo, como autor del texto, no esperaba que el artículo fuera a generar tanta conversación. Gracias a todos los que participaron en el interesante debate
• Pregunta sobre por qué desaparece el punto de la "j" en cursiva en el primer video
• Opinión de que el renderizado de fuentes con subpíxeles es muy importante para la legibilidad. Pero, como señaló el autor, es una lástima que con los estándares actuales de pantallas no se pueda obtener una especificación exacta de la disposición de píxeles
• Consideran que esto solo es necesario en pantallas de resolución estándar. En realidad no es imprescindible, más bien algo deseable. Como las pantallas tipo Retina ya se volvieron comunes, estamos en un entorno donde el renderizado subpíxel ya no es tan necesario. Más bien fue una innovación temporal de la era LCD y ahora se siente anticuada. Además tiene varios efectos secundarios, como depender de la disposición subpíxel en las capturas de pantalla y no permitir ampliar mapas de bits. Por eso creen que Apple terminó eliminando por completo este método en macOS
• Señalan que estándares como DisplayID fueron diseñados para proporcionar esta información de disposición. El problema es que los fabricantes no suelen implementarlo bien o no se guarda en las bases de datos, pero si se trata de modelos de pantalla populares, podría registrarse y aprovecharse en una base de datos de hardware. Ver wiki de DisplayID
• Lamentan que llevemos décadas conociendo la diversidad de estructuras subpíxel y valoran que el texto original lo haya organizado bien. También comparten una página de ejemplos conocida como el “zoológico de subpíxeles”: subpixel zoo
• Les parece exagerado llamarlo una ‘tragedia’. Creen que bastaría con que cada sistema operativo incluyera una función de ajuste fino por pantalla, como el antiguo afinador de ClearType de Windows. También haría falta recordar la configuración del usuario por si el monitor reporta mal la información
• Postura de que el renderizado subpíxel no es indispensable en la mayoría de los idiomas. Incluso fuentes bitmap sin antialiasing o fuentes vectoriales con hinting ya resultan cómodas de leer. Pero en idiomas que usan caracteres complejos, como chino o japonés, sí tendría más importancia
• Se comenta que GTK4 abandonó el renderizado subpíxel RGB al pasar a un modelo de renderizado centrado en GPU, y que esa decisión estuvo relacionada con la tecnología GPU. Pero como el texto original demuestra que también es posible hacerlo en GPU, surge la especulación de si hubo otras razones, desventajas o dificultades para integrar toda la pila
• Se menciona la posibilidad de que Cosmic Text (Cosmic DE) admita renderizado subpíxel sobre GPU mediante Swash
• Si te interesa cómo implementar SDF y MSDF en WebGL/WebGPU, recomiendan un tutorial escrito por el propio comentarista: enlace al tutorial
• Mencionan interés en WebGPU (WGPU), implementado en Rust. Sintieron que este tutorial era más bien avanzado, y comparten que les sirvió mucho aprender convirtiendo los ejemplos de JS a Rust
• Dicen que les encantó el formato del sitio y que les gustaría hacer así sus propios tutoriales sobre GPU. Preguntan si se trata de una plantilla específica o de parte de un curso
• Comparten el dato de que la biblioteca Slug es un middleware comercial que implementa un rasterizador de glifos en GPU: Slug Library
• Les parece interesante que el sitio de Slug publique el algoritmo con bastante detalle. Se preguntan si hay patentes. Creen que sería divertido hacer una versión open source para wgpu usando cosmic-text para el parsing y layout de fuentes, pero les preocupa que después Slug pudiera demandarlos
• Para quienes no están familiarizados con el tema, resumen la historia y la situación actual del renderizado de texto SDF. Valve presentó en 2007 una arquitectura basada en SDF, y luego en 2012 Glyphy (Behdad Esfahbod) publicó una implementación SDF basada en GPU, lo que trajo cambios. Aun así, los sistemas operativos principales y los navegadores web siguen anclados en el enfoque TrueType de los años 90. Ese método es pequeño y ligero, pero no soporta alineación subpíxel ni layout arbitrario, y además tiene fuertes limitaciones para ampliar texto o aplicar transformaciones 3D. Piensan que esta lenta evolución tecnológica se debe a que la ganancia no compensa el riesgo y a que no solo el renderizado, sino también el layout complejo como el salto de línea, dificulta la colaboración entre GPU y CPU
• Señalan que tareas de layout de texto como el salto de línea en realidad son casi independientes del renderizado
• Presentan Pathfinder de Servo como un ejemplo que ya implementó renderizado de texto en GPU con mucho mejor rendimiento usando compute shaders de GPU
• Comparten un artículo sobre el método de renderizado de texto en GPU de WebKit. Señalan que incluso en el estado actual ya se puede procesar bastante sobre la GPU, desde cadenas hasta bitmaps, pero que la esperada “antialiasing subpíxel” suele quedar fuera cuando se promociona el uso de GPU
• Mencionan que en realidad no solo Windows, sino también Chrome/Firefox, ya contaban desde hace años con aceleración por GPU incluso para antialiasing subpíxel. Enfatizan que es un error pensar que no se usan tecnologías modernas
• Comentario agradeciendo por haber resumido tan bien el panorama de forma concisa
• Si se quiere renderizado subpíxel, la premisa es que hay que conocer con exactitud la cuadrícula de subpíxeles de la pantalla. Consideran que pedir una configuración separada por monitor es la única UX razonable. El sistema operativo también tendría que manejar cosas como la rotación de pantalla
• Coinciden con el autor en que lo ideal sería que la propia pantalla informara directamente al sistema sobre su estructura subpíxel
• Evalúan el resultado como excelente y consideran que el antialiasing subpíxel tuvo ventajas claras en la era LCD de comienzos de los 2000, pero que en tiempos de pantallas Retina de alta resolución es casi irrelevante. Como desventajas mencionan que solo funciona con fondos opacos, que no permite posprocesamiento (redimensionar, espejar, desenfocar, etc.) y que las capturas de pantalla se ven raras en otros dispositivos
• Aun así, señalan que eliminar el AA subpíxel simplifica las cosas, pero todavía hay muchos usuarios de escritorio con pantallas de baja resolución de 96dpi y 1366x768, según datos de la encuesta de hardware de Firefox: datos
• También agregan la opinión de que, como usuario de pantallas de alta resolución, es irresponsable no tener en cuenta a quienes siguen usando pantallas de baja resolución
• Preocupa que, incluso si se introduce un protocolo de layout subpíxel, algunos fabricantes lo implementen mal y eso genere problemas de renderizado difíciles de entender para los usuarios comunes
• La primera reacción al ver la tipografía manuscrita (cursiva) fue una impresión honesta tipo: “¿quién demonios pensó que esta cursiva era una buena idea?”
• Explican que probablemente les gustaba a quienes escribían a mano, especialmente en épocas en que se usaban plumines o plumas fuente
• Añaden que la gente que escribía muchas cartas usaba cursiva, y que su uso disminuyó con la llegada de internet y las llamadas de larga distancia gratuitas
• Pregunta de alguien que no logra encontrar el enlace al código