HN Debrief

I built a GPU back end for Emacs

  • Programming
  • Open Source
  • Developer Tools
  • Infrastructure
  • AI

The post walks through an experimental GPU backend for GUI Emacs. It keeps Emacs’s existing redisplay logic, then swaps the old CPU-side drawing layer for GPU primitives, using Metal on macOS and OpenGL through EGL on Linux. The author says the code was fully LLM-generated, presents it as a proof of concept rather than upstream-ready work, and shows benchmark screenshots with large gains at 4K. One flashy demo showed YouTube playback inside Emacs, though the author later clarified it was pre-downloaded with ffmpeg rather than true streaming.

If you run Emacs on 4K or scaled Wayland setups, this is worth tracking even if it never merges upstream because it points to a real path out of current redraw and latency problems. More broadly, it is a concrete example of using LLM-generated code to de-risk a systems-level prototype, then deciding later whether the idea deserves a clean rewrite.

Discussion mood

Strongly positive about the technical result and excited by the performance potential, especially for 4K and Wayland users. The irritation was mostly aimed at Emacs and GNU process, plus a side argument over AI-generated code and AI-smelling prose.

Key insights

  1. 01

    Wayland scaling looks like the real pain point

    High-resolution Wayland users treated the benchmark numbers as confirmation of a problem they already feel every day. The sharpest clue was that fractional scaling appears to make Emacs PGTK latency much worse, which points to the current rendering stack doing extra expensive work before any GPU backend even enters the picture. The author’s note about a PGTK branch on top of the same EGL and GLES driver turns that from a complaint into an actionable test path.

    If your team standardizes on Linux laptops with 4K displays, test editor performance under fractional scaling instead of assuming complaints are subjective. A rendering rewrite may buy more than tweaking packages or dotfiles.

      Attribution:
    • sph #1
    • andros #1
    • zeendo #1
    • arikrahman #1
    • panza #1
  2. 02

    LLMs were treated as a design probe

    People did not praise the generated code as something to merge unchanged. They praised using it to answer a hard systems question quickly. That framing is important because it separates "can this architecture work" from "is this the final implementation," which is exactly where LLMs can create leverage without asking maintainers to trust a pile of opaque code forever.

    For risky refactors, use LLM output to validate the shape of the solution and flush out hidden constraints fast. Then decide whether the result earned a manual implementation before you spend weeks polishing it.

      Attribution:
    • arikrahman #1
    • wrs #1
    • jadyoyster #1
  3. 03

    Platform GPU wrappers would not solve Linux

    The suggestion to lean on CoreGraphics, Skia, or Cairo-GL sounds simpler than writing a custom backend, but it misses the portability constraint. The author’s response makes clear that Emacs’s rendering logic was refactored behind a vtable so the same draw model can target multiple platforms, while a macOS-specific acceleration trick would leave Linux on the old path and add a heavy dependency if Skia or Cairo-GL were pulled in.

    When you evaluate graphics acceleration proposals, check whether they solve one platform elegantly or the whole product awkwardly. Cross-platform apps often need a deeper abstraction change, not just a better library call on the nicest OS.

      Attribution:
    • simscitizen #1
    • andros #1
  4. 04

    Avoiding xdisp.c was part of the win

    The nod to the old "Buttery Smooth Emacs" write-up gives the architectural clue in one line. Emacs redisplay has long been tangled with multiple toolkit-specific implementations and compile-time branches, so progress depends on escaping that mess rather than trying to optimize inside it. This prototype mattered because it showed a cleaner seam exists.

    If a legacy codebase feels impossible to speed up, look for a boundary where you can replace a subsystem wholesale instead of micro-optimizing the worst file in the tree. Finding the right seam can be more valuable than any individual optimization.

      Attribution:
    • internet_points #1
  5. 05

    The project sharpened fork pressure around Emacs

    Some readers saw this as more than a renderer experiment. They saw it as proof that a modernized Emacs, or a compatible fork like Neomacs, could rally contributors by fixing long-standing desktop pain and dropping old constraints. That does not mean a fork will win, but it shows the pressure is no longer just aesthetic. It is tied to concrete usability gaps on modern hardware.

    If you rely on mature open source infrastructure, watch for performance work becoming the trigger for ecosystem splits. Compatibility alone stops being enough once modern hardware support becomes a daily quality-of-life issue.

      Attribution:
    • reinitctxoffset #1
    • joshjob42 #1

Against the grain

  1. 01

    Cursor effects do not require GPU rendering

    The push for shader-driven cursor effects overstates what this backend unlocks by itself. Emacs already has mechanisms like pulse.el, and the missing piece is often editor-side glue and polish rather than GPU primitives. The gap may be productization, not rendering capability.

    Do not assume a new rendering stack automatically delivers visible UX improvements. You still need someone to wire features into editor behavior and make them feel good.

      Attribution:
    • mickeyp #1
    • iLemming #1
  2. 02

    Stallman is not absent from the code

    The broader anti-FSF backlash drifted into caricature. One reply corrected the claim that Stallman has not written Emacs code in decades, pointing to recent commits and a substantial macro addition. That does not answer whether his views on GPUs are useful, but it does undercut the easier story that project inertia comes from total technical irrelevance.

    When governance becomes the story, separate process complaints from inaccurate personal myths. You will make better calls about a project’s future if you know who still has real influence and technical involvement.

      Attribution:
    • salutis #1
    • stackghost #1

In plain english

4K ↩
A high-resolution display format around 3840 by 2160 pixels, which increases rendering workload.
Cairo-GL ↩
A GPU-accelerated backend for the Cairo 2D graphics library.
CoreGraphics ↩
Apple’s 2D drawing framework for rendering text, shapes, and images.
EGL ↩
A cross-platform interface that connects rendering APIs like OpenGL ES to the native window system.
ffmpeg ↩
A popular open source command-line tool for converting, recording, and processing audio and video.
FSF ↩
Free Software Foundation, the organization that sponsors the GNU project and advocates for free software principles.
GLES ↩
OpenGL for Embedded Systems, a streamlined version of OpenGL often used on mobile and lightweight graphics stacks.
GNU ↩
A long-running free software project that develops tools and applications including Emacs.
GPU ↩
Graphics processing unit, a chip designed to perform many graphics and parallel math operations quickly.
LLM ↩
Large language model, an AI system that generates text or code from prompts.
Metal ↩
Apple’s low-level graphics and compute API for macOS and iOS.
OpenGL ↩
A cross-platform graphics API for drawing 2D and 3D content using the GPU.
PGTK ↩
Pure GTK, the Emacs build that uses the GTK toolkit directly on Wayland instead of going through X11.
Skia ↩
An open source 2D graphics library used in products like Chrome for drawing text and shapes.
vtable ↩
Virtual method table, a programming technique for swapping implementations behind a common interface.
Wayland ↩
A modern Linux display server protocol that replaces much of the older X11 graphics stack.

Reference links

Project references

  • emacs-gpu benchmark image for Linux 4K
    Used to point readers at the reported 4K speedup that made the project compelling for latency-sensitive users.
  • Neomacs
    Mentioned as a separate effort to modernize Emacs with Rust and GPU rendering, and as a possible base for a fork path.

Background on Emacs rendering

  • Buttery Smooth Emacs
    Quoted for background on why Emacs redisplay code is notoriously hard to work on and why avoiding xdisp.c matters.
  • Emacs-devel archive message
    Shared to locate the upstream mailing list discussion about the GPU backend proposal.

Related user reports and configs

Other author projects

  • Org Social
    Mentioned as another project by the same author for readers interested in their broader work.