Novos Renderizadores para GTK

Artigo original ↗ Discussão no Hacker News ↗

Os novos renderizadores do GTK acelerados por GPU despertam entusiasmo e ceticismo, com muitos acolhendo recursos há muito aguardados como escalonamento fracionário adequado, melhor tratamento de cores e a possibilidade de renderização fora da thread principal, enquanto outros se preocupam com regressões de desempenho em hardware mais antigo. Os comentaristas contrastam a evolução arquitetural do GTK com alternativas como Qt, mecanismos de jogos e abordagens baseadas na web como Broadway, debatendo trade-offs entre correção, velocidade, acessibilidade e renderização de texto. O fio também se expande para questões de governança e financiamento do ecossistema, argumentando que a distância entre técnicas gráficas de ponta e toolkits de desktop de código aberto é tanto uma questão de recursos e prioridades quanto de dificuldade técnica.

Broadway e “GTK no navegador”

  • Vários comentários recordam Broadway, o backend web do GTK que renderiza aplicativos em um canvas HTML5.
  • Ele é elogiado como “artesanal” e ainda é usado em ferramentas como o Cambalache e em configurações baseadas em Docker de “GUI no navegador”.
  • Outros enfatizam que isso não é uma UI HTML de verdade: ele transmite pixels como o VNC, com rolagem, entrada de texto, tratamento de links e acessibilidade ruins.
  • É comparado e contrastado com UIs web de verdade (por exemplo, a do qBittorrent) e com experimentos mais novos de Wayland no navegador.

UIs declarativas / semânticas e TUIs

  • Alguns gostariam de uma descrição de UI totalmente semântica e de alto nível (“visualização lista-detalhe”, “editor CRUD”) que mapeie automaticamente para widgets nativos e também possa gerar interfaces de terminal.
  • Sistemas existentes como XAML, SwiftUI e QML são vistos como excessivamente ligados à apresentação (retângulos, margens) em vez de à estrutura pura.

Novos renderizadores do GTK e escalonamento fracionário

  • Há entusiasmo em torno de escalonamento fracionário pixel-perfect e renderizadores unificados Vulkan/GL, vistos como uma paridade há muito necessária com Qt e outras plataformas.
  • Narrativas conflitantes:
    • Críticos dizem que a liderança do GTK/GNOME bloqueou por muito tempo o escalonamento fracionário e recursos como miniaturas no seletor de arquivos enquanto os chamava de “impossíveis”.
    • Outros respondem que isso exigia refatorações profundas no backend, descontinuações e cuidado com downstreams; “impossível” na verdade significava “não viável com a arquitetura antiga”.
  • Tecnicamente, agora a renderização é feita na resolução final escalada, em vez de renderizar em 2× e depois deixar o compositor reduzir a escala.

Trade-offs de desempenho

  • Alguns usuários em hardware mais antigo se preocupam com regressões e querem recursos que possam desativar.
  • Observa-se que o renderizador Vulkan, por enquanto, apenas iguala — e não supera — o desempenho antigo do GL; suspeita-se que o gargalo esteja mais acima na pilha.
  • Defensores destacam benefícios além da velocidade bruta: correção de cores (incluindo HDR), renderização de caminhos de GPU/glyphs, renderização fora da thread principal e potencial futuro de otimização.

Mecanismos de jogo vs toolkits de GUI e financiamento

  • Aparece a afirmação de que os desenvolvedores de gráficos de jogos estão “gerações à frente”, mas não podem se dar ao luxo de trabalhar em FOSS; outros chamam isso de irrealista ou algo próximo de extorsão.
  • Há forte reação contrária: renderizadores de GUI precisam lidar com shaping de texto, acessibilidade, impressão, PDF/SVG e integração com o sistema operacional — requisitos que mecanismos de jogo geralmente ignoram.
  • Uma reflexão mais ampla destaca que grande parte do trabalho substancial em FOSS já é pago (por exemplo, por fornecedores) e que o open source muitas vezes depende de privilégio, financiamento público ou patrocínio coordenado.

X11, Wayland e polimento da área de trabalho

  • Alguns culpam o legado cliente/servidor do X11 pelo atraso da área de trabalho Linux; outros argumentam que o X foi bem-sucedido e que o Wayland levou muitos anos e ainda tem lacunas.
  • Relatos em primeira mão dizem que o Wayland moderno parece mais suave, mais responsivo e mais seguro (sem tearing, melhor composição, telas de bloqueio mais seguras).
  • Comparações de GNOME, KDE e outros ambientes em termos de “polimento” versus configurabilidade, e debates sobre o tratamento de DPI no Windows/macOS.

Queixas sobre o design de UI

  • Desagrado por colocar widgets na barra de título: áreas de arrasto inconsistentes, menos espaço para títulos, percebido como uma tendência do GNOME/GTK (embora alguns deem crédito ao Chrome).

Responsabilidades da GPU

  • Breve سؤال sobre por que as GPUs não “assumem simplesmente” o escalonamento/anti-aliasing; a resposta é que GPUs são de baixo nível, então os toolkits precisam gerenciar a política e os detalhes de renderização.