New Renderers for GTK

Original Article ↗ Hacker News Discussion ↗

GTK’s new GPU-backed renderers spark both excitement and skepticism, with many welcoming long-awaited features like proper fractional scaling, better color handling, and the potential for off-main-thread rendering, while others worry about performance regressions on older hardware. Commenters contrast GTK’s architectural evolution with alternatives such as Qt, game engines, and web-based approaches like Broadway, debating trade-offs around correctness, speed, accessibility, and text rendering. The thread also broadens into questions of ecosystem governance and funding, arguing that the gap between cutting-edge graphics techniques and open-source desktop toolkits is as much about resources and priorities as it is about technical difficulty.

Broadway and “GTK in the browser”

  • Multiple comments recall Broadway, GTK’s web backend that renders apps into an HTML5 canvas.
  • It’s praised as “artisanal” and still used in tools like Cambalache and in Docker-based “GUI-in-browser” setups.
  • Others stress it is not a real HTML UI: it streams pixels like VNC, with poor scrolling, text input, link handling, and accessibility.
  • Compared and contrasted with true web UIs (e.g., qBittorrent’s) and newer Wayland-in-browser experiments.

Declarative / semantic UIs and TUIs

  • Some wish for a fully semantic, high-level UI description (“list-detail view”, “CRUD editor”) that auto-maps to native widgets and can also generate terminal UIs.
  • Existing systems like XAML, SwiftUI, QML are seen as too tied to presentation (rectangles, margins) rather than pure structure.

New GTK renderers & fractional scaling

  • Excitement around pixel-perfect fractional scaling and unified Vulkan/GL renderers, seen as long-needed parity with Qt and other platforms.
  • Conflicting narratives:
    • Critics say GTK/ GNOME leadership long blocked fractional scaling and features like file-chooser thumbnails while calling them “impossible”.
    • Others counter that these needed deep backend refactors, deprecations, and care for downstreams; “impossible” really meant “not feasible with old architecture”.
  • Technically, rendering is now done at the final scaled resolution instead of rendering at 2× then compositor-downscaling.

Performance tradeoffs

  • Some users on older hardware worry about regressions and want features they can disable.
  • Observations that the Vulkan renderer currently only matches, not exceeds, old GL performance; suspicion the bottleneck is higher in the stack.
  • Defenders highlight benefits beyond raw speed: color correctness (incl. HDR), GPU path/glyph rendering, off-main-thread rendering, and future optimization potential.

Game engines vs GUI toolkits & funding

  • A claim appears that game graphics devs are “generations ahead” but can’t afford to work on FOSS; others call this unrealistic or akin to extortion.
  • Strong pushback: GUI renderers must handle text shaping, accessibility, printing, PDF/SVG, OS integration—requirements game engines generally ignore.
  • Broader reflection that substantial FOSS work is already paid (e.g., by vendors) and that open source often depends on privilege, public funding, or coordinated sponsorship.

X11, Wayland, and desktop polish

  • Some blame X11’s client/server legacy for Linux desktop lagging; others argue X was successful and Wayland has taken many years and still has gaps.
  • First-hand reports that modern Wayland feels smoother, more responsive, and more secure (no tearing, better compositing, safer lock screens).
  • Comparisons of GNOME, KDE, and other DEs in terms of “polish” vs configurability, and debates over Windows/macOS DPI handling.

UI design complaints

  • Dislike for putting widgets in the titlebar: inconsistent drag areas, less room for titles, perceived as a GNOME/GTK trend (though some credit Chrome).

GPU responsibilities

  • Brief question why GPUs don’t “just handle” scaling/anti-aliasing; answer is that GPUs are low-level, so toolkits must manage policy and rendering details.