* bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
@ 2020-10-21 19:17 Lars Ingebrigtsen
2020-10-21 20:08 ` Alan Third
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-21 19:17 UTC (permalink / raw)
To: 44120
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
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
2020-10-21 19:17 bug#44120: 28.0.50; Animated GIFs sometimes leave "trails" Lars Ingebrigtsen
@ 2020-10-21 20:08 ` Alan Third
2020-10-22 12:01 ` Lars Ingebrigtsen
2020-10-22 12:54 ` Eli Zaretskii
2020-10-21 20:37 ` Stefan Kangas
2022-04-10 15:13 ` Lars Ingebrigtsen
2 siblings, 2 replies; 8+ messages in thread
From: Alan Third @ 2020-10-21 20:08 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44120
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
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
2020-10-21 20:08 ` Alan Third
@ 2020-10-22 12:01 ` Lars Ingebrigtsen
2020-10-22 12:14 ` Alan Third
2020-10-22 12:54 ` Eli Zaretskii
1 sibling, 1 reply; 8+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-22 12:01 UTC (permalink / raw)
To: Alan Third; +Cc: 44120
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
2020-10-22 12:01 ` Lars Ingebrigtsen
@ 2020-10-22 12:14 ` Alan Third
0 siblings, 0 replies; 8+ messages in thread
From: Alan Third @ 2020-10-22 12:14 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44120
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
2020-10-21 20:08 ` Alan Third
2020-10-22 12:01 ` Lars Ingebrigtsen
@ 2020-10-22 12:54 ` Eli Zaretskii
1 sibling, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2020-10-22 12:54 UTC (permalink / raw)
To: Alan Third; +Cc: larsi, 44120
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
2020-10-21 19:17 bug#44120: 28.0.50; Animated GIFs sometimes leave "trails" Lars Ingebrigtsen
2020-10-21 20:08 ` Alan Third
@ 2020-10-21 20:37 ` Stefan Kangas
2020-10-22 12:02 ` Lars Ingebrigtsen
2022-04-10 15:13 ` Lars Ingebrigtsen
2 siblings, 1 reply; 8+ messages in thread
From: Stefan Kangas @ 2020-10-21 20:37 UTC (permalink / raw)
To: Lars Ingebrigtsen, 44120
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
2020-10-21 20:37 ` Stefan Kangas
@ 2020-10-22 12:02 ` Lars Ingebrigtsen
0 siblings, 0 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-22 12:02 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 44120
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#44120: 28.0.50; Animated GIFs sometimes leave "trails"
2020-10-21 19:17 bug#44120: 28.0.50; Animated GIFs sometimes leave "trails" Lars Ingebrigtsen
2020-10-21 20:08 ` Alan Third
2020-10-21 20:37 ` Stefan Kangas
@ 2022-04-10 15:13 ` Lars Ingebrigtsen
2 siblings, 0 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-10 15:13 UTC (permalink / raw)
To: 44120
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-04-10 15:13 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-10-21 19:17 bug#44120: 28.0.50; Animated GIFs sometimes leave "trails" Lars Ingebrigtsen
2020-10-21 20:08 ` Alan Third
2020-10-22 12:01 ` Lars Ingebrigtsen
2020-10-22 12:14 ` Alan Third
2020-10-22 12:54 ` Eli Zaretskii
2020-10-21 20:37 ` Stefan Kangas
2020-10-22 12:02 ` Lars Ingebrigtsen
2022-04-10 15:13 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).