[sph]

https://github.com/tanrax/emacs-gpu/blob/main/.github/assets...

This massive speed-up on 4K screens makes me want to try it. The wayland pgtk version has such terrible latency I have to use the X11 build to avoid gnashing teeth during my working hours. And I think it's the X11 version that uses cairo, so the actual speedup in my case might be even larger.

I reported the issue years ago, the pgtk maintainer confirmed, say they can't do much as they're using GTK3 which isn't hardware accelerated, so I have to wait until they migrate to GTK4 (in a decade or so). A bit disappointing, but that's open source.

Looks like I'm not the only one suffering with a 4K screen: https://old.reddit.com/r/emacs/comments/ucv0at/awful_perform...

[andros]

Good news on the Wayland front: there is already a working branch (wayland-pgtk-backend) that adds a PGTK binding on top of the same EGL/GLES driver, pending merge to main. If you want to try it before that, the branch is available on the repo.

[zeendo]

I can't find that branch here - https://cgit.git.savannah.gnu.org/cgit/emacs.git

Am I looking in the wrong place?

[stebalien]

https://github.com/tanrax/emacs-gpu/tree/wayland-pgtk-backen...

The main emacs-gpu branch doesn't have wayland support.

[zeendo]

Oh thanks! I thought they meant this was going on in the real emacs man.

[panza]

My experience with Emacs, 4K and Wayland was so abysmal that I spent a weekend making my config fully compatible with a terminal.

Not ideal, but I'll keep running it through Ghostty until it's fixed.

[adrian_b]

I have been using only 4k monitors in Linux, with X11 (and XFCE) for more than a decade.

During the years, I have used a great number of text editors, e.g. vim, jedit, kate, geany, Visual Studio Code, neovim, etc.

Only this year I have switched to emacs, because it is more suitable for certain customizations that I prefer (for scripting, I like more Emacs Lisp than alternatives like Lua).

I have seen no performance problems (in GUI mode, I do not use it under a terminal emulator). On my hardware (with NVIDIA GPU) it is at least as fast as any other text editor that I had been using. Certainly much faster than Visual Studio Code.

As a terminal emulator I am now using ghostty, after previously using kitty and many other terminal emulators more distantly in the past, so GUI performance is important for me.

Ghostty seems faster than Emacs, so I believe that switching to GPU text rendering could accelerate Emacs, but for a significant speedup a more complete redesign of the graphics output would be necessary than in the parent article.

The problem is that this might be easy only when targeting a single GUI environment, but that would be in contradiction with the original Emacs goal, to be usable under many operating systems and GUI environments.

[aboardRat4]

Just switch to X11. Wayland is never going to work.

[sph]

Use the x11 build. It’s night and day

[arikrahman]

I didn't notice to much performance issue switching to PGTK on an ultrawide on Niri. Are you using the daemon to render Emacs as a client?

[zeendo]

I have perf issues with emacs-pgtk on a 4k screen on Wayland with Niri in both Emacs as a client and not. The issues appear with typing or scolling, the delay and lag become noticeable.

For me the issue is only unbearable when running fractional scaling, for some reason.

I'm going to try the branch mentioned in the sibling comment, though.

[arikrahman]

I have almost the exact same setup as you and even have strange behavior with fractional scrolling. I'm on NixOS so the setup is even inspectable: https://codeberg.org/arik/dotfiles

After resetting the scale from 1.2 to 1.0 through 'niri msg output HDMI-A-2 scale 1' I actually noticed a performance increase! I will have to troubleshoot this, although you may have stumbled on a great lead toward the root cause.

[amritananda]

Also on Niri with fractional scaling and pgtk. IIRC the issue here is that for programs that don't support wp_fractional_scale, compositors deal with this by rendering at the next highest integer factor, and downscaling it down to achieve the desired factor. This is much, much worse for Emacs since it uses GTK3 and doesn't support hardware acceleration with Cairo, at least according to Po Lu [1] so you're effectively rendering via CPU at a very high resolution.

For XWayland apps Niri just renders at the native resolution (ignoring scaling), meaning a decent workaround is to use the Lucid/non-pgtk version and manually scaling up the UI. Unfortunately I go from scaling at 1.25 on my screen to 1.00 on my external monitors, which means I can't use the non-Wayland versions without messing up the font size on either my desktop and monitor.

[1] https://mail.gnu.org/archive/html/bug-gnu-emacs/2024-09/msg0...

[green7ea]

I'm also on Emacs and Niri, seems to be a popular combo, and I don't have any performance problem.

At home I'm driving an Ultrawide (3440x1440@75Hz) at scale 1.1.

At work I'm driving two 4k screens at scale 1.2.

I might be less sensitive to latency but it could also be a graphics driver issue or something similar. I'm using Arch with emacs-wayland (pgtk) with a strix halo (all AMD) laptop.

[amritananda]

It might also just be the case that the hardware you have is good enough that the lag isn't noticable.

You should still be able to notice a spike in CPU usage whenever you force Emacs to redraw the frame by typing into it though.

[zeendo]

I didn't invent this mitigation FWIW - I saw it mentioned in one or another thread about this by someone else - possibly on the big reddit thread on this topic, not sure.

[aboardRat4]

Just switch to xlibre.

Wayland is a dead end.