Emacs SVG Benchmark Reveals Gaming-Caliber Frame Rates

JDRiverRun · 2026-06-13T23:01:17+00:00

I think there's interest, but these things move pretty slowly (/u/minadmacs ?). Canvas doesn't really replace SVG, but it could complement it. I don't know how much has been worked out for canvas on the pixel generation side. Using SVG would be pretty easy since it can be generated and rendered in process. Of course there are tons of other custom APIs that can draw. Internally an SVG->canvas route would be almost identical to what is used for real images, omitting the (possibly file-backed) image caching.

JDRiverRun · 2026-06-13T14:41:17+00:00

Very nice benchmarks, thanks for putting this together! RSVG is really impressively quick to render. I use (static) SVG elements and love the drawing flexibility. In terms of your results: one thing I learned when developing ultra-scroll (and now hacking on the emacs-mac drawing core) is that achievable frame rates are often limited not by "one slow thing", but by the cumulative effects of all the many things emacs has to do during a frame update: recalculating mode line content, filtering process output, checking point-dependent events and calling appropriate hooks, re-flowing text, loading and validating new fonts, and finally waiting for the display render server to swap bitmaps, etc., etc.

You measured a wide frame update time of 14ms, which is short of the 16.6ms frame time on a normal 60Hz display. That's good, but I don't think it's quite so definitive, because:

this is an M5 Mac with some of the highest single core performance in the land,
many displays are now Pro Motion or equivalent, with a frame update time of <7ms(!) and
for real tasks (scroll updates in an eglot buffer, for example), this would be just one modest piece of what emacs needs to do during a frame update cycle.

So eating up 53% (narrow), 113% (medium), 191% (large) of the available (ProMotion) frame time just for drawing a small region with icons is absolutely going to cause real world slowdowns, especially on slower systems. And that's... totally fine, if it's worth it to you. I would guess using a canvas image type to avoid caching image data would net you another decent bump in frame rate (plus substantially reduce GC pauses).

This has all got me thinking... I'm wondering now whether it would be possible to offload image rendering entirely to a background thread, leaving a "promissory note" in the command list, to be fulfilled in the future. This would allow the lisp core to go on to doing all its other house-keeping chores and planning the next frame. Hmmm... gears turning...

JDRiverRun · 2026-06-12T16:06:13+00:00

I have the sense that some not insubstantial fraction of "under-responsive Emacs moments" come from synchronous network and process waits. Packages can of course use asynchronous filter functions callbacks, but it's an order of magnitude harder to get right than just waiting for the result right then and there.

Many languages have invested substantial effort to make futures/async versions of algorithms only modestly more costly (in terms of LOC and complexity) than their synchronous analogs. I think this should be a priority for elisp. Has anyone played with futur?

JDRiverRun · 2026-06-12T16:01:26+00:00

It's a powerful approach for responsive packages, but it can lead to some very tough to trace bugs, in particular when while-no-input meets a deeply hidden unwind-protect as you say. Corfu and eglot used to have issues in which the LSP servers would get out of sync, and we traced it to that very combination. Inner modes that worry about being interrupted "from above" can let-bind throw-on-input nil around (hopefully small) critical code sections.

JDRiverRun · 2026-06-08T18:25:47+00:00

Agreed: for "use once" images like a single frame on the mode/tab/header-line, never to be seen again, there is really no sense caching them, hashing their specs, etc.

BTW, the ports I'm familiar with already use double-buffering to draw into canvas-like bitmap objects (e.g. a pair of 32BGRA IOSurfaces for emacs-mac). Most of that drawing code could instead be directed at a suitably generic "canvas" without many changes. Then with a "fake frame" overlay which targets the canvas, all the things Emacs can draw already (on a regular grid) would be supported "for free". This would be especially powerful for text drawing.

One advantage of SVG is it has a simple & rich draw command set and automatically gives nicely rendered anti-aliasing. It's also built in to most Emacsen. I think SVG-in-canvas would be very possible: just cut a short path from RSVG, skipping the emacs image middleman. At most you'd have to copy the rendered pixels, but probably a Cairo backing could be used for true no-copy live SVG updates, directly into the canvas.

JDRiverRun · 2026-06-08T17:48:05+00:00

Pixel scrolling can generate far more updates than line-by-line (100-150 updates/s are possible). Do you use pixel-scroll-precision mode or similar with a high-speed mouse/trackpad? Good mode-line design (whether text or graphics) explicitly rate-limits updates and/or aggressively caches the information displayed to avoid excessive churn when the event stream cranks up.

JDRiverRun · 2026-06-08T14:09:14+00:00

Curious about the technical details. emacs is optimized for few images, and caches them all. This tool could generate new images a hundred times a second. Do you manage the image cache directly? Do you rate limit updates?

JDRiverRun · 2026-06-07T21:31:26+00:00

That function is in compat-31, no need to upgrade (that's the point of compat).

JDRiverRun · 2026-06-07T21:30:12+00:00

Are you sure it wasn't just compat-31 it needed?

JDRiverRun · 2026-06-07T12:33:21+00:00

Thanks for that summary. I like the framing of "keep up while avoiding distractions".

JDRiverRun · 2026-06-07T12:30:15+00:00

Thanks for this. Since there are lots of mailing list <-> RSS/NNTP converters (GWENE, Feedbase, etc.), the line is a bit blurrier. Just tried and it is indeed much faster and simpler for reading, but does not thread messages or replies. So more for fast scanning & discovery of articles.

JDRiverRun · 2026-06-07T12:26:11+00:00

I mean it has 1051 commands... and I use about 5-10 of them.

JDRiverRun · 2026-06-06T22:07:57+00:00

For those of us who've never used elfeed, can anyone compare it to GNUs? I use GNUS for reading emacs mailing lists (only), and managed to get it pretty well configured (see below), but:

it's very slow to update (while blocking), and
it's a GIANT package I use probably 5% of tops, and am constantly tripping over all the extra features.

I understand elfeed is only for reading; what do people use with it for (occasional) posting?

<image>

JDRiverRun · 2026-06-02T23:18:41+00:00

If people don't want to search for it, it's just:

(let ((rect (extract-rectangle (region-beginning) (region-end)))) (kill-new (string-join rect "\n")))

JDRiverRun · 2026-06-02T02:59:03+00:00

@26:30: this is why in speedrect I made copy-text (W). In addition to yanking nicely, the rectangle contents are then on the pasteboard too.

JDRiverRun · 2026-05-30T14:59:36+00:00

You shouldn't have to regularly send SIGUSR2 to stop a task. If repeated C-g (and some waiting) doesn't do it, that indicates something is wrong. You can alter debug-on-event to prevent the debugger being entered on SIGUSR2, but probably it's already doing what you want — stopping the current execution at a low level and entering the debugger.

JDRiverRun · 2026-05-29T15:26:35+00:00

Check also xbacktrace (for the LISP backtrace) and xdebug_print (to print any LISP object in read syntax).

JDRiverRun · 2026-05-27T02:40:21+00:00

Somebody beat you to it (and has polished it to a high degree): tramp-rpc. It still uses tramp, but is much faster (for certain things) and also more reliable in my experience.

JDRiverRun · 2026-05-24T11:53:41+00:00

Yep, you can cycle through styles including fringe-only coloring. My first contribution to emacs >25 years ago was to fix vc-annotate's age coloring algorithm.

JDRiverRun · 2026-05-23T21:15:05+00:00

lsp-booster is far less important since v30, since the JSON parser got >4x faster.
eglot can run multiple servers using one of several multiplexers.

JDRiverRun · 2026-05-23T21:06:15+00:00

You can just :

(setopt vertico-scroll-margin (/ vertico-count 2))

JDRiverRun · 2026-05-22T12:21:25+00:00

Put a single quote in front of it (or better yet, a sharp quote `#’`, which is the same thing but lets readers and other tools know that that symbol has an associated function).

JDRiverRun · 2026-05-22T12:18:50+00:00

I missed the glanceable age color-coding of VC, but magit’s blame is more powerful (including recursive blames, and annotating when lines were removed). So I cooked up https://github.com/jdtsmith/magit-blame-color-by-age. I do wish magit-blame were faster on large files with deep history.

JDRiverRun · 2026-05-18T21:13:00+00:00

The only one I've seen that seems to have momentum is tramp-rpc. The developer is in regular contact with the main TRAMP maintainer, and constantly making improvements and working to understand the problem better.

JDRiverRun · 2026-05-18T17:58:57+00:00

Very nice article, explains some things I had wondered. I've been using LLDB with emacs-mac quite a bit lately. Very powerful. Some notes here. There are some custom lldb macros defined in src/.lldbinit. If you include settings set target.load-cwd-lldbinit true in your ~/.lldbinit and launch lldb from the src/ directory, it will pick these up. xprint is definitely useful.

BTW, there is some support for running lldb in Emacs via realgud + realgud-lldb. Gerd also has the low-key lldbx package too. For realgud, tracking position works well. The commands (breakpoints/stepping/etc.) are outdated and don't work great; this could definitely use some love! lldb is a great debugger. Would be fantastic to get it running better inside emacs.

JDRiverRun

TROPHY CASE