Renderizando texto nítido na GPU

• Propõe uma nova técnica de renderização vetorial em tempo real para resolver problemas de qualidade na renderização de texto, especialmente as limitações das abordagens baseadas em SDF (campos de distância)
• Ao enviar diretamente para a GPU os glifos (caracteres) em forma de curvas vetoriais e executar a rasterização em tempo real, alcança resolução ilimitada e baixo uso de memória
• Utiliza técnicas de atlas de textura e acumulação temporal para obter alta qualidade de anti-aliasing e cache eficiente
• Pode ser adaptado a diversas estruturas de subpixel (por exemplo, OLED, LCD etc.), oferecendo resultados suaves e nítidos sem problemas de fringing (vazamento de cor)
• Apresenta uma abordagem simples e altamente escalável para renderização de fontes de alta qualidade em texto em tempo real, UI e jogos

---

Introdução: os desafios da renderização de texto

• Na renderização de texto em tempo real, existem vários problemas, como aliasing (efeito serrilhado), texturas grandes, tempo de build, zoom e movimentação suave
• A abordagem Multi-Channel Signed Distance Fields (SDFs), muito usada até hoje, tinha limitações em termos de qualidade e flexibilidade
• Mais recentemente, o surgimento de estruturas de subpixel não padronizadas em monitores OLED e os problemas de fringing levaram ao desenvolvimento de uma nova abordagem que também considera anti-aliasing por subpixel

Limitações da abordagem SDF tradicional

Qualidade

• No caso do SDF, fontes com muitos detalhes finos ou traços estreitos sofrem com perda de qualidade e de informação
• Sem aumentar a resolução, alguns glifos ainda apresentam artefatos

Tamanho do atlas

• O SDF é gerado offline e depois armazenado em um atlas, mas isso pode ficar impraticavelmente grande em fontes com muitos glifos ou fontes CJK (chinês, japonês e coreano)
• Ao usar várias fontes ao mesmo tempo, o consumo de memória e a carga de banda de streaming aumentam bastante

Flexibilidade e simplicidade

• Como existe a etapa intermediária do SDF, o fluxo completo entre os dados de origem e o resultado final fica mais complexo
• Há grandes limitações para usar ou editar diretamente imagens vetoriais em tempo real ou dinâmicas

Nova abordagem: rasterização em tempo real de curvas vetoriais

• Em vez de gerar texturas antecipadamente, envia diretamente à GPU os dados de curvas vetoriais dos glifos realmente visíveis na tela (como curvas de Bézier) e faz a rasterização ali mesmo
• Insere no atlas de textura apenas os glifos necessários, mantendo-os ou liberando-os conforme a frequência de uso
• Enquanto o glifo permanece na tela, implementa um resultado muito suave e de altíssima qualidade (anti-aliased) por meio da acumulação temporal de amostras
• Como tudo é sempre processado de forma vetorial, o resultado permanece nítido sem limitação de resolução

Processamento dos dados de curvas da fonte

• Usa bibliotecas open source como o FreeType para ler vários formatos de fonte e extrair as informações de curvas dos glifos
• Os glifos são analisados como linhas e curvas de Bézier quadráticas/cúbicas, e todas as curvas são convertidas para Bézier quadrática para simplificar o processamento no shader da GPU
  • Linhas são convertidas em curvas quadráticas com a adição de um ponto de controle intermediário
  • Curvas cúbicas são convertidas em duas curvas quadráticas segmentadas

Cálculo de cobertura (preenchimento dentro do pixel)

• Para cada pixel, calcula-se a interseção entre um raio horizontal e as curvas, usando o winding number (número acumulado de interseções) para determinar interior e exterior
• Centenas de amostras (n amostras acumuladas) são somadas, e pequenos erros finos quase não afetam o resultado final
• Com uma técnica de posicionamento de pontos de amostragem (sequência quasialeatória), os resultados são acumulados em posições diferentes a cada frame

Otimização do acesso às curvas

• O glifo é dividido em bandas horizontais (bands), e em cada banda são testadas apenas as curvas relevantes, reduzindo o volume de cálculo
• Distribuição de threads e iteração por bandas maximizam a eficiência de processamento em lote na GPU

Empacotamento e gerenciamento do atlas

• Cada imagem de glifo é alocada e gerenciada dentro do atlas (textura compartilhada)
  • Glifos ausentes recebem novo espaço e são rasterizados; glifos já presentes são reutilizados
  • Vale notar que até o mesmo glifo pode exigir versões diferentes conforme a posição de subpixel e o tamanho
• Com Z-Order Packing (Morton code etc.), implementa empacotamento eficiente entre um bitmap unidimensional e um espaço 2D
  • Pode ser aplicado com flexibilidade conforme a estrutura da língua, como orientação vertical para alfabetos latinos e horizontal para sistemas como o árabe
• Quando um glifo deixa de ser necessário, o espaço do atlas pode ser realocado

Acumulação temporal (Temporal Accumulation)

• Por meio do cache de glifos e da acumulação de amostras, obtém rapidamente amostras de alta qualidade logo após a exibição, refinando depois nos frames seguintes
  • No primeiro frame, 8 amostras por pixel; depois, o número de amostras vai diminuindo, com acúmulo máximo de 512 vezes
• Concilia exibição suave dos glifos com otimização de recursos

Anti-aliasing por subpixel e prevenção de fringing

• Distribui a área de renderização em unidades de subpixel (tratando cada elemento, como RGB, como uma amostra) para obter um efeito de aumento de resolução horizontal
  • Compatível com estrutura padrão de LCD, além de vários arranjos como OLED/WOLED
  • Permite definir um efeito suave sem fringing (vazamento de cor)
• Quando as amostras de subpixel são organizadas com sobreposição (overlapping), também reflete o efeito real de mistura de luz do monitor
• É possível obter saída natural e nítida mesmo sem bordas alinhadas ao pixel ou hinting

A importância de abordar a estrutura de subpixel por tipo de display

• Se for possível identificar programaticamente as informações sobre o arranjo de subpixels do monitor, torna-se viável uma renderização muito mais precisa
• Reforça-se que isso não é uma limitação do hardware, mas sim uma questão de processamento em software

Encerramento e perspectivas de uso

• Uma boa renderização de texto tem grande impacto na usabilidade geral e na qualidade do serviço
• Especialmente em UI e jogos, a representação de fontes de alta qualidade pode fazer grande diferença na experiência do produto
• Trata-se de uma estrutura de trabalho que realiza os princípios de simplicidade, escalabilidade, alta qualidade e flexibilidade
• Uma implementação open source e o suporte a diversos tipos de subpixel tornam essa abordagem muito adequada para uso real na indústria e em produção

---

[GN⁺]

Comentários do Hacker News

• Eu, como autor do texto, não imaginava que ele fosse gerar tanta repercussão assim. Agradeço a todos que participaram da conversa interessante
• Pergunta sobre por que o ponto do "j" em itálico desapareceu no primeiro vídeo
• Opinião de que a renderização de fontes com subpixel é muito importante para a legibilidade. Mas, como o autor apontou, é uma pena que os padrões atuais de display não permitam obter especificações exatas do layout de pixels
• Considera que isso só é necessário em displays de resolução padrão. Na prática, não chega a ser essencial, mas seria bom ter. Como telas nível Retina agora são comuns, estamos em um ambiente em que a renderização por subpixel não é realmente necessária. Na verdade, foi mais uma inovação temporária surgida na era do LCD e agora parece algo defasado. Há vários efeitos colaterais, como dependência do layout de subpixels em capturas de tela e impossibilidade de ampliar bitmaps. Por isso, acredita que a Apple acabou removendo essa abordagem do macOS
• Aponta que padrões como o DisplayID foram projetados para fornecer esse tipo de informação de layout. O problema é que os fabricantes muitas vezes não implementam isso direito ou a informação não vai parar em bancos de dados, mas, no caso de modelos populares de display, seria possível registrar e usar isso em bancos de dados de hardware. Veja a wiki do DisplayID
• Lamenta que convivemos há décadas com a diversidade de estruturas de subpixel, e elogia o texto original por organizar bem o tema. Também compartilha uma página de exemplos chamada “subpixel zoo” subpixel zoo
• Acha “tragédia” uma palavra exagerada. Na visão dessa pessoa, bastaria que cada sistema operacional oferecesse um recurso de ajuste fino por display, como o antigo afinador do ClearType no Windows. Também seria necessário lembrar configurações definidas pelo usuário para casos em que o monitor reporte informações erradas
• Defende que a renderização por subpixel não é indispensável na maioria dos idiomas. Fontes bitmap sem antialiasing ou fontes vetoriais com hinting já são confortáveis para leitura. Ainda assim, em idiomas com caracteres complexos, como chinês ou japonês, ela tem mais importância
• Conteúdo sobre como o GTK4, ao migrar para uma renderização centrada na GPU, abriu mão da renderização RGB por subpixel, e como isso estaria relacionado à tecnologia de GPU. Mas, já que o texto original mostrou que isso também é possível na GPU, surge a especulação de que talvez houvesse outros motivos, desvantagens ou dificuldade de integração da stack
• Menção à possibilidade de o Cosmic Text (Cosmic DE) oferecer suporte a renderização por subpixel na GPU via Swash
• Se você tem interesse em como implementar SDF e MSDF em WebGL/WebGPU, recomenda um tutorial que eu mesmo escrevi link do tutorial
• Menciona interesse em WebGPU (WGPU), implementado em Rust. Achou que o tutorial parece um conteúdo mais avançado e compartilha a experiência de que foi eficaz aprender convertendo exemplos em JS para Rust
• Diz que gostou muito do formato do site e que também gostaria de fazer tutoriais sobre GPU desse jeito. Pergunta se isso usa algum template específico ou se faz parte de um curso
• Compartilha a informação de que a biblioteca Slug é um middleware comercial que implementa um rasterizador de glifos em GPU Slug Library
• Acha interessante que o site do Slug divulgue o algoritmo com bastante detalhe. Pergunta se há patentes envolvidas. Comenta que seria divertido fazer uma versão open source em wgpu usando o cosmic-text para parsing/layout de fontes, mas teme que depois a Slug possa processar o projeto
• Para quem não está familiarizado com a área, faz um resumo da história e da situação atual da renderização de texto com SDF. A Valve apresentou uma arquitetura baseada em SDF em 2007, e depois, em 2012, o Glyphy (de Behdad Esfahbod) trouxe uma implementação SDF baseada em GPU, o que marcou uma mudança. Mesmo assim, os principais sistemas operacionais e navegadores web ainda permanecem no modelo Truetype dos anos 1990. Esse modelo é pequeno e leve, mas não suporta alinhamento por subpixel nem layouts arbitrários, e também impõe grandes limitações para ampliar texto ou aplicar transformações 3D. A impressão é que essa evolução tecnológica avança devagar porque o ganho talvez não compense o risco e porque a cooperação entre GPU e CPU é difícil não só na renderização, mas também no processamento de layouts complexos, como quebra de linha
• Observação de que tarefas de layout de texto, como quebra de linha, na prática são quase separadas da renderização
• Apresenta o Pathfinder do Servo como um exemplo de renderização de texto em GPU que já implementou desempenho muito melhor usando compute shaders da GPU
• Link de artigo sobre a abordagem de renderização de texto em GPU do WebKit. Aponta que, mesmo no estágio atual, já é possível processar até certo ponto o caminho de string até bitmap na GPU, mas que a esperada “antialiasing por subpixel” costuma ficar de fora quando a GPU é promovida
• Menciona que, na prática, não só o Windows, mas também Chrome/Firefox já tinham aceleração por GPU até para antialiasing por subpixel há vários anos. Enfatiza que é um equívoco achar que tecnologia moderna não está sendo usada
• Comentário agradecendo pelo resumo claro e conciso
• Parte do princípio de que, para querer renderização por subpixel, é preciso conhecer com precisão a grade de subpixels do display. Opina que pedir uma configuração separada para cada monitor é a única UX razoável. O sistema operacional também teria de lidar com coisas como rotação de tela
• Concorda com a opinião do autor de que o ideal seria o próprio display informar diretamente ao sistema qual é sua estrutura de subpixels
• Avalia o resultado como excelente e considera que o antialiasing por subpixel teve vantagens claras no início dos anos 2000, na era dos LCDs, mas que na era das telas Retina de alta resolução ele é quase irrelevante. Como desvantagens, cita que só funciona com fundo opaco, não permite pós-processamento (redimensionamento, espelhamento, blur etc.) e faz com que capturas de tela pareçam estranhas em outros dispositivos
• Observa que remover o AA por subpixel simplifica as coisas, mas apresenta dados de que ainda há muitos usuários de desktop com telas de baixa resolução, como 96dpi e 1366x768, com base na pesquisa de hardware do Firefox dados
• Acrescenta a opinião de que, para quem usa telas de alta resolução, ignorar os usuários de baixa resolução ainda é irresponsável
• Preocupação de que, mesmo que um protocolo de layout de subpixels seja adotado, alguns fabricantes possam implementá-lo incorretamente, causando problemas de renderização difíceis de entender para usuários comuns
• A primeira reação ao ver a letra cursiva foi algo como: “quem foi que achou que essa porcaria de letra cursiva era uma boa ideia?”
• Explicação de que pessoas que escreviam à mão, especialmente na época em que se usavam penas ou canetas-tinteiro, provavelmente gostavam disso
• Explica que quem escrevia muitas cartas usava letra cursiva, e que seu uso diminuiu com a chegada da internet e das ligações de longa distância gratuitas
• Pergunta dizendo que não consegue encontrar o link para o código