Re: GdkPixbufAnimation

[Helmethead <hoshem mel comcen com au>]

On Fri, Apr 27, 2001 at 01:59:44AM -0400, jrb redhat com wrote:
> Helmethead <hoshem mel comcen com au> writes:
> 
> > While on the subject, you should try using the GdkPixbufLoader. I
> > haven't been able to get my head very well around the problems and
> > come up with a solution..
> > 
> > I vaguely remember some things:
> > - Biggest problem is that area_prepared doesn't pass in the new pixbuf
> > as documented, making the api unusable
> 
> It seems to work in the test suite.  Which loader (file type) isn't
> passing in a new pixbuf as documented?  Can you file a bug?

  void (*area_prepared)   (GdkPixbufLoader *loader);
there should be a GdkPixbuf *pixbuf argument too, according to the docs and if one wants the api to work at all for animations :)

> > - The api is awkward and crappy to implement. It seems designed for
> > applications that don't know whether they want a pixbuf or an
> > animation, which is a bit silly.
> 
> This is indeed what it's written for.  If you are opening an unknown
> file (like a web-browser might do) and are just getting a stream of
> bytes, you may not know until you have the second frame that you are
> getting an animation (as opposed to a static image.)  Indeed, we might
> make the generalization that all images are animations; some just have
> one frame.

This generalization is what I'm talking about, I think an app should be able to ask the loader for a pixbuf or ask it for an animation, not include code to deal with both on the basis of whether it receives the frame_done signal or not. That just seems ugly and potentially difficult to implement to me.

> > - It requires that the first frame of an animation be used as the
> > "static image" if that's what the app wants. Maybe this is what you
> > want though, I don't know.
> 
> It's up to you.  The loader just loads all the frames up.  I'm not sure
> what else it should do.

I'll copy what I wrote to Havoc :)
I rewrote the gif decoder as a little exercise, and at first, if the app asked for a pixbuf, I tried to return the first frame painted on top of the GIF "logical screen area", which is set to the background colour. There were problems with doing this, so I had to just return the same pixbuf I would return in the first GdkPixbufFrame. Basically, if the first frame in a GIF file does not fill the entire logical screen area, the current model of loader can't render it according to spec.

> > The loader api also depends on the GtkPixbufFrame style of doing
> > things, if you want to abolish it you need to rework the loader I
> > think.
> 
> There are definately issues with the GdkPixbufFrame, but I don't think
> the fundamental design is flawed -- just some of the details.
> 
> Thanks for the feedback,
> -Jonathan