GNU bug report logs -
#79295
[Bug] Artifacts in margin with display-line-numbers-mode (relative)
Previous Next
To reply to this bug, email your comments to 79295 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#79295
; Package
emacs
.
(Sat, 23 Aug 2025 20:59:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Marco <marconeumaier <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 23 Aug 2025 20:59:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Description:
Hi, when using `display-line-numbers-mode` with relative numbering,
scrolling a buffer sometimes produces
colored horizontal lines or dots in the line-number margin.
Steps to reproduce:
1. Start Emacs with GTK.
2. Enable relative line numbers:
(setq display-line-numbers-type 'relative)
(global-display-line-numbers-mode 1)
3. Scroll the buffer up and down.
Observed behavior:
- Horizontal bars or dots appear in the line-number margin while scrolling.
- Artifacts are colored (green/magenta/white on monitor) but screenshots
show them as dark blue.
- Absolute line numbers render correctly without artifacts.
Environment:
- Emacs version: GNU Emacs 30.2 (build 2, x86_64-pc-linux-gnu, GTK+
Version 3.24.41, cairo version 1.18.0) of 2025-08-15
- GTK version: 3.24.41
- OS: Ubuntu 24.04 with Gnome and Wayland
- Theme: Dracula
Additional observations:
- The issue persists with GDK_DEBUG=nogl and GDK_BACKEND=x11.
- Forcing a solid background for 'line-number' and
'line-number-current-line' mitigates the issue:
(set-face-attribute 'line-number nil :background "#282a36"
:foreground "#6272a4")
(set-face-attribute 'line-number-current-line nil :background
"#282a36" :foreground "#f8f8f2")
- Increasing display-line-numbers-width does not affect the artifacts.
Expected behavior:
Line-number margin should update cleanly without leaving visual artifacts.
This appears to be related specifically to the redraw path of relative
line numbers in `display-line-numbers-mode`.
additional useful info:
In GNU Emacs 30.2 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
cairo version 1.18.0) of 2025-08-15 built on lcy02-amd64-116
Repository revision: 32909ac267415e06a8b18a8b89827d7bbf180b58
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12302006
System Description: Ubuntu 24.04.3 LTS
Configured using:
'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3
--without-xaw3d --with-modules --with-cairo
--with-native-compilation=aot --without-pgtk --with-xinput2
--with-tree-sitter 'CFLAGS=-isystem
/build/emacs/parts/emacs/install/usr/include -isystem
/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem
/build/emacs/stage/usr/include -O2' 'CPPFLAGS=-isystem
/build/emacs/parts/emacs/install/usr/include -isystem
/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem
/build/emacs/stage/usr/include'
'LDFLAGS=-L/build/emacs/parts/emacs/install/lib
-L/build/emacs/parts/emacs/install/usr/lib
-L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
-L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu
-L/build/emacs/stage/usr/lib''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LANG: de_DE.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: ELisp/d
Minor modes in effect:
global-company-mode: t
company-mode: t
global-display-line-numbers-mode: t
display-line-numbers-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa epg rfc6068 epg-config gnus-util
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date company-oddmuse company-keywords company-etags
etags fileloop generator xref project company-gtags company-dabbrev-code
company-dabbrev company-files company-clang company-capf company-cmake
company-semantic company-template company-bbdb company pcase sclang
sclang-widgets tree-widget wid-edit sclang-server sclang-help
sclang-help-minor-mode sclang-minor-mode sclang-mode derived sclang-dev
sclang-document sclang-language sclang-interp compile
text-property-search comint ansi-osc ansi-color ring sclang-browser view
sclang-util dracula-theme display-line-numbers use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core finder-inf
site-start comp comp-cstr cl-extra help-mode comp-common warnings rx
company-autoloads dracula-theme-autoloads ement-autoloads
lua-mode-autoloads persist-autoloads plz-autoloads svg-lib-autoloads
taxy-magit-section-autoloads taxy-autoloads info magit-section-autoloads
llama-autoloads package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs icons password-cache json subr-x map byte-opt gv
bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process native-compile emacs)
Memory information:
((conses 16 204139 13238) (symbols 48 14132 0) (strings 32 48749 4819)
(string-bytes 1 1433272) (vectors 16 24295)
(vector-slots 8 289139 15606) (floats 8 93 160)
(intervals 56 993 357) (buffers 992 16))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#79295
; Package
emacs
.
(Sat, 23 Aug 2025 22:22:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 79295 <at> debbugs.gnu.org (full text, mbox):
Hi,
unfortunately the fix ( as suggested by chatGPT) described in the bug
report does not work:
"- Forcing a solid background for 'line-number' and
'line-number-current-line' mitigates the issue:
(set-face-attribute 'line-number nil :background "#282a36"
:foreground "#6272a4")
(set-face-attribute 'line-number-current-line nil :background
"#282a36" :foreground "#f8f8f2")"
The only way to get rid of these artifact pixels is to use absolute line
numbering.
Best,
Marco
Am 23.08.25 um 22:59 schrieb GNU bug Tracking System:
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
> bug-gnu-emacs <at> gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 79295 <at> debbugs.gnu.org.
>
> Please do not send mail to help-debbugs <at> gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#79295
; Package
emacs
.
(Sun, 24 Aug 2025 04:46:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 79295 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 23 Aug 2025 22:18:33 +0200
> From: Marco <marconeumaier <at> gmail.com>
>
> Description:
>
> Hi, when using `display-line-numbers-mode` with relative numbering,
> scrolling a buffer sometimes produces
> colored horizontal lines or dots in the line-number margin.
>
> Steps to reproduce:
> 1. Start Emacs with GTK.
> 2. Enable relative line numbers:
> (setq display-line-numbers-type 'relative)
> (global-display-line-numbers-mode 1)
> 3. Scroll the buffer up and down.
>
> Observed behavior:
> - Horizontal bars or dots appear in the line-number margin while scrolling.
> - Artifacts are colored (green/magenta/white on monitor) but screenshots
> show them as dark blue.
> - Absolute line numbers render correctly without artifacts.
>
> Environment:
> - Emacs version: GNU Emacs 30.2 (build 2, x86_64-pc-linux-gnu, GTK+
> Version 3.24.41, cairo version 1.18.0) of 2025-08-15
>
> - GTK version: 3.24.41
>
> - OS: Ubuntu 24.04 with Gnome and Wayland
>
> - Theme: Dracula
>
> Additional observations:
> - The issue persists with GDK_DEBUG=nogl and GDK_BACKEND=x11.
> - Forcing a solid background for 'line-number' and
> 'line-number-current-line' mitigates the issue:
> (set-face-attribute 'line-number nil :background "#282a36"
> :foreground "#6272a4")
> (set-face-attribute 'line-number-current-line nil :background
> "#282a36" :foreground "#f8f8f2")
> - Increasing display-line-numbers-width does not affect the artifacts.
>
> Expected behavior:
> Line-number margin should update cleanly without leaving visual artifacts.
>
> This appears to be related specifically to the redraw path of relative
> line numbers in `display-line-numbers-mode`.
I cannot reproduce this, but I don't have access to a GTK build.
It is possible that the problem is due to some "display optimization"
features in your video display driver software, so if you can try
disabling any such features, please do, and then try again.
Failing that, perhaps someone else who has access to such a build will
be able to reproduce and debug this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#79295
; Package
emacs
.
(Sun, 24 Aug 2025 05:47:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 79295 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 23 Aug 2025 23:05:05 +0200
> From: Marco <marconeumaier <at> gmail.com>
>
> unfortunately the fix ( as suggested by chatGPT) described in the bug
> report does not work:
What made you think that ChatGPT understands the Emacs display code
enough to provide any useful advice about it?
Anyway, like I said: I'm unable to reproduce this, and suspect it's
caused by some "display optimization" features of your video driver
software.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#79295
; Package
emacs
.
(Sun, 24 Aug 2025 19:19:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 79295 <at> debbugs.gnu.org (full text, mbox):
[Please use Reply All to reply, to keep the bug tracker on the CC list.]
> Date: Sun, 24 Aug 2025 21:07:05 +0200
> From: Marco <marconeumaier <at> gmail.com>
>
> Hi,
>
> thanks for looking into it. I made some more tests today.
>
> Findings:
>
> The issue occurs only in a Wayland session.
>
> When running Emacs in a true X11 session, the problem does not appear at
> all. If I'm wrong I'll correct myself.
>
> Setting GDK_BACKEND=x11 while under Wayland does not eliminate the
> problem, which suggests it still goes through XWayland and the
> compositor path.
>
> The artifacts are visible in screenshots and occur sometimes across the
> whole display width, though their colors sometimes differ slightly,
> which suggests this is a rendering bug.
>
> Most of the time they look similar to what you see here:
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2012-05/msg00023.html
> or
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2018-01/png1wmnm51YOW.png
>
> It only seem to occur when the emacs window is maximized!
>
> With absolute line numbers, I cannot reproduce the problem — it only
> appears with relative line numbers.
>
> Conclusion:
> This looks like a rendering bug in the GTK/Wayland (or XWayland) stack,
> but Emacs may be triggering it in a specific way when drawing relative
> line numbers.
>
> This is maybe related: When opening emacs in nw mode and using relative
> line number I also see artifacts, i.e. lines across the whole window
> width in a color slightly darker than the background. The height of the
> line is the same like the block cursor height.
>
> Again: This does not happen in a real x11 session.
Thanks for the footwork.
Po Lu, any ideas? Are problems like this with Wayland known to exist?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#79295
; Package
emacs
.
(Mon, 25 Aug 2025 07:30:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79295 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> [Please use Reply All to reply, to keep the bug tracker on the CC list.]
>
>> Date: Sun, 24 Aug 2025 21:07:05 +0200
>> From: Marco <marconeumaier <at> gmail.com>
>>
>> Hi,
>>
>> thanks for looking into it. I made some more tests today.
>>
>> Findings:
>>
>> The issue occurs only in a Wayland session.
>>
>> When running Emacs in a true X11 session, the problem does not appear at
>> all. If I'm wrong I'll correct myself.
>>
>> Setting GDK_BACKEND=x11 while under Wayland does not eliminate the
>> problem, which suggests it still goes through XWayland and the
>> compositor path.
>>
>> The artifacts are visible in screenshots and occur sometimes across the
>> whole display width, though their colors sometimes differ slightly,
>> which suggests this is a rendering bug.
>>
>> Most of the time they look similar to what you see here:
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2012-05/msg00023.html
>> or
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2018-01/png1wmnm51YOW.png
>>
>> It only seem to occur when the emacs window is maximized!
>>
>> With absolute line numbers, I cannot reproduce the problem — it only
>> appears with relative line numbers.
>>
>> Conclusion:
>> This looks like a rendering bug in the GTK/Wayland (or XWayland) stack,
>> but Emacs may be triggering it in a specific way when drawing relative
>> line numbers.
>>
>> This is maybe related: When opening emacs in nw mode and using relative
>> line number I also see artifacts, i.e. lines across the whole window
>> width in a color slightly darker than the background. The height of the
>> line is the same like the block cursor height.
>>
>> Again: This does not happen in a real x11 session.
>
> Thanks for the footwork.
>
> Po Lu, any ideas? Are problems like this with Wayland known to exist?
I'm not aware of any such problems, but I would still ask the OP whether
he has enabled fractional scaling on his Wayland desktop, which is a
recent innovation that has the potential to produce artifacts in
rendered text (particularly if the compositor believes a frame to be
completely opaque).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#79295
; Package
emacs
.
(Mon, 25 Aug 2025 08:36:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 79295 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I checked already if it depends on fractional scaling, but that´s not the
case. Will double check though.
My CPU is an AMD 9700X and i´m using its iGPU. I´m also running a very
recent MESA version (25.x, I have to check the exact version)
and I also just found this thread:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12809 where also Emacs is
mentioned.
Maybe it´s related.
Am Mo., 25. Aug. 2025 um 09:28 Uhr schrieb Po Lu <luangruo <at> yahoo.com>:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > [Please use Reply All to reply, to keep the bug tracker on the CC list.]
> >
> >> Date: Sun, 24 Aug 2025 21:07:05 +0200
> >> From: Marco <marconeumaier <at> gmail.com>
> >>
> >> Hi,
> >>
> >> thanks for looking into it. I made some more tests today.
> >>
> >> Findings:
> >>
> >> The issue occurs only in a Wayland session.
> >>
> >> When running Emacs in a true X11 session, the problem does not appear
> at
> >> all. If I'm wrong I'll correct myself.
> >>
> >> Setting GDK_BACKEND=x11 while under Wayland does not eliminate the
> >> problem, which suggests it still goes through XWayland and the
> >> compositor path.
> >>
> >> The artifacts are visible in screenshots and occur sometimes across the
> >> whole display width, though their colors sometimes differ slightly,
> >> which suggests this is a rendering bug.
> >>
> >> Most of the time they look similar to what you see here:
> >> https://lists.gnu.org/archive/html/bug-gnu-emacs/2012-05/msg00023.html
> >> or
> >>
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2018-01/png1wmnm51YOW.png
> >>
> >> It only seem to occur when the emacs window is maximized!
> >>
> >> With absolute line numbers, I cannot reproduce the problem — it only
> >> appears with relative line numbers.
> >>
> >> Conclusion:
> >> This looks like a rendering bug in the GTK/Wayland (or XWayland) stack,
> >> but Emacs may be triggering it in a specific way when drawing relative
> >> line numbers.
> >>
> >> This is maybe related: When opening emacs in nw mode and using relative
> >> line number I also see artifacts, i.e. lines across the whole window
> >> width in a color slightly darker than the background. The height of the
> >> line is the same like the block cursor height.
> >>
> >> Again: This does not happen in a real x11 session.
> >
> > Thanks for the footwork.
> >
> > Po Lu, any ideas? Are problems like this with Wayland known to exist?
>
> I'm not aware of any such problems, but I would still ask the OP whether
> he has enabled fractional scaling on his Wayland desktop, which is a
> recent innovation that has the potential to produce artifacts in
> rendered text (particularly if the compositor believes a frame to be
> completely opaque).
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#79295
; Package
emacs
.
(Wed, 27 Aug 2025 01:45:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 79295 <at> debbugs.gnu.org (full text, mbox):
Marco Neumaier <marconeumaier <at> gmail.com> writes:
> I checked already if it depends on fractional scaling, but that´s not
> the case. Will double check though. My CPU is an AMD 9700X and i´m
> using its iGPU. I´m also running a very recent MESA version (25.x, I
> have to check the exact version) and I also just found this thread:
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/12809 where also
> Emacs is mentioned. Maybe it´s related.
What if you configure `alpha-background' to a nearly opaque value such
as 99? It should suffice to prevent the compositor from regarding
Emacs's frames as completely opaque and disable the optimizations I
suspect are producing these artifacts.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#79295
; Package
emacs
.
(Thu, 28 Aug 2025 18:26:04 GMT)
Full text and
rfc822 format available.
Message #29 received at 79295 <at> debbugs.gnu.org (full text, mbox):
Hi,
I checked the `alpha-background' option yesterday and it still occured.
Then there was some update also updating MESA to 25.2.1
(https://docs.mesa3d.org/relnotes/25.2.1.html) and since installing this
I didn't see these artifacts again.
It's strange cause there was no bug report pointing to this, but maybe
something changed under the hood. If it comes back I´ll revive the thread.
Best and thanks!
Marco
Am 27.08.25 um 03:44 schrieb Po Lu:
> Marco Neumaier <marconeumaier <at> gmail.com> writes:
>
>> I checked already if it depends on fractional scaling, but that´s not
>> the case. Will double check though. My CPU is an AMD 9700X and i´m
>> using its iGPU. I´m also running a very recent MESA version (25.x, I
>> have to check the exact version) and I also just found this thread:
>> https://gitlab.freedesktop.org/mesa/mesa/-/issues/12809 where also
>> Emacs is mentioned. Maybe it´s related.
> What if you configure `alpha-background' to a nearly opaque value such
> as 99? It should suffice to prevent the compositor from regarding
> Emacs's frames as completely opaque and disable the optimizations I
> suspect are producing these artifacts.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Thu, 28 Aug 2025 18:57:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Marco <marconeumaier <at> gmail.com>
:
bug acknowledged by developer.
(Thu, 28 Aug 2025 18:57:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 79295-done <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 28 Aug 2025 20:25:38 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 79295 <at> debbugs.gnu.org
> From: Marco <marconeumaier <at> gmail.com>
>
> I checked the `alpha-background' option yesterday and it still occured.
>
> Then there was some update also updating MESA to 25.2.1
> (https://docs.mesa3d.org/relnotes/25.2.1.html) and since installing this
> I didn't see these artifacts again.
>
> It's strange cause there was no bug report pointing to this, but maybe
> something changed under the hood. If it comes back I´ll revive the thread.
Thanks, I'm therefore closing this bug.
This bug report was last modified 22 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.