- From: Helmethead <hoshem mel comcen com au>
- To: jrb redhat com
- Cc: Havoc Pennington <hp redhat com>, gtk-devel-list gnome org, federico ximian com, lewing ximian com
- Subject: Re: GdkPixbufAnimation
- Date: Fri, 27 Apr 2001 16:38:28 +1000
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,
] [Thread Prev