139176 - Animated gif with no global palette puts garbage in transparent area on first loop

Status: RESOLVED FIXED

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

Description

[Koike Kazuhiko]

Transparent animated gif without loop parameter doesn't become transparent.

Animated gif without loop parameter:
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=726

Animated gif with loop parameter:
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=727

Comment 1

[HARUNAGA Hirotoshi]

This is Windows specific bug.
There is no problem on FreeBSD and Mac OS 9.
Since the transparent color of these GIFs is #FFFFFF,
please see on dark background color.

Comment 2

[R.K.Aa.]

Looks like a dup of bug 22607

Comment 3

[ArronM (:paper)]

Attachment: Clear compositing frame even if there's no bg color set.

The problem was we were only clearing the composite frame (before drawing to
it) if the gif had a background color set. 
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=726 does not have a
global palette, and thus does not have a background color (since bgcolor is
chosen from the global palette)

This patch clears the composite frame before drawing on it no matter what.

Comment 4

[ArronM (:paper)]

Changing Summary from
"Transparent animated gif without loop parameter doesn't become transparent"
to
"Animated gif with no global palette puts garbage in transparent area on first loop"

What happened when you turned on the loop is that in the first loop the image
was garbage, but on the second loop, it fixed itself.  The time between the two
loops was set to a minumum so you have to be quick to catch it.

Comment 5

[HARUNAGA Hirotoshi]

Attachment: Another testcase with loop=1

This has a global color palette(table), and background color is black,
transparent color is white.

In the first loop, background of the image is broken, and in the second loop,
it's ok.

I think this problem is
"Animated GIF with background-color different from transparent-color puts
garbage in transparent area on first loop".

Comment 6

[ArronM (:paper)]

Attachment 82458 [details], WFM.  Win2k Build 2002050807

Are you getting the same type of garbage as with
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=726 ?  Could you
provide a screenshot?

Comment 7

[HARUNAGA Hirotoshi]

Attachment 82458 [details] is OK on Windows NT, but on Win98SE(2002051004), there is
similar garbage in the first loop.
This may be another problem.

Comment 8

[ArronM (:paper)]

Confirming Attachment 82458 [details] displays garbage on Windows 98 (non SE) Build
20020511xx and RC2.  

I'll look into it.

Comment 9

[ArronM (:paper)]

I've created Bug 143830 to deal with Attachment 82458 [details].  It's a seperate issue
from this one.  (Fixing one won't fix the other).

This bug is displayed on all Windows platforms as far as I know.

Comment 10

[tor]

Comment on attachment 82436 [details] [diff] [review]
Clear compositing frame even if there's no bg color set.

sr=tor

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 82436 [details] [diff] [review]
Clear compositing frame even if there's no bg color set.

looks correct. r=biesi

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

fixed

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

really marking fixed this time

Comment 14

[HARUNAGA Hirotoshi]

Using 2002081706-1.0branch/Win98SE,
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=726 causes garbage.
The patch isn't checked in 1.0 branch?

Comment 15

[HARUNAGA Hirotoshi]

http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/src/imgContainer.cpp
shows as follows:
---
169       if (NS_SUCCEEDED(firstFrame->GetBackgroundColor(&backgroundColor))) {
170         mCompositingFrame->SetBackgroundColor(backgroundColor);
171       }
172 
173       PRInt32 x;

179       firstFrame->GetWidth(&width);
180       firstFrame->GetHeight(&height);
181 
182       BlackenFrame(mCompositingFrame);
183       firstFrame->DrawTo(mCompositingFrame, x, y, width, height);
184       ZeroMask(mCompositingFrame);
185       BuildCompositeMask(mCompositingFrame, firstFrame);   
---

http://lxr.mozilla.org/mozilla1.0/source/modules/libpr0n/src/imgContainer.cpp
shows as follows:
---
169       if (NS_SUCCEEDED(firstFrame->GetBackgroundColor(&backgroundColor))) {
170         mCompositingFrame->SetBackgroundColor(backgroundColor);
171         BlackenFrame(mCompositingFrame);
172       }
173 
174       PRInt32 x;

180       firstFrame->GetWidth(&width);
181       firstFrame->GetHeight(&height);
182 
183       firstFrame->DrawTo(mCompositingFrame, x, y, width, height);
184       ZeroMask(mCompositingFrame);
185       BuildCompositeMask(mCompositingFrame, firstFrame);   
---

I think this patch isn't checked in 1.0 branch.