GNU bug report logs -
#44120
28.0.50; Animated GIFs sometimes leave "trails"
Previous Next
Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Wed, 21 Oct 2020 19:18:02 UTC
Severity: normal
Found in version 28.0.50
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #26 received at 44120 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> 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 <at> 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
This bug report was last modified 3 years and 44 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.