Gif animation not displayed properly

RESOLVED WORKSFORME

Status

Core Graveyard
Image: Painting
RESOLVED WORKSFORME
12 years ago
8 years ago

People

(Reporter: Lloyd Wood, Assigned: Stuart Parmenter)

Tracking

1.8 Branch
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

12 years ago
A gif animation displays properly as an animated background image, with each frame replacing the next. However, as a foreground image, with or without an animated background image made from the same image, the animation shows each frame drawn over preceding frames until the animation loops.

The foreground image should replace each frame as is done when it's a background image.

Updated

12 years ago
Assignee: nobody → general
Component: General → GFX
Product: Firefox → Core
QA Contact: general → ian
Version: 1.5 Branch → 1.8 Branch

Updated

12 years ago
Assignee: general → pavlov
Component: GFX → Image: GFX
QA Contact: ian

Comment 1

12 years ago
Hrm, I'm not reproducing this.

You may want to ensure that your animated GIF was created properly. Animated GIFs has 3 options for specifying how animation frames are to be drawn. The first option is for the frame to be drawn over whatever was previously displayed. The second option is for everything previous to be erased and the current frame drawn on a fresh slate. The third option is for the animated GIF to say "I don't care what you do with this frame", and so it doesn't care which of the first two options are used.

I would guess that the animated GIF that you're testing has each frame set to either "cumulative" or "I don't care". The GIMP is a great tool for analyzing animated GIFs and creating new ones as test cases -- I would recommend that you check your test case image with GIMP or at least post it here so that someone else can check it for you.
(Reporter)

Comment 2

12 years ago
I reproduced this using Firefox 1.5.0.6, loading in the URL given in the URL field:
http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/bug-8.html
Firefox renders the gif differently depending on whether it's a background image or foreground.
I posted a test case. That's what the URL field is for!

Comment 3

12 years ago
Hey Lloyd, thanks for the quick response!

I'm sorry, I totally missed that URL field. I've now looked at what you've done, and you really did create an excellent test case -- sorry for coming down on you hard like that. I'm not associated with the Mozilla project in any way -- I was just browsing bugs related to animated GIFs before I submitted one of my own, and I found this one. I thought I was helpful with my previous post -- I don't think I was. Here's another shot at being helpful -- we'll see how this one goes:

I opened up your animated GIF with Gimp -- and for starters -- it's a somewhat malformed GIF. I'm really not sure what tool you used to create that GIF, but it had every frame to have a display time of 0 ms, and it had an unspecified frame disposal for every frame (which means "I don't care if you draw this frame cumulatively or with a replace method").

So essentially, the animated GIF is giving instructions to Firefox that basically says "I don't care how fast you play me, and I don't care how you draw me".

I re-saved your GIF animation giving a specified frame interval (100 ms) and a specified frame disposal method (replace rather than cumulative), and put that back in your test case. Firefox then handles it correctly. You can see that version of your test case here:
(I only corrected the top picture so that you could see how it compares to the bottom GIF)
http://www.rickherron.com/clint/bug_reports/bug-8.html


So it seems like Firefox has *a* correct implementation of dealing with unspecified aspects of animated GIFs. Whether or not it's technically the *best* implementation is another story. There are tons of cases in web-page "standards" where it's not clear how software should behave in unspecified situations like this one.

I'm not a guy who fixes or manages Mozilla bugs, but my guess is that this bug will either marked invalid with a WAD (working as designed), or that it will be downgraded to an enhancement where you're asking to have the default behavior of animated GIFs where the frame disposal method is unspecified be changed from cumulative to replacement.

Anyways, I hope I was more helpful with this second try.

Thanks for the bug report.

--clint
(Reporter)

Comment 4

12 years ago
Thanks for the hint!

I created these in ~1997 or so using GifCreator on Mac OS 7.5. Part of my confusion is that in the example url I gave, I used a transparent gif in the foreground but a different non-transparent gif in the background - mozilla/firefox appear to default to cumulative drawing when frame behaviour is not specified, which makes some sense, but the non-transparent gif has a bunch of frames overwriting each other completely, so the setting and default of cumulative behaviour doesn't matter for the non-transparent case. (My test case could have been better thought out.)

I've now uploaded a transparent and non-transparent case.
http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/bug-8a.html
http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/bug-8b.html
which, even though these old GIFCreator'd gifs don't specify behaviour, do more what you would expect.

The default of cumulative frames when behaviour is unspecified caused my confusion; fixed in GIMP.

I think we can mark this resolved...
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 5

12 years ago
No specific bug / patch referenced as the fix.

-> WORKSFORME
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

12 years ago
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → WORKSFORME

Updated

8 years ago
Component: Image: Painting → Image: Painting
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.