78114 - Mozilla merges background chunk of first frame in transparent animated gif

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect, P1)

Description

[Mike Young]

When viewing the image at the URL, Mozilla displays the background color of the
GIF for the first frame, even though it is transparent. At the second frame, the
background color disappears and stays gone through every subsequent loop. If
this bug is confirmed, it needs to go as a blocker to bug 66967

Steps to Reproduce:
1. Change your default background color to something dark... like black.
2. Go to the URL above. or
http://www.floralconceptsintl.com/images/pagelayout/A01.gif

Expected results
The first frame of the image (which lasts about 8 seconds) is a leaf on a
transparent background.

Actual Results
The first frame of the image is a light yellow (the background chunk of the GIF)
adn then the image goes transparent after the first frame (8 sec).

Comment 1

[Igor Furlan]

WORKSFORME OK 

system:
Mozilla/4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
BuildID:    2001032614

Comment 2

[doctor__j]

2 additional testcase for your viewing pleasure.

Debug menu -> Viewer Demos -> #2 Images
Debug menu -> Viewer Demos -> #7 Scaled Anim Image

Look at the little pair of eyeballs. White background at first, then black
background for the rest of the cycles.

You must close the browser (all Moz breowsers, not just one browser window) and
load the page again in order to reproduce the bug.

Reproduced the bug on Win98 using Win32 build 2001042820.

Comment 3

[Stuart Parmenter]

saari, i know we know about this one.. but wasn't sure if you already had a bug
on it or not.

Comment 4

[Sean Richardson]

Confirmed with 2001-05-05-15-trunk on WinNT. The background colour appears,
until the second frame is drawn, where it goes black...see next para for that.

doctor__j's 2001-04-29 observation is another sighting of bug 77914, 
"Transparent animating GIFs have black background", distinct from this bug.

Comment 5

[saari (gone)]

Windows specific

Comment 6

[Jacek Piskozub]

*** Bug 80298 has been marked as a duplicate of this bug. ***

Comment 7

[Jacek Piskozub]

*** Bug 80995 has been marked as a duplicate of this bug. ***

Comment 8

[Jacek Piskozub]

I believe a fix for this bug should also fix bug 77914 (Transparent animating
GIFs have black background). In both cases it is the repainting which kills the
background.

Comment 9

[Jacek Piskozub]

Actually This bug and the two I duped to it (and then retracted) have different
symptoms but seem to be manifestations of the same or very similar problems.
However, the symptoms are different enough to keep them separate.

Comment 10

[Rafael Ebron (:rebron)]

Also occurs at http://business.netscape.com/business/

Comment 11

[Jacek Piskozub]

This one concerns an animated GIF, so it is a dup of bug 77914. Otherwise, I
would send it to bug 83726

*** This bug has been marked as a duplicate of 77914 ***

Comment 12

[Mike Young]

This is NOT a duplicate of that bug. Lets explain the problem in question a 
little better. Transparent animated Gif files are all showing black as their 
background, this is true... but that is a different bug. During the 1.5days 
where that bug was fixed prior to its regression, This bug still existed. The 
problem is that every transparent gif has a color defind as a "background". In 
the case of this bug, this color is actually displayed instead of transparency 
for the first frame of an animated gif. 

So in other words, for that one day when the black background was fixed, the 
gifs all had a background chunk displayed (in my case a light yellow) and the 
subsequent frames (including subsequent loops) all had proper transparency. 

So once again, this bug is not a dup of bug 77914. It is entirely different. 

Also adding as blocker to 66967 and top100

Comment 13

[Francis Chin]

Confirming Mike Young's explanation: Win98 build 2001061720 has the fix for bug
77914 (black background problem) but shows the background chunk on the first frame.

Comment 14

[doctor__j]

http://www.floralconceptsintl.com/images/pagelayout/A01.gif looks OK using Win32
build 2001061807.  Probably fixed by solving the bug 77914.

Comment 15

[Christoph]

I've been seeing this forever
Now bug 77914 is a nice fix and does get rid of the black afterwards, but this
is different.  If you go to http://dsl.snet.net and look right under the top
left of the screen where the animated 'DSL HOME' gif is, the first time it loads
up you can see the rectangle outline of the gif.  Watch the top left of the
outline and you can see it leaves a white cut-out on the grey arch that's above
it.  The next time it animates, however, it is fully transparent and doesn't
show again until you reload the page.  This behavior I have seen for a long
time.  Still see this too on some messageboards with little animated similey
faces.  The first time they pop up (some) will have a white/yellowish backround,
but the next time they animate it becomes normal.

Comment 16

[Jacek Piskozub]

I confirm this bug is not bug 77914. I do it as I was the guy who tried to dup
it against 77914 in the first place ;-) 

To see it, you have to change the defauld background to something else than
white. In my case unchecking "Use system colors" was enough to see the white
backround of the first frame.

Comment 17

[doctor__j]

My apology...

Jacek Piskozub was right.  Changing background color to grey really did the job
of revealing the damn bug.  The white background seems to hide this bug from my
eye...  This is still not fixed...

Comment 18

[Mike Young]

Attachment: test image that is easier to see

Comment 19

[Mike Young]

I've created a test image that should demonstrate this problem much more
clearly. (And at the same time demonstrate how serious this bug is.) :-)

So long as you don't have red as your default background you will be able to see
this test clearly. (If you do have red as your default, you will probably go
blind very shortly and should seek help immediately.)

The image is two frames, both black text on a transparent background. The first
is 8 sec to exaggerate the problem (slightly but not by much... many banner ads
do this) and the second frame is 3 sec. THere should be NO red in the image at
all. (Red is the background chunk)

Moz will display it for the first frame and then never again. To view it again,
hit reload.

Comment 20

[Jacek Piskozub]

Mike: Can you explain why I (using 2001061809 on WindowsME):

a) do not see any red (neither on the first or second frame)
b) see the GIF change frames many fimes (not one as you claim).

At the same time I see the white backround oa the first frame of the floral
testcase...

Comment 21

[Mike Young]

I've been looking at the libpr0n code for Gif decoding, and I found an
interesting function that seems as if it might have something to do with this
bug. (My C++ experience is somewhat limited.) 

http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/decoders/gif/GIF2.cpp#691

here's a quote. 
 For the first images in the sequence clear the logical
 screen to the background color, unless the first image
 completely covers the logical screen, in which case
 it's unnecessary.  XXX - This can be optimized.

I don't know whether this is it, but I figured I'd try to get this bug rolling. :-)

Comment 22

[Luke Morey]

The attached test case has worked for me with 2001061720 & 2001061804 under
Win2000Pro+SP1.

I was still seeing Red :) with a build from a couple of days before (can't
remember which).

Comment 23

[Mike Young]

Jacek: Well, truth be told, I was downloading 2001061804 as I made that test
case. Unfortunately, I have a slow connection, and wasn't able to check what
happens with this newest build. I can safely say now however, that this bug has
morphed. We are no longer seeing the background chunk of the gif images. We are
however seeing ... something ...

The background chunk of the floral example is actually a light peach. The
background chunk of the "No Red" example is Red. (Oh and sorry, the image loops.
It has two frames 8 and 3 sec which loop to show that the "first frame" issue
doesn't appear the second time around.)

What we are seeing now is indeed some sort of background being applied to the
images, but a background different from the GIF-defined background chunk. To me
it almost appears semi-transparent like it is just a tint applied to the
background of the page. (I looked at the image on a patterned backgound and it
seemed like I could make out the pattern through the tint.) Whether this is just
my imagination I don't know. For me, I can still see the red test image's
background if I look at it without "system colors" in prefs. (That is really weird.)

I've updated the summery to reflect this morphing of the bug. I still think it
may be related to the background chunk and that piece of code I mentioned, but
its going to take me a little while before I figure out exactly what's happening.

Oh, and in my description of the testcase I say, "Moz will display *it* for the
first frame..." it should read "Moz will display *the Background Chunk* for the
first frame..." I think that might have been a little confusing. :-P

Comment 24

[Luke Morey]

Not your imagination.  The test case now gives me

 - a white image background when the page background is white
 - a peach image background when the page background is grey
 - a red image background when the page background is black
 - a semi-transparent peach image background when there's a background image on
the page

Comment 25

[Mike Young]

Attachment: Testcase with different backgrounds

Comment 26

[Luke Morey]

P.S The "use system colours" pref doesn't appear to affect behaviour at all.

The background chunk is just getting added to whatever background there is.

black + red = red
grey + red = peach
white + red = white
image + red = peachy image

<disclaimer>non-programmer</disclaimer>

Comment 27

[Mike Young]

Darn these midair collisions!!!! Yes you're right.

------------

What we're doing is merging the background chunk of the GIF with the background
directly below the image. This bug actually never changed. Since GIFs had black
backgrounds, they were all showing their *full* background chunks. On a white
page no GIF will ever display its background chunk. The testcase will help
explain...

With the red example,
black = 000000, red = FF0000, background of first frame = FF0000
Green = 00FF00, red = FF0000, background = FFFF00 (yellow)

the same goes all the way through. different shades of grey show different
amounts of the background until you get to whith which is FFFFFF so nothing
shows. With a patterned background I believe this is done for each pixel based
on whats below it, leading to the semitransparent effect.

It looks like it only happens if the background chunk is greater than the
background so white backgrounds etc won't be affected.

Changing summary again. Sorry about that...

Comment 28

[Jacek Piskozub]

OK. I see it now. The second testcase is much better. Actually I get red or pink
on the black and gray squares even with white background. No need to change the
default anymore.

Comment 29

[Chris McClelland]

Is the problem at www.tvguide.com caused by this bug? At that site the tvguide 
logo (upper left) has a white background for a few seconds (while the logo 
animation makes one full loop) until the background replaces it. Using build 
2001062104 on WinME.

Comment 30

[Aaron Kaluszka]

Wow, this looks a lot like bug 84980 for binary transparent PNGs.
check out this test case
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=39549
Are they related?

Comment 31

[Mike Young]

Yes the TVGuide example is a case of this bug. I'm realizing more and more that
this bug is much bigger than I originally thought. The reason that mozilla
displays the background for 1 full loop of that Gif is because nothing ever
overwrites the first frame. The day of the week is a smaller image played only
in the center of the image. In theory it never has to refresh the outer part of
the gif until it starts over. This means that the corruption of the first frame
lasts throughout the entire animation. BTW the background chunk of that image is
grey, for those of you testing on your own.

Also, I am inclined to believe that this bug and the PNG Binary transparency bug
are related very closely. Still Gif files are not affected however, which makes
me think that something somewhere is getting binary transparency right. This
also only affects the first frame drawn of a gif (And any remnants of it that
are still visible during the animation) and the fixes for the two bugs may be
very similar. But before any goes duplicating, these bugs are different enough
to warrant seperate reports. :-)

Comment 32

[Aaron Kaluszka]

mozilla0.9.2->mozilla0.9.3
nsbeta2->nsbeta1

Comment 33

[saari (gone)]

->0.9.4 P1

Comment 34

[Scott Tran (Wildcard)]

*** Bug 87841 has been marked as a duplicate of this bug. ***

Comment 35

[saari (gone)]

-> 0.9.5

Comment 36

[Stuart Parmenter]

*** Bug 104009 has been marked as a duplicate of this bug. ***

Comment 37

[Vincent Nicolas]

Attachment: Background of this animated gif is not handled well

Same problem on W2k (2001122106) and some others weirdness (see attachment)
(ok with IE or Irfanview)

Comment 38

[Stuart Parmenter]

over to nivedita

Comment 39

[Nivedita (gone)]

Attachment: patch file for making first frame in transparent animated gif as transparent

The reason why the background color was not transparent for first frame, in
case of transparent animated gifs, was because for the first frame, we were
filling the background of the frame with background color of the image. But for
the subsequent frame's which is handled in DoComposite method of imgContainer
class, we are filling it with zero's. Hence, from the second frame onwards we
do not see the background color of the image.

Calling FillWithColor with the color as zero rather than the background color.

Comment 40

[Stuart Parmenter]

Comment on attachment 67906 [details] [diff] [review]
patch file for making first frame in transparent animated gif as transparent

r=pavlov

Comment 41

[tor]

Comment on attachment 67906 [details] [diff] [review]
patch file for making first frame in transparent animated gif as transparent

sr=tor

Comment 42

[Stuart Parmenter]

checked in