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

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

[Lars Ingebrigtsen]

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

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

[Alan Third]

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

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

[Stefan Kangas]

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.

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?

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

[Lars Ingebrigtsen]

Alan Third <alan@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

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

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@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

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

[Alan Third]

On Thu, Oct 22, 2020 at 02:01:21PM +0200, Lars Ingebrigtsen wrote:
> Alan Third <alan@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

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

[Eli Zaretskii]

> Date: Wed, 21 Oct 2020 21:08:42 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 44120@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.

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

[Lars Ingebrigtsen]

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