After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 467446 - Internal Image Viewer Truncates Image
Internal Image Viewer Truncates Image
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
pre-1.0 betas
Other All
: Normal normal
: 0.133
Assigned To: Charles Kerr
Pan QA Team
Depends on:
Blocks:
 
 
Reported: 2007-08-16 20:44 UTC by Aaron Von Gauss
Modified: 2008-07-08 04:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Unified Diff (3.52 KB, patch)
2007-08-16 20:56 UTC, Aaron Von Gauss
committed Details | Review
Complete File w/ Change (56.42 KB, text/x-c++src)
2007-08-16 20:57 UTC, Aaron Von Gauss
  Details

Description Aaron Von Gauss 2007-08-16 20:44:38 UTC
Please describe the problem:
With messages that contain inline images (such as image/jpeg), depending on the size of the image, sometimes the rendering of the image is truncated.  If the attachments are saved, the image is saved correctly, it is only related to the internal rendering.  This has always been an intermittent problem for me, but after recently trying the Kubuntu Gutsy and openSuse 10.3 betas with the newer GTK builds, it is happening on almost every message with a relatively large image attachment (250K+).

Steps to reproduce:
See problem description.

Actual results:
The image is shown truncated, with the remaining image being either black or contents of a previously viewed image.

Expected results:


Does this happen every time?


Other information:
Comment 1 Aaron Von Gauss 2007-08-16 20:55:34 UTC
Tracking down the issue, the underlying problem seems to be in the GTK pixbuf library and/or the jpeg image loader rather than Pan itself.  However, by modifying the get_pixbuf_from_gmime_part method in gui/body-pane.cc the issue can be avoided and so I am submitting a patch that from my testing appears to work well.  The crux of the change is rather than submitting the image data in one large chunk to the pixbuf loader, I am submitting it in smaller pieces similar to how the gdk_pixbuf_new_from_file method does which does not exhibit the problem.  The gdk_pixbuf_new_from_file method uses 1K chunks, which seems low in my opinion, the patch uses 8K chunks and appears to work well but could possibly be increased.  

Submitting the data as one large chunk did not create an error condition, but the result from the gdk_pixbuf_loader_write method was false indicating it did not accept all of the data.  A check was added to see if this happens in the future and adds a message to the event log and also the gdk_pixbuf_loader_get_pixbuf call was moved after the gdk_pixbuf_loader_close method to ensure that all data was processed first.

I'm attaching a unified diff and the resulting file.
Comment 2 Aaron Von Gauss 2007-08-16 20:56:51 UTC
Created attachment 93813 [details] [review]
Unified Diff
Comment 3 Aaron Von Gauss 2007-08-16 20:57:50 UTC
Created attachment 93814 [details]
Complete File w/ Change
Comment 4 Wade Menard 2007-08-24 04:35:06 UTC
Than you Aaron, I was seeing this problem in Ubuntu Gutsy as well and your patch works great.
Comment 5 Kevin D. Knerr, Sr. 2007-10-23 05:16:41 UTC
Ditto Aaron. I just upgraded to Gutsy and experienced the same problem--but I couldn't figure out what threshold was being violated because some images would load completely--although the vast majority would not.

Your patch worked beautifully on posts that did not load correctly on a freshly compiled pan-0.132. Muchas gracias!
Comment 6 walt 2007-12-05 15:01:54 UTC
The real fix for the pixbuf bug can be found in Bug 494667.
Comment 7 Charles Kerr 2008-07-08 04:33:52 UTC
fixed in trunk.  thanks for the patch. :)