Subject: Re: bug#77961: 31.0.50; Rendering HTML email is very slow since commit #eab14d68b2e72b9a6b8b0cc67c9667c2bfbed4f5

From: Gerd Möllmann <[email-masked]>
Date: Mon, 21 Apr 2025 20:31:53 +0200

Eli Zaretskii <[email-masked]> 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" <[email-masked]>
>> 
>> 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 <[email-masked]>
>>        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:

diff --git a/src/dispnew.c b/src/dispnew.c
index 440b1ba83b9..b9146b9ef3d 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -506,10 +506,9 @@ adjust_glyph_matrix (struct window *w, struct glyph_matrix *matrix, int x, int y
 	      row->glyphs[LEFT_MARGIN_AREA]
 		= xnrealloc (row->glyphs[LEFT_MARGIN_AREA],
 			     dim.width, sizeof (struct glyph));
-	      /* We actually need to clear only the 'frame' member, but
-                 it's easier to clear everything.  */
-	      memset (row->glyphs[LEFT_MARGIN_AREA], 0,
-		      dim.width * sizeof (struct glyph));
+
+	      for (int i = 0; i < dim.width; ++i)
+		row->glyphs[LEFT_MARGIN_AREA][i].frame = NULL;
 
 	      if ((row == matrix->rows + dim.height - 1
 		   /* The mode line, if displayed, never has marginal

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...