Package: emacs;
Reported by: laladrik <laladrik <at> protonmail.com>
Date: Tue, 10 Jun 2025 02:37:03 UTC
Severity: normal
Found in version 30.1
To reply to this bug, email your comments to 78739 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#78739; Package emacs.
(Tue, 10 Jun 2025 02:37:04 GMT) Full text and rfc822 format available.laladrik <laladrik <at> protonmail.com>:bug-gnu-emacs <at> gnu.org.
(Tue, 10 Jun 2025 02:37:04 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: laladrik <laladrik <at> protonmail.com> To: bug-gnu-emacs <at> gnu.org Subject: 30.1; Performance issue with inline image in an org file Date: Mon, 09 Jun 2025 19:23:56 +0000
Hello,
I've been experiencing performance issues with displaying inline images in Org
files. This happens only if an image is resized. Emacs stops being responsive
and its CPU core gets busy to 100%. There 3 ways to reproduce it:
1. Put the mouse cursor on an image and put the caret on some text. Select some
text with the keyboard. The process of the selection is like a slide show.
3.1. Open an Org file with some text and at least one inline image.
1.2. Put the caret on first line.
1.3. Put the mouse cursor on the image.
1.4. Press shift + space to start the selection.
1.5. Press down to select 10 or 20 lines. You can press up and down to change
the selection if you haven't got the lagging from the first time.
2. Scroll the document. Emacs slows down when an image appears under the
cursor. Details:
2.1. Open an Org file which long enough for scrolling and has inline images.
2.2. Make sure that inline images are displayed and big enough to be resized by
Emacs.
2.3. Scroll the document with the mouse cursor at any position, where it might
be over an image.
2.4. When the mouse cursor is over an image, I see that scrolling lags.
3. Move the mouse cursor on and off the image. The picture of the cursor
changes with a lag.
3.1. Open an Org file with some text and at least one inline image.
3.2. Make sure that inline images are displayed and big enough to be resized by
Emacs.
3.3. Move the mouse cursor on and off the image.
3.4. When the mouse cursor crosses the edge of the image, the picture of the
mouse cursor changes with some lag.
The init.el needed to reproduce has just one line:
(setq org-image-actual-width 1000)
The value 1000 can be replaced with any - no difference. After searching some
information on the internet I found that the problem can be cause by frequent
garbage collection. As a result I added this line:
(setq gc-cons-threshold (* 50 1000 1000))
It doesn't help, but for now I run into the performance issue with just these
two lines in the init.el anyway.
The Emacs CPU profiler shows this:
13131 95% - redisplay_internal (C function)
2 0% - eval
1 0% - if
1 0% frame-parameter
1 0% mode-line-eol-desc
1 0% - redisplay--pre-redisplay-functions
1 0% - run-hook-with-args
1 0% - redisplay--update-region-highlight
1 0% redisplay--highlight-overlay-function
616 4% - command-execute
566 4% - byte-code
566 4% - read-extended-command
566 4% - read-extended-command-1
566 4% - completing-read-default
395 2% redisplay_internal (C function)
170 1% - command-execute
170 1% - funcall-interactively
170 1% - minibuffer-complete
170 1% - completion-in-region
170 1% - completion--in-region
170 1% + #<byte-code-function 429>
50 0% + funcall-interactively
23 0% + timer-event-handler
3 0% + #<byte-code-function E5A>
2 0% + gui-set-selection
1 0% + internal-timer-start-idle
0 0% ...
The function redisplay_internal takes 95%.
I built Emacs with debug symbols to profile it with Linux Perf. The
output of perf stat:
Performance counter stats for process id '76585,76586':
16,656.41 msec task-clock:u # 0.913 CPUs utilized
0 context-switches:u # 0.000 /sec
0 cpu-migrations:u # 0.000 /sec
1,254 page-faults:u # 75.286 /sec
62,738,001,762 cycles:u # 3.767 GHz (49.97%)
941,864,008 stalled-cycles-frontend:u # 1.50% frontend cycles idle (50.01%)
268,065,500,133 instructions:u # 4.27 insn per cycle
# 0.00 stalled cycles per insn (50.04%)
31,137,526,550 branches:u # 1.869 G/sec (50.02%)
71,463,191 branch-misses:u # 0.23% of all branches (49.95%)
18.251526038 seconds time elapsed
I made a record with Linux perf, but the output doesn't make sense to me.
The function taking the CPU time is:
bits_image_fetch_separable_convolution_affine_none_x8r8g8b8
It's defined in libpixman. The problem is that the report doesn't show the
callstack to the function. As a result, I can't say what calls the function in
Emacs. I can upload the Linux Perf file somewhere and give a link to it.
Here is my system configuration:
System:
Kernel: 6.12.9-100.fc40.x86_64 arch: x86_64 bits: 64
Desktop: i3 v: 4.24 Distro: Fedora Linux 40 (Workstation Edition)
CPU:
Info: 8-core model: AMD Ryzen 7 3800X bits: 64 type: MT MCP cache: L2: 4 MiB
Speed (MHz): min/max: 2200/4559
Graphics:
Device-1: NVIDIA TU104 [GeForce RTX 2060] driver: nvidia v: 565.77
API: OpenGL v: 4.6.0 vendor: nvidia v: 565.77 renderer: NVIDIA GeForce
Info:
Memory: total: 64 GiB
I come across the issue with 2 versions of Emacs. 29.4 and 30.1. However, all
the data, I'm providing is from the version 30.1, because I compiled it with
debug symbols.
I experience it with a few Org files and pictures. However, I have two examples
I can share. I'll give the links to them on request to minimize the chance of
my message being considered as a spam.
I'm happy to provide more details if needed. Also, I had a discussion on
stackoverflow about it. The discussion doesn't have more information, but I
can provide a link to it as well on request.
About sending this bug report. I couldn't figure out how to send a bug report
via Emacs itself. As a result, I prepared the text of the template for the
message from Emacs only. The message is sent from an email client manually.
Given that, the bug report might miss some information, which is sent regularly
via Emacs. I'm happy to give you the information if you tell me how.
Best regards,
Aleksei Markov
In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.18.2, Xaw3d scroll bars) of 2025-06-06 built on raven
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 40 (Workstation Edition)
Configured using:
'configure 'CFLAGS=-g -O2''
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
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 XAW3D XDBE XIM XINPUT2 XPM
LUCID ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
global-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
blink-cursor-mode: t
minibuffer-regexp-mode: t
buffer-read-only: 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 derived epg rfc6068 epg-config
gnus-util text-property-search time-date mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils info evil-autoloads
goto-chg-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 dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty move-toolbar
make-network-process native-compile emacs)
Memory information:
((conses 16 87385 64353) (symbols 48 7825 2) (strings 32 24929 9977)
(string-bytes 1 841110) (vectors 16 14718)
(vector-slots 8 190273 44458) (floats 8 34 10) (intervals 56 388 263)
(buffers 992 11)
bug-gnu-emacs <at> gnu.org:bug#78739; Package emacs.
(Tue, 10 Jun 2025 11:34:02 GMT) Full text and rfc822 format available.Message #8 received at 78739 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: laladrik <laladrik <at> protonmail.com> Cc: 78739 <at> debbugs.gnu.org Subject: Re: bug#78739: 30.1; Performance issue with inline image in an org file Date: Tue, 10 Jun 2025 14:33:28 +0300
> Date: Mon, 09 Jun 2025 19:23:56 +0000 > From: laladrik via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> > > Hello, > > I've been experiencing performance issues with displaying inline images in Org > files. Is it necessary to reproduce in an Org buffer? Can you reproduce in a "normal" buffer that is in Fundamental mode? In any case, please post a complete recipe, starting from "emacs -Q", that reproduces the problem on your system, because what you say below is too vague to follow (I tried method 1, but couldn't reproduce). > This happens only if an image is resized. What does this mean? Can you elaborate? In particular, does this happen with any image file and type, or just with certain ones? > The init.el needed to reproduce has just one line: > > (setq org-image-actual-width 1000) And how to recreate a buffer where the problem happens, after starting with this customization? Finally, if this happens only in Org buffers, it could make sense to report this to Org developers first. The fact that redisplay_internal is the hot spot doesn't mean the bug is there: it could be something Org does in this case which forces redisplay to work very hard.
bug-gnu-emacs <at> gnu.org:bug#78739; Package emacs.
(Thu, 12 Jun 2025 06:11:01 GMT) Full text and rfc822 format available.Message #11 received at 78739 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: laladrik <laladrik <at> protonmail.com> Cc: 78739 <at> debbugs.gnu.org Subject: Re: bug#78739: 30.1; Performance issue with inline image in an org file Date: Thu, 12 Jun 2025 09:09:55 +0300
[Please use Reply All to reply, to keep the bug tracker CC'ed.] > Date: Wed, 11 Jun 2025 23:12:36 +0000 > From: laladrik <laladrik <at> protonmail.com> > > > Is it necessary to reproduce in an Org buffer? Can you reproduce in a > > "normal" buffer that is in Fundamental mode? > > I don't how to get a resized inline image within a non-Org file. I can do it > if you tell me how I can do it. I can't find any information on the internet > about it. Just FYI, I'm not an advanced Emacs user. I've been using it for a > year maybe and only as a note taking application. > > > Finally, if this happens only in Org buffers, it could make sense to > > report this to Org developers first. The fact that redisplay_internal > > is the hot spot doesn't mean the bug is there: it could be something > > Org does in this case which forces redisplay to work very hard. > > You might be right, because I found a scenario where I switch to Fundamental > mode and the lagging disappears. Please find details further in the message. > > > In any case, please post a complete recipe, starting from "emacs -Q", > > that reproduces the problem on your system, because what you say below > > is too vague to follow (I tried method 1, but couldn't reproduce). > > Let's get focused on the first scenario. > > Input data: > 1. The init.el file with the following content > > (setq org-image-actual-width 1000) ; this command resizes inline images > (setq gc-cons-threshold (* 50 1000 1000)) > > 2. An Org file has 45 lines. The last line is the link to the image line this > [[file:./inlineImage.png]]. I can provide an Org file if you request it. > 3. An image, which is big enough for resizing. One of the images I have > is 2778 x 880. The format of the image is png. Also, I tried jpg and bmp, but > they don't change anything. The size matters. The smaller the image, the less > Emacs slows down. Again, I can provide it if you request it. Yes, please post both the Org file and an image, so I could try exactly what you are trying. > Scenario: > 1. emacs -Q --init-directory=<path/to/folder/with/the/init.el> > <path/to/the/org/file.org> > 2. Set the cursor mouse over the inline image. > 3. Press Ctrl-Space > 4. Press Down for a second or two and see the lagging selection. > > I noticed that switching to Fundamental mode helps. However, it happens only > if I switch to Fundamental mode before moving the mouse cursor over the inline > image. > > Scenario: > 1. Move cursor to the corner of the desktop. > 2. emacs -Q --init-directory=<path/to/folder/with/the/init.el> > <path/to/the/org/file.org> > 3. M-x fundamental-mode > 4. Set the cursor mouse over the inline image. > 5. Press Ctrl-Space > 6. Press Down for a second or two and see the selection without lagging. > > If you swap steps 3 and 4 then the lagging happens again. > > Should I report it to the Org mode team? I will answer this after reproducing the issue on my system. Thanks.
bug-gnu-emacs <at> gnu.org:bug#78739; Package emacs.
(Fri, 13 Jun 2025 22:13:04 GMT) Full text and rfc822 format available.Message #14 received at 78739 <at> debbugs.gnu.org (full text, mbox):
From: laladrik <laladrik <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 78739 <at> debbugs.gnu.org Subject: Re: bug#78739: 30.1; Performance issue with inline image in an org file Date: Fri, 13 Jun 2025 22:12:08 +0000
> Yes, please post both the Org file and an image, so I could try > exactly what you are trying. I uploaded the files to my server, because I don't know how much space GNU has on their mail server. Also, they won't expire there. - The Org file is here https://share.laladrik.xyz/slowImage.org - The image is here https://share.laladrik.xyz/RenderingOperations.png Please, let me know if it's necessary send the files as attachment. > > Should I report it to the Org mode team? > > I will answer this after reproducing the issue on my system. Looking forward to it. Best regards, Aleksei Markov
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.