Ancient X11 scaling technology

Original Article ↗ Hacker News Discussion ↗

X11 vs Wayland: What’s Actually Possible

  • Several commenters say the post “proves” something nobody serious ever denied: X11 has long exposed physical display size/DPI (via RandR) and you can render at whatever resolution you want, including over the network.
  • The hard part is not getting DPI but building a full scaling ecosystem: dynamic per‑display scaling, mixed‑DPI multi‑monitor, hairline crispness, protocol semantics, and toolkit support.
  • Some argue many of these could have been added to X11 with more extensions or an “X12”; others say the community instead chose to clean up the stack around DRM/Mesa and start fresh with Wayland, similar to Python 2→3.

Fractional Scaling & Mixed DPI

  • Major pain point: multi‑monitor setups with different DPIs. Many report that X11 still handles this poorly in 2025; others say it “could” work but toolkits and DEs never did the work.
  • Debate over two approaches:
    • “Proper” per‑output scaling with clients rendering at target scale factors (Wayland fractional-scale protocol, Qt/GTK support).
    • The “2x then scale down” Retina-style approach that introduces blur and overhead but simplifies legacy support.
  • Some insist fractional scaling is fundamentally flawed and unnecessary; others counter that font/vector rendering and careful snapping to pixels make it good enough in practice.

DPI vs Scale Factor UX

  • Long subthread on whether users should think in absolute DPI (or PPI/PPD) vs relative scale factors (100–400%).
  • Pro‑DPI side: absolute metric would make matching sizes across displays trivial and predictable.
  • Pro‑scale side: people care about “how big it looks” (distance, eyesight, preference), not inches; DPI reporting is often wrong; UI sliders with percentages are more approachable. Some suggest UI could expose DPI‑like semantics while protocols/toolkits keep using scale factors.

Toolkits, Protocols, and Compatibility

  • X11 core drawing APIs are pixel‑centric; modern toolkits mostly bypass them using Cairo/Skia/OpenGL and upload buffers to X, which weakens arguments about “X can’t draw circles” but also undercuts the post’s claim of using “X11 scaling” (it’s really GL paths).
  • Wayland initially only had integer scale; fractional scaling is a later protocol extension that must be explicitly supported by compositors and toolkits, leading to mixed behavior and blurry XWayland apps.
  • Windows and macOS are cited as examples: both rely on app/toolkit cooperation and opt‑in DPI awareness, with varying degrees of legacy blur and redraw jank.

User Experiences and Desktop Preferences

  • Strongly divergent anecdotes:
    • Some say Wayland sessions (especially on new hardware) are clearly more polished, with less “jank” and better multi‑monitor behavior.
    • Others stick to X11 because Wayland sessions feel buggy, lack favorite DEs (Unity, ROX, LXDE‑style, CDE clones), or break workflows (window placement persistence, special tiling setups).
  • One view: Wayland “solves” problems by dropping old features and forcing new patterns; another: X11’s complexity and bolt‑ons doomed it, and Wayland finally aligns with how toolkits already render.

Remote Rendering, GLX, and Network Transparency

  • Several participants defend X11’s SSH‑forwarded UX as still very useful on LANs and in thin‑client or scientific setups, even if laggy on bad links.
  • Others note X11’s protocol is extremely chatty; modern remote protocols and things like Waypipe (Wayland‑to‑Wayland) are considered more appropriate going forward, though lacking X11’s universality and ssh integration.
  • There’s clarification that the article’s OpenGL example is effectively sending pixmaps, not exercising X11’s original vector drawing model.

Tearing, Performance, and “Real” Issues

  • Disagreement over how serious X11 tearing is: some barely notice or fix it with TearFree options; others report chronic tearing that “just went away” under Wayland.
  • Critics argue many Wayland wins (no tearing, better scaling) could have been achieved via config changes or modest X11 work; defenders reply that fundamental design (compositor model, DPI virtualization, input semantics) made a new protocol the more sustainable path.

Historical and Conceptual Context

  • NeWS/PostScript and Cairo are referenced as examples of truly device‑independent, vector‑oriented models that sidestep many pixel‑grid issues, highlighting that both X11 and Wayland still operate on pixel buffers.
  • Some lament that, in 2025, Linux still struggles with what older systems or printers solved via resolution‑independent rendering, and that much debate is about microscopic visual differences invisible to most users.