GNU bug report logs - #79132
30.1; lots of overlays with box face causes high usage of redisplay_internal

Previous Next

Full log

Message #11 received at 79132 <at> debbugs.gnu.org (full text, mbox):

From: Godefroy Vannoye <godefroy.vannoye <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79132 <at> debbugs.gnu.org
Subject: Re: bug#79132: 30.1; lots of overlays with box face causes high usage
 of redisplay_internal
Date: Thu, 31 Jul 2025 16:21:31 +0200

Thanks a lot for the quick response.

Digging around a bit it seems to be almost exactly the same as bug#74691
(Long errors with flymake-show-diagnostics-at-end-of-line really slows 
movement).

I had suspicions it would be difficult. On the top of my head I could 
imagine some caching
of where the boxes need to be drawn would help, but of course it's 
easier said than done…

Another possibility could be to not draw the boxes except after some 
idle time.

I have a curiosity question: what makes box particularly more expensive 
compared to
other faces properties like underline or strike-through (for which no 
slowdown is observed)?

On 31/07/2025 12:15, Eli Zaretskii wrote:
>> Date: Thu, 31 Jul 2025 11:57:55 +0200
>> From: Godefroy Vannoye <godefroy.vannoye <at> gmail.com>
>>
>> While using flymake with flymake-show-diagnostics-at-end-of-line set to
>> t, I notice a significant slowdown when moving the cursor up and down.
>>
>> After digging a bit, the issue seems to come from a high number of
>> overlays with the box face property (as flymake generates them). When I
>> change
>> the face to remove the box property, I don't notice any slowdown. It is
>> also possible that the slowdown mainly happens where there are multiple
>> boxes on the same line (due to multiple warnings from flymake on the
>> same line).
>>
>> I used to profiler and saw a high CPU usage from redisplay_internal.
>>
>> Tested on both pure-gtk and Xorg emacs, the slowdown happens in both
>> cases.
>>
>> I hope that my explanation is clear enough to give some hints on where
>> to look for a fix.
> Thanks, but I'm not sure what kind of fix could be found here.
> Massive usage of the box face is indeed expected to make redisplay
> more expensive, because the display engine needs to find where the box
> face starts and ends, and that requires additional scans of the buffer
> text.
>
> Sorry.

Previous Next

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