Re: gdk_pixbuf_loader_write and short files
- From: "Matthias Clasen" <matthiasc poet de>
- To: <gtk-devel-list gnome org>
- Subject: Re: gdk_pixbuf_loader_write and short files
- Date: Mon, 27 Aug 2001 10:43:38 +0200
Havoc, looking at the code of gdk_pixbuf_loader_close, I found that
it already does as you have outlined below. So it turns out that the
problems I have seen are really just bugs in gtk-pixbuf/test-loader.c
and demos/testpixbuf.c which don't use the loader API as documented.
Here is a patch to fix the two. For testpixbuf I have simply removed the
"After progressive load" window, which seems to be relatively pointless
as it will always show exactly the same as the "Progressive" window.
For test-loader, I have made it notice errors at close time so that you can
now have tests on short files fail (before this change, good loaders would
fail on invalid short files, but test-loader would ignore the error coming
out
at close time.)
OK to commit ?
----- Original Message -----
From: "Havoc Pennington" <hp redhat com>
To: "Matthias Clasen" <matthiasc poet de>
Cc: <gtk-devel-list gnome org>
Sent: Friday, August 24, 2001 5:56 PM
Subject: Re: gdk_pixbuf_loader_write and short files
>
> "Matthias Clasen" <matthiasc poet de> writes:
> > I don't know. Can we ? But it won't help for testpixbuf.c, since it
tries to
> > get
> > the pixbuf from the loader before calling close (see update_timeout).
> > Is that allowed behaviour ?
> >
>
> No, the pixbuf doesn't exist until you get the area_prepared signal.
>
> I would think that on close, we shove the remaining data we have into
> the loader and process it, before emitting "close" (This may mean
> emitting area_prepared out of gdk_pixbuf_loader_close(), but that
> should be OK)
>
> Havoc
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]