GNU bug report logs - #44120
28.0.50; Animated GIFs sometimes leave "trails"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44120 in the body.
You can then email your comments to 44120 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Animated GIFs sometimes leave "trails"
Date: Wed, 21 Oct 2020 21:17:28 +0200

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?  


In GNU Emacs 28.0.50 (build 119, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
 of 2020-10-21 built on xo
Repository revision: 4ef8c4a0f4e26f6ea2186a2b80c068b8d93e4993
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid

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

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

From: Alan Third <alan <at> idiocy.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 44120 <at> debbugs.gnu.org
Subject: Re: bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
Date: Wed, 21 Oct 2020 21:08:42 +0100

On Wed, Oct 21, 2020 at 09:17:28PM +0200, Lars Ingebrigtsen wrote:
> 
> 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?  

Well, I think this is the problem:

From image.c:

      /* From gif89a spec: 1 = "keep in place", 2 = "restore
	 to background".  Treat any other value like 2.  */

From the gif89a spec:

iv) Disposal Method - Indicates the way in which the graphic is to
            be treated after being displayed.

            Values :    0 -   No disposal specified. The decoder is
                              not required to take any action.
                        1 -   Do not dispose. The graphic is to be left
                              in place.
                        2 -   Restore to background color. The area used by the
                              graphic must be restored to the background color.
                        3 -   Restore to previous. The decoder is required to
                              restore the area overwritten by the graphic with
                              what was there prior to rendering the graphic.
                     4-7 -    To be defined.

That gif uses a disposal value of 3 quite a lot.

It looks like when a block is updated with a disposal value of 3 we
should hang onto the previous contents and then restore them in, I
guess, the next frame.
-- 
Alan Third

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, 44120 <at> debbugs.gnu.org
Subject: Re: bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
Date: Wed, 21 Oct 2020 13:37:27 -0700

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.

I'm also seeing slightly pixelated/jagged text, but it looks completely
smooth in Firefox.  Is anyone else seeing this?  Should perhaps be a
separate bug report?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 44120 <at> debbugs.gnu.org
Subject: Re: bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
Date: Thu, 22 Oct 2020 14:01:21 +0200

Alan Third <alan <at> idiocy.org> writes:

> It looks like when a block is updated with a disposal value of 3 we
> should hang onto the previous contents and then restore them in, I
> guess, the next frame.

So...  when rendering frame C, and there was a disposal of value 3 in
frame B, we should restore that area from frame A?

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 44120 <at> debbugs.gnu.org
Subject: Re: bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
Date: Thu, 22 Oct 2020 14:02:02 +0200

Stefan Kangas <stefankangas <at> gmail.com> writes:

> I'm also seeing slightly pixelated/jagged text, but it looks completely
> smooth in Firefox.  Is anyone else seeing this?  Should perhaps be a
> separate bug report?

I think it looks like Firefox applied extra blurring to the results?
But it's hard to tell...

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

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

From: Alan Third <alan <at> idiocy.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 44120 <at> debbugs.gnu.org
Subject: Re: bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
Date: Thu, 22 Oct 2020 13:14:44 +0100

On Thu, Oct 22, 2020 at 02:01:21PM +0200, Lars Ingebrigtsen wrote:
> Alan Third <alan <at> idiocy.org> writes:
> 
> > It looks like when a block is updated with a disposal value of 3 we
> > should hang onto the previous contents and then restore them in, I
> > guess, the next frame.
> 
> So...  when rendering frame C, and there was a disposal of value 3 in
> frame B, we should restore that area from frame A?

Yes. That's how I read it.

There's a note that if you are unable to keep the contents then the
next best solution is to cover the area in the background colour. It
appears from the comments that that's the solution we're using, but
it's clearly not working either.
-- 
Alan Third

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: larsi <at> gnus.org, 44120 <at> debbugs.gnu.org
Subject: Re: bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
Date: Thu, 22 Oct 2020 15:54:29 +0300

> Date: Wed, 21 Oct 2020 21:08:42 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: 44120 <at> debbugs.gnu.org
> 
> >From image.c:
> 
>       /* From gif89a spec: 1 = "keep in place", 2 = "restore
> 	 to background".  Treat any other value like 2.  */
> 
> >From the gif89a spec:
> 
> iv) Disposal Method - Indicates the way in which the graphic is to
>             be treated after being displayed.
> 
>             Values :    0 -   No disposal specified. The decoder is
>                               not required to take any action.
>                         1 -   Do not dispose. The graphic is to be left
>                               in place.
>                         2 -   Restore to background color. The area used by the
>                               graphic must be restored to the background color.
>                         3 -   Restore to previous. The decoder is required to
>                               restore the area overwritten by the graphic with
>                               what was there prior to rendering the graphic.
>                      4-7 -    To be defined.
> 
> That gif uses a disposal value of 3 quite a lot.
> 
> It looks like when a block is updated with a disposal value of 3 we
> should hang onto the previous contents and then restore them in, I
> guess, the next frame.

FTR, the image renders correctly on MS-Windows when
w32-use-native-image-API is non-nil, so this indeed seems like a
problem with our GIF code.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 44120 <at> debbugs.gnu.org
Subject: Re: bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
Date: Sun, 10 Apr 2022 17:13:33 +0200

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

Previous Next

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