bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"

[Lars Ingebrigtsen <larsi@gnus.org>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> M-x eww RET
> https://lh4.googleusercontent.com/TQ10szluPdXsKoYIeYe5ljxjVIoJzcCvLybUa3tEA24a6vISYkwiqAz9VymzgyNY_N8tfqHKvxSv9WhrcC-GvDc4uaiCE1T52y3C6xK1K--Lazicm9PSBiGxGVCyjFtDTBJaEOuExA
>
> will give you an animated GIF that displays the problem: It seems like
> when repainting, the previous area that has changed isn't reset...  or
> something.
>
> We're probably not following the GIF animation standard when applying
> the deltas?  

It looks like this was fixed by f9282e1d724:

commit f9282e1d724f1cb2e239f946957fdf02aa15dcc5
Author:     Stefan Kangas <stefan@marxist.se>
AuthorDate: Fri Oct 29 17:11:23 2021 +0200

    Don't parse GCB block by hand with giflib 5 or later
    
    * src/image.c (gif_load): If GIFLIB_MAJOR > 5, use
    DGifSavedExtensionToGCB instead of parsing the Graphic Control
    Extension block by hand.

I'm no seeing any trails in the example gif.  On the other hand, perhaps
Google has changed the GIF, because I'm not able to reproduce the
problem in Emacs 27.1 now either.

I think it'd been a while since I've seen a GIF that Emacs does the
wrong thing with, though, so I'm guessing Stefan's patch fixed this, and
I'm therefore closing this bug report.  If I see the problem again in
Emacs 29, I'll reopen.

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