Re: [gDesklets] ADL JPEG Handing different in Gutsy than Fiesy... Was Re: Gdesklets in Gutsy broken?
- From: Sean <sean mailcan com>
- To: gdesklets-list <gdesklets-list gnome org>
- Subject: Re: [gDesklets] ADL JPEG Handing different in Gutsy than Fiesy... Was Re: Gdesklets in Gutsy broken?
- Date: Tue, 27 Nov 2007 16:21:44 -0700
On Tue, 2007-11-20 at 15:17 -0700, Sean wrote:
> So I found a way to replicate the issue on the SlideShow desklet, but
> not sure of the solution as of yet. There is a behavior change from how
> python handles jpeg images from Gutsy from how it handled it in Feisty.
> I thought I tracked it down to the pixbuf/libjpeg62 libraries, however
> downgrading to the feisty version of libjpeg62 did not correct the
> issue.
>
> Basically, before in Feisty I could set the image URI in ADL to any size
> jpeg file. However now in Gutsy there appears to be a limit to how large
> (in filesize, not resolution) the image can be. If I set the image to
> something large now ( > ~150k ) gdesklets bombs with a:
>
> Failed to set URI /home/shizeon/Pictures/Picture1.jpg for key uri.
>
> However smaller sized images load fine. I'm guessing most desklets do
> not load 'big' images, so this probably doesn't effect many people. I do
> see the same behavior in that older ShadowImage desklet too when you
> drag a > 100k image on to it.
>
> Neal wasn't effected by this since the pictureframe desklet resizes the
> images locally before displaying.
>
> Anyhow, do any of the gdesklet core developers know what could have
> caused this behavior change? I'm guessing that it is external to
> gdesklets, but without any hardcore pixbuf/python/gtk skills it is tough
> to say for me at the moment. Maybe see what could cause the 'Failed to
> set' message to occur? The link below is to a simple desklet display
> that shows the problem in action.
>
> http://sean.mailcan.com/brokenjpeg.tar.gz
>
> Many thanks!
> - Sean
So I've chugged along a little more on this. Decided to get the
gdesklets source and try to trace the error. I'm getting towards the
end of my debugging skills, so I wanted to post my findings.
The actaul error is caught in tiling.c.
118:
if (!gdk_pixbuf_loader_close (loader, &error)) {
PyErr_SetString(PyExc_RuntimeError, "Couldn't read image" );
g_error_free (error);
return NULL;
}
The actual error message that is returned by error->message from the
gdk_pixbuf_loader_close is:
"Error interpreting JPEG image file (Application transferred too few
scanlines)"
I confirmed that the data variable getting loaded in TargetImage.py is
correct and it is also correct when getting passed in to tiling.c
So, after determining a pixbuf issue and since it was only jpegs with
the problem I found that the following library changed from feisty to
gutsy
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so
This comes from the libgtk2.0-0 package. I grabbed the feisty package
and extracted just the libpixbufloader-jpeg.so file and replaced the
gutsy version. Low and behold the problem goes away..
Anyway, so it appears isolated outside of gdesklets and inside this
library somehow. Not sure exactly where to proceed with getting that
corrected though. Would seem to effect any desklet that needs to load
an image (and scale it internally) that is larger than ~150K until this
is fixed upstream.
- Sean
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]