Re: Redisplay slower in Emacs 28 than Emacs 27

[Lars Ingebrigtsen <larsi@gnus.org>]

Alan Third <alan@idiocy.org> writes:

> I think the image cache is actually broken.
>
> If we have two image specs that have the same contents, but don't have
> identical memory locations, surely we still want the cache to work?

We used to use Fequal on the spec, so that used to work.  I thought the
point of the equal_lists function was to speed that up a bit, by
dropping that generality and just using EQ instead?  But it does indeed
mean that you have to be more careful with how you construct the image
specs, and I think that's a fair tradeoff.

It works for the vast majority of the use cases, but as we saw here, the
toolbar code hadn't been adjusted, but that's easily fixed (see the
patch I posted earlier).

Especially with huge :data images, the equal_lists code should be faster
than the Fequal code, I think?  On the other hand, when we're
constructing the hashes, we iterate over a lot of data anyway, so...

> For example when playing an animated gif image.el doesn't store the
> image specs for each frame, it generates them on the fly by
> incrementing the frame counter. I can see that Emacs creates a new
> cache entry for every frame every time the gif is played through.
>
> That means it must be decoding every frame every time.

Yes, I think so.  I think there's at least one open bug report about
making animated gifs faster (because they're really slow now).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no