GNU bug report logs - #77961
31.0.50; Rendering HTML email is very slow since commit #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Iñigo Serna <inigoserna <at> gmx.com>, 77961 <at> debbugs.gnu.org
Subject: bug#77961: 31.0.50; Rendering HTML email is very slow since commit #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5
Date: Mon, 21 Apr 2025 20:31:53 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Mon, 21 Apr 2025 10:34:01 +0200
>> From:  Iñigo Serna via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> Hi,
>> 
>> Since a few weeks ago I'm noting that HTML emails rendering is 
>> very slow,
>> f.e. from 1 second to 5-6 seconds.
>> 
>> I compile Emacs with PGTK and Native Compilation every week on
>> GNU/Linux Fedora 41/42, and use mu4e to read emails.
>> More info of my compilation flags below.
>> 
>> 
>> Today I got some free time and proceed to profile the issue, it 
>> showed
>> ~10x more time in function 'shr-render-td-1' vs emacs v30.1.
>> 
>> As this function is not changed since time ago I've bisected the 
>> problem,
>> which showed that the commit 
>> #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5
>> was the culprit:
>> 
>>    [machine] /h/_/l/d/emacs.bug > git bisect good
>>        eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5 is the first bad 
>>        commit
>>    commit eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5
>>    Author: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>>        Make sure to initialize glyph::frame to NULL (bug#77039)
>>                * src/dispnew.c (adjust_glyph_matrix): Clear glyph 
>>                memory when
>>        enlarging window-system window glyph matrices.
>>     src/dispnew.c | 3 ++-
>>     1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> 
>> If I comment out the two lines added in this commit, problem 
>> disappears.
>> 
>> I've read bug #77039 comment but it's way off my understanding.
>> 
>> 
>> But looking deeper into the problem, it is related with my own 
>> theme,
>> which hides mode-line of non-active windows by setting its height 
>> to a small value:
>> 
>>    (mode-line-inactive ((((type tty)) (:background "#222222" 
>>    :foreground
>> ,elms-fg :height 0.1))
>>                        (((type graphic)) (:background ,elms-bg
>> :foreground ,elms-fg :height 0.1))))
>> 
>> 
>> If remove that height attribute (or set it to a bigger value such 
>> as 0.6) the issue disappears.
>
> Gerd, any comments or suggestions?

Please try if this helps:

[xxx.diff (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

The hypothesis behind this would be: The rendering apparently leads to
increasing glyph matrix sizes; maybe it does something with fonts, no
idea. The memset clears all glyphs which I can only imagine to play a
role when we somewhere in the display code compare desired and current
glyphs, and that fails with the memset and didn't fail without it. Where
that might be I have no idea.

Anyway, with the loop in my diff it should be as before, and
glyph::frame is unused in the window-system case, so...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.