Re: Redisplay slower in Emacs 28 than Emacs 27

[Gregory Heytings]

> > > > No, with the tests were ran with emacs -Q.  I forgot to mention this, 
> > > > it was too obvious to me.
> > >
> > > But "emacs -Q" does show images in the tool bar.  :-) (Very small 
> > > ones, though.)
> >
> > Yes, and as you probably understood, by "does not load any image" I 
> > meant "in a buffer"... ;-)
>
> You asked why Emacs messes with the image cache although there are no 
> images in the buffer,

No, I did not ask this.

> and the answer is probably that Emacs doesn't mess with images in the 
> buffer, it messes with images elsewhere on display.  Depending on 
> whether your build uses GTK, this could happen each time Emacs scrolls 
> the window, because it then examines the tool bar in order to decide 
> whether it needs to be redrawn.

I don't know, that's possible indeed.

In the other thread I referenced in my initial message, you wrote: "If 
someone can afford [to search the history to find the source of the 
slowdown], it would be nice to know.  Assuming a single commit causes it, 
that is (it could be several commits instead, each one slowing down Emacs 
by a few percents)."  I did exactly that, no more, no less.

That being said, it seems to me that this slowdown is avoidable.  Lars 
considers that the minor modification he made should not have changed 
anything.