Cómo renderizar texto nítido en la GPU
(osor.io)- El método Multi-Channel SDF existente funcionaba bastante bien, pero seguía teniendo límites con trazos finos, atlas grandes, reducción y ampliación, y movimiento suave, por lo que se volvió a implementar mediante rasterización en tiempo de ejecución en la GPU
- El nuevo pipeline envía a la GPU solo los datos de curvas Bézier de los glifos visibles en ese momento, los dibuja en el atlas en tiempo de ejecución y luego los muestrea en pantalla
- Si un glifo permanece en pantalla, se mantiene la caché del atlas y se acumulan muestras para mejorar la calidad, comenzando con 8 samples-per-pixel en el primer frame y refinando hasta un máximo de 512 samples
- La clave de caché incluye
font,glyph_index, tamaño en píxeles y offset subpíxel; usando punto fijo de 8 bits se agrupan posiciones y tamaños cercanos en el mismo valor para aumentar la reutilización - Si se modela la estructura RGB subpíxel de cada monitor como un área de muestreo, se puede reducir el color fringing incluso en disposiciones no estándar como la del OLED G9, y una demo de texto a pantalla completa en 4K muestra un costo pico de alrededor de 0.1 ms en una Radeon 9070
Por qué se eligió rasterización vectorial en tiempo de ejecución en lugar de SDF
- La implementación anterior usaba Multi-Channel Signed Distance Fields y en general funcionaba bien, pero en uso real seguían existiendo varias limitaciones
- Calidad: en fuentes con trazos finos o mucho detalle, algunas características desaparecían o aparecían artefactos, y a veces se necesitaba un SDF de mayor resolución
- Tamaño del atlas: como el SDF se genera offline y luego se guarda en un atlas, las fuentes japonesas o chinas con muchos glifos son difíciles de hornear en un solo atlas
- Flexibilidad: era complicado aplicar ideas nuevas como problemas de reducción/ampliación o antialiasing subpíxel, y tampoco encajaba bien con imágenes vectoriales que pudieran generarse o editarse en tiempo de ejecución
- Simplicidad: la etapa de convertir las curvas originales del glifo en una textura intermedia aumentaba la complejidad del sistema
- Incluso una fuente latina como Miama requería un atlas de
4096×1152usando un área de64×64por glifo, y usar varias fuentes en tiempo de ejecución incrementa los costos de memoria y ancho de banda de streaming - El objetivo del nuevo enfoque es usar de forma más directa las curvas Bézier creadas por el diseñador del glifo, reduciendo las etapas de transformación desde los datos originales hasta el píxel final
Pipeline completo
- La idea clave es que, en lugar de hornear todos los glifos offline por adelantado, solo se envían a la GPU las curvas de los glifos visibles en ese momento para rasterizarlas cuando se necesiten
- El flujo de procesamiento es simple
- Se cargan desde la fuente los datos de curvas del glifo
- La GPU rasteriza el glifo en el atlas en tiempo de ejecución
- Al mostrarlo en pantalla, se muestrea ese atlas
- Si el mismo glifo sigue usándose en frames posteriores, se deja en el atlas y se acumulan muestras para refinar incluso el antialiasing subpíxel de alta calidad
- Como se renderiza directamente la representación vectorial, es fácil adaptarse a cambios de resolución y calcular no solo la cobertura total del píxel, sino también la cobertura de cada componente subpíxel
Procesamiento de curvas de glifos
- Para cargar fuentes se usa FreeType como capa intermedia en una herramienta offline para leer formatos compatibles, recorrer las curvas de cada glifo y guardarlas en un formato de assets propio
- Las curvas de glifo pueden incluir líneas, Bézier cuadráticas y Bézier cúbicas; para simplificar el shader, todas se convierten a Bézier cuadráticas
- Las líneas se convierten en Bézier cuadráticas agregando un punto de control en el punto medio entre dos puntos
- Las Bézier cúbicas se dividen en dos Bézier cuadráticas, lo que implica una conversión con pérdida al reducir el grado
- Dividir una Bézier cúbica en dos Bézier cuadráticas funcionó bien con la mayoría de las fuentes probadas, aunque también serían posibles métodos más sofisticados para reducir aún más el error
- Si se necesita una conversión de mayor calidad, se puede usar una herramienta offline para convertir a un formato con solo Bézier cuadráticas, como TrueType
.ttf, y evitar por completo esta conversión - En este gráfico de Desmos se puede comparar la forma de la Bézier cúbica de entrada y las dos Bézier cuadráticas resultantes
Cálculo de cobertura y optimización del acceso a curvas
- La cobertura se calcula por píxel lanzando un rayo horizontal de izquierda a derecha y comprobando las intersecciones con las curvas para acumular el winding number
- Para la base matemática y la implementación, se puede consultar GPU Font Rendering de GreenLightning y el video Rendering Text de Sebastian Lague
- La imprecisión en el cálculo de intersecciones puede aparecer en muestras a ciertas alturas, pero al acumular cientos de muestras, uno o dos errores casi no se notan tras el promedio
- Si se acumulan hasta 512 muestras y una sale mal, el resultado pasa a ser
1/512=0.00195en vez de0, o511/512=0.99804en vez de1 - También se pueden usar umbrales para clamping cuando la cobertura está cerca de valores extremos
- Si se acumulan hasta 512 muestras y una sale mal, el resultado pasa a ser
- Para la distribución de posiciones de muestreo se usa la $R_2$ sequence de Martin Roberts, y en este ejemplo de Shadertoy se puede ver cómo se distribuye en el tiempo
- Para reducir el costo de acceso a curvas, el glifo se divide en varias bandas horizontales y solo se guardan como bitset las curvas que tocan cada banda
- Como solo se rastrean rayos horizontales, se reduce mucho el conjunto de curvas que cada píxel debe revisar
- Si a nivel de wave se accede al mismo rango de bandas, es posible escalarizar la iteración y lectura de curvas
- Al rasterizar en el atlas con un compute shader, los threads se empaquetan horizontalmente en orden row-major para minimizar el rango de bandas que toca la wave
Empaquetado del atlas y claves de caché
- Al principio se rasterizaba directamente en pantalla, pero el costo de calcular antialiasing de alta calidad en cada frame era alto
- La mayor parte del texto permanece durante varios frames en el mismo tamaño y posición, y el mismo glifo se repite al mismo tamaño, así que un atlas con acumulación temporal resulta adecuado
- Si el glifo necesario no está en el atlas, se le asigna espacio y se inicia la rasterización; si ya existe, se reutiliza el resultado anterior
- Durante el frame se inspeccionan los glifos del atlas para decidir si deben mantenerse, si conviene seguir muestreándolos o si no se usan y se puede liberar su espacio
- La clave del atlas incluye los siguientes elementos
fontglyph_indexquantized_size_in_pixels_x,quantized_size_in_pixels_yquantized_subpixel_offset_x,quantized_subpixel_offset_y
- El offset subpíxel corresponde a
frac(pixel_position)y es necesario para producir un resultado de antialiasing acorde con la posición cuando el glifo no coincide exactamente con la grilla de píxeles o cuando se desplaza suavemente - Si se usan directamente valores de punto flotante como clave, valores que matemáticamente deberían ser iguales pueden diferir a nivel de bits, así que se agrupan posiciones y tamaños cercanos en el mismo valor usando punto fijo con 8 bits fraccionales
- En un editor de texto con mucho contenido estático y fuente monoespaciada, alinear el espaciado de caracteres y la posición de las líneas a los bordes de píxel puede mejorar la tasa de aciertos de la caché del atlas para el mismo glifo
Ubicación en el atlas basada en Z-Order
- La asignación de glifos en tiempo de ejecución usa Z-Order Packing y un bitset de celdas libres
- El Z-Order basado en código Morton permite tratar celdas 2D como si fueran un arreglo 1D largo, y si se asignan celdas contiguas en cantidades que sean potencia de dos, en el atlas 2D forman una región cuadrada
- La celda base es de
16×16texels y el tamaño del glifo se redondea hacia arriba a la siguiente potencia de dos- Por ejemplo, un glifo de
25×29recibe un chunk de32×32 - En ese caso se necesitan 4 celdas de
16×16, así que se busca un bloque contiguo alineado de 4 bits y se usa
- Por ejemplo, un glifo de
- Los glifos latinos largos y delgados suelen ser verticales, así que con Z-Order transpuesto glifos como
l,j,i,1pueden usar solo la mitad del espacio - En cambio, para glifos largos y delgados en horizontal, como en árabe, el Z-Order estándar resulta más adecuado
Cómo se mejora la calidad con acumulación temporal
- Si un glifo permanece en el atlas, en cada frame se pueden añadir algunas muestras más para refinar el resultado
- El esquema base es: 8 samples-per-pixel en el frame en que aparece el glifo por primera vez, 4 en el siguiente, 2 en el siguiente y luego 1 adicional por frame hasta acumular un total de 512
- La razón para fijar una calidad inicial alta es que un glifo que se mueve suavemente o cambia de tamaño equivale, en la práctica, a reinicializarse en cada frame
- La calidad y el rendimiento se pueden ajustar de varias maneras
- Cuántas muestras/rayos adicionales añadir por frame
- Si aumentar las muestras durante los primeros frames del glifo
- El límite máximo de muestras totales por frame
- Time-slicing, actualizando los glifos existentes no en cada frame sino cada varios frames
- Formas de limitar el costo de las pruebas de intersección según la cantidad de curvas del glifo
- En esta implementación el rendimiento no fue un problema importante: el texto a pantalla completa mostrado al inicio tuvo un pico de unos 0.1 ms en 4K sobre una Radeon 9070, y cuando los glifos alcanzan el máximo de muestras el costo cae rápidamente casi a cero
Antialiasing subpíxel y color fringing
- El antialiasing subpíxel renderiza tratando por separado los componentes rojo, verde y azul dentro de cada píxel del monitor como áreas de muestreo
- En la estructura clásica de franjas verticales RGB de un LCD, la resolución horizontal se vuelve efectivamente 3 veces mayor, de modo que una pantalla
3840×2160puede tratarse como si fuera3840×6480 - El problema es que monitores como el OLED G9 tienen una estructura subpíxel no estándar, distinta de las franjas verticales RGB convencionales
- Si se asume la estructura rectangular vertical RGB básica, aparece color fringing verde arriba y magenta abajo
- Si las posiciones de muestreo se ajustan a la estructura subpíxel real del monitor, el color fringing casi desaparece y el resultado se ve suave
- Subpixel Zoo muestra ejemplos de distintas estructuras subpíxel, y la estructura red-white-blue-green de los LG WOLED es un ejemplo con un orden distinto del estándar
- Se obtuvieron resultados más precisos al tratar los componentes subpíxel como más grandes que su tamaño físico real y hacer que se superpongan entre sí
- La luz de los subpíxeles se mezcla de forma natural y se difunde un poco, así que el área de muestreo actúa como si fuera mayor que el subpíxel físico
- El área de muestreo también debe extenderse fuera del píxel y mezclarse con la luz subpíxel de los píxeles vecinos
- Easy Scalable Text Rendering de Evan Wallace plantea que después del antialiasing subpíxel hace falta un blur horizontal, lo que en la práctica produce un efecto equivalente a considerar componentes subpíxel más grandes y superpuestos
El software necesita conocer la información de subpíxeles de la pantalla
- Si se pudiera acceder a estructuras subpíxel arbitrarias del monitor, sería posible mejorar tanto el antialiasing subpíxel general como la calidad del renderizado de texto
- Si este tipo de información se ofreciera mediante protocolos de pantalla comunes, incluso en monitores con arreglos estándar se podría hacer un renderizado más fino según el hardware
- Los fabricantes de pantallas no tendrían que evitar experimentar con mejores estructuras subpíxel por temor a problemas de renderizado de texto
- Samsung cambió la estructura subpíxel de sus QD-OLED del G8 al G9 para reducir este tipo de problemas, y tanto en LG WOLED como en Samsung QD-OLED el color fringing suele mencionarse con frecuencia
- Este problema puede abordarse en parte con corrección por software en vez de depender de reemplazar el hardware
Valor práctico del renderizado de glifos en tiempo real
- Una buena UI y una buena calidad de texto pueden elevar la calidad percibida de un producto
- En los juegos aparecen con frecuencia elementos que atraen la mirada del usuario, como cuadros de texto, menús, títulos y notificaciones, y una mala calidad de texto puede afectar la experiencia tanto como una escena 3D mal renderizada
- La serie Persona, Metaphor: ReFantazio y Nier: Automata son buenos ejemplos de UI y presentación de texto
- Los intentos por mejorar la calidad del renderizado de glifos en tiempo real tienen un valor práctico tanto en UI como en renderizado para juegos
1 comentarios
Opiniones de Hacker News
¿Qué pasó con el punto de la j en cursiva en el primer video?
El renderizado de fuentes con subpíxeles es importante para la legibilidad, pero, como señala el artículo, es una lástima que con los estándares de pantalla existentes no se pueda obtener la especificación de la disposición de los píxeles
El mundo se fue moviendo cada vez más hacia pantallas tipo Retina, donde casi no hay razón para usar renderizado con subpíxeles
Hay muchos problemas: las capturas de pantalla quedan atadas a una disposición específica de subpíxeles, y escalar bitmaps también se vuelve difícil
Fue una innovación temporal de la era LCD entre CRT y Retina, y hoy es casi una tecnología que mira hacia atrás. Hay una buena razón por la que Apple la eliminó de macOS hace unos años
Me pregunto si los fabricantes de pantallas simplemente no lo implementan. En cualquier caso, para los modelos de pantalla más comunes es información que podría inferirse fácilmente y guardarse en una base de datos de información de hardware
El artículo es excelente y también enlaza un “subpixel zoo” que muestra varios casos: https://geometrian.com/resources/subpixelzoo/
Incluso en los casos inevitables en que el monitor informe una disposición incorrecta, se necesitaría un enfoque así
Con fuentes bitmap sin antialiasing o fuentes vectoriales con hinting ya se logra una legibilidad muy buena
Solo se vuelve importante en idiomas cuyos caracteres tienen detalles muy complejos, como el chino o el japonés
GTK4 abandonó el renderizado con subpíxeles RGB al mover el renderizado a la GPU
Había oído que, por decisiones centradas en la GPU, se volvió difícil seguir usando renderizado con subpíxeles RGB, pero el artículo muestra que es posible
Entonces puede que las razones de GTK estuvieran en otro lado, o que la solución propuesta tenga desventajas, o que no se integre bien con el stack existente
Si te interesa cómo implementar SDF y MSDF en WebGL / WebGPU, puedes ver un tutorial que escribí: https://infinitecanvas.cc/guide/lesson-015#msdf
He intentado pasar ejemplos de JavaScript a Rust, y como no se puede simplemente copiar y pegar, pero las API son lo suficientemente parecidas como para que el port sea sencillo, resulta ideal para aprender
También sirve como puerta de entrada para acostumbrarse a la documentación de WGPU
Me gusta crear tutoriales relacionados con GPU y quisiera estructurarlos así; me pregunto si es una plantilla existente o parte de algún curso
La biblioteca Slug es middleware comercial que implementa este tipo de rasterizador de glifos en GPU
[1]: https://sluglibrary.com/
Sería divertido crear una versión open source en wgpu usando parte del análisis y layout de fuentes de cosmic-text, pero no tendría nada de divertido si al final Slug te demanda
La GPU parece tener una capacidad prácticamente infinita para dibujar vértices/píxeles, así que todavía no entiendo por qué hay que renderizar el texto offline, guardarlo en un atlas y usar trucos como SDF
El artículo también dice que escribe las curvas de los glifos en un atlas, pero me pregunto por qué el shader no puede renderizar el texto directamente
Seguramente debe haber alguna forma de convertir Bézier en una malla de triángulos. Justo estoy por empezar un renderizador de texto en GPU para una app CAD, así que espero descubrir pronto la razón
La GPU es rápida, pero no infinitamente rápida, y es muy fuerte muestreando texturas prerenderizadas
No es solo un tema de velocidad, sino también de consumo de energía. Si ya alcanzaste la frecuencia de refresco del monitor, más rendimiento no mejora la respuesta, pero sí puede aumentar la duración de la batería
En renderizado no existe algo como “suficientemente rápido”; si se vuelve más rápido, siempre hay beneficio
Ninguna arquitectura moderna de GPU maneja bien geometría de alta densidad. En estos casos, simplemente empujar triángulos a la GPU es mucho menos eficiente que usar un atlas u otras técnicas
La mayoría de las GPU despachan shaders de píxel en grupos de 4. Si todos los triángulos miden 1 píxel, 3 hilos del shader no contribuyen a la salida visual
A esto se le llama sobredibujo de quads. Además, se pierde mucho tiempo en procesamiento de vértices sin una razón real
Es posible, pero terminas cediendo parte del presupuesto de frame y aumentando el consumo de energía sin gran beneficio
El autor usa atlas porque supermuestrea curvas Bézier con hasta 512 muestras por píxel, lo cual es muy costoso
En cambio, calcular la integral de la intersección entre el área de la curva Bézier y el área del subpíxel podría ser mucho más rápido, y parece que podría ejecutarse en tiempo real sin atlas y ser más preciso que el supermuestreo
Y casi siempre vas a querer usar ese tiempo en otra cosa
Cuanto más tiempo de GPU necesites, más rápido tendrá que ser el hardware mínimo requerido. El texto es bonito e importante, pero quizá no tanto como para perder usuarios o clientes
Se ve peor que simplemente decir “los nuevos OLED se ven bien, pero tienen problemas de fringing de color por sus estructuras de subpíxeles no estándar”
Según entiendo, no es solo que no sean estándar: en OLED hay varias disposiciones de subpíxeles incompatibles entre sí
Por eso FreeType no implementó renderizado subpíxel para OLED, y se convierte en una razón para evitar OLED si necesitas trabajar con texto
Tampoco es un problema solo de FreeType; los toolkits de GUI como Qt y GTK también tendrían que adaptarse. No sé bien si ha habido avances hacia una solución
Sería bueno poder acceder a la estructura de subpíxeles de cualquier monitor, y quizá esta información debería transmitirse mediante EDID
Por ejemplo, mi laptop tiene una disposición BGR vertical, y FreeType y KDE la soportan bien
Creo que las disposiciones raras suelen aparecer en pantallas HDR porque hay que usar tamaños distintos para cada color, para que ciertos colores, especialmente el azul, no se quemen demasiado rápido
Es un trabajo muy impresionante
Para quienes no estén familiarizados con esta área, Valve creó el renderizado de texto SDF para juegos y publicó en 2007 un artículo influyente sobre el tema
Incluso hoy es una técnica muy usada en videojuegos, casi sin modificaciones
En 2012, Behdad Esfahbod creó Glyphy, una implementación de SDF que corre en la GPU con OpenGL ES, y aunque fue ampliamente reconocida por su rendimiento y nuevas funciones como transformaciones rápidas de texto, no tuvo un uso masivo
Los sistemas operativos modernos y los navegadores web prefieren depender de la rasterización TrueType al estilo de los años 90 en vez de usar estas técnicas
Es un enfoque ligero y efectivo, pero como se ve en el artículo, no permite alineación subpíxel ni disposiciones arbitrarias de subpíxeles; hacer zoom tiene un costo de rendimiento alto; y transformaciones complejas como inclinación, rotación o transformaciones 3D tampoco pueden hacerse dentro del motor de renderizado de texto
Si necesitas texto rotado o deformado, tienes que remuestrear el bitmap, lo que arruina todos los pequeños detalles que lo hacen legible y termina viéndose mal
La razón por la que el avance es lento puede ser que el trabajo y el riesgo son demasiado grandes frente al beneficio. Imaginar reescribir un motor moderno de navegador web con renderizado de texto acelerado por GPU no es poca cosa
El renderizado de glifos es solo una parte; el salto de línea es otro problema. Puede ser lento porque requiere mucha comunicación entre CPU y GPU, y también es difícil integrar profundamente el software con la GPU
Este enfoque rinde mucho mejor que forzarlo a encajar en el pipeline de renderizado 3D por hardware, como ocurre con SDF
Safari probablemente también, pero no puedo afirmarlo de primera mano
La idea de que el estado del arte o las implementaciones distribuidas a usuarios no han avanzado es incorrecta
SDF codifica la distancia local (Distance) desde un píxel dado hasta el borde de la letra como un campo (Field), es decir, un arreglo bidimensional de datos, y marca si esa distancia está dentro o fuera de la letra con un bit de signo (Sign)
Cada letra tiene un pequeño mapa de datos; estos se empaquetan juntos en un formato de archivo de imagen amigable para la GPU, y el shader de renderizado SDF los usa junto con un archivo de descripción que indica dónde encontrar la subimagen de cada letra
Esta definición de letras es muy resistente a la interpolación lineal entre valores del campo, por lo que incluso con mapas de resolución relativamente baja se puede escalar casi perfectamente. La GPU también es buena interpolando valores de píxeles de un mapa
Pero lo importante es que estos mapas deben preprocesarse durante el desarrollo para todos los caracteres que se quieran renderizar desde el sistema de fuentes existente. Hace falta para cada carácter que soporte la fuente
Requiere muchos menos datos que renderizar todos los caracteres como una fuente bitmap de alta resolución, pero muchos más que la propia definición de contornos de la fuente
Un sistema que intenta soportar todo el texto posible del mundo, como un sistema operativo o un navegador, no puede usar SDF como sistema de renderizado de texto. Necesitaría mapas SDF para todo el conjunto de caracteres Unicode, lo que lo haría demasiado grande
En los juegos encaja bien porque, en general, no necesitan una localización suficientemente completa o no tienen que mostrar texto completamente arbitrario
El SDF original tampoco puede soportar emoji, porque solo codifica la distancia al borde del glifo y no contiene información de color dentro del glifo
Existe una versión mejorada llamada Multichannel SDF que soporta varios colores, pero tiene un límite en la cantidad total de colores
En la práctica, si miras de cerca un juego que usa SDF para el texto dentro del juego y además tiene un sistema de chat donde interactúa una comunidad global, es muy probable que el renderizado del texto del juego y el del chat sean distintos
Según https://keithclark.co.uk/articles/gpu-text-rendering-in-webk... (2014), “cuando un elemento se promueve a la GPU en las versiones actuales de Chrome, Safari u Opera, pierde el antialiasing subpíxel y el texto se renderiza en escala de grises”
Entonces me pregunto qué es lo que falta. Si esa frase es correcta, parecería que al menos una parte del paso de una cadena UTF-8 a un bitmap puede hacerse en la GPU
Es un trabajo impresionante.
Pero personalmente creo que el antialiasing subpíxel no tiene mucho sentido. Era un buen hack en los años 2000, cuando se usaban monitores de 72 dpi, pero en las pantallas Retina modernas es difícil de notar y se obtienen varias desventajas a cambio de una mejora muy pequeña.
Solo funciona sobre fondos opacos, no se pueden aplicar efectos como cambio de tamaño, espejado o desenfoque al resultado rasterizado, y las capturas de pantalla se ven peor si se miran en otra pantalla.
Según la encuesta de hardware de Firefox [1], el 16% de los usuarios usa pantallas con resolución 1366x768.
No es solo un problema de hardware viejo: todavía se fabrican monitores y laptops de 96 dpi.
[1]: https://data.firefox.com/dashboard/hardware
Los otros argumentos no son tan importantes comparados con los mejores resultados que ofrece el renderizado subpíxel donde se puede aplicar.
Es importante que SDF calcule la distancia en píxeles hasta el borde más cercano, mientras que los renderizadores de fuentes tradicionales calculan la cobertura de píxel.
La cobertura de píxel es óptima. En fuentes pequeñas, SDF puede verse mal en las zonas donde se encuentran los bordes.
Quizá sea un problema menor en pantallas de alto PPI. Implementé mi propio renderizador SDF y se veía peor que FreeType.
Sin embargo, es correcto señalar que el campo de distancia causa problemas en las intersecciones o, en general, en las esquinas pronunciadas.
Se puede mitigar en cierta medida usando varios campos de distancia y renderizando su intersección. Por ejemplo, está https://github.com/Chlumsky/msdfgen.