GTK: Introducing Graphics Offload

Platform / OS Support

• Current graphics offload only works on Wayland on Linux with dmabuf-based content.
• macOS and Windows have roughly equivalent primitives (IOSurface on macOS, Direct3D shared handles on Windows), but GTK doesn’t yet wire them up; maintainers say it’s “just work” and time is the main blocker.
• The Wayland tearing-control protocol exists; some argue it’s not yet as convenient as X11’s global TearFree toggle.

GTK’s Direction and Cross‑Platform Role

• Several commenters see GTK becoming increasingly Linux/Wayland‑centric and less viable as a cross‑platform “native” toolkit; some apps have moved to Qt.
• Others argue GTK was always primarily Linux/X11‑first, and non‑GNOME environments historically contributed little upstream, so GNOME’s needs now define the roadmap.
• There is disagreement over whether GNOME “killed” an OS‑neutral GTK or simply evolved it.

Wayland vs X11

• Supporters: Wayland’s design (subsurfaces, dmabuf, overlay planes) makes zero‑copy / direct scan‑out relatively straightforward and secure, and compositor‑based rendering eliminates tearing by default.
• Skeptics: X11 already had concepts like Xv overlays, DGA, etc., and this feels like “reinventing the wheel,” though others respond that X never actually delivered the same thing under compositing or for arbitrary GPU formats.
• Security debate: one side stresses X11’s fundamental lack of isolation between clients and long history of exploitable parsing bugs; the other side claims such issues are largely theoretical for typical desktop users.

How Graphics Offload Works

• GTK 4 already renders via GL to GPU textures backed by dmabufs; offload simply lets GTK attach a child widget to a Wayland subsurface so the compositor can map that buffer directly to a hardware plane.
• Benefit: lower power and CPU/GPU usage for things like video, webcams, and emulator output by avoiding extra compositing work.
• Several developers clarify that pixels are not copied back to main memory; this is all GPU‑side.

Rounded Corners and UI Trade‑offs

• Rounded window corners interfere with direct scan‑out because clipping currently happens in the client, not the compositor.
• Workarounds include letterboxing (black bars) so the video itself is rectangular, or forgoing rounded corners for offloaded content.
• Some see rounded corners and heavy effects as needless performance tax; others consider them non‑negotiable UX polish as long as the overhead is modest.

Compositors, Latency, and Tearing

• Compositors enable effects (transparency, zoom, overviews) and no‑tearing, but add latency.
• Some users prefer tearing and immediate front‑buffer writes for text editing or gaming responsiveness; others argue that, given human reaction times and modern refresh rates, the marginal latency gains are minor versus the visual artifacts.
• There’s disagreement on how noticeable tens of milliseconds of latency are in everyday editing and coding.

Ecosystem Coordination and History

• Multiple references to freedesktop/Wayland hackfests and Linux conferences indicate that kernel, compositor, and toolkit developers already coordinate on requirements.
• Comparisons are drawn to BeOS/Haiku and SunView, which had early direct‑framebuffer and shared‑buffer models; some praise their smoothness, others note they lacked features, security, and GPU‑centric designs expected today.

OpenGL vs Vulkan and GTK Internals

• GTK 4 moved from immediate‑mode Cairo/X11 assumptions to a scene‑graph (GSK) and a Wayland‑like model, significantly simplifying backends and enabling features like threaded/tiled renderers in the future.
• Current accelerated rendering is GL‑based with dmabufs; there is a Vulkan renderer but it’s less mature and needs contributors.
• Some call GL “legacy bloat” relative to Vulkan; others point out GL implementations are still maintained and practical for toolkits.