Persistent tearing in emacs
Hopefully this is a OK place to report bugs. I remember there was a github issue collecting graphic issues but I couldn't find it somehow...
System information
- Kernel version: 6.12.10-asahi-2-1-ARCH
- Mesa version: 20241211 tag
- Desktop manager and compositor: kwin 6.2.4
- Hardware: MBA M1, 16GB
Describe the issue
I have an emacs configuration with a translucent background (alpha 80 I believe). And while it usually works well initially, over time the window would not refresh correctly anymore. After/during scrolling, block of window area would start to display content from a different part of the file that was previously shown. Moving the affected area in/out of view doesn't always help. OTOH, highlighting the area would usually trigger a sufficient refresh to have the content correctly shown.
Below is an example using the MAINTAINERS file from the kernel. (emacs is running under xwayland and all what I did to trigger it is scrolling up and down as well as selecting(highlighting) some text).
First the affected version
which might not look like much other than a small glitch on the third line but in fact the correct content should've been the following.
. As you can see, a lot of the content is actually completely BS..... (edit: I think I clipped one more line for the second screenshot but the point still stand...)
I do have blurring effect on in kwin (it was off by default initially). It's been a long time but I think the part of my emacs configuration responsible for the transparency and bluring is
(set-frame-parameter (selected-frame) 'alpha '(80 80))
(shell-command
(concat "xprop -f _KDE_NET_WM_BLUR_BEHIND_REGION 32c "
"-set _KDE_NET_WM_BLUR_BEHIND_REGION 0 -id "
(frame-parameter (selected-frame) 'outer-window-id)))
(add-to-list 'default-frame-alist '(alpha 80 80))Regression
This is an issue that was affecting me ever since a very early version of the GPU driver. It briefly disappeared for one version (I believe around when https://asahilinux.org/2023/03/road-to-vulkan/ was published) but all of the versions (kernel + mesa) since that I've tested are affected. I thought this might be because I've been using an old version of firmware (I didn't upgrade my macos installation for a long time) but updating the macos version didn't help. I've also tested this on both X11 and wayland and the behavior is basically the same.
Activity
Actually, looking at the files loaded by emacs I believe it's probably using X protocol for rendering. That checks out with it using X protocol for input method interaction.... In any case, at least it DOES reproduce under xwayland....
I've created a trace with xtrace though I don't really want to upload it publicly (and it's also 72MB large...).
What toolkit are you using for Emacs? I've personally noticed some strange graphical issue of this nature on my end and have tried compiling Emacs with several different toolkits and observing the results of my day-to-day editing while using KDE Plasma 6 + Wayland on my M1 Macbook Air.
- Pure GTK appears to work flawlessly, haven't seen any graphical issues
- Athena (aka Lucid) toolkit produces graphical artefacts extremely frequently to the extent that it is borderline unusable
- Motif
occasionally produces graphical artefacts, however this appears to happen less frequently than with the Athena toolkit- Actually, after going back and checking Motif again after writing this comment, it seems to be pretty much just as bad as Athena. Not sure if I was just getting lucky before or what. With this knowledge, it most likely is an xwayland thing.
Anecdotally, I've noticed that issues seem most likely to arise when you create a wrapped line and then cause a change to the file which moves that line downwards and then upwards visually, such as adding and then deleting a newline somewhere before that line. With the Athena toolkit, this almost always causes strange graphical artefacts in the space left by the moved line and/or the wrapped portion of the line. Here is an example I intentionally created with the Athena toolkit using this method in just two attempts:
Edited by OpenSauce-
Here is more extreme example of an artefact I encountered when I was editing with Athena while waiting for Emacs to recompile with a different toolkit:
Edited by OpenSauce
