The GIF loader used to be completely broken; unfortunately the API was
also broken, it wasn't possible to correctly display an animation
using it even after the loader was fixed.

The CVS version of GTK has a new API for animation and lots of fixes
to the loader. For me your penguin image works fine and the butterfly
image has an odd white background that flashes (I'm testing with
testanimation). I'm leaving the bug open to fix the funny white
background on the butterfly.

I don't think it's possible to fix the stable version of gdk-pixbuf,
unfortunately, since the API is incorrect.

If you could leave the butterfly image online until this bug is closed
or attach the GIF to this bug, would appreciate it a lot.

Thanks!

Created attachment 598 [details]
Animated butterfly

I'm not sure about the reliability of the URL, so I'll attach it.

I ran gtk+/demos/testanimation on the butterfly and the only thing
I noticed was that the first frame get a solid white background instead of a transparent one. The attached one-liner fixes this.

 

Created attachment 943 [details] [review]
the patch

I always get alpha confused; I thought 255 was opaque? I'm sure I'm
misunderstanding the code.

If we make this change there's an equivalent place later in the code
that should also be changed (search for bg_transparent).

Patch looks wrong to me too, without deep understanding
of the code ... 255 is definitely opaque, not transparent.

But the patch definitively fixed the problem of the first frame of 
the butterfly animation loosing its transparent background. Maybe
the real bug is somewhere else, I'll investigate further. 

Ok, the butterfly problem also goes away if I use 
composite_line_22_4a4 instead of composite_line_22_4a4_mmx_stub
in pixops_composite. So my previous patch is indeed wrong, instead
there seems to be a problem in the assembler code which I can't 
decipher...

The function is called with bg_transparent == FALSE, and the
pixbuf that is rendered has all 255 for alpha; it's some
problem with the GIF loader.

I don't expect we'll have time to look at this before 2.0.0

"Compressed Image Formats", by John Miano is supposed to 
contain useful information about the GIF format.

Here is a link to the gif89 spec:

http://www.cica.indiana.edu/graphics/image_specs/gif.89.format.txt

I have looked a bit deeper in the butterfly.gif and the result is
that it has background_index == 0 != gif89.transparent == 29. 

Thus gdk_pixbuf_gif_anim_frame_composite() may be formally correct
in using the nontransparent background color (which is white) for
filling the pixmap onto which to composite the frames.
But other tools seem to handle this differently. 
Maybe a better heuristic would be to fill the pixbuf with transparent
background if the first frame contains transparent pixels (which
is the case for butterfly.gif)

The GIF "spec" differs a bit from what all apps conventionally do with
GIFs, in my experience. So don't take the spec too seriously.

I know I spent a long time figuring out the background issue in the
past, and like a moron I neither wrote down what I discovered
nor saved any test images, unless there are comments in io-gif.c. 
:-(

I have studied gifsicle ( http://www.lcdf.org/gifsicle/ ) 
in some detail now, and it also takes the approach that 
the background is irrelevant if the first frame contains 
transparency: Trying to change the background pixel of butterfly.gif
to something else yields:

gifsicle butterfly.gif --background 29 > butterfly2.gif
gifsicle: warning: irrelevant background color
gifsicle: (The background will appear transparent because
gifsicle: the first image contains transparency.) 

And the companion gifview program indeed displays butterfly.gif
with a transparent first frame. 

Btw. the function in gifsicle for determining the background pixel
contains the following comment:

  /* This code is SUCH a PAIN in the PATOOTIE!! */

      

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

Moving non-critical or hard to fix bugs to 2.0.2

Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.

Can we figure out a patch for this?

http://lxr.mozilla.org/mozilla/source/modules/libpr0n/decoders/gif/imgContainerGIF.cpp

is the Mozilla source code ... it seems on quick inspection to 
_always_ clear the initial frame and "disposed" areas with
transparent pixels, no matter whether the frame has transparency
or not. But I don't really understand the code very well.

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

Created attachment 14062 [details]
another gif

Attached .gif rendered fine with

Mozilla
GIMP
Internet Explorer
ACDSee

but wrong with GdkPixbuf. Background is black instead of being
transparent.

Here is a patch which does as you say Mozilla does: Always fill with
transparent initially. This inded seems to fix the problematic gifs.

Created attachment 14111 [details] [review]
patch

Patch works for me -- everything is fine! Thanks Matthias

Committed to both branches.

The URL field has been removed from bugzilla.gnome.org. This URL was in the old URL field, and is being added as a comment so that the data is not lost. Please email bugmaster@gnome.org if you have any questions.

URL: 
http://www.cs.ucsb.edu/~warmen/pixbuf.html