Nuevos renderizadores para GTK

Artículo original ↗ Discusión en Hacker News ↗

Los nuevos renderizadores de GTK acelerados por GPU despiertan tanto entusiasmo como escepticismo, y muchos celebran funciones largamente esperadas como el escalado fraccional adecuado, un mejor manejo del color y la posibilidad de renderizar fuera del hilo principal, mientras que otros temen regresiones de rendimiento en hardware antiguo. Los comentaristas contrastan la evolución arquitectónica de GTK con alternativas como Qt, los motores de juego y enfoques basados en la web como Broadway, debatiendo los compromisos entre corrección, velocidad, accesibilidad y renderizado de texto. El hilo también se amplía hacia preguntas sobre gobernanza y financiación del ecosistema, argumentando que la brecha entre técnicas gráficas de vanguardia y toolkits de escritorio de código abierto depende tanto de recursos y prioridades como de dificultad técnica.

Broadway y “GTK en el navegador”

  • Varios comentarios recuerdan Broadway, el backend web de GTK que renderiza aplicaciones en un lienzo HTML5.
  • Se lo elogia como “artesanal” y todavía se usa en herramientas como Cambalache y en configuraciones de “GUI en el navegador” basadas en Docker.
  • Otros subrayan que no es una verdadera interfaz HTML: transmite píxeles como VNC, con mal desplazamiento, entrada de texto, manejo de enlaces y accesibilidad deficientes.
  • Se compara y contrasta con verdaderas UIs web (por ejemplo, la de qBittorrent) y con experimentos más recientes de Wayland en el navegador.

UIs declarativas / semánticas y TUIs

  • Algunos desean una descripción de interfaz totalmente semántica y de alto nivel (“vista lista-detalle”, “editor CRUD”) que se asigne automáticamente a widgets nativos y que también pueda generar interfaces de terminal.
  • Sistemas existentes como XAML, SwiftUI y QML se ven como demasiado ligados a la presentación (rectángulos, márgenes) en lugar de a la estructura pura.

Nuevos renderizadores de GTK y escalado fraccional

  • Entusiasmo por el escalado fraccional pixel-perfect y por renderizadores unificados Vulkan/GL, vistos como algo largamente necesario para alcanzar la paridad con Qt y otras plataformas.
  • Narrativas contrapuestas:
    • Los críticos dicen que GTK/ el liderazgo de GNOME bloquearon durante mucho tiempo el escalado fraccional y funciones como las miniaturas del selector de archivos mientras las llamaban “imposibles”.
    • Otros responden que eso requería refactorizaciones profundas del backend, deprecaciones y cuidado con los downstreams; “imposible” en realidad quería decir “no viable con la arquitectura القديمة”.
  • Técnicamente, ahora el renderizado se hace a la resolución final escalada en lugar de renderizar a 2× y luego dejar que el compositor reduzca la escala.

Compromisos de rendimiento

  • Algunos usuarios con hardware antiguo temen regresiones y quieren funciones que puedan desactivar.
  • Se observa que el renderizador Vulkan actualmente solo iguala, no supera, el rendimiento del antiguo GL; se sospecha que el cuello de botella está más arriba en la pila.
  • Quienes lo defienden destacan beneficios más allá de la velocidad bruta: corrección del color (incluido HDR), renderizado de texto/grafos por GPU, renderizado fuera del hilo principal y potencial futuro de optimización.

Motores de juego vs toolkits de GUI y financiación

  • Aparece la afirmación de que los desarrolladores de gráficos para juegos están “generaciones por delante”, pero no pueden permitirse trabajar en FOSS; otros la consideran irrealista o similar a una extorsión.
  • Fuerte rechazo: los renderizadores de GUI deben manejar shaping de texto, accesibilidad, impresión, PDF/SVG e integración con el sistema operativo; requisitos que los motores de juego generalmente ignoran.
  • Reflexión más amplia sobre que gran parte del trabajo sustancial en FOSS ya está pagado (por ejemplo, por proveedores) y que el open source a menudo depende del privilegio, la financiación pública o el patrocinio coordinado.

X11, Wayland y pulido del escritorio

  • Algunos culpan al legado cliente/servidor de X11 de que el escritorio Linux vaya rezagado; otros argumentan que X fue exitoso y que Wayland ha tardado muchos años y aún tiene carencias.
  • Informes de primera mano dicen que el Wayland moderno se siente más fluido, más responsivo y más seguro (sin tearing, mejor composición, pantallas de bloqueo más seguras).
  • Comparaciones de GNOME, KDE y otros entornos de escritorio en términos de “pulido” frente a configurabilidad, y debates sobre el manejo de DPI en Windows/macOS.

Quejas sobre el diseño de la UI

  • Desagrado por poner widgets en la barra de título: áreas de arrastre inconsistentes, menos espacio para títulos y percepción de que es una tendencia de GNOME/GTK (aunque algunos atribuyen esto a Chrome).

Responsabilidades de la GPU

  • Breve pregunta sobre por qué las GPUs no “se encargan simplemente” del escalado/anti-aliasing; la respuesta es que las GPUs son de bajo nivel, así que los toolkits deben gestionar la política y los detalles de renderizado.