Improving cursor rendering on Wayland

Original Article ↗ Hacker News Discussion ↗

Efforts to modernize mouse cursor rendering on Linux’s Wayland display system are prompting debate over formats, performance, and who should control the cursor pipeline. One camp backs Hyprland’s new “hyprcursor” vector-based theme format and the wp_cursor_shape protocol as more flexible and space‑efficient than legacy XCursor bitmaps, while others worry about added complexity, bespoke config languages, and fragmentation if major toolkits like GTK and compositors such as GNOME’s Mutter don’t adopt them. The exchange also surfaces broader tensions in the Wayland ecosystem around minimal core protocols, reliance on extensions, and the influence of large corporate contributors on standards and interoperability.

Storage, Size, and “Wasting Space”

  • Some argue XCursor themes taking megabytes on disk is irrelevant in the “TB era” and compression can mitigate it further.
  • Others counter that installer images and live media still have tight size budgets, so bloat matters.
  • There’s a broader tension between “don’t waste effort on micro-optimizations” and “death by a thousand inefficiencies,” with OS and game bloat cited as warnings.

Wayland Cursor Model vs X

  • Original Wayland design has clients provide cursor surfaces, with the compositor just compositing them.
  • Critics find it “insane” that ordinary apps must handle theming, sizing, and rendering instead of just requesting a standard cursor type.
  • The newer wp_cursor_shape protocol lets clients request named cursor shapes, seen as better for most apps while still allowing custom cursors for games and drag-and-drop.

GTK/GNOME and Protocol Adoption

  • Discussion notes GTK as a hold‑out on wp_cursor_shape, though issues/MRs do exist.
  • Some see GNOME as frequently blocking or delaying Wayland extensions; others say consensus-building is slow but necessary and GNOME doesn’t have formal veto power.

Hyprcursor Format and Adoption Concerns

  • Hyprcursor (from the Hyprland ecosystem) is pitched as a superior, vector-capable, modern cursor format.
  • Concerns: dependence on a bespoke config language (Hyprlang), reduced cross-desktop appeal, and risk of yet another incompatible cursor standard.
  • Suggestions include: using a common config format (e.g., XDG-style INI), publishing a spec, and providing shims for existing XCursor APIs.

Vector vs Raster and SVG Debates

  • Many like the idea of vector cursors for high DPI, but worry full SVG is overkill: complex, heavy dependencies, even scripting support.
  • Some advocate a simpler dedicated vector format (e.g., citing Haiku’s icon format) or a constrained SVG subset.

Broader Wayland Design & Governance Issues

  • Wayland’s “minimal core, everything as extensions” is praised in theory but criticized for fragmentation when compositors can’t agree on extensions.
  • There’s recurring debate over client-side vs server-side decorations, with arguments about synchronization, VRAM use, and UI consistency.
  • Speculation about corporate (especially enterprise vendor) influence appears, but others rebut conspiracy theories and emphasize diverse contributors and real technical constraints.

Miscellaneous

  • Requests appear for features like color-inverting cursors, noting past patent concerns but likely expiration.
  • Some comment that this all feels like re-solving long-standing Xorg problems instead of building on them.